VPN-Server in Box integrieren

[MaxMuster]

Hi,

hast du (oder hatte ich?) die Einträge vertauscht? Der Server hatte doch das Standard-Netz (192.168.178.0) und der Client 192.168.0.0 ?

Wenn das "verkehrt rum" eingetragen wäre, würde der Server sein eigenes Netz (192.168.178.0) in Richtung des Clients schicken....

EDIT: Ach so, wenn das so wäre sollte aber die VPN-Verbindung (auf die 192.168.200.1) noch funktionieren.

Jörg

 

[chriwi]

Hallo MaxMuster,

doch daran wirds wohl liegen, da ich beide Boxen auf 192.168.1.254 bzw. 192.168.0.254 jeweils mit 255.255.254.0 konfiguriert habe, deshalb ist das 192.168.178.0 Netz auf dem server jetzt natürlich falsch, aber jetzt kann ich wohl nichs mehr daran ändern, jetzt ist sogar die Nabelschnur gerissen.
Kein Proble, kann ich ja alles richten wenn ich wieder zu Hause bin nurmuss ich dann bei jeder Änderung auf dem Client hier auf den Philippienen anrufen damit mal jemand kurz den Netzstecker zieht.

.

 

[MaxMuster]

Das ist aber keine gute Idee mit den Adressen. Du solltest die Bereiche nicht überlappend vergeben, also jeweils die Maske 255.255.255.0.

Du solltest aber weiterhin über die VPN-Verbindung von der einen auf die andere Box kommen (von 192.1668.200.2 auf 192.168.200.1), damit könntest du das wieder "gerade biegen", indem du das Routing entfernst ("route del 192.168.0.0 255.255.254.0 gw 192.168.200.2")

Jörg

 

[maceis]

Ich hab's zwar in diversen Threads schon öfter gesagt, aber ich denke, man kann es nicht oft genug wiederholen.
Auf der OpenVPN.net Website gibt es erstklassige detailierte Anleitungen in den Howto Seiten.
Wenn man das liest und nachmacht, kann nicht mehr viel schiefgehen.

 

[chriwi]

Hallo ,

alos ich komme an den server nicht mehr ran, aber am Samstag fliege ich eh zurück, jetzt kann ich nur noch versuchen sicherzustellen das auf dem Client alles läuft.
Ich habe "verb 10" aktiviert und der las log zeig folgende schleifen:

/var/mod/root # Thu Sep  6 00:18:44 2007 us=178000 OpenVPN 2.1_rc2 mipsel-linux [SSL] [LZO2] [EPOLL] built on Jul  9 2007
Thu Sep  6 00:18:44 2007 us=188000 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.
Thu Sep  6 00:18:44 2007 us=198000 WARNING: file '/var/tmp/client.key' is group or others accessible
Thu Sep  6 00:18:44 2007 us=198000 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Sep  6 00:18:44 2007 us=208000 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep  6 00:18:44 2007 us=218000 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Sep  6 00:18:44 2007 us=218000 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Sep  6 00:18:44 2007 us=358000 TUN/TAP device tun0 opened
Thu Sep  6 00:18:44 2007 us=358000 TUN/TAP TX queue length set to 100
Thu Sep  6 00:18:44 2007 us=368000 /sbin/ifconfig tun0 192.168.200.2 pointopoint 192.168.200.1 mtu 1500
Thu Sep  6 00:18:44 2007 us=438000 /sbin/route add -net 192.168.178.0 netmask 255.255.255.0 gw 192.168.200.1
Thu Sep  6 00:18:44 2007 us=508000 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:4 ET:0 EL:0 ]
Thu Sep  6 00:18:44 2007 us=508000 Socket Buffers: R=[65535->131070] S=[65535->131070]
Thu Sep  6 00:18:44 2007 us=508000 UDPv4 link local (bound): [undef]:1194
Thu Sep  6 00:18:44 2007 us=508000 UDPv4 link remote: 91.21.180.21:1194
Thu Sep  6 00:18:44 2007 us=508000  event_wait returned 1
Thu Sep  6 00:18:44 2007 us=508000  read from TUN/TAP returned 36
Thu Sep  6 00:18:44 2007 us=518000  event_wait returned 1
Thu Sep  6 00:18:44 2007 us=518000 UDPv4 WRITE [76] to 91.21.180.21:1194:  DATA efa642f7 fe4935e2 e2d7b6bf e2ec159a aab7ec53 1d6133f7 003098b8 a527126[more...]
Thu Sep  6 00:18:44 2007 us=518000 UDPv4 write returned 76
Thu Sep  6 00:18:44 2007 us=518000  event_wait returned 1
Thu Sep  6 00:18:44 2007 us=518000  read from TUN/TAP returned 32
Thu Sep  6 00:18:44 2007 us=518000  event_wait returned 1
Thu Sep  6 00:18:44 2007 us=518000 UDPv4 WRITE [76] to 91.21.180.21:1194:  DATA a65fce98 09cc2b06 29421534 fec1c95e de37915f 99f87e43 64184c36 dd925f2[more...]
Thu Sep  6 00:18:44 2007 us=518000 UDPv4 write returned 76
Thu Sep  6 00:18:44 2007 us=528000  event_wait returned 1
Thu Sep  6 00:18:44 2007 us=528000  read from TUN/TAP returned 32
Thu Sep  6 00:18:44 2007 us=528000  event_wait returned 1
Thu Sep  6 00:18:44 2007 us=528000 UDPv4 WRITE [76] to 91.21.180.21:1194:  DATA 36b21ace 1f016f5b 297188f0 ec8c720d 61d84679 1a596f60 190fff20 bdfe911[more...]
Thu Sep  6 00:18:44 2007 us=528000 UDPv4 write returned 76
Thu Sep  6 00:18:45 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:45 2007 us=378000  read from TUN/TAP returned 84
Thu Sep  6 00:18:45 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:45 2007 us=378000 UDPv4 WRITE [124] to 91.21.180.21:1194:  DATA be66f4b0 168909e9 ef2dcc0a 4edfd06c 06fa37a6 25f237e8 5d98d834 c1e8b66[more...]
Thu Sep  6 00:18:45 2007 us=378000 UDPv4 write returned 124
Thu Sep  6 00:18:45 2007 us=858000  event_wait returned 1
Thu Sep  6 00:18:45 2007 us=858000  read from TUN/TAP returned 32
Thu Sep  6 00:18:45 2007 us=858000  event_wait returned 1
Thu Sep  6 00:18:45 2007 us=858000 UDPv4 WRITE [76] to 91.21.180.21:1194:  DATA 3ebf3792 1bc35ff9 3abd7b0e 212e62a1 d13afb28 080068bc 4db0084e 63531be[more...]
Thu Sep  6 00:18:45 2007 us=858000 UDPv4 write returned 76
Thu Sep  6 00:18:46 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:46 2007 us=378000  read from TUN/TAP returned 84
Thu Sep  6 00:18:46 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:46 2007 us=378000 UDPv4 WRITE [124] to 91.21.180.21:1194:  DATA 8314d9cd 4c29dfd1 92d2119c 4d361a37 9b05e3f0 d348f994 d101ec59 709f6c0[more...]
Thu Sep  6 00:18:46 2007 us=378000 UDPv4 write returned 124
Thu Sep  6 00:18:47 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:47 2007 us=378000  read from TUN/TAP returned 84
Thu Sep  6 00:18:47 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:47 2007 us=378000 UDPv4 WRITE [124] to 91.21.180.21:1194:  DATA 6a2e01dc 75fdc32e 88e30527 5b885b7a bb33070e cf8ea057 8ddbea95 ca434b3[more...]
Thu Sep  6 00:18:47 2007 us=378000 UDPv4 write returned 124
Thu Sep  6 00:18:48 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:48 2007 us=378000  read from TUN/TAP returned 84
Thu Sep  6 00:18:48 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:48 2007 us=378000 UDPv4 WRITE [124] to 91.21.180.21:1194:  DATA 5f95bc65 8e7527a3 de661ed3 772efff9 1a7c4cb3 65df8f06 a4c3762e c7ae075[more...]
Thu Sep  6 00:18:48 2007 us=378000 UDPv4 write returned 124
Thu Sep  6 00:18:49 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:49 2007 us=378000  read from TUN/TAP returned 84
Thu Sep  6 00:18:49 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:49 2007 us=378000 UDPv4 WRITE [124] to 91.21.180.21:1194:  DATA 5fad2d06 33d31039 3b97e34d 1d6a5271 ccbe4f97 63d94145 5b7999e4 ecb3924[more...]
Thu Sep  6 00:18:49 2007 us=378000 UDPv4 write returned 124
Thu Sep  6 00:18:50 2007 us=328000  event_wait returned 1
Thu Sep  6 00:18:50 2007 us=328000  read from TUN/TAP returned 32
Thu Sep  6 00:18:50 2007 us=328000  event_wait returned 1
Thu Sep  6 00:18:50 2007 us=328000 UDPv4 WRITE [76] to 91.21.180.21:1194:  DATA 2c9cd225 960514ea d07f57c7 f1021d3e 2a9c2372 fae83c89 ba327434 8b66a8a[more...]
Thu Sep  6 00:18:50 2007 us=328000 UDPv4 write returned 76
Thu Sep  6 00:18:50 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:50 2007 us=378000  read from TUN/TAP returned 84
Thu Sep  6 00:18:50 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:50 2007 us=378000 UDPv4 WRITE [124] to 91.21.180.21:1194:  DATA 403629c7 6b4fd8db 8e9467c6 b570298f f9defe9f 9c3ea8a0 d8fbd278 db697a5[more...]
Thu Sep  6 00:18:50 2007 us=378000 UDPv4 write returned 124
Thu Sep  6 00:18:51 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:51 2007 us=378000  read from TUN/TAP returned 84
Thu Sep  6 00:18:51 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:51 2007 us=378000 UDPv4 WRITE [124] to 91.21.180.21:1194:  DATA d3904ea4 899bea57 83428876 f69c8b13 dba3a254 c8a1ab92 ff196efd 4301c20[more...]
Thu Sep  6 00:18:51 2007 us=378000 UDPv4 write returned 124
Thu Sep  6 00:18:52 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:52 2007 us=378000  read from TUN/TAP returned 84
Thu Sep  6 00:18:52 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:52 2007 us=378000 UDPv4 WRITE [124] to 91.21.180.21:1194:  DATA cf64ebe1 dd3dd6c8 1037bc0f 902cff0d ca45f90c 2df54f2a f9229e48 6419cd3[more...]
Thu Sep  6 00:18:52 2007 us=378000 UDPv4 write returned 124
Thu Sep  6 00:18:53 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:53 2007 us=378000  read from TUN/TAP returned 84
Thu Sep  6 00:18:53 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:53 2007 us=378000 UDPv4 WRITE [124] to 91.21.180.21:1194:  DATA bbaee816 437b3934 b2d083ae dc529256 f1db6b41 59d819a4 b9501847 1b89c57[more...]
Thu Sep  6 00:18:53 2007 us=378000 UDPv4 write returned 124
Thu Sep  6 00:18:54 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:54 2007 us=378000  read from TUN/TAP returned 84
Thu Sep  6 00:18:54 2007 us=378000  event_wait returned 1
Thu Sep  6 00:18:54 2007 us=378000 UDPv4 WRITE [124] to 91.21.180.21:1194:  DATA eec06b8a c0079a6d 5938c3e1 14fa0262 a6f25b1e 77082a6c ab5d1cd3 a267c83[more...]
Thu Sep  6 00:18:54 2007 us=378000 UDPv4 write returned 124
/var/mod/root # killall openvpn
Thu Sep  6 00:18:55 2007 us=258000  event_wait returned -1
Thu Sep  6 00:18:55 2007 us=258000 event_wait : Interrupted system call (code=4)
Thu Sep  6 00:18:55 2007 us=258000 TCP/UDP: Closing socket
Thu Sep  6 00:18:55 2007 us=258000 /sbin/route del -net 192.168.178.0 netmask 255.255.255.0
/var/mod/root # Thu Sep  6 00:18:55 2007 us=338000 Closing TUN/TAP interface
Thu Sep  6 00:18:55 2007 us=348000 SIGTERM[hard,] received, process exiting

/var/mod/root #

ist das soweit OK?
Und was sagt das darüber aus ob der Server überhaupt erreicht wird und ob die Ports durchkommen?

.

 

[MaxMuster]

Leider sagt das so, ohne etwas von der Server-Seite zu sehen wenig.
Du bist im Moment "vor Ort" beim Client, nicht wahr? Dann könnte ich dir anbieten, dass du deine Konfig mit dem anhängenden Key benutzt, den ich gerade generiert habe. Ich lasse dir später per PN mal eine IP zukommen, unter der ich dann eine Box mit "deiner Konfig" laufen lasse.
Wenn es dann klappt, sollte alles gut werden...

Jörg

 

[Muldini]

IP-Adressen Bahnhof

Hallo,

ich bin dabei OpenVPN auf meine Frizbox (7141) zu bringen. (nach dieser Anleitung)
Der Hintergedanke ist, mich von überall (Uni, Arbeit etc. etc.) in das heimische Netz einzuwählen und von da aus weiter ins Internet bzw. auf die dort vorhandenen Rechner zuzugreifen. Praktisch einen Tunnel aus dem "unsicheren" öffentlichen Uni-/Arbeits- Netz nach Hause und von da weiter und/oder zurück.

Das sollte nach Möglichkeit mit mehreren PCs gleichzeitig funktionieren.
Bin ich da mit OpenVPN richtig oder eignet sich etwas anderes besser?

Mein heimisches Netz besteht aus der FritBox (192.168.0.1 / 255.255.255.0) und mehreren Rechnern (192.168.0.20+ / 255.255.255.0). Die IP-Adressen und Subnetzmasken variieren an Uni- und Arbeitsplatz stark, daher meine Frage wie die Server- und Client- Configs auszusehen haben, da ja nur das Servernetz "bekannt" ist?

Ich hoffe ich hab vor lauter Verwirrung nichts wichtiges vergessen, ansonsten bitte ich euch mich darauf hinzuweisen, dann werde ich versuchen das nachzureichen.

Vielen Dank,
Muldini

 

[MaxMuster]

Erstmal sind grundsätzlich die Netzwerke und deren Masken, aus denen du zugreifen willst, ohne Belang, weil du im VPN virtuelle Netzwerkadapter bekommst, die im VPN vergeben werden. Mit diesem Adapter nimmt dann der Client am VPN teil.
Wie du ja gelesen hast gibt es zwei Möglichkeiten, einen Tunnel oder eine Brücke. Erstmal solltest du dich da entscheiden, was du brauchst/willst, denn: Ja, OpenVPN ist dafür ganz gut geeignet.

Für beide Wege gibt es gute Anleitungen und Vorschläge, hier solltest du "wieder anklopfen", wenn du ein konkretes Problem/eine konkrete Frage hast oder die, falls ich zu blöd war, die zu erkennen ;-), nochmal neu stellen...

Jörg

 

[Muldini]

Das klingt ja schon mal vielversprechend, ich muss - glaube ich - allerdings das Pferd von hinten aufzäumen was die Entscheidung Brücke oder Tunnel angeht, weil ich da einfach überfragt bin.

Ich kann das Szenario also nur noch ein mal verdeutlichen und dann auf euren Rat hoffen, was in diesem Fall das "sauberste" wäre.

Ich habe im Normalfall 2 Notebooks, die an der Uni bzw. bei der Arbeit eine IP Adresse zugewiesen bekommen, die Adressen unterscheiden sich je nach Gebäude.

Zu Hause habe ich die FritzBox (192.168.0.1) stehen, auf der der OpenVPN Server laufen soll. Die FB ist gleichzeitig HTPC Server für das heimische Netzwerk (192.168.0.X).

Jetzt möchte ich von den beiden Notebooks jeweils eine sichere Verbindung zur Fritzbox aufbauen um:
1) über meine FB zu Hause ins Internet zu kommen und
2) auf die Rechner hinter der FB zugreifen zu können
Bedingung: das Arbeits-LAN (also lokale Drucker, File Server etc.) müssen erreichbar bleiben. Kann es sein dass dieser Punkt die Brücke ausschließt?

Hintergrund für 1) ist, das z.b. das Unigelände eine offene WLAN Verbindung ist, 2) dürfte klar sein.


Daraufhin habe ich mich also an die oben erwähnte Anleitung gemacht, Telnet und FTP eingerichtet und stecke jetzt bei den config Dateien fest, im speziellen hier:

#server:
#Routen setzen, bei route Subnetz des Clients
# bei push Subnetz des eigenen Servers eintragen
route 192.168.2.0 255.255.255.0 10.0.0.5
push "route 192.168.178.0 255.255.255.0"
push "redirect-gateway"


#client:
#Routen setzen, bei route Subnetz der Server-Box
# bei push Subnetz der eignen Client-Box eintragen
;route 192.168.178.0 255.255.255.0
;push "route 192.168.2.0 255.255.255.0"

Es will mir irgendwie nicht einleuchten was hier einzutragen ist. Ich bitte also vielmals um Hilfe

Grüße

 

[MaxMuster]

O.k., fangen wir mal an:

Die Frage nach Brücke/Tunnel ist auf zwei Fragen zurückzuführen:
- Benötigst du "nicht routbare" Verbindungen? Ein "schlechtes" (weils eben nicht schön ist ;-)) Beispiel sind "Windows Netzwerkzugriffe mit Namen" (aber auch dafür gibt es Möglichkeiten, das anders zu machen)
- Wieviel Verkehr soll da durch gehen.

Der Tunnel ist immer dann Verbindung der Wahl, wenn relativ große Datenmenge im LAN und über die Verbindung gehen sollen, denn über den Tunnel gehen nur explizit für die "Gegenseite" bestimmte Pakete. Die Brücke kopiert alles auf die andere Seite, viel Traffic im LAN kann daher die VPN-Verbindung belasten, ohne dass das eigentlich notwendig wäre. Dafür sind eben solche "Windows-Geschichten" damit meist einfacher...

Wenn du mit mehreren Clients zureifen willst,ist dann der Weg mit Zertifikaten für dich das "Mittel der Wahl". Dein Problem hast du schon ganz gut erkannt, denn du möchtest ja "Multiclient"-Fähig sein. Sofern du aber nur mit dem Client zugreifen willst, ist das garnicht so wild:

Der Server (also deine FBox) sollte also dein "Heimnetz" als Route schicken per "push" (nicht die Standard 192.168.178.0 sondern "deine" 192.168.0.0). Das "redirekt-gateway" sorgt dann dafür, dass der Internettraffic auch über diesen Tunnel und dann über die Box geht.
Du müsstest drauf achten, dass eventuell neben dem lokalen Netz, in dem sich dein Client-Rechner befindet, eventuell noch andere Netze über die Defalutroute erreicht werden, was dir der Parameter "wegnimmt": Beispiel: Das UNI-Netz ist 1.2.3.0 255.255.255.0 DG 1.2.3.1. Wenn nun die UNI-Server im Netz 1.2.4.0 sind, und dafür die vorhandene Default-Route über das DG genutzt würde, sind diese Server nach dem "redirect-gateway" dann auch nichtmehr erreichbar...
Einen "route <Netz> <Maske>" Eintrag brauchst du nicht, du willst ja nicht aus dem "Heimnetz" ins Uninetz zugreifen oder so.

Beim Client reicht dann ein "pull" und er bekommt alles was er braucht vom Server.
Du solltest die Client-Adresse per "ifconfig-pool" vergeben lassen, dann ist diese Arbeit schonmal weg.

Also bleibt für dich jetzt folgendes zu tun:
Zertifikate erstellen (siehe WIKI)
Tunnel-Brücken Entscheidung treffen
-> danach IPs für die VPN-Verbindung festlegen. Beim Tunnel ein eigenes Netz, was "unbenutzt" ist sowohl bei dir als auch an den Client-Orten (UNI und Arbeitsplatz), bei Brücke ein "freier" Bereich aus deinem lokalen LAN.
Dieser Adressbereich kommt dann in den "ifconfig-pool"

Das sollte es gewesen sein...

Jörg

 

[Muldini]

Wow, erstmal ein riesen Danke für die ausführliche Erklärung Jörg!

Klappt 1a, habe mich für die Tunnel-Variante entschieden und alle Einstellungen wie von dir erläutert vorgenommen.
Bei der ersten Verbindung konnte ich nach dem Verbinden allerdings auf nichts zugreifen, kann das daran gelegen haben, dass ich aus dem LAN auf die interne IP (192.168.0.1) zugegriffen habe (als remote host)?
Ein schneller Test aus dem WLAN meines Nachbarn ( ) zeigte dann dass es klappt, scheinbar jetzt auch aus dem eigenen LAN wenn ich als remote host meine dyndns Adresse eintrage. Morgen folgt dann der Test von der Arbeit aus.

Einige offen gebliebene Fragen:
- ist die Verbindung jetzt schon automatisch verschlüsselt oder sind dafür weitere Schritte notwendig?
- kann ich den eingehenden Port ändern? (xxxx -> 1194) ?
- wie sage ich meinem Notebook(also den Programmen die ich nutze) jetzt was über das VPN und was über das LAN gehen soll? Beispiel: der komplette Internetverkehr soll über das VPN gehen (IM, Email, ...); ein Druckauftrag hingegen soll einfach in das Firmennetz geschickt werden.
- wie unterbinde ich bei VPN-Verbindungsverlust den Versuch von z.B. Mozilla über das LAN ins Internet zu gelangen?

Ich hoffe die Fragen sind gerade noch im Rahmen, geht hier ja eigentlich um OpenVPN.

Nochmal vielen Dank!

 

[MaxMuster]

Einige offen gebliebene Fragen:
- ist die Verbindung jetzt schon automatisch verschlüsselt oder sind dafür weitere Schritte notwendig?
- kann ich den eingehenden Port ändern? (xxxx -> 1194) ?
- wie sage ich meinem Notebook(also den Programmen die ich nutze) jetzt was über das VPN und was über das LAN gehen soll? Beispiel: der komplette Internetverkehr soll über das VPN gehen (IM, Email, ...); ein Druckauftrag hingegen soll einfach in das Firmennetz geschickt werden.
- wie unterbinde ich bei VPN-Verbindungsverlust den Versuch von z.B. Mozilla über das LAN ins Internet zu gelangen?

