Puerta de enlace VPN en Raspberry Pi: una NIC o un puerto de cliente dedicado

Tiene una Pi, un perfil VPN de salida que funciona y dos dispositivos que deberían llegar a internet a través de ella. La pregunta que decide toda la construcción no es qué guía seguir, sino cuánta contención necesita. Un solo puerto permite que la Pi se sitúe junto a esos dispositivos en la LAN del router y actúe como puerta de enlace adicional; un segundo puerto permite ponerlos en un segmento donde la Pi es la única salida. Todo lo que viene después de esa elección — DHCP, alcance del cortafuegos, DNS, el caso de caída — se deriva de ella.

En qué se diferencian realmente los dos diseños

Ambos diseños enrutan. La diferencia es quién más está en el cable y qué pasa cuando su política es incorrecta.

La contención es el eje real. El diseño A es orientativo: un dispositivo que ignora la puerta de enlace entregada por DHCP y elige el router sigue funcionando, sin cifrar. El diseño B se impone por topología, porque no hay otro salto siguiente que elegir.

Diseño A: la Pi como puerta de enlace adicional en la LAN existente

Suponga que el router del ISP es 192.168.50.1, la Pi es 192.168.50.2 y los clientes elegidos apuntan a la Pi. Lo importante es que dos flujos de paquetes distintos comparten un solo cable. El paquete interno del cliente llega a la Pi y debe salir por el túnel; el paquete cifrado propio de la Pi hacia el par VPN debe salir por el mismo cable hacia el router. Viajan en direcciones opuestas por la misma interfaz y necesitan un tratamiento distinto.

Dele a la Pi su dirección mediante el gestor de red instalado, no con una receta antigua de archivo de interfaz que compite con él por el dispositivo. Luego configure los clientes: una puerta de enlace estática en un dispositivo, o una reserva DHCP que entrega 192.168.50.2 como router. No cambie todo el ámbito DHCP del router por dos dispositivos, y no dé por hecho que un cliente respeta la opción — verifíquelo.

La debilidad es estructural, no reparable. Cualquier cliente de ese segmento puede apuntar a 192.168.50.1 y salir en claro, y un dispositivo con una segunda interfaz o una radio celular abandona por completo su ruta de aplicación. Si esa frase es inaceptable para el dispositivo en cuestión, ya tiene su respuesta: use el diseño B.

Diseño B: un puerto dedicado encierra los dispositivos

Aquí la Pi conserva 192.168.50.2 en el enlace ascendente con puerta de enlace 192.168.50.1, y toma 10.20.0.1/24 en una segunda interfaz para los dispositivos conectados. Ahora la Pi es un router con dos redes, y el segmento conectado tiene exactamente una salida.

Compruebe el rango contra todo lo demás antes de comprometerse: la subred propia del túnel, otros prefijos entre sedes y cualquier cosa alcanzable a través de la VPN. Una 10.20.0.0/24 que choca con una LAN remota produce ese resultado a medio funcionar que cuesta una tarde de diagnóstico. Si el segundo puerto es un adaptador USB, confirme que es compatible y fije su nombre en el gestor de red para que una reordenación tras el reinicio no mueva su dirección de LAN.

Ejecute el oyente DHCP solo en esa interfaz. Un servidor que responde en el enlace ascendente compite con el router del ISP y entrega las direcciones de su segmento al resto de la casa. Átelo a la interfaz LAN, restrínjalo al rango declarado y mantenga la dirección propia de la Pi fuera del grupo.

Reenvío, traducción y la regla de cierre ante fallo

Cuatro cosas se describen a menudo como una y no lo son. Habilitar el reenvío (net.ipv4.ip_forward=1) solo dice al núcleo que puede mover paquetes entre interfaces; no permite nada por sí mismo ni garantiza ningún camino. Elegir la salida es una decisión de enrutamiento. Permitir el paquete es una decisión de política en la cadena forward. Reescribir su origen es una decisión de postrouting. Una construcción que solo hace lo primero produce una Pi que reenvía alegremente el tráfico de los clientes hacia el enlace ascendente.

Limite el permiso a las fuentes que pretendía y a la interfaz que el tráfico debe usar, e incluya el camino de vuelta y los destinos que la Pi necesita. Luego traduzca en la salida del túnel si el proveedor no le enruta de vuelta el prefijo de su LAN. manual de nftables trata el reenvío, la salida local y la traducción de origen como operaciones separadas, que es el modelo mental correcto aquí.

El fallo habitual es una regla masquerade amplia en la interfaz física. Entonces el tráfico llega a internet por la ruta del ISP mientras, desde el lado del cliente, parece exactamente una VPN que funciona. No demuestra nada. Mantenga la traducción ligada a la salida declarada y mantenga sus reglas en el cortafuegos que el host ya usa, en lugar de añadir un conjunto de reglas competidor que vacía una cadena postrouting compartida.

Después aborde la ausencia del túnel. Un perfil de cliente que instala una ruta por defecto amplia también significa que, cuando el túnel cae, la ruta por defecto ordinaria puede volver y el tráfico del cliente regresa en silencio al enlace ascendente. Donde la vuelta a texto claro no es aceptable, la política forward debe denegar explícitamente el tráfico de cliente al enlace ascendente, en el estado en que la ruta VPN ha desaparecido. Escríbalo como una regla de rechazo, no como una suposición. El transporte cifrado propio de la Pi hacia el par VPN es un flujo local-output aparte y debe seguir permitido, o el túnel nunca podrá volver.

DNS e IPv6 necesitan su propia respuesta

Si los clientes usan la Pi como resolutor, llegan a un oyente local y la Pi origina una consulta nueva. Esa consulta ascendente sigue la ruta propia de la Pi, no la regla forward que escribió para los clientes, así que una ruta de cliente solo por el túnel más un resolutor que sale directamente es una fuga sin ningún mensaje de error. Decídalo a propósito: un resolutor alcanzado por el túnel, o uno local que acepte como directo, y haga que la política de salida propia de la Pi coincida con esa decisión.

IPv6 es de nuevo un caso aparte. Una regla forward de IPv4 no restringe nada sobre IPv6, y los anuncios de router en el enlace ascendente pueden dar a la Pi, y a través de ella al segmento conectado, una segunda ruta por defecto que esquiva su política. O bien dé a IPv6 su propio camino protegido con el mismo principio, o bien restrínjalo explícitamente en el segmento de clientes y dígalo.

Pruebe la frontera antes de confiar en ella

Acepte el diseño solo tras cuatro comprobaciones separadas, porque la tentadora prueba única — abrir un navegador en un cliente — pasa en varios estados rotos.

Confirme que un cliente real llega a internet por el túnel, y luego confirme que ese mismo cliente no puede llegar a internet con el túnel caído. Confirme que la resolución DNS funciona y que la consulta sale donde usted quería. Confirme que el transporte propio de la Pi sigue funcionando tras un reinicio del túnel, y que la recuperación no exige reiniciar la máquina. Por último, compruebe un dispositivo que no eligió: con el diseño A debería seguir funcionando con normalidad, y con el diseño B no debería existir en absoluto en ese segmento.

• Dos puertos y una regla de denegación dan aplicación; un puerto y una opción DHCP dan consejo.
• La traducción en la interfaz equivocada parece un éxito y no lo es.
• El tráfico propio de la Pi, el DNS e IPv6 necesitan cada uno una decisión, no una inferencia.