"Christmas - the time to fix the computers of your loved ones" « Lord Wyrm

VPN zwischen zwei WRT54GL Routern

jb 04.01.2009 - 23:19 1738 8
Posts

jb

Here to stay
Registered: May 2000
Location: /home/noe/
Posts: 3513
Sitze nun schon seit knapp 2 Tagen an nem VPN zwischen 2 WRT54GL Routern und es will irgendwie nicht klappen.

Hab mich genau an diese Anleitung gehalten (mal abgesehen von anderen IP Bereichen und keiner DHCP Nutzung), nur aus irgendeinem Grund der sich mir nicht erschließt verweigern mir die Geräte die Mitarbeit. Die mit OpenVPN erstellten Schlüssel und Zertifikate hab ich natürlich schon überprüft, aber da steht überall das Richtige drinnen soweit ich gesehen habe.

Hatte das Ganze vor nem halben Jahr schon mal mit genau der Anleitung testweise laufen gehabt, dann aber die Configs gelöscht weil ich es zu dem Zeitpunkt noch nicht gebraucht habe. :bash:

Irgendjemand eine Idee, wie man das Ganze schrittweise testen kann oder zumindest rausfinden kann ob es an der Client oder an der Serverseite spießt?

Edit:
Ziel des Ganzen ist eine direkte Verbindung zwischen zwei privaten IP Netzen (selbes Netz, selbe Subnetzmaske, natürlich keine doppelten IPs ;) ), z.B. zur Fernadministration per VNC, aber auch für kleinere Filetransfers und zur Netzwerküberwachung (The Dude). Die beiden Router haben jeweils eine öffentliche, fixe IP, einer davon hängt im Chello Netz (evtl. eine Fehlerquelle, aber es hat ja vor einigen Monaten schon mal funktioniert). DHCP (wie in der Anleitung) gibt es ebenfalls keines, ich bevorzuge fixe IPs, das ist übersichtlicher für private Netze.

Zuerst habeich die Keys und Zertifikate per Open-VPN erstellt (wie hier beschrieben), und in den entsprechenden Bereichen der Router Config Files eingefügt, danach diese über Administration -> Diagnose in die Startup-Dateien der Router eingehängt und am "Server" Router noch zusätzlich die IP-Tables Rule in der Firewall-Config dazugehängt.
Die Router wurden anschließend beide rebootet, nur baut sich keine Verbindung auf, das hab ich per Ping überprüft, es ist auch direkt von den Routern kein Ping auf einen Client bzw. auf die private IP des Routers der anderen Seite möglich.

Mir fehlen jetzt irgendwie Infos, wie man genauer überprüfen könnte, wo der Fehler liegt bzw. wie man ihn eingrenzen könnte.
Bearbeitet von jb am 04.01.2009, 23:46

COLOSSUS

Administrator
GNUltra
Avatar
Registered: Dec 2000
Location: ~
Posts: 12060
Das ist (leider) ein gutes Beispiel fuer einen schlechten Fehlerbericht.

Was _genau_ funktioniert denn nicht, bzw. ab wo haut es nicht mehr hin? Was versuchst du zu tun? Was ist das erwartete, was das tatsaechlich erhaltene Resultat?

jb

Here to stay
Registered: May 2000
Location: /home/noe/
Posts: 3513
So bin jetzt etwas weitergekommen, indem ich ein Logfile schreiben lasse und dafür die Zeile
Zitat
log /tmp/openvpn.log
ins VPN Config File aufgenommen habe.

Im Logfile hat sich ein Fehler mit der db1024.pem gefunden, der ist nach einem kompletten Neuschreiben der Config-Files jetzt aber nicht mehr da.

Dafür scheint irgendein anderer Fehler meine Verbindung noch zu blockieren. Hier das Server-Logfile:
Code:
Mon Jan  5 20:56:56 2009 OpenVPN 2.1_rc7 mipsel-unknown-linux-gnu [SSL] [LZO1] [EPOLL] built on Jul 27 2008
Mon Jan  5 20:56:56 2009 Diffie-Hellman initialized with 1024 bit key
Mon Jan  5 20:56:56 2009 TLS-Auth MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Jan  5 20:56:56 2009 TUN/TAP device tap0 opened
Mon Jan  5 20:56:56 2009 TUN/TAP TX queue length set to 100
Mon Jan  5 20:56:56 2009 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Mon Jan  5 20:56:56 2009 Socket Buffers: R=[32767->65534] S=[32767->65534]
Mon Jan  5 20:56:56 2009 UDPv4 link local (bound): [undef]:1194
Mon Jan  5 20:56:56 2009 UDPv4 link remote: [undef]
Mon Jan  5 20:56:56 2009 MULTI: multi_init called, r=256 v=256
Mon Jan  5 20:56:56 2009 Initialization Sequence Completed
Mon Jan  5 20:57:00 2009 MULTI: multi_create_instance called
Mon Jan  5 20:57:00 2009 xxx.Client-IP.xxx:2052 Re-using SSL/TLS context
Mon Jan  5 20:57:00 2009 xxx.Client-IP.xxx:2052 LZO compression initialized
Mon Jan  5 20:57:00 2009 xxx.Client-IP.xxx:2052 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Jan  5 20:57:00 2009 xxx.Client-IP.xxx:2052 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Mon Jan  5 20:57:01 2009 xxx.Client-IP.xxx:2052 TLS: Initial packet from xxx.Client-IP.xxx:2052, sid=9bc538a7 0e9705d5
Mon Jan  5 20:57:04 2009 xxx.Client-IP.xxx:2052 VERIFY ERROR: depth=0, error=unsupported certificate purpose: /C=AT/ST=TU/O=privat/CN=client1/emailAddress=mein_email@xyz.at
Mon Jan  5 20:57:04 2009 xxx.Client-IP.xxx:2052 TLS_ERROR: BIO read tls_read_plaintext error: error:140890B2:lib(20):func(137):reason(178)
Mon Jan  5 20:57:04 2009 xxx.Client-IP.xxx:2052 TLS Error: TLS object -> incoming plaintext read error
Mon Jan  5 20:57:04 2009 xxx.Client-IP.xxx:2052 TLS Error: TLS handshake failed
Mon Jan  5 20:57:04 2009 xxx.Client-IP.xxx:2052 SIGUSR1[soft,tls-error] received, client-instance restarting

