Neuer Privacy Server in Reykjavik, Island verfügbar

Perfect Privacy

Perfect Privacy

Administrator
Wir haben soeben einen neuen Privacy Server zu unserem Serverpark hinzugefügt. Der Server steht in Reykjavik, Island und verfügt über eine 100mpbs Anbindung (unmetered), und 20 IP Adressen. Die ggf. benötigten Konfigurationsdateien findet ihr auf der Download Seite im Mitgliederbereich.

Mit freundlichen Grüssen,

Euer PP-Team
 
An manchen Tagen funktioniert das Multihopping nicht richtig.
Beide Einwahlen funktionieren, IP-Test ok und nach 2 Minuten nippelt Hop2 ab.
Dabei ist Hop2 völlig ok, sobald man für Hop1 nicht Island, sondern einen anderen Server wählt.
Diese Phänomen tritt sporadisch auf und wenn , dann ist mit Hop1 Island etwas nicht in Ordnung während einer gewissen Zeitspanne.

Gibt's dafür eine Erklärung?
 
Heute mal wieder Verbindungsabbruch kurz nach Rechnerstart auf Hop2, wenn Island Hop1 ist:

Code: 
Mon Jan 20 08:51:03 2020 us=934687 Initialization Sequence Completed
Mon Jan 20 08:54:46 2020 us=965607 [Server_prague.perfect-privacy.com] Inactivity timeout (--ping-restart), restarting
Mon Jan 20 08:54:46 2020 us=965914 TCP/UDP: Closing socket
Mon Jan 20 08:54:46 2020 us=965992 SIGUSR1[soft,ping-restart] received, process restarting
Mon Jan 20 08:54:46 2020 us=966096 Restart pause, 5 second(s)
Mon Jan 20 08:54:51 2020 us=966247 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mon Jan 20 08:54:51 2020 us=966327 Re-using SSL/TLS context
Mon Jan 20 08:54:51 2020 us=966367 LZO compression initialized
Mon Jan 20 08:54:51 2020 us=966474 Control Channel MTU parms [ L:1604 D:1138 EF:112 EB:0 ET:0 EL:3 ]
Mon Jan 20 08:54:51 2020 us=966540 Socket Buffers: R=[87380->262144] S=[16384->262144]
Mon Jan 20 08:54:51 2020 us=966569 TCP/UDP: Preserving recently used remote address: [AF_INET]195.138.249.2:1152
Mon Jan 20 08:54:51 2020 us=966598 Data Channel MTU parms [ L:1604 D:1450 EF:104 EB:143 ET:0 EL:3 AF:3/1 ]
Mon Jan 20 08:54:51 2020 us=966644 Local Options String: 'V4,dev-type tun,link-mtu 1604,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client'
Mon Jan 20 08:54:51 2020 us=966669 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1604,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server'
Mon Jan 20 08:54:51 2020 us=966701 Local Options hash (VER=V4): 'c19f87b0'
Mon Jan 20 08:54:51 2020 us=966721 Expected Remote Options hash (VER=V4): 'eda38e81'
Mon Jan 20 08:54:51 2020 us=966749 Attempting to establish TCP connection with [AF_INET]195.138.249.2:1152 [nonblock]
^CMon Jan 20 08:54:57 2020 us=498089 TCP/UDP: Closing socket
Mon Jan 20 08:54:57 2020 us=498131 Closing TUN/TAP interface
Mon Jan 20 08:54:57 2020 us=498146 /sbin/ip addr del dev tun1 10.1.149.245/24
Mon Jan 20 08:54:57 2020 us=550343 updown.sh tun1 1500 1604 10.1.149.245 255.255.255.0 init
updown.sh: STARTED
updown.sh: hop number:              2 (default: 1)
updown.sh: gateway of previous hop: 10.1.161.3 (default: local gateway)
updown.sh: local gateway:           
updown.sh: VPN: int. IP address:    
updown.sh: VPN: netmask:            
updown.sh: VPN: gateway:            
updown.sh: VPN: public IP address:  
updown.sh: ERROR:  ('route_vpn_gateway') is not an IPv4 address
updown.sh: ABORT
Mon Jan 20 08:54:57 2020 us=555423 WARNING: Failed running command (--up/--down): external program exited with error status: 1
Mon Jan 20 08:54:57 2020 us=555479 Exiting due to fatal error

Bei keinem anderen Hop1-Server tritt das so häufig auf.
 
Geht hier auch nicht.
Die Isländer sind halt den Pragern nicht geneigt. Vielleicht haben die aber auch gerade irgendso einen Vulkanausbruchdingens...
Aber die Hop Verbindung ist ja auch ein bißchen exotisch...
Ganz ohne dem Gepinge, man kann es auch hier sehen:

CapturFiles.jpg
 
Ich muss da mal fragen ob das Problem ist, das Island kein IPv6 hat, aber Prag schon... Kann ich jetzt aber nicht sagen, muss ich selber fragen
 
Hallo.

Honk said:
Code: 
Mon Jan 20 08:54:57 2020 us=550343 updown.sh tun1 1500 1604 10.1.149.245 255.255.255.0 init
updown.sh: STARTED
updown.sh: hop number: 2 (default: 1)
updown.sh: gateway of previous hop: 10.1.161.3 (default: local gateway)
updown.sh: local gateway:
updown.sh: VPN: int. IP address:
updown.sh: VPN: netmask:
updown.sh: VPN: gateway:
updown.sh: VPN: public IP address:
updown.sh: ERROR: ('route_vpn_gateway') is not an IPv4 address
updown.sh: ABORT
Click to expand...

Das Problem hier sind die leeren Felder, wo eigentlich IP Adressen stehen sollten. Diese kommen aus den Umgebungsvariablen, die OpenVPN setzen sollte (die Parameter aus der updown.sh-Kommandozeile werden dafür nicht verwendet).

Ist das gezeigte Log der erste Verbindungsversuch oder schon ein Reconnect? In letzterem Fall wären auch die Zeilen im Log vor dem Reconnect des Hop 2 interessant, also die Meldung mit der die Verbindung beendet wurde.

Wir werden mal versuchen, die Probleme nachzustellen.
 
PP Werner said:
Ist das gezeigte Log der erste Verbindungsversuch oder schon ein Reconnect? In letzterem Fall wären auch die Zeilen im Log vor dem Reconnect des Hop 2 interessant, also die Meldung mit der die Verbindung beendet wurde.
Click to expand...

Ob das schon ein Reconnect war, weiß ich nicht mehr.
Die Zeilen vor dem Reconnect haben ausgesehen wie immer, mir ist nix ungewöhnliches aufgefallen.
Eines noch, passiert ist das Ganze unter LinuxMint 18.3 (openvpn 2.3), mittlerweile bin ich auf 19.3 (openvpn 2.4) umgestiegen. Wenn du nix mehr von mir hörst, dann hat sich das Problem mit dem frischen Linux erledigt.
 
Honk said:
@PP Werner:
zu früh gefreut, auch mit der neuen Linuxversion das gleiche Spiel,
nach ca. einer halben Stunde nippelt Hop2 ab:
pastebin.com

$ openvpn --config zurich2 --script-security 2 --route remote_host --persist-tun - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
pastebin.com pastebin.com
Click to expand...
Sat Jan 25 10:05:16 2020 us=471610 [Server_zurich.perfect-privacy.com] Inactivity timeout (--ping-restart), restarting

Würde just4fun einfach mal "inactive" hochschrauben. Der parameter "ping" klingt hier auch vielversprechend.

Openvpn24ManPage – OpenVPN Community

community.openvpn.net community.openvpn.net
 
Heute wieder mal Hop2 (Zurich) abgenippelt, Hop1 war Island.
Das passiert meist kurz nachdem ein Download gestartet wurde.

Wegen dieses Fehlers ist der Server für mich leider nicht nutzbar.
Wäre schön, wenn dieser mal aktualisiert / neu installiert oder/und ein anderes RZ ausgesucht würde.

Der hier beschriebene Fehler taucht nur auf, wenn Island Hop1 ist.
 
Honk said:
Das passiert meist kurz nachdem ein Download gestartet wurde.
[QOUOTE]
Naja, Kasquarden sind auch nicht unbedingt dafür gedacht drüber Downzuloaden und dafür völlig overkill :rolleyes:
Wenn Du meinst irgendwelche Drogen/Waffen zu kaufen oder verkaufen zu müssen oder andere richtig schlimme Sachen, mag es dafür ja eine Bergründung geben aber für alles Normale wie DL, Torrents, Uploads, Streams, usw. reicht eine normale VPN Verbindung vollkommen aus.
Click to expand...
 
You must log in or register to reply here.
Back
Top