OpenVPN - automatisches Routing

[Daether]

Moin Moin,
ich kämpfe z.Zt. mit meinem OpenVPN-Netz. Alle Server laufen unter Debian.
Ich beschreibe einmal den Aufbau :

Code: Alles auswählen

VPN-Client :
Netz-IP : xxx.xxx.xxx.xxx
VPN-IP : 192.168.1.2

VPN-Server :
Netz-IP : 172.16.1.111
VPN-IP : 192.168.1.1

Internes Gateway ( Firewall ) :
Netz-IP : 172.16.1.1
VPN-IP : keine

Somit sind VPN-Server/VPN-Client und VPN-Server/Firewall miteineander verbunden.
Ein Ping vom VPN-Client zur Firewall ist nicht möglich.

Erst nach hinzufügen der folgenden Routen, funktioniert die Verbindung :

Code: Alles auswählen

Internes Gateway ( Firewall ) :
route add -net 192.168.1.0  netmask 255.255.255.0 gw 172.16.1.111

VPN-Client
route add -net 172.16.1.0  netmask 255.255.255.0 gw 192.168.1.1

Nun hatte ich gehofft, dass sich diese Routen auch automatisch verteilen lassen.

Code: Alles auswählen

cat /proc/sys/net/ipv4/ip_forward

liefert bei allen 3 Servern "1".

Hat jemand einen Tipp, wie ich die Routernbverteilung automatisieren kann, bzw. wo bei mir das Problem liegt ?

[Duff]

Du kannst z.B. mit der Optin push in der server.conf eine Route mit angeben, die dann bei einem Connect vom Client auf dessen eingefügt wird.

Beispiel:
Auszug auf dem Server (server.conf)

Code: Alles auswählen

port 443
proto udp
dev tun
tun-mtu 1492
fragment 1300
mssfix
ca /etc/openvpn/vpn-ca.pem
cert /etc/openvpn/servercert.pem
key /etc/openvpn/serverkey.pem
dh /etc/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
keepalive 10 120
auth SHA1
cipher AES-256-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
verb 3

Route auf dem Client, die hinzugefügt wurde:

Code: Alles auswählen

....
Tue Jan 13 18:11:41 2009 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Tue Jan 13 18:11:41 2009 OPTIONS IMPORT: timers and/or timeouts modified
Tue Jan 13 18:11:41 2009 OPTIONS IMPORT: --ifconfig/up options modified
Tue Jan 13 18:11:41 2009 OPTIONS IMPORT: route options modified
Tue Jan 13 18:11:41 2009 ROUTE default_gateway=192.168.2.1
Tue Jan 13 18:11:41 2009 TUN/TAP device tun0 opened
Tue Jan 13 18:11:41 2009 TUN/TAP TX queue length set to 100
Tue Jan 13 18:11:41 2009 /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1492
Tue Jan 13 18:11:41 2009 /sbin/route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.8.0.5
Tue Jan 13 18:11:41 2009 /sbin/route add -net 10.8.0.1 netmask 255.255.255.255 gw 10.8.0.5
Tue Jan 13 18:11:41 2009 Initialization Sequence Completed

[Daether]

Moin Moin,
das ist mir bewusst und mache ich auch.
Allerdings kann ich so nur den VPN-Client/-Server die Routen verteilen. Refchner die hinter dem VPN-Server stehen ( wie Firewall ) kennen diese Routen aber nicht.

[Duff]

Was hast du denn für iptables-Regeln auf der Firewall definiert?
Darüber müsste auch ein Forwarding möglich sein.

[Daether]

Moin Moin,
entschuldigt, dass ich erst so spät antworte.
Z.Zt. sind keine Iptables-Regeln von mir definiert.

Wie kann ich denn über Iptables das Ganze automatisch routen ?

[Duff]

Du müsstest meiner Meinung nach eine Forward-Rule auf dem VPN-Server einrichten, der Anfragen vom einkommenden Interface zum ausgehenden Interface in Richtung firewall weiterleitet.

Bspw so:

Code: Alles auswählen

# Akzeptiere alle Pakete, die Teil einer aufgebauten Verbindung sind
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -i $E_IFACE -o $O_IFACE -m state --state NEW -j ACCEPT

[Daether]

Moin,
danke für die Hilfe.

Die Verbindung untereinander, über den VPN-Tunnel funktioniert nun einwandfrei.

Nun habe ich aber ein neues Problem :
Hinter dem VPN-Client soll noch ein kleines Netz eingerichtet werden. Dementsprechend habe ich einen Test-Server aufgesetzt und nun folgende Struktur :

Code: Alles auswählen

VPN-Client :
eth0 : 
Netz-IP : 88.88.xxx.xxx
eth0:1 :
Netz-IP : 172.16.13.1
tap0 :
VPN-IP : 192.168.1.2

Test-Client ( Server 2008 )
IP : 172.16.13.2

Der VPN-Client kann aufs Internet zugreifen ( über seine externe IP ).
Der Test-Client kann alle Rechner im eigenen Netz und Rechner über das VPN-Netz erreichen, allerdings kriegt er keine Verbindung ins Internet, über den VPN-Client !
Ip-Forwarding ist aktiviert und über iptables verbiete ich nichts !

[roli]

Hi,

ich gehe mal davon aus das alle Rechner in deinem "kleinen Netz" 172.16.13.x haben das selbe default Gateway, oder? Wenn dem so ist, dann richtest du einfach dort eine Route in dein VPN-Netz 192.168.1.y ein. Damit sollte es das dann sein, wenn ich dein Problem richtig verstanden habe.

[Daether]

Moin,
ist etwas schwer zu beschreiben was ich will.

Beim 2. Standort ( VPN-Client ), soll ein eigenständiges Netzwerk entstehen ( 172.16.13.0/24 ).
Der VPN-Client soll ( auch ohne VPN ) praktisch der Router der für das Internet sein.
Also sollte bei einem Traceroute von 172.16.13.2 zu google.de das ganze folgendermaßen aussehen :

Code: Alles auswählen

Ziel
1 172.16.13.1
2 google.de

Die Clients kommen aber nur bis 172.16.13.1. Weiter kommen keine Antworten zurück.

EDIT : Der VPN-Client, hat eine eigene übers das Internet erreichbare Internetaddresse und kann ohne Probleme google.de aufrufen ( getestet mit lynx ).

[roli]

Mhh,

du willst also zwei Netze mittels VPN verbinden, oder? Wenn ja muesste eine Bridge die Loesung sein. Das habe ich aber auch noch nicht gemacht.
Wie auch immer, auf dem Default Gateway deiner zwei Standorte sollte es ja bereits eine Route in's Internet geben. Weiter richtest du hierauf dann noch eine Route in das VPN-Netz ein. Alle "Clients" am Standort sollten dann jeweils nur die Defaultroute auf das Default Gatewy haben.

[Duff]

Also ich blicke jetzt irgendwie nicht mehr durch.

Kannst du eventuell deine Netzwerktopologie mal skizzieren?

[Daether]

So, ich habe mal auf die schnelle eine Zeichnung gemacht.

http://gallery.debianforum.de/v/verschi ... r.jpg.html

Alle Geräte können sich intern über den VPN-Tunnel erreichen ! Das Problem mit dem VPN-Tunnel ist also erstmal erledigt.

Wenn nun der Client "172.16.13.2" eine Anfrage an das Internet hat ( z.B. google.de ) muss er dafür nur über die IP 172.16.13.1 des Servers an Standort B gehen ( der VPN-Tunnel ist dabei nicht nötig ). Leider kann der Client "172.16.13.2" keine Verbindung aufbauen, obwohl er die IP 172.16.13.1 als Gateway nimmt.

Ist es etwas verständlicher geworden ?

[Duff]

So, ich habe mal auf die schnelle eine Zeichnung gemacht.

http://gallery.debianforum.de/v/verschi ... r.jpg.html

Danke.

Alle Geräte können sich intern über den VPN-Tunnel erreichen ! Das Problem mit dem VPN-Tunnel ist also erstmal erledigt.

Was hast du gemacht bzw. geändert?

Wenn nun der Client "172.16.13.2" eine Anfrage an das Internet hat ( z.B. google.de ) muss er dafür nur über die IP 172.16.13.1 des Servers an Standort B gehen ( der VPN-Tunnel ist dabei nicht nötig ). Leider kann der Client "172.16.13.2" keine Verbindung aufbauen, obwohl er die IP 172.16.13.1 als Gateway nimmt.

Ist es etwas verständlicher geworden ?

Kann der Client denn den Server von Standort B (im gleichen Subnetz) anpingen?
Wie kommt Server vom Standort B ins Internet? Direkt oder über den Standort A?

[Daether]

Ich habe die Routen fix eingetragen.
Sind im ganzen nicht sehr viele.


Der Server B ( Server an Standort B ) geht über eine fixe IP, direkt ins Internet ( feste IP vom Provider ). Standort A gehört nichtmehr zu dem Teil der Problematik dazu.

Der Client 172.16.13.2 kann den Server B anpingen. Sowohl mit der externen als oauch mit der internen IP des Server B. Diese sollte nun bei einer Verbindung ins Internet den Router für den Client spielen. Tut dies aber nicht !

Code: Alles auswählen

C:\Users\Administrator>tracert 85.183.248.105

Routenverfolgung zu 85.183.248.105 über maximal 30 Abschnitte

  1    <1 ms    <1 ms    <1 ms  172.16.13.1
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.

[Duff]

Wenn du den Server an Standort B anpingen kannst (auf beiden IP-Adressen), dann könnte ich mir noch vorstellen, dass du ein Problem bei der Namensauflösung hast.

Sonst probiert mal google.de über die IP 209.85.135.99 anzupingen.

Wie sieht denn die /etc/resolv.conf auf dem Server Standort B und dem Client aus?

[Daether]

Die Namensauflösung ist nicht das Problem.

Der Ping zu 209.85.135.99 ist vom Server B möglich. Vom Client ( 172.16.13.2 ) jedoch nicht.
In der Resolv.conf auf dem Server B sind die Nameserver meines Providers eingetragen. Auf dem Client ( Win2008-Server ) ebenfalls.

Update :
Da das Ganze noch ne Testumgebung ist, habe ich den Server B komplett neu installiert.
Nach der Neuinstallation die Schnittstellen belegt und IP-Forwarding aktiviert.

Selbes Ergebnis.

Server bekommt Verbindung ins Internet.
Client kriegt nur Verbindung bis zum Server B.


So langsam bin ich echt am verzweifeln .

[Duff]

Musst du nicht noch FORWARD-Regeln auf dem Rechner B einrichten?

In etwa so:

Code: Alles auswählen

# Akzeptiere alle Pakete, die Teil einer aufgebauten Verbindung sind
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Akzeptiere Verbindungsaufbauten von innen 
$IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -m state --state NEW -j ACCEPT

Wobei LAN_IFACE das device zum Client und INET_IFACE das device zum Internet ist.

[Daether]

Nabend,
stimmt, habe vergessen die heute abend nochmal einzupflegen (sehr langer Tag -.- ).

Momentan nicht auf der Firma und komme an die Testumgebung von zu Hause nicht ran.
Werde das Ganze morgen nochmal testen, mit den Firewall Regeln und mich melden !

[Daether]

Moin Moin,
hab das ganze heute morgen durchführen können.
Client B kommt weiterhin nicht ins Internet !

Code: Alles auswählen

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     0    --  anywhere             anywhere            state NEW

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     0    --  anywhere             anywhere            state RELATED,ESTABLISHED

Ich verstehe die Ganze Sache so langsam nichtmehr !

[Duff]

Hast du die FORWARD-Regeln aktiviert?

Aktiviere weiterhin mal das Logging in iptables und schau ins Logfile, ob was geblockt wird.

Code: Alles auswählen

iptables -A INPUT  -j LOG --log-prefix "INPUT: "
iptables -A FORWARD  -j LOG --log-prefix "FORWARD  : "
iptables -A OUTPUT  -j LOG --log-prefix "OUTPUT: "

[Daether]

Nabend,
hab jetzt mal das Logging ausprobiert.

Die Forward-Regeln wurde nicht angezeigt im Logging. Die eingzigen Einträge die miz de IP 172.16.13.2 zusammenhängen :
INPUT
SRC=172.16.13.2
DST=172.16.13.1

Keine weiteren Einträge von dem Client auf dem Server zu finden.

Hier noch die Routing-Tabellen beider Systeme :

Code: Alles auswählen

Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0      172.16.13.1     172.16.13.2       1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      172.16.13.0    255.255.255.0      172.16.13.2     172.16.13.2       20
      172.16.13.2  255.255.255.255        127.0.0.1       127.0.0.1       20
   172.16.255.255  255.255.255.255      172.16.13.2     172.16.13.2       20
        224.0.0.0        240.0.0.0      172.16.13.2     172.16.13.2       20
  255.255.255.255  255.255.255.255      172.16.13.2     172.16.13.2       1
  255.255.255.255  255.255.255.255      172.16.13.2               2       1
Standardgateway:       172.16.13.1
===========================================================================
Ständige Routen:
  Keine

Code: Alles auswählen

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.252 U     0      0        0 tap0
85.182.147.176  0.0.0.0         255.255.255.240 U     0      0        0 eth1
172.16.6.0      192.168.1.1     255.255.255.0   UG    0      0        0 tap0
172.16.13.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         85.182.147.177  0.0.0.0         UG    0      0        0 eth1

[DynaBlaster]

Ich habe den Thread nur überflogen, aber ich würde vorschlagen, dass du den VPN-Tunnel nicht über das tap-Device aufbaust, sondern dass du das tun-Device verwendest. Das tap-Device wird normalerweise nur verwendet, wenn du eine Bridge verwenden willst/musst. Dann wird das tap-Device mit der Netzwerkkarte zum LAN gebdrigded. Du beschreibst aber ein geroutetes Netzwerk mit 3 Netzen: Standort A, Standort B und eben die Endpunkte des VPN's. In einem gebridgten LAN hätten beide Standorte das gleiche Netz ...

[Daether]

Nabend,
also der VPN-Tunnel an sich ist nichtmehr das Problem.
Ich hab ein Problem mit dem Netz hinter dem VPN-Tunnel.

Ich werde mir Montag alles nochmal in Ruhe anschauen und aufschreiben. Sofern ich es dann immernoch nicht zum laufen gekriegt habe, werde ich hier einen neuen Thread mit meinem neuen Problem machen.

MfG Daether