VPN de doble salto: solo se puede ver el tráfico LAN, no Internet

VPN de doble salto: solo se puede ver el tráfico LAN, no Internet

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 openvpny pi-hole. Tengo dos instancias de openvpn:

  • server.conf- Host VPN terminado tun-incoming. Esto está funcionando, puedo ver las solicitudes de DNS de VPN en pi-hole.
  • outgoing.conf- conectarse a un proveedor de VPN a través de tun-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-outgoingla 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/24conoce 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:

  1. Configurando (estática/automáticamente) una ruta en cada host al que necesita acceder desde dentro de su VPN ( tun-incoming)
  2. 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/24a 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 raspberrypi2es la puerta de enlace predeterminada de la LAN, simplemente puede eliminar la regla NAT y todo funcionará correctamente.

Si rasperrypi2esnola 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 raspberrypi2solo a la 10.8.0.0/24subred).

información relacionada