Bestimmten Traffic über Gerät im Netzwerk Routen, welches eine VPN Anbindung hat

[ebolalemon]

Moin,

folgendes Szenario:

Ich habe einen OpenVPN Server an den mehrere Clienten angebunden sind.
Diese würde ich gerne alle von meinem Heimnetzwerk aus erreichen.

VPN Netz: 10.8.0.0/24, wobei 10.8.0.1 der Server ist.
Heimnetz: 192.168.10.0/24

Nun habe ich mir überlegt, damit ich mich nicht bei jedem meiner Geräte im Heimnetz zum VPN connecten muss, nehme ich mir einen Raspberry, verbinde diesen mit dem VPN Server und lasse meinen lokalen Traffic bei dem das Ziel im Netz 10.8.0.0/24 liegt über den Pi routen.

Dazu habe ich in meinem Router folgende statische Route eingetragen:

Ziel-IP-Adresse	Subnetz-Maske	Gateway
10.8.0.0	255.255.255.0	192.168.10.11

Auf dem Pi habe ich ipv4 Packet forwarding aktiviert.

Also vom Pi aus den Server anpingen geht, tcpdump zeigt:

listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
14:17:48.793290 IP 10.8.0.2 > 10.8.0.1: ICMP echo request, id 993, seq 1, length 64
14:17:48.793322 IP 10.8.0.1 > 10.8.0.2: ICMP echo reply, id 993, seq 1, length 64

Alles so, wie es sein muss, Paket geht raus und eine Antwort kommt zurück.
Wenn ich nun allerdings von einem anderen Gerät aus meinem Heimnetzwerk aus die 10.8.0.1 anpinge, nimmt der Pi das ausgehende Paket zwar wahr, aber leitet es offensichtlich nicht weiter.
tpcdump vom Pi:

listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
18:57:57.719090 IP 192.168.10.20 > 10.8.0.1: ICMP echo request, id 1, seq 533, length 40

-> Keine Antwort, also habe ich nachgeguckt ob beim Server überhaupt etwas ankommt, der tcpdump bleibt also leer.

Nun Frage ich mich, warum der Pi das Paket nicht weiterleitet, er kennt die Route und Packet Forwarding ist aktiviert.
Habe ich einen grundsätzlichen Denkfehler, oder muss ich zur Not einen weiteren Tunnel aufbauen, bei dem der Server sich als Client zu meinem Pi verbindet?

Ich bin über jeden Rat erfreut (außer: lass es bleiben)

 

[Harrdy]

Was du brauchst.

1) Statische Route von deinem Gateway (Fritzbox) in das VPN Netz. In diesem Beispiel 10.8.0.0/24 über IP des Raspberry
2) Statische Route am VPN Server in dein Netz

Hier ein Auszug aus meiner Routing Tabelle wie das ganze aussehen sollte. VPNGateway wäre bei dir der Pi

root@vpnServer:~# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         94.23.219.254   0.0.0.0         UG    0      0        0 eth0
94.x.x.x   0.0.0.0         255.255.255.255 UH    0      0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.170.0   192.168.10.10   255.255.255.0   UG    0      0        0 br0


root@vpngateway:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.170.1   0.0.0.0         UG    0      0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.0   U     0      0        0 tap0
192.168.170.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

In diesem Beispiel ist vpnServer mein Rootserver. Das VPN-Netz ist 192.168.10.0/24, das Heimnetz bei mir Zuhause ist 192.168.170.0/24. Der VPNServer hat die IP 192.168.10.1, mein VPNGateway hat die 192.168.10.10 sowie 192.168.170.250

Die Route in der Fritzbox lautet 192.168.10.0/24 über 192.168.170.250

Dann brauchst du am Pi nur noch das Routing aktivieren

       sysctl -w net.ipv4.ip_forward=1
        sysctl -w net.ipv6.conf.all.forwarding=1

Ein Tracert aus dem Netz 192.168.170.0/24 sieht dann so aus.

C:\Users\user>tracert -d 192.168.10.1

Routenverfolgung zu 192.168.10.1 über maximal 30 Hops

  1    <1 ms    <1 ms    <1 ms  192.168.170.1
  2    <1 ms    <1 ms    <1 ms  192.168.170.250
  3    34 ms    34 ms    33 ms  192.168.10.1

Das ganze funktioniert 100% auch mit dem Pi. Weil ich genau diesen Setup bei meinen Eltern aufgrund eines nicht vorhandenen Servers mit einem Pi umgesetzt habe.

 

[ebolalemon]

Die Routen sind alle gesetzt, Routing ist ja wie gesagt auch aktiviert.
Trotzdem funktioniert es nicht.

Die ICMP Pakete kommen ja am Pi an, aber ab da verschwinden sie ins Nirvana, am Server kommt nie etwas an.

