TL; DR: Двойной VPN на Raspberry Pi. Может ssh и видеть акции samba на локальных устройствах через VPN. Не удается получить интернет-трафик через VPN. Не знаю, как действовать.
Моя установка - это один запущенный Raspberry Pi openvpn и pi-hole. У меня есть два экземпляра openvpn:
server.conf - VPN-хост через tun-incoming. Это работает, я могу видеть запросы DNS VPN на 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 нат -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
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 (например, хостам LAN и внешнему поставщику VPN).
Рассматривая только второй вариант использования, который вы упомянули (используйте поставщика VPN для серфинга в Интернете), теоретически у вас есть два способа решить эту проблему:
tun-incoming)Очевидно, что первый метод не возможно при наличии внешних субъектов (провайдера 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 подсеть).