Und das Client-Logfile:
Code:
Mon Jan  5 21:23:21 2009 OpenVPN 2.1_rc7 mipsel-unknown-linux-gnu [SSL] [LZO1] [EPOLL] built on Jul 27 2008
Mon Jan  5 21:23:21 2009 LZO compression initialized
Mon Jan  5 21:23:21 2009 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Jan  5 21:23:21 2009 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Mon Jan  5 21:23:21 2009 Socket Buffers: R=[32767->65534] S=[32767->65534]
Mon Jan  5 21:23:21 2009 UDPv4 link local: [undef]
Mon Jan  5 21:23:21 2009 UDPv4 link remote: xxx.Server-IP.xxx:1194
Mon Jan  5 21:23:21 2009 TLS: Initial packet from xxx.Server-IP.xxx:1194, sid=7d0f9672 a50f1cfb
Mon Jan  5 21:23:22 2009 VERIFY OK: depth=1, /C=AT/ST=TU/L=Kirchberg/O=privat/CN=OPENVPN-CA/emailAddress=mein_email@xyz.at
Mon Jan  5 21:23:22 2009 VERIFY OK: nsCertType=SERVER
Mon Jan  5 21:23:22 2009 VERIFY OK: depth=0, /C=AT/ST=TU/O=privat/CN=server/emailAddress=mein_email@xyz.at
Mon Jan  5 21:24:21 2009 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Jan  5 21:24:21 2009 TLS Error: TLS handshake failed
Mon Jan  5 21:24:21 2009 TCP/UDP: Closing socket
Mon Jan  5 21:24:21 2009 SIGUSR1[soft,tls-error] received, process restarting
Mon Jan  5 21:24:21 2009 Restart pause, 2 second(s)
Mon Jan  5 21:24:23 2009 Re-using SSL/TLS context

Woran könnte es jetzt liegen, wie gesagt, die Files hab ich schon 100x überprüft und auch schon ein paar mal die kompletten Open-VPN Files neu erzeugt.

COLOSSUS

Administrator
GNUltra
Avatar
Registered: Dec 2000
Location: ~
Posts: 12060
Lass mal alle optionalen Komponenten aus den Certs raus (-> neue generieren), vielleicht funktioniert es dann.

Cpt. Google meint: http://gozer.ectoplasm.org/blog/arc...vpn-verify.html

jb

Here to stay
Registered: May 2000
Location: /home/noe/
Posts: 3513
So jetzt hab ich's irgendwie geschafft, daß der Client-WRT gar nicht mehr mag. Die Power LED blinkt mit ca. 3Hz, DMZ und WLAN sind finster und alle 4 LAN LEDs + WAN LED leuchten permanent, egal ob was dransteckt oder nicht. Werd mir jetzt doch mal so ein JTAG Kabel bauen glaub ich, denn alles andere was ich in Richtung Wiederherstellung kenne hat nicht gefruchtet.
:bash:

COLOSSUS

Administrator
GNUltra
Avatar
Registered: Dec 2000
Location: ~
Posts: 12060
Per TFTP funktioniert das Flashen eigentlich immer, es sei denn, du hast den Bootloader geschrottet (was ich im Zuge einer OpenVPN-Konfiguration ehrlichgesagt bezweifle ;)).

othan

Layer 8 Problem
Avatar
Registered: Nov 2001
Location: Switzerland
Posts: 4222
Wie schnell ist die Leitung zwischen den Routern?

ich habe mit einem cross-over kabel ca. 2-3 mbit durchgebracht (Asus 500gp, openvpn, beide hatten 100% cpu last).

jb

Here to stay
Registered: May 2000
Location: /home/noe/
Posts: 3513
Der Router am Land hat 2048/2048 (Funkinternet), der andere hängt an nem Chello Modem (8192/768).
Werds heute Nacht nochmals probieren, vielleicht war gestern einfach nur ein schlechter Tag.
Bearbeitet von jb am 06.01.2009, 17:20

nexus_VI

Overnumerousness!
Avatar
Registered: Aug 2006
Location: südstadt
Posts: 3733
Die Uhrzeiten bei den beiden Logfiles sind verdächtig weit auseinander ... ;)
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz