☰

Double-Hop-VPN - Kann nur LAN-Verkehr sehen, kein Internet

tag-icon • tag-icon debian iptables vpn openvpn
Double-Hop-VPN - Kann nur LAN-Verkehr sehen, kein Internet

Kurz zusammengefasst: Double-Hop-VPN auf Raspberry Pi. Kann per SSH auf Samba-Freigaben lokaler Geräte über VPN zugreifen und diese anzeigen. Internetverkehr kann über VPN nicht empfangen werden. Bin mir nicht sicher, wie ich weiter vorgehen soll.

Mein Setup besteht aus einem einzelnen Raspberry Pi openvpnund pi-hole. Ich habe zwei Instanzen von OpenVPN:

  • server.conf- VPN-Host über tun-incoming. Das funktioniert, ich kann VPN-DNS-Anfragen auf sehen pi-hole.
  • outgoing.conf- Verbindung zu einem VPN-Anbieter über tun-outgoing. Funktioniert lokal. Ich kann eine neue IP sehen.

Ich folge hauptsächlich dieser Anleitung:https://www.comparitech.com/blog/vpn-privacy/raspberry-pi-vpn/ Die Idee ist, dass ich (1) auf allen meinen Geräten unter 192.168.*.* in meinem lokalen Netzwerk SSH verwenden, freigegebene Dateien sehen usw. können und (2) das Internet über den VPN-Anbieter tunneln lassen kann. Der erste Anwendungsfall funktioniert einwandfrei.

Ich habe dies gemäß der Anleitung versucht:

ip rule add from 192.168.1.166 lookup 101
ip route add default via 192.168.1.1 table 101

Danach konnte ich keine SSH-Verbindung mehr herstellen ipv4.

Nachfolgend sind einige relevante Ergebnisse aufgeführt:

IP-Routenliste

pi@raspberrypi2:~ $ ip route list
0.0.0.0/1 via 10.1.11.5 dev tun-outgoing
default via 192.168.1.1 dev eth0 src 192.168.1.166 metric 202
10.1.11.1 via 10.1.11.5 dev tun-outgoing
10.1.11.5 dev tun-outgoing proto kernel scope link src 10.1.11.6
10.8.0.0/24 dev tun-incoming proto kernel scope link src 10.8.0.1
128.0.0.0/1 via 10.1.11.5 dev tun-outgoing
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.166 metric 202
199.229.249.184 via 192.168.1.1 dev eth0

IP-Regelliste

pi@raspberrypi2:~ $ ip rule list
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

iptables -t nat -S

pi@raspberrypi2:~ $ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -m comment --comment openvpn-nat-rule -j MASQUERADE

ifconfig

pi@raspberrypi2:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.166  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2604:2000:6aa0:c0d0::307  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::7a09:12ee:27ff:f6fc  prefixlen 64  scopeid 0x20<link>
        inet6 fd38:2d6b:a55b::111  prefixlen 128  scopeid 0x0<global>
        inet6 fd38:2d6b:a55b::307  prefixlen 128  scopeid 0x0<global>
        inet6 fd38:2d6b:a55b:0:3ed3:ce3b:88db:5070  prefixlen 64  scopeid 0x0<global>
        inet6 2604:2000:6aa0:c0d0:70cf:5710:52e:373e  prefixlen 64  scopeid 0x0<global>
        ether dc:a6:32:65:73:5d  txqueuelen 1000  (Ethernet)
        RX packets 48570  bytes 8636380 (8.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 55906  bytes 34181320 (32.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 331  bytes 27074 (26.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 331  bytes 27074 (26.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun-incoming: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.1  netmask 255.255.255.0  destination 10.8.0.1
        inet6 fe80::a8c2:d1fa:b798:f945  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 432 (432.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun-outgoing: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.1.11.6  netmask 255.255.255.255  destination 10.1.11.5
        inet6 fe80::9fe5:8e1:b1c0:86c5  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 24200  bytes 3403386 (3.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 30214  bytes 29464427 (28.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:65:73:5e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Antwort1

Kurz zusammengefasstSie benötigen keine IP-Regel. Alles, was Sie hier brauchen, ist eine weitere NAT-Regel für Pakete, die über tun-outgoingdie Schnittstelle ausgehen.

Erläuterung: Was passiert, ist, dass der Router des VPN-Anbieters (z. B. 10.1.11.5 dev tun-outgoing) nicht weiß, wie er zurückkommt 10.8.0.0/24, sodass Pakete gelöscht werden/verloren gehen.

Dies liegt daran, dass das Netzwerk 10.8.0.0/24dem Router bekannt ist (d. h., es befindet sich in der Routing-Tabelle) raspberrypi2, aber keinem anderen Host, der sich nicht im selben VPN befindet (wie z. B. LAN-Hosts und dem externen VPN-Anbieter), bekannt ist.

Betrachtet man nur den zweiten Anwendungsfall, den Sie erwähnt haben (Nutzung des VPN-Anbieters zum Surfen im Internet),in der TheorieSie können dieses Problem auf zwei Arten lösen:

  1. Indem Sie (statisch/automatisch) in jedem Host eine Route konfigurieren, die Sie von Ihrem VPN aus erreichen müssen ( tun-incoming)
  2. Oder durch Maskieren der IP mit NAT

Die erste Methode ist offensichtlichnichtDies ist bei Vorhandensein externer Akteure (des VPN-Anbieters) nicht möglich, daher können Sie dieses Problem nur durch die Erstellung einer NAT-Regel wie dieser lösen:

-A POSTROUTING -s 10.8.0.0/24 -o tun-outgoing -j MASQUERADE

Diese Regel maskiert alle Verbindungen von Ihrem VPN 10.8.0.0/24zum Internet über VPN unter Verwendung der (Quell-)IP-Adresse des raspberrypi2, die dem VPN-Anbieter bekannt ist.

Erster Anwendungsfall (LAN-Zugriff): Für den ersten Anwendungsfall können Sie (und tun dies auch) immer noch die NAT-Methode verwenden, aber auch Methode 2 kann anwendbar sein. Um sie anzuwenden, raspberrypi2können Sie, wenn das Standard-Gateway des LAN ist, einfach die NAT-Regel entfernen und alles wird ordnungsgemäß funktionieren.

Wennrasperrypi2​nichtdas Standard-Gateway des LAN, können Sie Methode 2 trotzdem anwenden, indem Sie:

  • Konfigurieren einer statischen Route im aktuellen Standard-Gateway des LAN
  • oder die Konfiguration einer statischen Route injedeHost des LAN

(beide verweisen offensichtlich raspberrypi2nur auf das 10.8.0.0/24Subnetz).

verwandte Informationen