OpenVPN-Paket

knox · 23 Nov 2007

Da es sich bei TCP um eine verbindungsorientierte Kommunikation handelt (die sehr anfällig für Unterbrechungen ist), wirst Du möglicher Weise Probleme bekommen - zumal in Deinem Fall ja offensichtlich noch einige, zum Teil "strenge" Zwischenstationen durchlaufen werden müssen.

In dem von Dir angefragten Fall würde ich wohl so eine Art Call-Back implementieren: eine eingehende Anfrage auf Port 80 oder 443 löst dann eine ausgehende VPN Verbindung aus. Das bringt aber natürlich auch nur dann Vorteile, wenn ausgehender Verkehr nicht ebenfalls bestimmten Einschränkungen unterliegt (wie in den meisten Standardscenarios der Fall).

Es gibt da z.B. das Knockd Package im ds-mod.... Viel Erfolg!

koepie · 1 Dez 2007

Hi

Ich habe auf meiner FB 7170 den neusten ds mod mit openvpn laufen.
Ich möchte jetzt das der openvpn Server auf Port 443 TCP läuft.

Der Client soll sich dann über einen Proxy verbinden können.
Wenn der Client mit der FB verbunden ist soll er über die Fritzbox ins Inet kommen und er soll auf die Computer die an die Fritzbox angeschlossen sind kommen (192.168.178.0)

Wäre nett wenn ihr mir sagen würdet wie ich da die FB mit ds mod konfigurieren muss und wie den client?

Gruß
koepie

AndreR · 1 Dez 2007

@kopie
Ein Thread reicht, Antworten bitte hierhin

Heiko_Heider · 25 Dez 2007

OpenVPN mit Zertifikaten: "Connection Reset"

Hallo zusammen,

zunächst wünsche ich allen ein Fröhliches Weihnachtsfest.
Nachdem ich vor kurzem ein OpenVPN mit statischen Keys zum Laufen bekommen habe, versuche ich mich nun an einer Konfiguration mit Zertifikaten, weil ich auch auf Ordner-Freigaben im Server-Netz zugreifen können will.

Ich bin dabei streng nach der Wiki vorgegangen, allerdings klappt es nocht nicht ganz, ich denke aber, dass nicht mehr viel fehlt.

Folgende Ausgangssituation:
Server-Fritzbox:
192.168.0.1 / 255.255.255.0

Client-Win-PC am Remote-Standort
192.168.0.20 / 255.255.255.0 (d.h. gleicher IP-Bereich an beiden Standorten).

Einstellungen im DSMod entsprechen dem Muster auf der Wiki-Seite;
nur bei "Server-Einstellungen (bei Zertifikaten)" habe ich noch als DNS-Server die virtuelle IP des Zielsystems eingetragen, d.h. 192.168.200.1
Verschlüsselung ist bei mir AES-256, weil das bei der Zertifikat-Erstellung so erzeugt wurde.
Das Protokoll ist bei mir TCP, sollte aber eigentlich auch nichts machen.

openvpn.conf sieht wie folgt aus

Code:

#  OpenVPN 2.1 Config, Tue Dec 25 17:16:22 CET 2007
proto tcp-server
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
tls-auth /tmp/flash/static.key 0
port 1194
push "dhcp-option DNS 192.168.200.1"
push "redirect-gateway"
mode server
ifconfig-pool 192.168.200.100 192.168.200.150
ifconfig 192.168.200.1 255.255.255.0
push "route-gateway 192.168.200.1"
max-clients 5
tun-mtu 1500
mssfix
verb 3
daemon
cipher AES-256-CBC
keepalive 10 120

Meine client.ovpn sieht wie folgt aus:

Code:

remote MeinName.dyndns.org
proto tcp-client
dev tap
tls-client
ns-cert-type server
ca "C:\\Program Files\\OpenVPN\\keys\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\keys\\client01.crt"
key "C:\\Program Files\\OpenVPN\\keys\\client01.key"
tls-auth "C:\\Program Files\\OpenVPN\\keys\\static.key" 1
tun-mtu 1500
mssfix
nobind
pull
verb 3

Und dies ist die zugehörige Log-Datei beim Versuch, vom Remote-Standort über OpenVPN auf die Ziel-Fritzbox zu gelangen:
(Die drei ??? wurden von mir hier eingesetzt; die IP wird aber normal aufgelöst!)

Code:

Tue Dec 25 17:35:29 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2006
Tue Dec 25 17:35:29 2007 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Dec 25 17:35:29 2007 Control Channel Authentication: using 'C:\Program Files\OpenVPN\keys\static.key' as a OpenVPN static key file
Tue Dec 25 17:35:29 2007 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec 25 17:35:29 2007 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec 25 17:35:29 2007 Control Channel MTU parms [ L:1575 D:168 EF:68 EB:0 ET:0 EL:0 ]
Tue Dec 25 17:35:29 2007 Data Channel MTU parms [ L:1575 D:1450 EF:43 EB:4 ET:32 EL:0 ]
Tue Dec 25 17:35:29 2007 Local Options hash (VER=V4): '8a6c6b5b'
Tue Dec 25 17:35:29 2007 Expected Remote Options hash (VER=V4): '47106f19'
Tue Dec 25 17:35:29 2007 Attempting to establish TCP connection with ???.???.46.0:1194
Tue Dec 25 17:35:29 2007 TCP connection established with ???.???.46.0:1194
Tue Dec 25 17:35:29 2007 TCPv4_CLIENT link local: [undef]
Tue Dec 25 17:35:29 2007 TCPv4_CLIENT link remote: ???.???.46.0:1194
Tue Dec 25 17:35:29 2007 TLS: Initial packet from ???.???.46.0:1194, sid=f0bd0e2b 38315709
Tue Dec 25 17:35:30 2007 VERIFY OK: depth=1, /C=DE/ST=BW/L=???/O=FortHeiko/OU=Heiko/CN=ca/emailAddress=???
Tue Dec 25 17:35:30 2007 VERIFY OK: nsCertType=SERVER
Tue Dec 25 17:35:30 2007 VERIFY OK: depth=0, /C=DE/ST=BW/O=FortHeiko/OU=Heiko/CN=fritzbox/emailAddress=???
Tue Dec 25 17:35:32 2007 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Dec 25 17:35:32 2007 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec 25 17:35:32 2007 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Dec 25 17:35:32 2007 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec 25 17:35:32 2007 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Dec 25 17:35:32 2007 [fritzbox] Peer Connection Initiated with ???.???.46.0:1194
Tue Dec 25 17:35:33 2007 SENT CONTROL [fritzbox]: 'PUSH_REQUEST' (status=1)
Tue Dec 25 17:35:33 2007 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.200.1,redirect-gateway,route-gateway 192.168.200.1,ping 10,ping-restart 120,ifconfig 192.168.200.100 255.255.255.0'
Tue Dec 25 17:35:33 2007 OPTIONS IMPORT: timers and/or timeouts modified
Tue Dec 25 17:35:33 2007 OPTIONS IMPORT: --ifconfig/up options modified
Tue Dec 25 17:35:33 2007 OPTIONS IMPORT: route options modified
Tue Dec 25 17:35:33 2007 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Dec 25 17:35:33 2007 TAP-WIN32 device [Local Area Connection 3] opened: \\.\Global\{757FC3D6-D3E1-4093-A60B-B73EE91E0B07}.tap
Tue Dec 25 17:35:33 2007 TAP-Win32 Driver Version 8.4 
Tue Dec 25 17:35:33 2007 TAP-Win32 MTU=1500
Tue Dec 25 17:35:33 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of [URL="http://192.168.200.100/255.255.255.0"]192.168.200.100/255.255.255.0[/URL] on interface {757FC3D6-D3E1-4093-A60B-B73EE91E0B07} [DHCP-serv: 192.168.200.0, lease-time: 31536000]
Tue Dec 25 17:35:33 2007 Successful ARP Flush on interface [2] {757FC3D6-D3E1-4093-A60B-B73EE91E0B07}
Tue Dec 25 17:35:34 2007 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Tue Dec 25 17:35:34 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Dec 25 17:35:35 2007 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Tue Dec 25 17:35:35 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Dec 25 17:35:36 2007 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Tue Dec 25 17:35:36 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Dec 25 17:35:37 2007 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Tue Dec 25 17:35:37 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Dec 25 17:35:38 2007 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Tue Dec 25 17:35:38 2007 route ADD ???.???.46.0 MASK 255.255.255.255 192.168.0.1
Tue Dec 25 17:35:38 2007 Route addition via IPAPI succeeded
Tue Dec 25 17:35:38 2007 route DELETE 0.0.0.0 MASK 0.0.0.0 192.168.0.1
Tue Dec 25 17:35:38 2007 Route deletion via IPAPI succeeded
Tue Dec 25 17:35:38 2007 route ADD 0.0.0.0 MASK 0.0.0.0 192.168.200.1
Tue Dec 25 17:35:38 2007 Route addition via IPAPI succeeded
Tue Dec 25 17:35:38 2007 Initialization Sequence Completed
Tue Dec 25 17:35:38 2007 Connection reset, restarting [0]
Tue Dec 25 17:35:38 2007 TCP/UDP: Closing socket
Tue Dec 25 17:35:38 2007 route DELETE ???.???.46.0 MASK 255.255.255.255 192.168.0.1
Tue Dec 25 17:35:38 2007 Route deletion via IPAPI succeeded
Tue Dec 25 17:35:38 2007 route DELETE 0.0.0.0 MASK 0.0.0.0 192.168.200.1
Tue Dec 25 17:35:38 2007 Route deletion via IPAPI succeeded
Tue Dec 25 17:35:38 2007 route ADD 0.0.0.0 MASK 0.0.0.0 192.168.0.1
Tue Dec 25 17:35:38 2007 Route addition via IPAPI succeeded
Tue Dec 25 17:35:38 2007 Closing TUN/TAP interface
Tue Dec 25 17:35:39 2007 SIGUSR1[soft,connection-reset] received, process restarting
Tue Dec 25 17:35:39 2007 Restart pause, 5 second(s)
Tue Dec 25 17:35:43 2007 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Dec 25 17:35:43 2007 Control Channel Authentication: using 'C:\Program Files\OpenVPN\keys\static.key' as a OpenVPN static key file
Tue Dec 25 17:35:44 2007 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec 25 17:35:44 2007 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec 25 17:35:44 2007 Control Channel MTU parms [ L:1575 D:168 EF:68 EB:0 ET:0 EL:0 ]
Tue Dec 25 17:35:44 2007 Data Channel MTU parms [ L:1575 D:1450 EF:43 EB:4 ET:32 EL:0 ]
Tue Dec 25 17:35:44 2007 Local Options hash (VER=V4): '8a6c6b5b'
Tue Dec 25 17:35:44 2007 Expected Remote Options hash (VER=V4): '47106f19'
Tue Dec 25 17:35:44 2007 Attempting to establish TCP connection with ???.???.46.0:1194
Tue Dec 25 17:35:45 2007 TCP connection established with ???.???.46.0:1194
Tue Dec 25 17:35:45 2007 TCPv4_CLIENT link local: [undef]
Tue Dec 25 17:35:45 2007 TCPv4_CLIENT link remote: ???.???.46.0:1194
Tue Dec 25 17:35:45 2007 TLS: Initial packet from ???.???.46.0:1194, sid=688c44c9 4658192f
Tue Dec 25 17:35:46 2007 VERIFY OK: depth=1, /C=DE/ST=BW/L=???/O=FortHeiko/OU=Heiko/CN=ca/emailAddress=???
Tue Dec 25 17:35:46 2007 VERIFY OK: nsCertType=SERVER
Tue Dec 25 17:35:46 2007 VERIFY OK: depth=0, /C=DE/ST=BW/O=FortHeiko/OU=Heiko/CN=fritzbox/emailAddress=???
Tue Dec 25 17:35:47 2007 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Dec 25 17:35:47 2007 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec 25 17:35:47 2007 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Dec 25 17:35:47 2007 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Dec 25 17:35:47 2007 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Dec 25 17:35:47 2007 [fritzbox] Peer Connection Initiated with ???.???.46.0:1194
Tue Dec 25 17:35:48 2007 SENT CONTROL [fritzbox]: 'PUSH_REQUEST' (status=1)
Tue Dec 25 17:35:49 2007 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.200.1,redirect-gateway,route-gateway 192.168.200.1,ping 10,ping-restart 120,ifconfig 192.168.200.100 255.255.255.0'
Tue Dec 25 17:35:49 2007 OPTIONS IMPORT: timers and/or timeouts modified
Tue Dec 25 17:35:49 2007 OPTIONS IMPORT: --ifconfig/up options modified
Tue Dec 25 17:35:49 2007 OPTIONS IMPORT: route options modified
Tue Dec 25 17:35:49 2007 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Dec 25 17:35:49 2007 TAP-WIN32 device [Local Area Connection 3] opened: \\.\Global\{757FC3D6-D3E1-4093-A60B-B73EE91E0B07}.tap
Tue Dec 25 17:35:49 2007 TAP-Win32 Driver Version 8.4 
Tue Dec 25 17:35:49 2007 TAP-Win32 MTU=1500
Tue Dec 25 17:35:49 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of [URL="http://192.168.200.100/255.255.255.0"]192.168.200.100/255.255.255.0[/URL] on interface {757FC3D6-D3E1-4093-A60B-B73EE91E0B07} [DHCP-serv: 192.168.200.0, lease-time: 31536000]
Tue Dec 25 17:35:49 2007 Successful ARP Flush on interface [2] {757FC3D6-D3E1-4093-A60B-B73EE91E0B07}
Tue Dec 25 17:35:49 2007 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Tue Dec 25 17:35:49 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Dec 25 17:35:50 2007 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Tue Dec 25 17:35:50 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Dec 25 17:35:50 2007 TCP/UDP: Closing socket
Tue Dec 25 17:35:50 2007 Closing TUN/TAP interface
Tue Dec 25 17:35:50 2007 SIGTERM[hard,] received, process exiting

Es wäre echt super, wenn mir kurz jemand einen Wink mit dem Zaunpfahl geben könnte, wo ich ansetzen musste.

Vielen Dank schonmal + viele Grüße,

Heiko

kriegaex · 25 Dez 2007

Es gibt doch einen Thread für OpenVPN. Damit Du nicht ständig neue Threads erzeugst, verschiebe ich Deine Anfrage samt dieser Antwort dorthin.

MaxMuster · 25 Dez 2007

Heiko_Heider schrieb:
... versuche ich mich nun an einer Konfiguration mit Zertifikaten, weil ich auch auf Ordner-Freigaben im Server-Netz zugreifen können will.

Warum brauchst du Zertifikate für die Nutzung von Freigaben???

Heiko_Heider schrieb:
...allerdings klappt es nocht nicht ganz, ich denke aber, dass nicht mehr viel fehlt.

Es wäre nett wenn du sagst was nicht klappt. Kannst du die "VPN-IP" (192.168.200.1) der Box vom PC anpingen? Das Problem bei den überlappenden IP-Netzen wird sein, dass du von deinem PC aus die Systeme in dem Netz hinter der Box nicht erreichen kannst, weil der PC "denkt", dass alle IPs aus dem Netz 192.168.0.x "lokal" sind, sofern du nicht zusätzliche Routen für bestimmte IPs einträgst, (die dann aber in deinem "normalen" Netz nicht vorhanden sein dürfen...

Jörg

Benny · 9 Jan 2008

Hi

Ich bekomme den OpenVPN Server nicht gestartet. Die einzige Meldung, die ich erhalte ist:
"Starting OpenVPN ...failed."

Woran kann das liegen? Ich habe zwar diese Stellen hier schon gelesen, aber erstens weiß ich damit nix weiter anzufangen und zweitens war das ja noch eine ältere Version, oder?

Hier Bilder meiner Konfiguration

knox · 9 Jan 2008

wiseguy-bike schrieb:
bekomme den OpenVPN Server nicht gestartet. Die einzige Meldung, die ich erhalte ist:
"Starting OpenVPN ...failed."

Schau ins Log, dort wird mit Sicherheit der Grund zu finden sein. :-Ö

hermann72pb · 9 Jan 2008

...oder starte openvpn über console mit

Code:

/etc/init.d/rc.openvpn-lzo start

(evtl. auch ohne lzo am ende, ich weiß es nicht 100%), dann siehst du die Fehler direkt als Ausgabe. Lese dich ein über verbosity-Level. Damit kann man auch für OpenVPN die die Genauigkeit der Fehlerausgaben steuern.
Hast du denn überhaupt schon mal mit OpenVPN zu tun gehabt? Warum fangen alle hier sofort mit Zertifikaten an? Kannst du nicht es erstmal mit "static key" zum laufen bringen und dann die paronoidalen Sicherheitsbestimmungen hochschrauben? So ist die normale Vergehensweise.

Ich tippe mal, dass deine Fehlern in den Zertiffikaten liegen.

MfG

MaxMuster · 9 Jan 2008

... und noch der Hinweis auf das Wiki, was dir dazu vermutlich auch weiterhelfen könnte (speziell die Tipps zu Problemen). Mit den so gewonnen Infos solltest du in der Lage sein, dein Problem zu fixen oder du hast mehr "Input", um dein Problem hier zu konkretisieren.

EDIT: Noch was zum Inhaltlichen:

Du solltest dir nochmal über die IP Struktur Gedanken machen, denn so hast du da im Ergebnis was "Widersinniges" eingetragen:

Lokale und Entfernte Adresse sind bei dir identisch, dass kann nicht gut gehen
Das "Tunnel-Netz" (worin die Endpunkte sind) hast du dann noch ins Routing eingetragen, dass ist zumindest überflüssig (den das Interface ist schon in dem Netz, dafür brauchst du kein Routing)
Die "Tunnel-IPs", die du oben bei "IP-Adressen" vergeben hast sind aus einem volkommen anderen Netz als die Angabe beim "Client Adressbereich"

Jörg

Benny · 9 Jan 2008

Lokale und Entfernte Adresse sind bei dir identisch, dass kann nicht gut gehen

Hm - ich möchte, dass der Notebook quasi genauso ansprechbar ist, wie wenn ich im LAN währe; also ich hab ja z.B. die IP auf die MAC Adresse festgelegt. Und ich wollte, dass der Rechner genau wieder diese MAC Adresse bekommt zum Beispiel. Ist sowas denn nicht möglich?

hermann72pb · 9 Jan 2008

Welchen Notebook meinst du? Denkst du, wir können hell sehen? Am besten, du beschreibst komplett die Aufgabe (was du vor hast) und wir sagen dir, was für dich dafür am besten geeignet wäre.
Es ist nicht immer OpenVPN erforderlich und schon gar nicht immer gleich mit Zertiffikaten. Ich habe so einen Eindruck, dass du mit Kanonen auf die Spatzen schießen versucht, wobei du noch keine Schrotflinte bedienen kannst. Entschuldige den Vergleich.

MfG

knox · 9 Jan 2008

Die Disukssion hat (mal wieder) überhaupt nichts mit dem ds-mod oder dem OpenVPN Package zu tun.

Bitte einschlägige Dokumentation lesen und nachvollziehen und ggf. an geeigneter Stelle zusätzliche Informationen einholen, z.B. OpenVPN Forum, etc. etc.

Das hier ist KEIN Anfängerkursus Netzwerktechnik!

Benny · 9 Jan 2008

Die Disukssion hat (mal wieder) überhaupt nichts mit dem ds-mod oder dem OpenVPN Package zu tun

Stimmt - sorry, ich hab deswegen hier weiter geschrieben.

@hermann: Sorry, ich hatte ganz vergessen, dass ich das in einem anderen Thread erwähnt hatte - hab mich im Thread geirrt.

Stefanius76 · 19 Jan 2008

[Edit frank_m24: Fullquote auf das Notwendige beschränkt. Lies noch mal die Forumregeln.]

jspies schrieb:
Das Problem liegt wohl in den OpenSSL Shared Libs im DS-Mod. Ich habe Dein Binary mal gegen meine aktuelle Version (OpenSSL 0.9.8b) laufen lassen - das funktioniert.

Hallo Jürgen,

folgendes Problem:
FRITZ!Box Fon WLAN 7170 (UI)
Firmware-Version 29.04.49
Linux (none) 2.6.13.1-ohio #1 Wed Dec 12 15:47:14 CET 2007 mips unknown

Habe mir die Dateien runtergeladen:
Pfad: /var/tmp/vpn
libcrypto.so openvpn server.key libssl.so openvpn.conf

Beim Starten des openvpn kommt immer die Fehlermeldung:
./openvpn: can't resolve symbol '__uClibc_start_main'

Ist das noch immer ein Problem mit dem Kernel in Vers. 2.6 ?
Bin leider kein Linuxprofi, aber gibt es eine Möglichkeit openvpn ans rennen zu bekommen ? Please help...ich verzweifele!

MaxMuster · 19 Jan 2008

Moin,

und Willkommen im Forum.
Ich denke, du bist hier im falschen Thread, denn hier geht es um das OpenVPN-Paket im ds-mod. Für den braucht man nichts weiter herunterladen, denn alle Dateien sind in der entsprechenden Firmware drin.

"./openvpn: can't resolve symbol '__uClibc_start_main'" ist ein zeimlich sicheres Zeichen für ein "altes" Binary auf dem neueren Kernel.

Wenn du das über die "Downloadmethode" machen willst, dann solltest du dir diesen und diesen Thread ansehen und natürlich das Wiki dazu.

Jörg

sweetie-pie · 19 Jan 2008

Stabilität OpenVPN Verbindung

Hallo,

ich habe eine Verbindung zwischen zwei Boxen/Subnetzen und optional noch die Einwahl von zwei Roadwarrioren. Im Leerlauf scheint die Verbindungen zwischenden Netzen stabil zu sein, sobald ich aber Traffic erzeuge (z.B. Abruf einer Webseite), werden die Pingzeiten höher.
Auch eine Erhöhung der Packetgröße der Pings kann die Verbindung zum Abbruch bringen.

Code:

64 bytes from 192.168.1.110: icmp_seq=7233 ttl=63 time=75.3 ms
64 bytes from 192.168.1.110: icmp_seq=7234 ttl=63 time=76.6 ms
64 bytes from 192.168.1.110: icmp_seq=7235 ttl=63 time=75.9 ms
64 bytes from 192.168.1.110: icmp_seq=7236 ttl=63 time=75.0 ms
64 bytes from 192.168.1.110: icmp_seq=7237 ttl=63 time=75.4 ms
64 bytes from 192.168.1.110: icmp_seq=7238 ttl=63 time=74.3 ms
64 bytes from 192.168.1.110: icmp_seq=7239 ttl=63 time=74.1 ms
64 bytes from 192.168.1.110: icmp_seq=7240 ttl=63 time=75.2 ms
64 bytes from 192.168.1.110: icmp_seq=7241 ttl=63 time=73.6 ms
64 bytes from 192.168.1.110: icmp_seq=7242 ttl=63 time=74.9 ms
64 bytes from 192.168.1.110: icmp_seq=7243 ttl=63 time=75.1 ms
[B]jetzt Datentransfer nebenbei...[/B]
64 bytes from 192.168.1.110: icmp_seq=7244 ttl=63 time=100 ms
64 bytes from 192.168.1.110: icmp_seq=7245 ttl=63 time=129 ms
64 bytes from 192.168.1.110: icmp_seq=7246 ttl=63 time=97.8 ms
64 bytes from 192.168.1.110: icmp_seq=7247 ttl=63 time=731 ms
64 bytes from 192.168.1.110: icmp_seq=7248 ttl=63 time=108 ms
64 bytes from 192.168.1.110: icmp_seq=7249 ttl=63 time=124 ms
64 bytes from 192.168.1.110: icmp_seq=7250 ttl=63 time=84.0 ms
64 bytes from 192.168.1.110: icmp_seq=7251 ttl=63 time=81.5 ms
64 bytes from 192.168.1.110: icmp_seq=7252 ttl=63 time=104 ms
64 bytes from 192.168.1.110: icmp_seq=7253 ttl=63 time=75.6 ms
64 bytes from 192.168.1.110: icmp_seq=7254 ttl=63 time=176 ms
64 bytes from 192.168.1.110: icmp_seq=7255 ttl=63 time=101 ms
64 bytes from 192.168.1.110: icmp_seq=7256 ttl=63 time=100 ms
64 bytes from 192.168.1.110: icmp_seq=7257 ttl=63 time=85.7 ms
64 bytes from 192.168.1.110: icmp_seq=7258 ttl=63 time=117 ms
64 bytes from 192.168.1.110: icmp_seq=7259 ttl=63 time=93.5 ms
64 bytes from 192.168.1.110: icmp_seq=7260 ttl=63 time=77.6 ms
64 bytes from 192.168.1.110: icmp_seq=7261 ttl=63 time=289 ms
64 bytes from 192.168.1.110: icmp_seq=7262 ttl=63 time=1250 ms
64 bytes from 192.168.1.110: icmp_seq=7263 ttl=63 time=258 ms
64 bytes from 192.168.1.110: icmp_seq=7264 ttl=63 time=79.9 ms
64 bytes from 192.168.1.110: icmp_seq=7265 ttl=63 time=129 ms
64 bytes from 192.168.1.110: icmp_seq=7266 ttl=63 time=89.0 ms
64 bytes from 192.168.1.110: icmp_seq=7267 ttl=63 time=96.1 ms
64 bytes from 192.168.1.110: icmp_seq=7268 ttl=63 time=86.0 ms
64 bytes from 192.168.1.110: icmp_seq=7269 ttl=63 time=76.9 ms
64 bytes from 192.168.1.110: icmp_seq=7270 ttl=63 time=257 ms
64 bytes from 192.168.1.110: icmp_seq=7271 ttl=63 time=115 ms
64 bytes from 192.168.1.110: icmp_seq=7272 ttl=63 time=109 ms
64 bytes from 192.168.1.110: icmp_seq=7273 ttl=63 time=85.3 ms
64 bytes from 192.168.1.110: icmp_seq=7274 ttl=63 time=105 ms
64 bytes from 192.168.1.110: icmp_seq=7275 ttl=63 time=126 ms
64 bytes from 192.168.1.110: icmp_seq=7276 ttl=63 time=92.7 ms
64 bytes from 192.168.1.110: icmp_seq=7277 ttl=63 time=790 ms
64 bytes from 192.168.1.110: icmp_seq=7278 ttl=63 time=89.0 ms
64 bytes from 192.168.1.110: icmp_seq=7279 ttl=63 time=202 ms
64 bytes from 192.168.1.110: icmp_seq=7280 ttl=63 time=78.8 ms
64 bytes from 192.168.1.110: icmp_seq=7281 ttl=63 time=81.2 ms
64 bytes from 192.168.1.110: icmp_seq=7282 ttl=63 time=81.4 ms
64 bytes from 192.168.1.110: icmp_seq=7283 ttl=63 time=203 ms
64 bytes from 192.168.1.110: icmp_seq=7284 ttl=63 time=160 ms
64 bytes from 192.168.1.110: icmp_seq=7285 ttl=63 time=79.8 ms

Hat jemand von euch schon mal ähnliches beobachtet... ?

RalfFriedl · 19 Jan 2008

sweetie-pie schrieb:
sobald ich aber Traffic erzeuge (z.B. Abruf einer Webseite), werden die Pingzeiten höher.

Ja, was erwartest Du denn?

Auch eine Erhöhung der Packetgröße der Pings kann die Verbindung zum Abbruch bringen.

Was haben die Ping-Zeiten mit "stabil" und "zum Abbruch bringen" zu tun?

MaxMuster · 19 Jan 2008

sweetie-pie schrieb:
Auch eine Erhöhung der Packetgröße der Pings kann die Verbindung zum Abbruch bringen.

Was bricht denn ab? Die VPN-Verbindung oder die "Datenverbindung" über den VPN Tunnel?

Du solltest bedenken, dass bei einem ADSL-Anschluss für denjenigen, der sich verbindet "das A zuschlägt", du hast vom Server ausgehend, beim Client aber eingehend nur den niedrigen "Upstream" zur Verfügung ebenso wie dies beim "Rückweg" vom Client zum Server durch dessen Upstream begrenzt wird.

Jörg

sweetie-pie · 19 Jan 2008

MaxMuster schrieb:
Was bricht denn ab? Die VPN-Verbindung oder die "Datenverbindung" über den VPN Tunnel?

Die VPN-Verbindung, da der Client am Standort B abstürzt... d.h. die Box sich zurücksetzt und neu startet...

MaxMuster schrieb:
Du solltest bedenken, dass bei einem ADSL-Anschluss für denjenigen, der sich verbindet "das A zuschlägt", du hast vom Server ausgehend, beim Client aber eingehend nur den niedrigen "Upstream" zur Verfügung ebenso wie dies beim "Rückweg" vom Client zum Server durch dessen Upstream begrenzt wird.

Zu meinem Verständnis, was passiert denn, wenn mehr Daten kommen als übertragen werden können?

Also nach meinem Verständis:
Mit dem Ping-Befehl sende ich ein Datenpaket bestimmter Größe im Ethernet (Layer2) zu einem Partner und der sollte mir das ganze möglichst zurücksenden...
Mein Flaschenhals ist daher der Upstream am Standort B. Hier sagt Fritz: Nutz-Datenrate Senderichtung 203 kBit/s.
Mal kurz gerechnet: 203 kBit/s * 1024 = 207.872 Bit/s : 8 = 25.984 Byte/s : 1024 = 25,37 kByte/s.
Nochmal für den Standort A gerechnet: 1.072 * 1024 = 1.097.728 Bit/s : 8 = 137.216 Byte/s : 1024 = 134 kByte/s

Okay, dann testen wir mal mit 90%iger Auslastung (25.984 Byte/s *0,9) von A->B:

Code:

holly@julia:~$ ping -s 23377 -t 128 192.168.1.110
PING 192.168.1.110 (192.168.1.110) 23377(23405) bytes of data.
23385 bytes from 192.168.1.110: icmp_seq=1 ttl=63 time=1393 ms
23385 bytes from 192.168.1.110: icmp_seq=2 ttl=63 time=1497 ms
23385 bytes from 192.168.1.110: icmp_seq=3 ttl=63 time=1599 ms
[B]---schnipp--- von mir entfernt, alles normal[/B]
23385 bytes from 192.168.1.110: icmp_seq=64 ttl=63 time=7951 ms
23385 bytes from 192.168.1.110: icmp_seq=65 ttl=63 time=8053 ms
23385 bytes from 192.168.1.110: icmp_seq=66 ttl=63 time=8155 ms
23385 bytes from 192.168.1.110: icmp_seq=67 ttl=63 time=8265 ms
23385 bytes from 192.168.1.110: icmp_seq=68 ttl=63 time=8359 ms
23385 bytes from 192.168.1.110: icmp_seq=69 ttl=63 time=8464 ms
23385 bytes from 192.168.1.110: icmp_seq=70 ttl=63 time=8568 ms
23385 bytes from 192.168.1.110: icmp_seq=71 ttl=63 time=8673 ms
23385 bytes from 192.168.1.110: icmp_seq=72 ttl=63 time=8778 ms
23385 bytes from 192.168.1.110: icmp_seq=73 ttl=63 time=8874 ms
23385 bytes from 192.168.1.110: icmp_seq=[B]74[/B] ttl=63 time=[B]8980[/B] ms
23385 bytes from 192.168.1.110: icmp_seq=[B]76[/B] ttl=63 time=[B]8083[/B] ms
23385 bytes from 192.168.1.110: icmp_seq=77 ttl=63 time=8192 ms
23385 bytes from 192.168.1.110: icmp_seq=78 ttl=63 time=8302 ms
23385 bytes from 192.168.1.110: icmp_seq=79 ttl=63 time=8405 ms
23385 bytes from 192.168.1.110: icmp_seq=80 ttl=63 time=8504 ms
23385 bytes from 192.168.1.110: icmp_seq=81 ttl=63 time=8611 ms
23385 bytes from 192.168.1.110: icmp_seq=82 ttl=63 time=8707 ms
23385 bytes from 192.168.1.110: icmp_seq=83 ttl=63 time=8810 ms
23385 bytes from 192.168.1.110: icmp_seq=84 ttl=63 time=8918 ms
23385 bytes from 192.168.1.110: icmp_seq=[B]85[/B] ttl=63 time=[B]9024[/B] ms
23385 bytes from 192.168.1.110: icmp_seq=[B]87[/B] ttl=63 time=[B]8129[/B] ms
23385 bytes from 192.168.1.110: icmp_seq=88 ttl=63 time=8230 ms
23385 bytes from 192.168.1.110: icmp_seq=89 ttl=63 time=8330 ms
23385 bytes from 192.168.1.110: icmp_seq=90 ttl=63 time=8427 ms

Also, ich deute das mal so:
Die Leitung wird bis zur Grenze ausgereizt.... die Antwortzeiten steigen. Irgendwann fehlt ein Paket, die Antwortzeit ist gesunken.
Danach steigt die Antwortzeit wieder, bis wieder ein Paket fehlt usw....

Da die Datenübertragung ungesichert passiert, ist das ja okay, aber wer verwirft das Paket?
Bei einer zeitlichen Verzögerung von ca. 9 Sekunden, einer Paketgröße von
23.385 Bytes und einem Ping pro Sekunde, muss ja irgendwer 210.465 Bytes zwischenspeichern.

Wenn ich jetzt noch TCP/IP-Traffic verursache bricht die Verbindung ab... d.h. die Box am Standort B stürzt ab.

Was passiert denn, wenn ich den Tunnel auf Clientseite mit 20.000 Byte/s mit einem shaper begrenze?

Hat jemand einen Tipp, wo ich solche Grundlagen erlesen kann?

produktiv:	in Kündigung:
FRITZ!Box 7490, Firmware-Version geheim ewetel 108000/44504 VDSL2 G.Vector dropbear openvpn*	FRITZ!Box Fon WLAN 7390, Firmware-Version geheim t-online 16.431/2.551 Annex J avm-firewall dropbear * openvpn*

produktiv:	in Kündigung:
FRITZ!Box 7490, Firmware-Version geheim ewetel 108000/44504 VDSL2 G.Vector dropbear openvpn*	FRITZ!Box Fon WLAN 7390, Firmware-Version geheim t-online 16.431/2.551 Annex J avm-firewall dropbear * openvpn*

OpenVPN-Paket

Mitglied

Neuer User

Aktives Mitglied

Mitglied

Aktives Mitglied

IPPF-Promi

Neuer User

Anhänge

Mitglied

IPPF-Promi

IPPF-Promi

Neuer User

IPPF-Promi

Mitglied

Neuer User

Neuer User

IPPF-Promi

Neuer User

IPPF-Urgestein

IPPF-Promi

Neuer User

Statistik des Forums