VPN с двойным подключением — видит только трафик локальной сети, интернета нет

Question

Краткий обзор: Double-hop VPN на Raspberry Pi. Можно подключиться по SSH и увидеть общие ресурсы Samba локальных устройств через VPN. Невозможно получить интернет-трафик через VPN. Не уверен, что делать дальше.

Моя настройка — это один Raspberry Pi, работающий openvpnи pi-hole. У меня есть два экземпляра OpenVPN:

• server.conf- VPN-хост через tun-incoming. Это работает, я вижу VPN DNS-запросы на pi-hole.
• outgoing.conf- подключение к поставщику VPN через tun-outgoing. Работаю локально. Я вижу новый IP.

Я в основном следую этому руководству:https://www.comparitech.com/blog/vpn-privacy/raspberry-pi-vpn/ Идея в том, что я должен иметь возможность (1) ssh, видеть общие файлы и т. д. на всех моих устройствах в 192.168.*.* в моей локальной сети и (2) иметь интернет-туннелирование через поставщика VPN. Первый вариант использования работает нормально.

Я попробовал сделать это согласно инструкции:

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

После этого я потерял возможность подключаться по SSH ipv4.

Ниже приведены некоторые соответствующие результаты:

список маршрутов ip

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

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

Answer 1

TL;DRВам не нужно правило IP. Все, что вам нужно здесь, это еще одно правило NAT для пакетов, выходящих из tun-outgoingинтерфейса.

Объяснение: Происходит следующее: маршрутизатор VPN-провайдера (например 10.1.11.5 dev tun-outgoing) не знает, как связаться с ним 10.8.0.0/24, поэтому пакеты отбрасываются/теряются.

Это связано с тем, что сеть 10.8.0.0/24известна raspberrypi2маршрутизатору (то есть она есть в таблице маршрутизации), но она неизвестна ни одному другому хосту, не входящему в ту же VPN (например, хостам локальной сети и внешнему провайдеру VPN).

Рассматривая только второй вариант использования, который вы упомянули (использование VPN-провайдера для серфинга в Интернете),в теорииУ вас есть два способа решить эту проблему:

1. Настроив (статически/автоматически) маршрут на каждом хосте, к которому вам необходимо получить доступ изнутри вашего VPN ( tun-incoming)
2. Или, маскируя IP с помощью NAT

Первый способ, очевидно,нетосуществимо при наличии внешних участников (провайдера VPN), поэтому решить эту проблему можно, только создав правило NAT, подобное следующему:

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

Это правило будет маскировать все подключения вашего VPN 10.8.0.0/24к Интернету через VPN с использованием (исходного) IP-адреса raspberrypi2, который известен провайдеру VPN.

Первый вариант использования (доступ к локальной сети): Для первого варианта использования вы можете (и фактически используете) по-прежнему использовать метод NAT, но также может быть применим метод 2. Чтобы применить его, если raspberrypi2является шлюзом по умолчанию локальной сети, вы можете просто удалить правило NAT, и все будет работать правильно.

Если rasperrypi2естьнетшлюз по умолчанию локальной сети, вы все равно можете применить метод 2:

• настройка статического маршрута в текущем шлюзе по умолчанию локальной сети
• или, настроив статический маршрут вкаждыйхост локальной сети

(оба, очевидно, указывают raspberrypi2только на 10.8.0.0/24подсеть).