[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OpenVPN: Routing-Problem



Am Donnerstag, den 17.05.2007, 13:54 +0200 schrieb Michael Hierweck:
> Hallo Ingo und alle anderen,

Hallo Michael

Ich selbst habe das noch nie gemacht, aber alleine aus der Theorie kann
da schon was nicht stimmen.

> ich glaube, ich habe das Problem etwas unklar formuliert, abgesehen
> davon habe von tun auf tap gewechselt, was mir empfohlen wurde, weil das
> Routing dann einfacher sein soll.
> 
> Zweiter Anlauf:
> 
> Wir haben zwei Netzwerke 192.168.100.0 und 192.168.200.0.
> In den Netzwerken gibt jeweils einen Server 192.168.x.100 und einen
> Internet-Router 192.168.x.250.
> 
> Alle Hosts in den Netzwerken verwenden den jeweiligen Server als Default
> Gateway. Die Server verwenden dann wiederum den Router als Default
> Gateway. Traffic für nicht-lokale IPs läuft also von den Hosts über den
> Server und den Router ins Internet. Das klappt auch.
> 
> Idee: Da Traffic zu nicht lokalen Zielen aber stets auch über die Server
> läuft, kann ich diese Server so konfigurieren, dass diese Traffic für
> das jeweils andere Netzwerk nicht über deren Default Route ins Internet,
> sondern über eine VPN-Verbindung senden.
> 
> --------------------------------------------------------------------------
> 
> Der Server aus dem 192.168.100.0er Netzwerk:

> 
> tap0      Link encap:Ethernet  HWaddr 2A:44:57:76:58:30
>           inet addr:192.168.111.1  Bcast:192.168.111.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:9 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100
>           RX bytes:1078 (1.0 KiB)  TX bytes:1078 (1.0 KiB)
> 
> tap1      Link encap:Ethernet  HWaddr 8A:2A:B1:8B:00:E0
>           inet addr:192.168.222.2  Bcast:192.168.222.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:72 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:87 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100
>           RX bytes:8535 (8.3 KiB)  TX bytes:9511 (9.2 KiB)

Mich würde vorerst mal interessieren warum du von Tunnel (tun-Devices)
auf Brücke (tap-Devices) umgestiegen bist?
Solange die Verbindungen auf das IP-Protocol aufbauen, reicht tunneln
völlig aus und ist bei Problemen im Netz leichter zu untersuchen.
Wenn zwischen den beiden Netzen aber auch andere Protocole zum Einsatz
kommen (zB IPX), musst du Brücken schlagen.

Hast du die tap-Devices selbst über '/etc/network/interfaces' angelegt,
oder werden die von OpenVPN erzeugt?
Den IP-Adressen nach, vermute ich, du hast sie selbst erstellt.
Beim tunneln erstellt jeder Tunnelpartner ein tun-Device.
Soweit ich weis, kann OpenVPN die Devices selbst erstellen.

Dein Szenario:
LAN-1: 192.168.100.0
LAN-2: 192.168.200.0
VPN-Netz: 192.168.150.0

Für das VPN-Netz habe ich jetzt einfach mal das 150er Netz angenommen.
Alle tun-Devices erhalten eine IP aus dem VPN-Netz.
z.B. der Server aus dem 100er Netz 'tun0 192.168.150.1' und der Server
aus dem 200er Netz 'tun0 192.168.150.2'.

> Kernel IP routing table
> 192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
> 192.168.200.0   192.168.222.1   255.255.255.0   UG    0      0        0 tap1
> 192.168.111.0   0.0.0.0         255.255.255.0   U     0      0        0 tap0
> 192.168.222.0   0.0.0.0         255.255.255.0   U     0      0        0 tap1
> 0.0.0.0         192.168.100.250 0.0.0.0         UG    0      0        0 eth0

zu den Routen:

192.168.100.0   0.0.0.0         255.255.255.0   U   0   0   0 eth0
0.0.0.0         192.168.100.250 0.0.0.0         UG  0   0   0 eth0

Die beiden sind logisch.
Damit der Server zum routen auch das andere Netz kennt (das 200er),
braucht er eine weitere Route:

192.168.200.0   192.168.100.100 255.255.255.0   UG  0   0   0 tun0

Auf dem Server im 200er Netz verfährst du analog.

> Michael

mfG Sascha




Reply to: