Re: OpenVPN und Routing machen mich konfus...
Hallo Dirk,
Am 06.10.2010 20:04, schrieb Dirk Linnerkamp:
>
....um nicht Überblick zu verlieren, fasse ich das mal kurz zusammen:
1. Von deinem VPN CLIENT Netzwerk kann nicht nur der VPN Client den VPN
Server erreichen, sondern ALLE Rechner dieses LAN's können den VPN
Server sowohl unter 10.8.0.1 ALS AUCH unter 192.168.200.14 erreichen,
Ja. Beide Adressen sind erreichbar aus dem OVPN-Client LAN
2. der VPN Server und die übrigen Rechner dieses LAN's können den VPN
Client nur unter seiner VPN Adresse (10.8.0.6) erreichen, NICHT aber
unter seiner LAN Adresse,
Ja.
3. logischerweise sind auch die übrigen Rechner des Client LAN's vom VPN
Server nicht erreichbar.
Ja.
4. auf dem VPN Client Rechner ist TUN/TAP und Ibv4 Forwarding aktiviert.
Ja.
5. es gibt weder auf dem VPN Server als auch auf dem VPN Client eine
Firewall, die ein- ausgehende Pakete blockieren könnte.
Ja, richtig.
6. Auf den jeweiligen Standardgateways beider LAN's sind statische
Routen zu dem jeweiligen anderen LAN Netzwerk gelegt, die auf die LAN IP
des Servers bzw. Clients als Gateway verweisen. Zusätzlich ist in dem
Server LAN eine statische Route auf das VPN Netzwerk gelegt mit GW=LAN
IP des Servers.
Ja.
tracert 192.168.10.15
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
1<1 ms<1 ms * Firewall-GW [192.168.200.250]
2<1 ms *<1 ms OpenVPN-Server [192.168.200.14]
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
Folgerung:
1. Entweder die Pings kommen gar nicht in das Client LAN hinein ODER sie
finden den Weg zurück nicht.
2. Da aber ein ping auf das Server LAN von allen Rechnern des Client LAN
aus möglich ist, müssten also die Routen an das 192.168.200.0/24 Ziel
AUS dem Client LAN zurück ins Server LAN stimmen und der Weg frei sein -
- daraus folgernd:
Kämen die Pings aus deinem Server LAN korrekt ins Client LAN, müssten
sie auch beantwortet werden können, da der Rückweg ja funktioniert. Tun
sie aber nicht!
Für mich daher an dieser Stelle:
Die Pakete vom VPN Server LAN mit Zielpunkt 192.168.10.0/24 kommen dort
gar nicht an und können deshalb auch nicht beantwortet werden.
Das wiederum lässt eigentlich nur den Schluss zu:
Es kann auch nicht an der Firewall des Client Standard Gateways liegen,
denn dann müssten die pings des Servers an 192,168,10.15 trotzdem
ankommen und beantwortet werden, da dieser eine Route für diese Ziel
Adressen über 10.8.0.2 besitzt.
Ja, vollkommen logisch.
Also können sie eigentlich, wenn ich jetzt keinen Denkfehler gemacht
habe, nur zwischen tun0 und eth0 auf dem VPN Client hängen bleiben,
sprich: das TUN - und IP Forwarding zwischen den devices funktioniert
nicht!
Was ich mir (noch) nicht erklären könnte, aber ja, möglich.
...ich weiß, kann eigentlich auch nicht sein, aber mir gehen da im Moment
wirklich die Ideen aus.
Ich habe schon keine mehr :(
Stell doch mal deine FORWARDING Policy auf DROP
und versuch Folgendes:
OK
iptables -A FORWARDING -i tun0 -o eth0 -s 10.8.0.0/24 -d
192.168.10.0/24 -j ACCEPT
und
iptables -A FRWARDING - i eth0 -o tun0 -s 10.8.0.0/24 -d 192.168.10.0/24
-j ACCEPT
Leider passiert jetzt auch nicht mehr und/oder weniger. Bei mir musste
es allerdings "FORWARD" lauten:
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -d 192.168.10.0/24 -j
ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -s 10.8.0.0/24 -d 192.168.10.0/24 -j
ACCEPT
Mehr weiß ich im Moment leider auch nicht :-( . Vielleicht trotzdem mal
die Firewalls auf den Standardgateways deaktivieren und pingen, um wider
deer Logik ALLES auszuschließen..?
Das war auch schon einer meiner Versuche - ebenfalls ohne Erfolg.
Was passiert eigentlich, wenn ich diese Regel einpflege?
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
Bzw. finde ich dann keine Einträge unter "iptables -L"
Fakt ist, dass ich scheinbar diese Regel brauche, aber wieso? Ist es so,
dass alle Router immer maskieren müssen?! Kann ich mir nicht vorstellen.
Beste Grüße, axel
PS: ab FR ist langer Urlaub angesagt. 4-6 Wochen. Vllt. komme ich
zwischenzeitlich mal dazu, ein wenig weiter zu machen, falls wir bis
morgen Abend noch keinen Erfolg verzeichnen können, also bitte nicht
wundern, wenn dann Antworten länger auf sich warten lassen bzw. das
Thema ruht.
Reply to: