VPN-Server in Box integrieren

[Muldini]

Trag ich den push-Befehl in der Server- oder Clientconfig ein? Und übernehm ich den 1:1 oder trag ich für DNS eine IP ein?

Bleibt auch noch die Frage nach dem tap -> tun, muss ich auf mehr achten als das einfache ersetzen des Wortes auf beiden Seiten?

Und am wichtigsten, sofern der Eintrag auf Server Seite erfolgen muss, wie starte ich den Server mit der neuen config neu? Vorheriges abschalten fällt ja aus.

Grüße

 

[MaxMuster]

- beim Server
- Dabei müssen dann auch die ip-Daten verändert werden. Wenn du die Config aber so hast, kannst du es übrigens auch mit dem TAP lassen, denn du hast die Brücke ja nicht mit dem LAN verbunden, dann geht das noch ;-)
- Am besten mit einen "killall -HUP openvpn" (Du kannst natürlich auch erstmal mit den Windows-Bordmitteln dem VPN-Adapter als DNS-Server direkt 10.0.0.1 eintragen)

Jörg

 

[chriwi]

Hallo,

ich bin zurück, und versuche es weiter.
Ich habe heute nochmal versucht den Server zu starten (mit einer anderen openvpnversien (die von MaxMuster geratenen, die schon auf dem Client läuft)) bekomme jetzt aber folgendes Protokoll:

# ./openvpn --config openvpn.cfg
Mon Sep 17 21:14:06 2007 us=938309 OpenVPN 2.1_rc2 mipsel-linux [SSL] [LZO2] [EPOLL] built on Jul  9 2007
Mon Sep 17 21:14:06 2007 us=941832 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.
Mon Sep 17 21:14:06 2007 us=946491 WARNING: file '/var/media/ftp/USBDISK-Partition-0-1/client.key' is group or others accessible
Mon Sep 17 21:14:06 2007 us=949840 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Sep 17 21:14:06 2007 us=950872 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Sep 17 21:14:06 2007 us=953163 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Sep 17 21:14:06 2007 us=954195 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Sep 17 21:14:06 2007 us=957833 Assertion failed at tun.c:380
Mon Sep 17 21:14:06 2007 us=958609 Exiting
#

was ist jetzt wieder falsch?

.

 

[MaxMuster]

Dieser Fehler sollte nicht auftreten (ist ein interner OpenVPN-Fehler der dann auftritt, wenn OpenVPN ein Virtuelles Interface "befragt" ob es denn Point-to-Point sei oder nicht, und das Interface weder TUN noch TAP ist [was aber eigentlich nicht sein darf...])
Tritt das immer auf? Postest du bitte nochmal die aktuelle Config?

Jörg

 

[chriwi]

Hallo Max Muster,

hab die Config leider nicht hier, bin ja auf der arbeit und komme nichtmal an mein FTP-Server ran (wegen Firewall), ist aber vom Prinziep her die Minimal-Config, die du oben mal gepostet hast auch wieder ohne routing, weil das bei den letzten Versuchen immer zu unerreichbarkeit der Fritzbox geführt hat, deshalb wollte ich erstmal den Rest zum Laufen bekommen.
Vielleicht liegts jairgendwie an dem mknod-Befehl und dem Ort und Name des tun-Devices, muß esjetzt tun oder tun0 heißen und ist es OK das es unter /var/tmp/tun liegt und muß dieser Pfad in der Cnfig mit angegeben werden ("dev /var/tmp/tun" oder "dev tun"(habe eigentlich schon beides versucht ohne Änderung bei der Fehlermeldung))?
Außerdem habe ich gestern die VPN-Laborfirmware durch die aktuellste AVM-Software ersetzt, macht aber auch keien Unterschied.
Die Verbindungsrequests vom Client kann ich im Telnet übrigens manchmal sehen, das läuft scheinbar soweit.

.

 

[MaxMuster]

Es sollte so aussehen:

dev tun
dev-node /var/tmp/tun

Jörg

 

[chriwi]

Hallo MaxMuster,

muß das beides in die Config?

dev-node habe ich dort noch nie gesehen, aber vielleicht hilfts ja, muß ich heute abend mal probieren.

.

 

[MaxMuster]

Ja, muss beides rein! Der erste Punkt sagt: "Es ist ein Tunnel", der zweite sagt: Da ist das entsprechende Device (braucht man nur dann, wenn man das Device selbst anlegen musste, weil es nicht im normalen System ist. (Standard ist meiner Erinnerung nach "/dev/net/tun")

Ach, mir fiel gerade auf, du machst das ja beim Starten mit dem "--dev-node /var/tmp/tun", dann braucht es in die Konfig natürlich nicht nochmal rein...

Jörg

 

[chriwi]

Hallo MaxMuster,

danke für die Mühe, aber genau das ist wohl jetzt das Problem, den zusätzlichen Parameter "--dev-node /var/tmp/tun" hatte ich nach über einer Woche Pause beim Starten von Hand vergessen, ich glaube in der Config ist er eh besser aufgehoben, da kann er wenigstens nicht verloren gehen.
Werds wie gesagt heute abend nochmal versuchen und dann berichten.
Hoffe nur das man mit nem Tunnel über ne Strecke auf der auch Skype ein deutliches Rauschen liefert überhaupt was vernünftiges anfangen kann.

.

 

[chriwi]

Hallo,

OK, ich bin wieder so weit wie vorher von der anderen Seite, hatte beiden letzten Versuchen nur "dev-node" vergessen, aber sobald ich in einem 192.168.0.0 255.255.254.0 Network bei openvpn das routing 198.168.0.0 255.255.254.0 (identische Netzeauf beiden Seiten) aktiviere bricht hier das lokale Netz zusammen, extern funktioniert noch alles.
Also lieg es wohl daran, das sich überlappende IP-Bereiche nicht so ohne weiteres mit einer solchen Konfiguration durch ein VPN verbinden lassen. Leider ist es auch auf keiner der beiden Seiten so ohne weiteres möglich den IP-Bereich zu ändern.
Gibt es eien einfache Möglichkeit das ferne Netz jeweils auf virtuelle IP-Adressen im Lokalen Netz zu routen, immer unter der Voraussetzung dasdas mit den beiden vorhandenen Fritzboxen geschehen muß?

.

 

[MaxMuster]

Wenn ich mich so "zurück erinnere": Könntest du die "wichtigen" Geräte trennen? Also dass beim Client die 192.168.1.x und beim Server die 192.168.0.x Adressen sind? Dann könntest du jeweils einen Teil routen.

Das grundsätzliche Problem kannst du nicht lösen: Ein Netz kann nur auf einer Seite sein! (Ist genau so wie mit Adressen oder Telefonnummern: Die müssenunterscheidbar sein, sonst geht es schief!)
Die einzige Möglichkeit, damit klar zu kommen, wäre Bridging, was zum einen starke Netzlast erzeugt, zum andern müssen dann alle Adressen in den jeweiligen Netzen eindeutig sein!

Darauf hatte ich aber schon mehrfach hingewiesen, das es so mit überlappenden Netzen nicht geht...

Da jetzt noch mit Adressübersetzung (NAT) ranzugehen ist ziemlich aufwändig und eher nicht so sinnvoll.

Jörg

 

[chriwi]

Hallo MaxMuster,

im Clientnetz geht es mir ja primär um den Zugriff auf den Client(die FB7050) selbst, die anderen beiden PCs im Netz und der ZYXEL-Router interessieren mich erstmal weniger, die FB7050 hängt als ATA-Client im 192.168.0.0-Netz (da weis ich eh nicht so genau ob das mit dem Routen so richtig funktioniert, da sie janicht router des Netzes ist sondern der ZYXEL).
Kann man nicht irgendwie den tunnel nur mit den Ports der FB7050 verbinden damit sie eine lokale IP-Adresse hier in meinem hiesigen Heimnetz hat? Sie bräuchte fürs Erste nichtmal aus dem dortigen IP-Netz zugänglich sein, sie muß n nur das VPN über dieses Netz und den ZYXEL-Router aufbauen.
Ich kann das Netz dort nicht mehr ändern, weil ich von hier keine Zugriff auf den ZYXEL-Router habe und die Leute dort haben keine Anung wie man das macht(selbst der leitentende Techniker des örtlichen DSL-Anbielters hat danoch nie was von Portforwarding, VOIP oder gar VPN gehört), deshalb will ich auch nicht zu viele ungewöhnliche konfigurationen dort einbauen, weil das sonst keiner versteht.
Hier habe ich im Netz 192.168.1.0 einen Server mit diversen Diensten und vielen darauf verweisenden Portforwardings laufen, bei dem ich mir nicht sicher bin ob ich den ohen Problem in eine anderes Netzt verfrachten kann.

.

 

[MaxMuster]

Dann wird es ja einfacher!
Der Client selbst ist ja schon über die VPN-IP erreichbar, da kannst du das Routing von der Server-Seite komplett weglassen! Du müsstest jetzt nur noch sicherstellen, dass du aus deinem Netz die Clientbox mit einer IP ansprichst, die es in dem Netz vor Ort nicht gibt (sagen wir mal 192.168.0.234). Dann trägst du auf auf dem Client eine Route für den PC ein:

route 192.168.0.234 255.255.255.255

und kannst aus dem "Servernetz" die 192.168.200.2 als "andere" Box erreichen...
Evtl kannst du das dann auf einen "größeren Bereich" von IPs ausweiten, die in den beiden Netzen sicher nur auf einer Seite vergeben sind.

Jörg

 

[chriwi]

Hallo MaxMuster,

das klingt sehr vielversprechend und wäre wohl genau die richtige Lösung für mich.
Nur ist mir nicht ganz klar wie das ohne Routing vom Server her funktionieren soll, woher weis das Rotuing dann das genau diese Adresse vom Serv er aus über das VPN gerouted werden soll? Muß nicht beim Server diese route eingestellt werden und beim Client nur sichergestellt das das die Pakete von tun0 nach localhost kopiert (gerouted?) werden und reverse.

> und kannst aus dem "Servernetz" die 192.168.200.2 als "andere" Box erreichen...
da haperts wohl irgendwo auch noch, aber ich dachte das läge vielleicht am Routing:
Ich kann nur 192.168.200.1 anpingen, von 192.168.200.2 bekomme ich keine Antwort.
Mit --verb 10 bekomme ich folgenden Meldungen:
"event_wait returned 0" (während eines Ping Versuchs auch andere returned Values)
Ist das OK oder wie kann ich sonst den Status der VPN- Verbindung überprüfen, hilft vielleicht noch ein höherer verbosity-level und wo gibt es eine Beschreibung diese Meldungen zu interpretieren?

Mikr geht es hauptsächlich darum später eine SIP-Verbindung über das VPN aufzubauen (weil dies die einzie Möglichkeit ist (Direktverbindung scheidet wegen doppeltem NAT und fehlendem Portfoewarding aus, anmeldung bei Europäischen SIP-Providern klappt nur selten bis nie und lokale SIP-Anbieter gibt es nicht weil die nationale Telefongesellschaft das nicht erlaubt)) .

.

 

[MaxMuster]

Was dir fehlt, ist die Rückroute. Der Client antwortet vermutlich in die falsche Richtung (sofern du die Route noch nicht eingetragen hast), weil der die Anfrage nicht als "aus Deutschland kommend" erkennt, sondern denkt, die käme aus dem eigenen LAN.

Also, mal etwas langsamer, ich mache das mal mit Straßen und Adressen:

Du hast auf beiden Seiten das gleiche Netz, also wohnen alle in der gleichen "Hauptstraße", nur an unterschiedlichen Orten, und alle können immer nur ihre "echten" Nachbarn erreichen, wenn sie jemand in der Hauptstraße besuchen wollen.

Nun hast du eine "Verbindungsstraße" zwischen den beiden gebaut, an der es auch Adressen gibt. Wenn du nun in einem der beiden Häusern an der Verbindungsstraße wohnst, kannst du das andere Haus erreichen, schließlich ist die Adresse ja "Verbindungsstraße 2" und du bist in "Verbindungstraße 1". Also: kein Problem. Wenn dir jemand einen Brief für "Verbindungstraße 2" mitgibt, kannst du den dort abgeben. Das Problem ist: Die Antwort wird nie ankommen, weil der Absender "Hauptstraße 12" ist und der in der Verbindungsstraße 2 sagt: Klar, Hauptsraße, das ist ja hier vor der Tür (was natürlich falsch ist). Also muss auch der Absender "eindeutig sein" , und das machtst du mit dem Routing...

Übertragen: Die beiden beteiligten Geräte "kennen" das verbindungsnetz 192.168.200.x, dafür ist kein Routing nötig, und sie selbst "reagieren" auch auf die Adressen, es ist (übertragen) eine Weitere Tür im selben Haus an einer anderen Straße.
Sichergestellt werden muß nur, das Pakete aus dem jeweils anderen Netz wieder zurück finden, dafür sollten sie lokal nicht vergeben sein und das Routing zum jeweils anderen VPN-Router über dessen VPN-IP muss eingetragen werden.

Jörg

 

[chriwi]

Hallo MaxMuster,

gute Beschreibung, got the point.
Nur ist mir nicht klar was ich jetzt in die openvpn.cfg auf welcher Seite eintragen muß. ?) Ergibt sich hier vielleicht wieder das Problem das die Fritzboxen in Beiden Netzwerken die selb IP-Adresse haben, das könnte ich aber ohne große Probleme ändern, muß ich dann also die IP-Adresse der hiesigen Fritzbox von 192.168.0.254 auf 1921.68.0.253 ändern (schade, der erste wert ist bei Knoppix glaube ich default für den Nameserver) und beim Client "route 192.168.0.253 255.255.255.255" eintragen?

Außerdem muß ich vielliecht noch dazusagen das ich die Ping-Versuche immer direkt von der konsole der jeweiligen Fritzbox mache und nicht von DOS-Fenster des PC.

Und nochmal die Frage ist fortlaufendes "event_wait returned 0" im Sekundentakt richtig für eine stehende VPN-Verbindung oder ist das auch eine Anzeichen für einen Fehler?

.

 

[MaxMuster]

Also, du musst nur im Client ein Routing eintragen. Und auch das nur für Geräte aus dem Server-LAN, die die Clientbox erreichen sollen. Die LAN-IPs der Boxen sind dafür unerheblich, weil die beiden sich ja direkt über die VPN-IPs unterhalten.

Aber nochmal zurück: Die Boxen können sich gegenseitig nicht über die VPN-IP anpingen?!? Also kannst du von der Serverbox die Clientbox nicht erreichen? Dann liefe das VPN nicht.

Jörg

 

[chriwi]

Hallo Jörg,

"ping 192.168.200.2" von der Konsole der Serverbox liefert keine replies, alledings dachte ich das Deien Straßen und hausnummern Beschreibung schon den Grund für das mißlingen beinhaltet, die FB7050 auf den Philippiene bekommt einen Ping Request mit der lokalen IP-Adresse der FB7170 hier alsabsender also 192.168.0.254, was lokal wiederum die Adresse der FB7050 auf den Philippienen entspricht also würde sie versuchen sich selbst zu antworten und nicht über das VPN, oder sehe ich das falsch?
Beim route oder if config werden die tun0 devices und die Gateways jedenfalls angezeigt, ich weis halt nicht ob das schon ausreicht eine bestehende Verbindung zu verifizieren, deshalb reite ich ja auch immer wieder auf der Interpretation der "event_wait returned 0" Meldungen oder einer sonstigen Möglichkeit zur Bestimmung des Status der VPN-Verbindung herum.
Die Rx-Werdte von tun0 bei ifconfig zeigen halt immer den Wert 0.

Christian

.

 

[MaxMuster]

Nein, dabei ist das IP-Protokoll "intelligent": Die "Absendeadresse" ist die "aus deren Tür ich zum Ziel gehe".
Da die Boxen die jeweilig andere Adresse 192.168.200.x "hinter dem Tunnel" wissen, senden sie ihre Tunnel-IP als Absende-IP.

Mir scheint ernsthaft, der VPN-Tunnel steht nicht. Sihest du den "read" und "write" Daten?
Blöde Frage: Hast du den Key wieder "zurückgedreht" nach dem Test?!?

Jörg

 

[chriwi]

Hallo Jörg,

na gut dann müsste das ja klappen.

Ich verwende sicher auf beiden Seiten den Selben key, stammen vorläufig sogar noch immer von der selben Quelle (FTP-Server der FB7170), sollte also nicht das Problem sein.

Read- und Write-Daten, da sehe ich auch das Problem, bei ifconfig seh ich bei tun0 halt nur bei Tx Daten Rx steht fest auf 00000.

Kommt der Sekundentakt der zyklischen Meldungen "event_wait ..." eigentlich vom Server oder kommt nur für jedes Tunnelpaket eine Meldung?
Irendwann, mehr per Zufall habe ich ja mal abgelehnte Requestpakete vom Clien in der Konsole des Servers gesehen, gibt es da noch ne verlässlichere Möglichkeit anzuzeigen ob Requests vom Client reinkommen oder nicht.
Gibt es irgendwo eigentlich ne Beschreibung der Verbosity Meldungen von openvpn?

.