Normalerweise müsste ich ja im tcpdump sehen, dass die Pakete von meinem PC am Pi ankommen, und dass dann Pakete an den Server gesendet werden (oder?), aber diesen Schritt macht der Pi ja gar nicht erst.
Meine Vermutung liegt daher, dass am Pi was nicht stimmt, aber hätte ja auch sein können, dass meine Routen falsch sind, was ja eigentlich nicht der Fall ist.

Ergänzung (22. April 2017)

Ich bin ein Held, habe in die iptables-regeln tun00 statt tun0 geschrieben.
Problem ist damit gelöst, für andere Fehlersuchende, folgende iptables regel steht:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

 

[Harrdy]

Eigentlich sollten iptables in diesem Szenario nicht notwenig sein. Einzig die "Default Policy" für Forward muss auf Accept stehen

iptables -P FORWARD ACCEPT

Bzw. selektiv gesetzt sein für Clients die Zugriff erhalten sollen

iptables -A FORWARD -s $i -m state --state NEW -j ACCEPT

Du hast jetzt NAT für tun0 aktiviert. Das heißt sämtliche Pakete aus deinem 192.168.10.0/24er Netz tauchen an deinem VPNServer mit der IP Absenderadresse auf welche dein Pi VPN seitig hat. Auch benötigt der Pi für NAT deutlich mehr Rechenleistung als wenn er nur Routen müsste.

 

[ebolalemon]

Ich hatte es auch zu erst ohne nat bzw. iptables probiert, funktioniert hat es aber nicht.
Auch iptables -P FORWARD ACCEPT funktioniert nicht, Pakete kommen wieder beim Pi an aber werden nicht weitergeleitet.

Ergänzung (22. April 2017)

Und jetzt hab ich's total zerschossen, der Pi "NATet" auf einmal nicht mehr, obwohl nur das als iptables Regel steht. Beim Server kommt dann die Anfrage von meinem Gerät (192.168.10.20 bspw.), weshalb ich noch die iroute 192.168.10.0 in die Server config packen musste und ich muss jedes mal wenn ich den openvpn dienst starte die route "192.168.10.0 10.8.0.200 255.255.255.0 UG 0 0 0 tun0" erstellen.
Gibts da ne Möglichkeit das permanent zu machen? (habe die ip des pi gateways zu 10.8.0.200 geändert)

 

[Harrdy]

Um es einen Config-Befehl gibt um Serverseitig routen zu setzen kann ich dir gar nicht genau sagen. Ich nutz dafür ein Bashscript weil ich mehrere OpenVPN Instanzen (tcp/udp) habe und dafür ein Bridgeinterface nutze.

#!/bin/bash

#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils
#################################

# Define Bridge Interface
br="br0"

tap="tap0 tap1"

eth="eth0"
eth_ip="192.168.10.1"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.10.255"

for t in $tap; do
    /usr/sbin/openvpn --mktun --dev $t
done

/sbin/brctl addbr $br

for t in $tap; do
    /sbin/brctl addif $br $t
done
/sbin/brctl addif $br eth1

for t in $tap; do
    /sbin/ifconfig $t 0.0.0.0 promisc up
done
/sbin/ifconfig eth1 0.0.0.0 promisc up


/sbin/ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast

/sbin/route add -net 192.168.170.0 netmask 255.255.255.0 gw 192.168.10.10
/sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.10.20

/etc/init.d/firewall start

Das wird gestartet sobald die Netzwerkkarte on gekommen ist.

iface eth0 inet static
        address 178.x.x.x
        netmask 255.255.255.255
        broadcast 178.x.x.x
        post-up route add 94.x.x.x dev eth0
        post-up route add default gw 94.x.x.x
        post-up /etc/openvpn/bridge.sh
        pre-down route del 94.x.x.x dev eth0
        pre-down route del default gw 94.x.x.x

 

[Raijin]

Problem ist damit gelöst, für andere Fehlersuchende, folgende iptables regel steht:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

NAT bzw. masquerade braucht man nur, wenn das Routing eben NICHT stimmt - mal von der Firewall abgesehen, s.u.. Bei korrektem Routing kommen Pakete von "fremden" IP-Adressen am Ziel an und werden anhand der Routing Tabelle wieder zurückgeschickt. Ist auf beiden Seiten des Tunnels also eine Route ins jeweils andere Subnetz vorhanden, braucht man kein NAT.

Allerdings hat die lokale Firewall auch noch ein Wörtchen mitzureden. Windows blockt zum Beispiel standardmässig Traffic von unbekannten Subnetzen, nur die lokalen Subnetze sind freigegeben. Hier muss also mindestens die Quell-IP des anfragenden Geräts bzw. das Subnetz ebenfalls freigegeben werden. Darüberhinaus können Serverdienste zum Teil auch selbst Anfragen aus fremden Subnetzen abblocken. Das sind zwei Stellschrauben am Server, die man prüfen muss. NAT erschlägt zwar beides, aber das ist eher der Dampfhammer, weil man es nicht besser weiß.

Wie sehen denn die anderen Subnetze aus? Oder auf welche IPs willst du dich eigentlich verbinden? Deine OpenVPN-Config wäre auch mal ganz interessant zwecks Topologie Einstellungen, etc. Sofern du nämlich nicht topology subnet verwendest, sondern net30 (bei älteren OpenVPN Versionen Standard!), dann wird das VPN-Subnetz in /30er Bereiche gesplittet und jeder Client bekommt sein eigenes /30er Subnetz zum Server.

Mit route 192.168.10.0 255.255.255.0 kann man OpenVPN sagen, dass diese Route lokal hinzugefügt und über das VPN geroutet werden soll. iroute ist ein Client-Kommando und hat in der server.conf nix zu suchen. Dafür muss im Server client-config-dir ccd aktiviert sein und im entsprechenden Clientfile (ccd/client) dann das iroute Kommando. Dann weiß der Server, dass er grundsätzlich lokal dieses Subnetz überhaupt über das VPN routen soll und wenn der jeweilige Client verbindet weiß er auch an welches Gateway er es routen soll. Wenn auch andere Clients über diese Route in Kenntnis gesetzt werden sollen, muss im Server push "route 192.168.10.0 255.255.255.0 eingetragen werden, um diese Route an die VPN-Clients zu verteilen.

 

[ebolalemon]

Danke aber es funktioniert doch jetzt schon alles so wie du es schreibst. Die iroute ist im Prinzip schon in der Server config, nur Abend noch in eine andere Datei gepackt, die ja vom Server eingelesen wird, was in der config vermerkt ist

Aber das mit der lokalen Route brauche ich noch, allerdings führt die Serverseitige Option route 192.168.10.0 255.255.255.0 zu nichts. Die Route steht dann immer noch nicht (mit route -n getestet) und ich muss diese manuell hinzufügen.

 

[Raijin]

Danke aber es funktioniert doch jetzt schon alles so wie du es schreibst. Die iroute ist im Prinzip schon in der Server config, nur Abend noch in eine andere Datei gepackt, die ja vom Server eingelesen wird, was in der config vermerkt ist

Wie gesagt, iroute ist client-spezifisch. Das hat nix in der server.conf zu suchen, sondern ausschließlich in einer client-spezifischen Datei (client-config-dir). Solange du deine Config aber nicht postest, kann man nicht beurteilen ob du das auch so gemacht hast. "funktioniert doch alles" hörte sich aber in Beitrag 5 ganz anders an.

Aber das mit der lokalen Route brauche ich noch, allerdings führt die Serverseitige Option route 192.168.10.0 255.255.255.0 zu nichts. Die Route steht dann immer noch nicht (mit route -n getestet) und ich muss diese manuell hinzufügen.

Ich kann's gerade leider nicht testen, aber evtl. fügt OpenVPN die Route erst hinzu, wenn die dazugehörige iroute im ccd ausgeführt wurde. Hab mal Onkel google bemüht und folgende Resultate bekommen: Klick1 + Klick2

Kannst ja mal durchlesen falls ich ausm Kopp irgendwas vergessen habe

 

[ebolalemon]

hier meine ccd:

push "redirect-gateway autolocal"
ifconfig-push 10.8.0.200 255.255.255.0
iroute 192.168.10.0 255.255.255.0

Ich hab das auch nicht direkt in die server config getan, sondern wie gesagt verlinkt man diese dort nur.

Da man ja aber auch die Zertifikate wie ca.crt direkt in die Server/Client config mittels
<ca>
CERT
</ca>
schreiben kann, würde ich jetzt nicht ausschließen, dass das beim ccd auch geht.
In Beitrag 5 steht doch nur, dass mein NAT nicht mehr funktioniert, sondern nun das Routing
(Vielleicht etwas unschön geschrieben)

server.conf:

port *****
proto udp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
script-security 2
push "redirect-gateway autolocal"
route 192.168.10.0 255.255.255.0
push "dhcp-option DNS 8.8.8.8"
keepalive 10 30
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
auth SHA512
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 6
user openvpn
group openvpn
log-append /var/log/openvpn.log
client-config-dir /etc/openvpn/ccd

client config vom gateway (pi):
client
dev tun
proto udp
remote public-ip port
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
auth SHA512
comp-lzo
verb 3
explicit-exit-notify
log-append /var/log/openvpn.log
<alle benötigten zertifikate/keys>

Ergänzung (24. April 2017)

Es könnte sein, dass das mit route 192.168.10.0 255.255.255.0 doch funktioniert hat, es kommt zwar keine zusätzliche route wenn ich mir route -n ausgeben lasse, allerdings kann ich von anderen Pi's aus meinem Heimnetzwerk den openvpn server anpingen.
Ich werde dann heute abend wenn ich zu Hause bin checken ob alles so funktioniert, ich war jetzt nur kurz via SSH im Heimnetz.