Serverstats - Aktuelle Infos zu den Servern

Ich glaube davon gibt es einige User ;), kannst Du das mit den faulen IP´s netterweise kurz mal erläutern?

Ich bin so frei und übernehme.

Faule IPs sind IP Adressen die dir als Nutzer zugewiesen werden, die aber nach außen hin nicht funktionieren. Das heist du hast eine funktionierende Verbindung zum PP Server, aber trotzdem keinen Zugriff aufs Internet. Und davon gibts leider zahlreiche, oft muss man sich 2-3x manuell neu verbinden bis man Internet hat um beim nächsten PC Start das ganze zu wiederholen.

War der Hauptgrund wieso ich gewechselt bin und jetzt dem sinkenden Schiff nachtrauere.
 
Danke für die Erklärung.

@PP Christian : Ist es wirklich so schwer, zwecks Bestandsaufnahme die Server selber durchzutesten, insbesodere neue Server, bevor diese dem Kunden zur Verfügung gestellt werden?

Als nächstes die Konfigurationen der fehlerfreien Server mit denen zu vergleichen, die faule IPs haben, um dann final das Problem zu lösen?

Wenn dein Techniker das nicht kann, musst du dir einen kompetenten Mann suchen.
 
Ich bin so frei und übernehme.

Faule IPs sind IP Adressen die dir als Nutzer zugewiesen werden, die aber nach außen hin nicht funktionieren. Das heist du hast eine funktionierende Verbindung zum PP Server, aber trotzdem keinen Zugriff aufs Internet. Und davon gibts leider zahlreiche, oft muss man sich 2-3x manuell neu verbinden bis man Internet hat um beim nächsten PC Start das ganze zu wiederholen.

War der Hauptgrund wieso ich gewechselt bin und jetzt dem sinkenden Schiff nachtrauere.
Nachdem man das hier gelesen hat, stellt man sich als Feinschmecker doch die Frage aller Fragen… was wenn das servierte Filet in den letzten Jahren nicht Kobe war, sondern billigstes Tofu?

Der VPN Manager für Windows ist jedenfalls auch ein Armutszeugnis und jeder Entwickler mit 2 Jahren Erfahrung, hätte so ein Bugfest nicht zugelassen.
 
Wieso habt ihr so viele "faule IPs" und ich sehe das nicht?
Bei mir läuft alle fünf Minuten für jeden Tunnel ein Test, ob die Verbindung zu google und zur pp-Seite noch klappt.
Ist das nicht der Fall, wird der Tunnel auf "FAIL" gesetzt und neu gestartet.
Ich sehe gelegentlich (1-2 x in der Woche), daß z.B. Düsseldorf auf "FAIL" geht und neu gestartet werden muß, aber i.a. läuft das alles zufriedenstelled. Diese gelegentlichen Ausfälle gibt es eigentlich schon seit Jahren und die sind damit nicht neu...

Welche Verbindungen machen Probleme? Open-Vpn? Stimmt vielleicht die vpn.conf nicht?

Ich lese hier immer was von ssh, was mit vpn natürlich nichts zu tun hat. Vielleicht klappt da das port-mapping nicht immer?
View attachment status.png
 
Wieso habt ihr so viele "faule IPs" und ich sehe das nicht?
Bei mir läuft alle fünf Minuten für jeden Tunnel ein Test, ob die Verbindung zu google und zur pp-Seite noch klappt.
Ist das nicht der Fall, wird der Tunnel auf "FAIL" gesetzt und neu gestartet.
Weil die meisten keine IT Prof's sind und so eine special Konfiguration wie du verwenden.
Fakt ist das die da sind.
Fakt ist das die gefixt werden müssen.
 
Oder PP bekommt vom Rechenzentrum Mengenrabatt, wenn sie die faulen IPs übernehmen.

Spaß beiseite, könnte vielleicht noch jemand kurz erklären, wieso faule IPs überhaupt entstehen? So ein Problem hatte ich in den letzten 15 Jahren noch bei keinem anderen VPN-Anbieter und ich war schon bei einigen, inklusive einigen eher fragwürdigen...
 
Es ist eigentlich klar, daß sowas vom server-seitigen routing bzw. von der server-seitigen Firewall herrühren muß.
Die vpn-Verbindung klappt, und man kann mit Sicherheit die 10.x.y.1 anpingen. Nur geht es von dort aus nicht mehr weiter...

Die Frage ist, unter welchen Bedingungen tritt das auf? Will sicher gehen, daß es kein PEBCAK ist
 
Warrant Canary ✅
Moskau ✅

Hongkong disfunktional?

Our server locations:
Australia Austria Canada China Czech Republic Denmark France Germany Great Britain Iceland Italy Japan Latvia Netherlands Norway Poland Russia Serbia Singapore Spain Sweden Switzerland United States of America

Perfect Privacy VPN is offering you VPN-servers in 21 countries

Denmark und Iceland Fähnchen aus der Liste nehmen?
 
Ich kann das hier auch nicht nachstellen und ich nutze den VPN-Manager.

Ich nutze Terminal, aber ist das überhaupt wichtig?
Bitte kein Gaslighting, das hängt mir zum Hals raus.

Einige Server verbinden beim ersten Mal korrekt und andere eben nicht.
Also müssen einige Server besser bzw. richtig konfiguriert werden.
Es ist Aufgabe dieser Firma, die Server mit faulen IPs ausfindig zu machen und einwandfrei funktionierende Server bereitzustellen.

Solange der Wille dazu fehlt, wird sich die Kundenanzahl weiter verringern, so einfach ist das.
 
Ich würde mindestens mal nachgucken, was die Logs sagen. Laufen die Verbindungsversuche in ein Time-out, kommt ein connection refused, oder stimmt was mit certs/passwort nicht.
Einmal gestartet versucht openvpn bei mir selbsttätig einen Verbindungsaufbau, bis es klappt; da muß ich nichts händisch versuchen.
Wenn klappt steht am Ende des Logs: Initialization Sequence Completed
 
Ich würde mindestens mal nachgucken, was die Logs sagen. Laufen die Verbindungsversuche in ein Time-out, kommt ein connection refused, oder stimmt was mit certs/passwort nicht.
Einmal gestartet versucht openvpn bei mir selbsttätig einen Verbindungsaufbau, bis es klappt; da muß ich nichts händisch versuchen.
Wenn klappt steht am Ende des Logs: Initialization Sequence Completed

Schwurbelbus hat das doch schon erklärt:
Faule IPs sind IP Adressen die dir als Nutzer zugewiesen werden, die aber nach außen hin nicht funktionieren. Das heist du hast eine funktionierende Verbindung zum PP Server, aber trotzdem keinen Zugriff aufs Internet. Und davon gibts leider zahlreiche, oft muss man sich 2-3x manuell neu verbinden bis man Internet hat um beim nächsten PC Start das ganze zu wiederholen.

Wie soll was in den Logs stehen, wenn die Verbindung zu PP erfolgreich aufgebaut wird, die Server aber dann nicht ins Internet weitereichen.
 
Honk sagte "Einige Server verbinden beim ersten Mal korrekt und andere eben nicht."
Wenn die nicht verbinden, lohnt sich ein Blick. Außerdem muß zumindest die Gegenstelle anpingbar sein.
Geht das nicht, ist schon die Verbindung faul - dann müßte man in der Tat von Hand (oder automatisch) neu starten.
Sowas hatte ich auch schon; das sind dann aber keine "faulen IPs"
 
Die Server verbinden schon, aber
Faule IPs sind IP Adressen die dir als Nutzer zugewiesen werden, die aber nach außen hin nicht funktionieren. Das heist du hast eine funktionierende Verbindung zum PP Server, aber trotzdem keinen Zugriff aufs Internet. Und davon gibts leider zahlreiche, oft muss man sich 2-3x manuell neu verbinden bis man Internet hat um beim nächsten PC Start das ganze zu wiederholen.

Soeben bei London1 (hat außerdem eine neue IP) und Österreich festgestellt.
 
Die Server verbinden schon, aber


Soeben bei London1 (hat außerdem eine neue IP) und Österreich festgestellt.
und hast Du mal probiert, ob bei den Problemfällen ein ping 10.x.y.1 funktioniert? Die ping Zeit ist je nach Ziel auch entsprechend hoch.
 
Beide Hops funktionieren gerade.

Code:
$ ping -c 1 10.0.242.1 # VPN Gateway London1 Hop1
PING 10.0.242.1 (10.0.242.1) 56(84) bytes of data.
From 10.5.224.32 icmp_seq=1 Destination Port Unreachable
--- 10.0.242.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

$ ping -c 1 10.5.224.1 # VPN Gateway Austria Hop2
PING 10.5.224.1 (10.5.224.1) 56(84) bytes of data.
From 10.5.224.32 icmp_seq=1 Destination Port Unreachable
--- 10.5.224.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Oder soll ich das probieren, wenn ich gerade eine faule IP erwischt habe?
 
Setzt Du die auf dem System ab, wo der vpn tunnel gestartet wird?
Bei mir sieht das so aus (Interface ist nicht tun0 sondern AMS2):
Code:
ip addr show dev AMS2
589: AMS2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none 
    inet 10.5.210.84/24 scope global AMS2
...
ping 10.5.210.84
PING 10.5.210.84 (10.5.210.84) 56(84) bytes of data.
64 bytes from 10.5.210.84: icmp_seq=1 ttl=64 time=0.044 ms
64 bytes from 10.5.210.84: icmp_seq=2 ttl=64 time=0.029 ms
...
PING 10.5.210.1 (10.5.210.1) 56(84) bytes of data.
64 bytes from 10.5.210.1: icmp_seq=2 ttl=64 time=17.3 ms
64 bytes from 10.5.210.1: icmp_seq=3 ttl=64 time=292 ms
...
 
Back
Top