TLDR: VPN de doble salto en Raspberry Pi. Puede enviar ssh y ver recursos compartidos de samba de dispositivos locales a través de VPN. No puedo obtener tráfico de Internet a través de VPN. No estoy seguro de como proceder.
Mi configuración es una única Raspberry pi ejecutándose openvpn
y pi-hole
. Tengo dos instancias de openvpn:
server.conf
- Host VPN terminadotun-incoming
. Esto está funcionando, puedo ver las solicitudes de DNS de VPN enpi-hole
.outgoing.conf
- conectarse a un proveedor de VPN a través detun-outgoing
. Trabajando localmente. Puedo ver una nueva IP.
Estoy siguiendo principalmente esta guía:https://www.comparitech.com/blog/vpn-privacy/raspberry-pi-vpn/ La idea es que debería poder (1) hacer ssh, ver archivos compartidos, etc. en todos mis dispositivos en 192.168.*.* en mi red local y (2) tener un túnel de Internet a través del proveedor de VPN. El primer caso de uso está funcionando bien.
He probado esto según la guía:
ip rule add from 192.168.1.166 lookup 101
ip route add default via 192.168.1.1 table 101
Después, perdí la capacidad de conectar SSH a través de ipv4
.
A continuación se presentan algunos resultados relevantes:
lista de rutas 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
lista de reglas 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
Respuesta1
TL;DRNo necesitas una regla de IP. Todo lo que necesita aquí es otra regla NAT para los paquetes que salen de tun-outgoing
la interfaz.
Explicación:
Lo que sucede es que el enrutador del proveedor de VPN (p. ej. 10.1.11.5 dev tun-outgoing
) no sabe cómo comunicarse 10.8.0.0/24
, por lo que los paquetes se descartan o se pierden.
Esto se debe al hecho de que el enrutador 10.8.0.0/24
conoce la red (lo que significa que está en la tabla de enrutamiento) raspberrypi2
, pero es desconocida para cualquier otro host que no esté en la misma VPN (como los hosts de LAN y el proveedor de VPN externo).
Mirando solo el segundo caso de uso que mencionaste (usar el proveedor de VPN para navegar por Internet),En teoriaTienes dos formas de resolver esto:
- Configurando (estática/automáticamente) una ruta en cada host al que necesita acceder desde dentro de su VPN (
tun-incoming
) - O bien, enmascarando la IP mediante NAT
El primer método es obviamentenofactible en presencia de actores externos (el proveedor de VPN), por lo que puede resolver este problema solo creando una regla NAT como esta:
-A POSTROUTING -s 10.8.0.0/24 -o tun-outgoing -j MASQUERADE
Esta regla enmascarará todas las conexiones de su VPN 10.8.0.0/24
a Internet a través de VPN utilizando la dirección IP (de origen) del raspberrypi2
, que es conocida por el proveedor de VPN.
Primer caso de uso (acceso LAN):
Para el primer caso de uso, puede (y de hecho lo hace) seguir utilizando el método NAT, pero también puede aplicarse el método 2. Para aplicarlo, si raspberrypi2
es la puerta de enlace predeterminada de la LAN, simplemente puede eliminar la regla NAT y todo funcionará correctamente.
Si rasperrypi2
esnola puerta de enlace predeterminada de la LAN, aún puede aplicar el método 2 de la siguiente manera:
- configurar una ruta estática en la puerta de enlace predeterminada actual de la LAN
- o, configurando una ruta estática encadaanfitrión de la LAN
(ambos, obviamente, apuntan raspberrypi2
solo a la 10.8.0.0/24
subred).