Re: OpenVPN und Routing machen mich konfus...
Am Mittwoch, den 06.10.2010, 00:18 +0200 schrieb ako:
Hallo Axel,
> Gruß axel
>
> PS. werde auch gleich erst wieder zum Testen kommen. Kam gerade ausm
> Büro zurück...
....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,
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,
3. logischerweise sind auch die übrigen Rechner des Client LAN's vom VPN
Server nicht erreichbar.
4. auf dem VPN Client Rechner ist TUN/TAP und Ibv4 Forwarding aktiviert.
5. es gibt weder auf dem VPN Server als auch auf dem VPN Client eine
Firewall, die ein- ausgehende Pakete blockieren könnte.
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.
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.
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!
...ich weiß, kann eigentlich auch nicht sein, aber mir gehen da im Moment
wirklich die Ideen aus. Stell doch mal deine FORWARDING Policy auf DROP
und versuch Folgendes:
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
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..?
Gruß Dirk
Reply to: