[Gelöst] PC als VPN Gateway für das Netzwerk nutzen

[CrunkBass]

Hallo zusammen,

Ich möchte einen PC als "VPN Gateway" verwenden.
Dieser PC hat die IP Adresse 192.168.2.3 und stellt eine VPN Verbindung zu einem externen Server her.
Der Server ist so konfiguriert, dass er Pakete, die aus dem VPN kommen, weiterleitet. Er kann also als Gateway verwendet werden.
Nun würde ich den PC gerne bei anderen PCs im Netzwerk als Gateway eintragen können um über die IP des VPN Servers zu surfen.
Hier mal die Ausgabe von route und ifconfig damit ihr euch ein Bild machen könnt.

Code: Alles auswählen

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.168.2.1     0.0.0.0         UG    0      0        0 wlan0
default         10.8.0.9        0.0.0.0         UG    1      0        0 tun0
10.8.0.1        10.8.0.9        255.255.255.255 UGH   0      0        0 tun0
10.8.0.9        *               255.255.255.255 UH    0      0        0 tun0
123.45.67.89    192.168.2.1     255.255.255.255 UGH   0      0        0 wlan0
192.168.2.0     *               255.255.255.0   U     0      0        0 wlan0

Code: Alles auswählen

eth0      Link encap:Ethernet  Hardware Adresse b8:27:eb:2c:85:ce
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:300 (300.0 B)  TX bytes:300 (300.0 B)

tun0      Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet Adresse:10.8.0.10  P-z-P:10.8.0.9  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1500  Metrik:1
          RX packets:85 errors:0 dropped:0 overruns:0 frame:0
          TX packets:85 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX bytes:7140 (6.9 KiB)  TX bytes:7140 (6.9 KiB)

wlan0     Link encap:Ethernet  Hardware Adresse 80:1f:02:87:76:3a
          inet Adresse:192.168.2.3  Bcast:192.168.2.255  Maske:255.255.255.0
          inet6-Adresse: fe80::3/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:6817 errors:0 dropped:6842 overruns:0 frame:0
          TX packets:4952 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:1274218 (1.2 MiB)  TX bytes:2042071 (1.9 MiB)

Die Herausforderung dabei ist allerdings, dass der PC nur den Traffic der anderen PCs (192.168.2.0/24) durch das VPN leiten soll und selbst die Verbindung ins Internet über den Router (192.168.2.1) herstellen muss. Dies sollte ja mit den entsprechenden iptables Regeln möglich sein.
Leider weiß ich nicht nach was ich genau suchen muss. Es wäre sehr nett wenn mich jemand in die richtige Richtung weisen könnte.

[DynaBlaster]

Wenn dein Gateway mit der IP 192.168.2.3 als Gateway bei allen Clients im Netz 192.168.2.0/24 eingetragen sein sollte, reicht ein

Code: Alles auswählen

route -add net xxx.xxx.xxx.xxx/24 gw 10.8.0.1 tun0

xxx.xxx.xxx.xxx ist das Netz hinter dem VPN-Server mit der IP 10.8.0.1 auf dessen tun0-Interface. Auf dem VPN-Server mit der tun0-IP 10.8.0.1 ensprechend eine Route zurück ins Netz 192.168.2.0/24 über 10.8.0.10 setzen. Falls das nicht möglich sein sollte (kein Zugriff auf den VPN-Server), einfach alles per iptables auf die tun0-IP-Adresse des Gateways umsetzen

Code: Alles auswählen

iptables -t nat -I POSTROUTING -s 192.168.2.0/24 -o tun0 -j SNAT --to 10.8.0.10

Ggf. sind einige Korrekturen bei der Syntax bzw. den IP-Adressen notwendig. OpenVPN bspw. baut immer /30-Netze pro Client auf. Das macht die Identifikation der korrekten Gateways manchmal etwas schwierig ...

[dufty]

Also, Dein bisheriges Default-Gateway für Deine Clients war der (DSL-)Router 192.168.2.1.
Nun soll PC 192.168.2.3 das VPN-Gateway spielen und die anderen PCs im Netz jenen als Gateway verwenden, korrekt?

Jetzt hast Du nicht verraten, welche VPN-software verwendest, unter OpenVPN (zuzüglich Verschlüsselung) wär's in etwa

root@host:~# openvpn --remote 123.45.67.89 --dev tun0 --ifconfig 10.8.0.10 10.8.0.9 --redirect-gateway

was zur

Code: Alles auswählen

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.9        0.0.0.0         UG    0      0        0 tun0
10.8.0.9        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
123.45.67.89    192.168.2.1     255.255.255.255 UGH   0      0        0 wlan0

und im "VPN aus"-Zustand wieder zurück zu

Code: Alles auswählen

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 wlan0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0

führt. Damit wurde das "Umbiegen der Default-Route" rein zum anderen Tunnel-Endpunkt (nämlich der 10.8.0.9) bereits vollzogen.
Was soll jetzt noch iptables (auf der OpenVPN-Client-Seite) zusätzlich machen?

Danke.

[dufty]

... , reicht ein

Code: Alles auswählen

route -add net xxx.xxx.xxx.xxx/24 gw 10.8.0.1 tun0

Nö, das reicht keinesfalls:
Die default-route von 192.168.2.3 - die bislang auf den 192.168.2.1 zeigte - muss in den Tunnel rein zeigen,
damit Verbindungen von z. B. "192.168.2.17 => 8.8.8.8" dahin geroutet werden.

xxx.xxx.xxx.xxx ist das Netz hinter dem VPN-Server mit der IP 10.8.0.1 auf dessen tun0-Interface.

Der "Tunnel-Partner" 123.45.67.89 von 192.168.2.3 (jener ist die 10.8.0.10) hat tunnel-intern die 10.8.0.9 und nicht die 10.8.0.1.
Seine Beschreibung habe ich so verstanden, dass bereits 10.8.0.9 in der Lage ist, allen traffic in die weite Welt weiterzureichen.
Für was er dann die zusätzliche Route zum 10.8.0.1 noch braucht, ist mir nicht klar. [1]

Wenn ich mir die wlan0-Interface-Statistik anschaue,

RX packets:6817 errors:0 dropped:6842 overruns:0 frame:0

macht es evtl. Sinn, VPN-Gateway und DSL-Router per Kabel (eth0) zu verbinden.

[1] Nachtrag:
Ok, nach lesen der FAQs ist dies 'ne Folge von openvpn's komischen "/30"-modus

[CrunkBass]

Danke für euere schnellen Antworten. Ihr habt mein Anliegen anscheinend falsch verstanden.
Falls ich mich nicht deutlich genug ausgedrückt habe tut es mir leid. Ich versuche es mal darzustellen.

Verbindung zu 193.99.144.80 von einem PC, der 192.168.2.3 als Gateway eingetragen hat:

Code: Alles auswählen

192.168.2.0/24 (LAN) --> 192.168.2.3 (VPN-GATEWAY-IP) --> 10.8.0.9 (VPN-SERVER-IP-TUN) --> 123.45.67.89 (VPN-SERVER-IP-ETH) --> 193.99.144.80

Verbindung zu 193.99.144.80 vom Gateway selbst (zum Beispiel per wget):

Code: Alles auswählen

192.168.2.3 (VPN-GATEWAY-IP) --> 192.168.2.1 (ROUTER) --> x.x.x.x (DSL-IP) --> 193.99.144.80

Jetzt hast Du nicht verraten, welche VPN-software verwendest

Ich verwende OpenVPN. Das redirect-gateway ist aber für mein Vorhaben leider nicht zu gebrauchen, weil es jeglichen Traffic durch den VPN Server schicken würde. Auch die Anfragen, die direkt vom Gateway stammen (zum Beispiel per wget).

Wenn dein Gateway mit der IP 192.168.2.3 als Gateway bei allen Clients im Netz 192.168.2.0/24 eingetragen sein sollte, reicht ein...

Das reicht leider nicht weil dann nur der Traffic zum entfernten Netzwerk durch den Tunnel geleitet wird. Ich müsste 0.0.0.0 angeben um den kompletten Traffic durch den VPN Server zu routen. Nach dem Hinzufügen dieser Route würde immer noch die Standard Route zum DSL Router existieren. Die müsste man löschen. Nur dann hat das Gateway keine Route mehr zum VPN Server. Natürlich müsste auch diese noch hinzugefügt werden (Siehe die Ausgabe von route im ersten Beitrag).

Seine Beschreibung habe ich so verstanden, dass bereits 10.8.0.9 in der Lage ist, allen traffic in die weite Welt weiterzureichen.
Für was er dann die zusätzliche Route zum 10.8.0.1 noch braucht, ist mir nicht klar.

Das ist richtig. Der Server leitet bereits alle Anfragen über seine externe öffentliche IP weiter.
Diese Route nehme ich wegen der Einfachheit immer mit rein. So kann jeder Client den Server unter 10.8.0.1 erreichen. Normalerweise würde der Server ja nur unter 10.8.0.9 zu finden sein oder an einem anderen Client unter 10.8.0.11, 10.8.0.13 usw...

Wenn ich mir die wlan0-Interface-Statistik anschaue, macht es evtl. Sinn, VPN-Gateway und DSL-Router per Kabel (eth0) zu verbinden.

Die verworfenen Pakete stammen höchstwahrscheinlich vom Testen. Für viele Pakete existiert(e) keine gültige Route.
Dieser PC ist nur mein Testrechner. Der richitge PC, den ich später dafür verwenden werde, ist selbstverständlich per Kabel verbunden.

Ich hoffe mein Vorhaben jetzt deutlich erklärt zu haben und freue mich schon über die Lösungsvorschläge.

[dufty]

Ich verwende OpenVPN

Aha, bisher wusste ich, dass openvpn bei Angabe von
"--redirect-gateway" alleine die Default-Routen "austauscht", bei
"--redirect-gateway def1" den "/1-Trick" verwendet und so die bestehende default-route nicht anfasst.
Dass es aber die Metric erhöht ist mir neu. Man lernt nie aus

Die IP vom VPN-Gateway selbst vom Tunnel-Reinrouten rauszunehmen, sollte eigentlich über z. B.

Code: Alles auswählen

root@host:~# ip route add default via 192.168.2.1 dev wlan0 table 100
root@host:~# ip rule add from 192.168.2.3/32 table 100
root@host:~# ip route flush cache

gelingen (sog. Policy-based routing).
Versuche diesbezüglich waren bei mir jetzt nicht sonderlich erfolgreich

EDIT:
Sollte das nicht funktionieren, könnte ja auch noch die Weg "andersrum" probieren:
openvpn ohne "--redirect-gateway" starten und dann

Code: Alles auswählen

root@host:~# ip route add default via 10.8.0.9 dev tun0 table 100
root@host:~# ip rule add from 192.168.2.4/32 table 100
root@host:~# ip rule add from 192.168.2.5/32 table 100
root@host:~# ip rule add from 192.168.2.6/32 table 100
...
root@host:~# ip route flush cache

[CrunkBass]

Das könnte durchaus funktionieren. Werde es heute abend gleich mal testen sobald ich zuhause bin.
Ich habe zu dem Thema auch noch einen Link gefunden der eventuell nützlich sein könnte. http://lartc.org/howto/lartc.rpdb.multi ... tml#AEN298

EDIT: Heute werde ich leider doch keine Zeit mehr zum Testen haben. Ich melde mich am Freitag abends bzw. nachts wieder.

[CrunkBass]

Ich habe das Gateway nun richtig konfiguriert. Vielen Dank an dich dufty für die Hilfe. Hier meine Befehle:

Code: Alles auswählen

if [ `cat /etc/iproute2/rt_tables | grep -wc 181` -eq 0 ] ; then echo "181 gateway" >> /etc/iproute2/rt_tables ; fi

ip route add default via 10.8.0.9 dev tun0 table gateway
ip route add 10.8.0.1 via 10.8.0.9 dev tun0 table gateway
ip route add 10.8.0.9 dev tun0 table gateway
ip route add 123.45.67.89 via 192.168.2.1 dev wlan0 table gateway
ip route add 192.168.2.0/24 dev wlan0 proto kernel src 192.168.2.3 table gateway

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

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 192.168.2.0/24 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -o tun0 -j SNAT --to 10.8.0.10

ip rule add from 192.168.2.2/32 table gateway
for i in {4..254} ; do ip rule add from 192.168.2.$i/32 table gateway ; done

ip route flush cache

Für die Regeln habe ich leider keine andere Möglichkeit gefunden. Am liebsten wäre es mir anfangs ja gewesen wenn man einfach 192.168.2.0/24 über table gateway routen könnte und dann eben die Ausnahmen für 192.168.2.1 und 192.168.2.3 nochmals mit table main setzten müsste. Wenn ich das mache werden die 2 Einträge aber leider nicht beachtet. Im nachhinein ist diese Variante aber gar nicht mal so schlecht weil keine Regeln für die Standard-Verbindung benötigt werden. Somit gibt es schon mal eine Fehlerquelle weniger.

Bei funktionierender VPN Verbindung sehen meine Routing Tabellen folgendermaßen aus:

ip route show table main

Code: Alles auswählen

default via 192.168.2.1 dev wlan0
10.8.0.1 via 10.8.0.9 dev tun0
10.8.0.9 dev tun0  proto kernel  scope link  src 10.8.0.10
192.168.2.0/24 dev wlan0  proto kernel  scope link  src 192.168.2.3

ip route show table gateway

Code: Alles auswählen

default via 10.8.0.9 dev tun0
10.8.0.1 via 10.8.0.9 dev tun0
10.8.0.9 dev tun0  proto kernel  scope link  src 10.8.0.10
123.45.67.89 via 192.168.2.1 dev wlan0
192.168.2.0/24 dev wlan0  proto kernel  scope link  src 192.168.2.3

Das Routing funktioniert bis jetzt auch wunderbar:

traceroute 8.8.8.8 (Auf Gateway ausgeführt)

Code: Alles auswählen

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.2.1 (192.168.2.1)  6.474 ms  6.150 ms  5.753 ms
 2  217.0.119.13 (217.0.119.13)  22.122 ms  21.808 ms  21.470 ms
 .
 .
 .
10  google-public-dns-a.google.com (8.8.8.8)  32.336 ms  36.325 ms  35.960 ms

tracert 8.8.8.8 (Auf PC ausgeführt)

Code: Alles auswählen

Routenverfolgung zu google-public-dns-a.google.com [8.8.8.8] über maximal 30 Abschnitte:

  1     6 ms     3 ms     3 ms  192.168.2.3
  2    55 ms    52 ms    51 ms  10.8.0.1
  .
  .
  .
 13   146 ms   101 ms   100 ms  google-public-dns-a.google.com [8.8.8.8]

Ablaufverfolgung beendet.

OpenVPN hatte ich übrigens schon die ganze Zeit ohne "redirect-gateway" laufen.
Das steht zwar in der Server Config mit drinnen um es für die Einwahl von PCs leicher zu machen aber am Gateway habe ich es mit "route-nopull" deaktiviert.

Falls Interesse besteht kann ich meine Scripts, welche von OpenVPN nach dem Herstellen und Trennen der Verbindung aufgerufen werden, auch noch hier posten.
Das wird aber ein bisschen dauern weil ich sie erst noch schreiben muss.

EDIT: Deinen editierten Beitrag habe ich gerade erst gelesen. Ja es gab Probleme bei der ersten Variante. Wahrscheinlich lag es nur an ein paar Einträgen, die ich in der Routing Tabelle vergessen hatte. Als ich dann ein bisschen drüber nachdachte fand ich die jetzige Lösung schöner. So bleibt die main Routing Tabelle unangetastet und es kann zu keinen Fehlern bei einem Verbindungsaufbau kommen. Bzw. falls etwas nicht funktionieren sollte weiß ich schon mal dass es nicht an der Routing Tabelle liegen kann.