Am Do 04.08.2005 09:44 schrieb Thomas Gräber :

Am Mittwoch, 3. August 2005 20:43 schrieb Sven Gehr:

[...]

...

Der Rechner hat zwei Netzwerk-Karten. eth0 ist mit dem LAN verbunden und hat die IP-Adresse 192.168.0.10 das Netz ist 192.168.0.0/24. In diesem Netz ist die 192.168.0.10 auch das Default-Gateway Die 2. Netzwerkkarte bekommt beim booten zunächst einmal die IP 192.168.100.9 Diese Karte ist mit dem DSL-Modem verbunden und bekommt bei der Einwahl vom ISP eine dynamische IP zugewiesen. Das OpenVPN-Device (tun0) hat die IP 10.1.0.1. Das Netz im VPN-Tunnel ist demnach 10.1.0.0/24 Wenn ich mich nun vom entfernten Windows-Client aus mit dem VPN verbinde bekomme ich durch den Tunnel eine IP zugewiesen (10.1.0.4) und kann das VPN-Gateway sowohl unter der Adresse im Tunnel (10.1.0.1) wie auch auf dessen LAN-IP (192.168.0.10) pingen. Ich bin ziemlich sicher das es sich lediglich um ein Routing-Problem handelt da ich auch das LAN-Interface pingen kann.

...

Hier noch einmal die Routing-Tabelle des Gateways: Destination Gateway Genmask Flags Metric Ref Use Iface 10.1.0.2 * 255.255.255.255 UH 0 0 0 tun0 217.0.116.59 * 255.255.255.255 UH 0 0 0 ppp0 192.168.100.0 * 255.255.255.0 U 0 0 0 eth1 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 10.1.0.0 10.1.0.2 255.255.255.0 UG 0 0 0 tun0 link-local * 255.255.0.0 U 0 0 0 eth1 loopback * 255.0.0.0 U 0 0 0 lo default 217.0.116.59 0.0.0.0 UG 0 0 0 ppp0

wenn ich das richtig verstehe, willst du, dass der Windows-Rechner in das 192.168.0.0/24 Netz kommt? Zeig doch mal die Routing-Tabelle auf dem Windows-PC.

Genau. Das möchte ich. Hier die Routing-Tabelle des Windows-Clients nach dem Verbinden: =========================================================================== Aktive Routen: Netzwerkziel          Netzwerkmaske              Gateway    Schnittstelle  Anzahl              0.0.0.0                  0.0.0.0               10.1.0.5               10.1.0.6      1             10.1.0.0       255.255.255.0               10.1.0.5              10.1.0.6      1             10.1.0.4    255.255.255.252              10.1.0.6               10.1.0.6      1             10.1.0.6    255.255.255.255             127.0.0.1             127.0.0.1      1   10.255.255.255    255.255.255.255              10.1.0.6              10.1.0.6      1      84.162.254.2     255.255.255.255      92.168.111.3   192.168.111.144      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.1.0.5               10.1.0.6      1     192.168.111.0       255.255.255.0  192.168.111.144  192.168.111.144      1   192.168.111.144   255.255.255.255             127.0.0.1           127.0.0.1      1   192.168.111.255  255.255.255.255   192.168.111.144  192.168.111.144      1             224.0.0.0             224.0.0.0               10.1.0.6              10.1.0.6      1             224.0.0.0             224.0.0.0   192.168.111.144  192.168.111.144      1   255.255.255.255   255.255.255.255              10.1.0.6              10.1.0.6      1 Standardgateway:            10.1.0.5 =========================================================================== Ständige Routen:   Keine

Schalte doch mal testweise die SuSEfirewall2 ab

Habe ich auch schon probiert ohne Erfolg

und aktiviere anschliessend mit echo 1 >/proc/sys/net/ipv4/ip_forward das Routing auf dem Linuxserver und probier es dann nochmal.

Das ist sowieso gesetzt. Steh der Parameter ip_forward mit der SuSEFirewall in Verbindung d.h. Muß ich wenn dieser sowieso gesetzt ist und ich dann die Firewall deaktiviert diesen auf jeden Fall nochmal setzten? Diesen Fall habe ich noch nicht probiert. Ich habe lediglich überprüft ob der Wert gesetzt ist und habe dann mal die Firewall deaktiviert.

Was ich mal festgestellt habe, ist, dass wenn das tun0-device noch nicht up ist, bevor die Firewall startet, es dann auch nicht funktioniert, in dem Fall einfach die Firewall nochmal starten.

Ja, auch das habe ich schon versucht. Viele Grüße Sven

Tatsache. Wenn ich die Firewall abschalte und anschließend den Wert:

echo 1 >/proc/sys/net/ipv4/ip_forward

neu setze funktioniert es. Ich kann die Rechner im entfernten LAN alles pingen. Das Werte ich jetzt mal als Fortschritt! Nun möchte ich aber die Firewall nicht unbedingt deaktiviert lassen. Was kann ich einstellen damit es auch mit FW geht?

Entweder passende Forwarding Regeln eintragen unter FW_FORWARD oder die Interfaces alle in eine Gruppe (intern oder dmz z.B.) und FW_ALLOW_CLASS_ROUTING auf yes.

Sven Gehr schrieb:

...

Entweder passende Forwarding Regeln eintragen unter FW_FORWARD

Damit funktioniert es nicht. Ich habe dort zum testen mal:

0/0,0/0,udp,1194

eigetragen was keinen Erfolg brachte.

Keine Ahnung er das als "alle Richtungen gehen" interpretiert, den normalerweise muss man die Richtungen getrennt angeben, so wie in: FW_FORWARD="192.168.1.0/24,192.168.0.0/24 192.168.0.0/24,192.168.1.0/24" Das erlaubt das Routing zwischen den Netzen 192.168.1.0 und 192.168.0.0 in beiden Richtungen, alle Dienste und Protokolle.

Damit funktioniert es. Wäre es aber nicht flexibler es mit FW_FORWARD zu realisieren?

Ja, vor allem weil man unerwünschtes filtern kann.

Sven Gehr schrieb am Thursday, August 04, 2005 4:52 PM

Damit das Routing zwischen dem Tunnel (10.1.0.0/24) und dem LAN hinter dem Gateway (192.168.0.0/24) in beide Richtungen funktioniert funktioniert. Kann ich hiermit nun auch die nutzbaren Dienste beschränken das z.B. nur ssh, groupware und TerminalServer durch den Tunnem möglich sind?

Kannst Du, das entsprechende Beispiel, wie die Syntax dafür aussieht, findest Du unter Punkt 13.) im Konfigfile der Firewall erklärt.

Wenn ich mich vom entfernten Windows-Client aus anmelde wird ja die default-route auf den Tunnel gesetzt was zur folge hat das wenn der entfernte User surfen geht das auch alles durch den Tunnel geht. Ich denke aber mal das läßt sich nicht anderst lösen, oder?

Das hängt vom Client ab. Normalerweilse haben die meisten VPN Clients eine Option in der Art "Defaultroute setzen" ... Wenn Du das verneinst, dann geht mal nicht der ganze Verkehr über den Tunnel geroutet, sondern es wird IIRC eine Route entsprechend der IP/Netzklasse der zugewiesenen IP für die Tunnelverbindung gesetzt. Du musst dann evtl. eben dafür sorgen, dass die Route entsprechend erweitert/angepasst wird, falls notwendig und evtl für eine Namensauflösung sorgen (WINS, Hosts-Datei o.ä.). Ich hatte das in meiner Exfirma mit meinem Notebook und meiner VPN-Verbindung derart lösen können, kann Dir aber nicht mehr sagen wie der Client hieß ... SafeNet Secure irgendwas oder so ähnlich ... HTH, Regards Markus

Hey es klappt!! Auf die Filterung würde nochmal gerne zu sprechen. Ich habe jetzt eingragen:

10.1.0.0/24,192.168.0.0/24 192.168.0.0/24,10.1.0.0/24

funktioniert. Kann ich hiermit nun auch die nutzbaren Dienste beschränken das z.B. nur ssh, groupware und TerminalServer durch den Tunnem möglich sind?

Im Prinzip ja, bin mir aber nicht sicher ob 10.1.0.0/24,192.168.0.0,tcp,22 alleine schon ausreicht oder doch eher 10.1.0.0/24,192.168.0.7,tcp,22 192.168.0.7,10.1.0.0/24,tcp für ssh auf einen Rechner .7 im 192er netz

Wenn ich mich vom entfernten Windows-Client aus anmelde wird ja die default-route auf den Tunnel gesetzt was zur folge hat das wenn der entfernte User surfen geht das auch alles durch den Tunnel geht. Ich denke aber mal das läßt sich nicht anderst lösen, oder?

Doch, bei open vpn in der server.conf push "redirect-gateway" auskommentieren. Per push "route 192.168.1.0 255.255.255.0" und ähnlichem dann die gewünschten Regeln schicken. Achtung der Client kann das akzeptieren von Regeln die vom Server kommen ablehnen.

Am Do 04.08.2005 10:10 schrieb Dieter Kluenter : Hallo, [...]

Darüber stolpere ich ja erst jetzt :-( Windows kann meines Wissens nur mit dem tap Device arbeiten, auf dem Windows Rechner sollte eigentlich auch ein tap Device installiert sein,

ja das ist auch so.

ebenfalls natürlich in der OpenVPN Konfiguration auf dem Linuxserver.

Nein. Auf dem Linux-VPN-Gateway sollte man das tun benutzen. Viele Grüße Sven