• Ja (ohne weitere Einstellung wird "Blowfish" als Verschlüsselung gewählt)
• Wenn du die Portweiterleitung über die ar7.cfg gemacht hast, kannst du dann "vorne" einen anderen Port eintragen und "hinten" 1194 (udp 0.0.0.0:4711 0.0.0.0:1194) oder auch beides (damit es übersichtlich bleibt: udp 0.0.0.0:4711 0.0.0.0:4711) und dann in der Server-Config z.B. "port 4711" angeben
• Wenn du den "redirect-gateway" Befehl drin hast (eventuell musst du vorher noch das Gateway des Servers mit push "route-gateway <Server-VPN-IP>" bekanntgeben) sollte das funktionieren: Der Befehl sucht dein altes DG (default gateway), richtet eine Route zum VPN-Server über das alte DG ein und trägt als neues DG den VPN-Server ein. Als Resultat sollte alles, wofür du lokal auf dem Client eine Route hast, danach auch lokal bleiben, alles, was über die Defaultroute ging, über den VPN-Server. Daher oben mein Hinweis: Wenn du "lokal" was erreichen musst, was über die Defaultroute erreicht wurde, musst du dafür eventuell "von Hand" eine Route eintragen...
• Solange dein VPN aktiv ist, greift auch die veränderte Defaultroute und das sollte nicht passieren, sondern der Client sollte versuchen, die VPN-Verbindung wieder herzustellen...

Jörg

 

[Muldini]

Morgen

Leider muss ich mich zurückmelden, die Verbindung von der Arbeit aus klappt,
ich bekomme eine IP zugewiesen und kann auf die FB zugreifen, (telnet über die VPN / Webinterface). Jegliche andere Art von traffic scheint nicht zu funktionieren, Internetseiten werden nicht angezeigt etc.

Wie kann ich weiter vorgehen um die Ursache zu erkennen?

Gruß

 

[MaxMuster]

Das Wichtigste wäre die Routingtabelle des Clients, am besten einmal vor und einmal nach dem Verbinden mit dem Server (zur Not kannst du ja "geheime" Netze aus-x-en, solange es eindeutig bleibt)
Dann wären die kompletten Configs gut und (evtl später, je nachdem, ob man was sieht) noch ein Log vom Server.

Jörg

 

[Muldini]

Soo,

Routingtabelle ohne VPN connect:

===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 ff 80 f7 d4 5c ...... TAP-Win32 Adapter V9
0x10004 ...00 19 d2 0c 0a d2 ...... Intel(R) PRO/Wireless 3945ABG Network Connection
0x10005 ...00 a0 d1 a1 7a 07 ...... Broadcom NetLink (TM) Gigabit Ethernet
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0   192.168.30.254  192.168.30.130	  25
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1	  1
     192.168.30.0    255.255.255.0   192.168.30.130  192.168.30.130	  25
   192.168.30.130  255.255.255.255        127.0.0.1       127.0.0.1	  25
   192.168.30.255  255.255.255.255   192.168.30.130  192.168.30.130	  25
        224.0.0.0        240.0.0.0   192.168.30.130  192.168.30.130	  25
  255.255.255.255  255.255.255.255   192.168.30.130           10005	  1
  255.255.255.255  255.255.255.255   192.168.30.130  192.168.30.130	  1
  255.255.255.255  255.255.255.255   192.168.30.130               2	  1
Standardgateway:    192.168.30.254
===========================================================================
St„ndige Routen:
  Keine

Routingtabelle mit VPN connect:

===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 ff 80 f7 d4 5c ...... TAP-Win32 Adapter V9
0x10004 ...00 19 d2 0c 0a d2 ...... Intel(R) PRO/Wireless 3945ABG Network Connection
0x10005 ...00 a0 d1 a1 7a 07 ...... Broadcom NetLink (TM) Gigabit Ethernet
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0         10.0.0.1        10.0.0.3	  1
         10.0.0.0    255.255.255.0         10.0.0.3        10.0.0.3	  30
         10.0.0.3  255.255.255.255        127.0.0.1       127.0.0.1	  30
   10.255.255.255  255.255.255.255         10.0.0.3        10.0.0.3	  30
    dyndns-adresse  255.255.255.255   192.168.30.254  192.168.30.130	  1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1	  1
      192.168.0.0    255.255.255.0         10.0.0.1        10.0.0.3	  1
     192.168.30.0    255.255.255.0   192.168.30.130  192.168.30.130	  25
   192.168.30.130  255.255.255.255        127.0.0.1       127.0.0.1	  25
   192.168.30.255  255.255.255.255   192.168.30.130  192.168.30.130	  25
        224.0.0.0        240.0.0.0         10.0.0.3        10.0.0.3	  30
        224.0.0.0        240.0.0.0   192.168.30.130  192.168.30.130	  25
  255.255.255.255  255.255.255.255         10.0.0.3        10.0.0.3	  1
  255.255.255.255  255.255.255.255   192.168.30.130  192.168.30.130	  1
  255.255.255.255  255.255.255.255   192.168.30.130           10005	  1
Standardgateway:          10.0.0.1
===========================================================================
St„ndige Routen:
  Keine

client config:

# OpenVPN v2.0.5 config:
####################################################
# Authentifizierung und Verschluesselung
keys und so ...

####################################################
# Grundsaetzliches
dev tap
proto udp
#for 2.4: dev-node /dev/misc/net/tun 
# for 2.6:
#do not forget to insert onto shell: mknod /var/tmp/tun c 10 200
dev-node VPN

nobind


####################################################
# Client-Einstellungen
tls-client
ns-cert-type server #for OVP2.0 and below: check the server.crt
pull	# Fetch configuration from Server


####################################################
# Server-Einstellungen
remote mein-dyndns 1194    #Server IP/URI und evtl. port anpassen

####################################################
## Enable compression
## server & client entry must be equal!
comp-lzo

####################################################
# Protokollierungseinstellung
verb 4

####################################################
# Daemon
;daemon #ausführung im Hintergrund


#server:
#Routen setzen, bei route Subnetz des Clients
# bei push Subnetz des eigenen Servers eintragen
#route 192.168.xx.0 255.255.255.0
#push "route 192.168.yy.0 255.255.255.0"


#client:
#Routen setzen, bei route Subnetz der Server-Box
# bei push Subnetz der eignen Client-Box eintragen
#route 192.168.178.0 255.255.255.0 10.0.0.1
#push "route 192.168.1.0 255.255.255.0"


# Don't close and reopen TUN/TAP device or run up/down 
# scripts across SIGUSR1 or --ping-restart restarts.
persist-tun 

# Don't re-read key files on reconnect
persist-key

# Change process priority after initialization 
# n>0 : lower priority; n<0 : higher priority).
nice 1
    

####################################################
# Verbindung aufrecht halten
ping 10
ping-restart 60

Server config gestaltet sich etwas schwerer, wenn def. benötigt poste ich die gleich noch.

 

[MaxMuster]

Das sieht eigentlich gut aus...
Mach doch mal einen trace auf google oder so

tracert -d www.google.de

Kannst du denn die Geräte in deinem Netz (hinter der Fritzbox) erreichen?

Die Serverconfig wäre doch von Interesse, die IP-Config vor allem (also "ifconfig" und "ifconfig-pool", Einträge.)

Was ich gerade noch sehe: Hattest du nicht oben geschrieben, dass du dich "für den Tunnel" entschieden hättest?!? Die Client-Config nimmt aber den Brücken-Modus "TAP")

Jörg

 

[Muldini]

Hm, du hast Recht, ich hatte angenommen das Beispiel wäre Tunnel basierend, muss ich beim Umstellen etwas beachten außer aus "tap", "tun" zu machen?

Abweichungen von der Beispielconfg sind folgende:

- den "route 192.168.2.0 255.255.255.0 10.0.0.5" Befehl entfernt
- "push "resolv-retry infinite" entfernt <- gab Fehler beim Verbinden

Den Server kann ich bei Verbindung sowohl mit 192.168.0.1 als auch mit 10.0.0.1 erreichen, das Netz dahinter (z.b. ein PC 192.168.0.32) ist auch erreichbar. Mein Client hier bekommt die 10.0.0.2.

Der trace ergibt folgendes:

Der Zielname www.google.de konnte nicht aufgel”st werden.

Die Server config sieht so aus:

# OpenVPN v2.0.5 config:
####################################################
# Authentifizierung und Verschluesselung
.... passt, Verdinung klappt ja


####################################################
# Grundsaetzliches
port 1194
proto udp
dev tap
# insert onto shell: mknod /var/tmp/tun c 10 200
dev-node /var/tmp/tun


####################################################
# Server-Einstellungen
mode server
tls-server
client-to-client
server 10.0.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt  # assign right IP-Addresses (optional)
mssfix 


#server:
#Routen setzen, bei route Subnetz des Clients
# bei push Subnetz des eigenen Servers eintragen
push "route 192.168.0.0 255.255.255.0"
push "redirect-gateway"

# Don't close and reopen TUN/TAP device or run up/down 
# scripts across SIGUSR1 or --ping-restart restarts.
persist-tun 

# Change process priority after initialization 
# n>0 : lower priority; n<0 : higher priority).
nice 1
    

####################################################
# Verbindung aufrecht halten
#-- Server:
ping 10
ping-restart 60


#-- Client:
push "ping              15" # keep firewall open
push "ping-restart      60" # 1 minute





####################################################
## Enable compression
## server & client entry must be the same!
comp-lzo


####################################################
# Protokollierungseinstellung
verb 4

####################################################
# Daemon (Wenn alles funktioniert)
daemon

####################################################
#Allow remote peer to change its IP address and/or port number, such as due to DHCP
# float tells OpenVPN to accept authenticated packets from any address, not only the 
# address which was specified in the --remote option.
float

Vielen Dank und beste Grüße

 

[MaxMuster]

Dann brauche ich noch ein

ipconfig /all
und, wenn du schonmal dabei bist, einen Trace ohne Namensauflösung auf google:
tracert -d 209.85.129.104

denn scheinbar funktioniert die Namensauflösung nicht...

Jörg

 

[Muldini]

Du hast Recht, die Namensauflösung scheint nicht zu funktionieren, google klappt über die Adresse, hier dennoch die logs:

ipconfig /all:

Windows-IP-Konfiguration



        Hostname. . . . . . . . . . . . . : ...

        Primäres DNS-Suffix . . . . . . . : 

        Knotentyp . . . . . . . . . . . . : Hybrid

        IP-Routing aktiviert. . . . . . . : Nein

        WINS-Proxy aktiviert. . . . . . . : Nein

        DNS-Suffixsuchliste . . . . . . . : xxx.local



Ethernetadapter VPN:



        Verbindungsspezifisches DNS-Suffix: 

        Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V9

        Physikalische Adresse . . . . . . : xxx

        DHCP aktiviert. . . . . . . . . . : Ja

        Autokonfiguration aktiviert . . . : Ja

        IP-Adresse. . . . . . . . . . . . : 10.0.0.3

        Subnetzmaske. . . . . . . . . . . : 255.255.255.0

        Standardgateway . . . . . . . . . : 10.0.0.1

        DHCP-Server . . . . . . . . . . . : 10.0.0.0

        Lease erhalten. . . . . . . . . . : Montag, 17. September 2007 11:40:09

        Lease läuft ab. . . . . . . . . . : Dienstag, 16. September 2008 11:40:09



Ethernetadapter Drahtlose Netzwerkverbindung:



        Verbindungsspezifisches DNS-Suffix: xxx.local

        Beschreibung. . . . . . . . . . . : Intel(R) PRO/Wireless 3945ABG Network Connection

        Physikalische Adresse . . . . . . : xxx

        DHCP aktiviert. . . . . . . . . . : Ja

        Autokonfiguration aktiviert . . . : Ja

        IP-Adresse. . . . . . . . . . . . : 192.168.30.130

        Subnetzmaske. . . . . . . . . . . : 255.255.255.0

        Standardgateway . . . . . . . . . : 

        DHCP-Server . . . . . . . . . . . : 192.168.30.254

        DNS-Server. . . . . . . . . . . . : 192.168.0.10

                                            192.168.0.11

        Lease erhalten. . . . . . . . . . : Montag, 17. September 2007 10:10:33

        Lease läuft ab. . . . . . . . . . : Dienstag, 18. September 2007 10:10:33



Ethernetadapter LAN-Verbindung:



        Medienstatus. . . . . . . . . . . : Es besteht keine Verbindung

        Beschreibung. . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet

        Physikalische Adresse . . . . . . : xxx

tracert:

Routenverfolgung zu 209.85.129.104 �ber maximal 30 Abschnitte



  1   111 ms   229 ms   124 ms  10.0.0.1 

  2   145 ms   190 ms   276 ms  213.20.95.173 

  3   215 ms   224 ms    70 ms  213.20.88.81 

  4   149 ms   123 ms   223 ms  195.71.251.201 

  5   243 ms   196 ms   211 ms  195.71.143.178 

  6   248 ms     *      192 ms  195.71.254.1 

  7   204 ms   230 ms   184 ms  195.71.234.242 

  8   337 ms   197 ms   267 ms  195.71.254.97 

  9   252 ms   274 ms   268 ms  62.52.50.162 

 10   248 ms   248 ms   211 ms  72.14.198.21 

 11   205 ms   221 ms   221 ms  72.14.238.126 

 12   280 ms   190 ms   223 ms  72.14.232.201 

 13   206 ms   243 ms   189 ms  72.14.233.210 

 14   113 ms   229 ms   227 ms  209.85.129.104 

Ablaufverfolgung beendet.

Liegt das am DNS Server im anderen Netz? Für Ratschläge bin ich wie immer dankbar

Grüße

 

[MaxMuster]

Dann gibt es zwei Möglichkeiten (ich hatte es ja geahnt ;-) ) und ein Problem:
Wenn der "interne" DNS, den du sonst so nutzt, auch externe Adressen auflöst, dann reicht eine Route für das Netz, in dem Der DNS steht:

route add -p 192.168.0.0 mask 255.255.255.0 192.168.30.254

(aber damit kappst du dir die Verbindung ins heimische Netz, was ja das gleiche Netz ist :-( )

Oder du lässt dir vom Server einen DNS "schicken", z.B. die Fritzbox selber
"push dhcp-option DNS 10.0.0.1"

Jörg