VPN Pi con varios routers: pon cada ruta en el dispositivo que decide
Un router descendente añade una segunda subred de clientes, y cada uno de los cuatro dispositivos posee una decisión. Coloca las rutas, comprueba el origen y luego prueba desde un cliente real.
Poner una caja Wi-Fi detrás de la Pi convierte una decisión de enrutamiento en cuatro, y el plan se rompe cuando las cuatro se toman en un solo dispositivo. La primera pregunta no es qué ruta añadir. Es si la caja nueva hace puente o enruta, porque esa respuesta decide cuántas subredes existen y qué dispositivos deben aprender sobre ellas. Elige primero el modelo de conexión; cada ruta se deriva de él.
Puente o enrutamiento: la elección que fija el recuento
Un puente pone a los clientes nuevos en la misma subred que la Pi ya sirve. Una subred, una autoridad DHCP y ningún traspaso que enrutar. Esta es la disposición más simple y la correcta cuando una red de clientes separada nunca fue un requisito. Un enlace enrutado es un diseño distinto: la caja conserva su propia subred, y ese prefijo debe llevarse a todas partes adonde va el tráfico.
El resto de este plan conserva el router descendente y preserva las direcciones de origen de los clientes. El objetivo es una red VPN privada, no una salida completa a internet. Escribe el modelo antes de las direcciones, porque la lista de abajo es solo un ejemplo de conexión enrutada.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24Quién decide qué
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Cada dispositivo toma una decisión, y ninguno puede tomar la de otro por él. La Pi necesita dos entradas, no una, y el camino de vuelta es el que la gente olvida. El tráfico reenviado llega correctamente a la red privada y luego muere a la vuelta, porque la Pi no tiene idea de dónde vive 10.41.0.0/24. Eso parece un problema de cortafuegos y en realidad es una ruta que falta.
El lado remoto también necesita su propia ruta. Si el servicio del extremo lejano no sabe que se puede llegar a 10.41.0.0/24 por tu túnel, las respuestas se detienen en el primer salto que no tiene respuesta. Añade ambas direcciones antes de leer filtros de paquetes.
Los siguientes saltos vienen de la conexión
El siguiente salto debe ser una dirección en una red a la que el dispositivo pueda llegar de verdad. La dirección pública del par VPN no es el siguiente salto para una subred privada, y la red de servicio remota no es un siguiente salto en absoluto. Una ruta hacia una puerta de enlace inalcanzable parece correcta en un listado y descarta cada paquete. Comprueba que la puerta de enlace responde antes de culpar al destino.
Mantén el par VPN exterior de la Pi accesible a través de su propia ruta de capa inferior. Esa entrada está separada de las rutas de carga útil, y mezclarlas da un túnel que no puede restablecerse tras un cambio de camino.
La documentación de rutas estáticas aclara la distinción entre destino y puerta de enlace, aunque cada plataforma nombra sus menús de forma distinta. Lee la documentación del dispositivo que tienes delante en lugar de copiar la pantalla de otro fabricante. Los comandos de abajo muestran la forma de las entradas en Linux.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1Qué hace la traducción al origen
Si el router descendente ya traduce a sus clientes a la dirección de tránsito, la Pi ve un solo origen traducido en lugar de la dirección propia de cada cliente. Ese es un diseño distinto del que preserva el origen de arriba. Cambia la política basada en origen, el registro y qué lado puede iniciar conexiones. Ambos diseños funcionan; responden a preguntas distintas.
Cuando un servicio VPN aguas arriba se niega a enrutar de vuelta el prefijo de cliente, una traducción estrecha en la salida del túnel de la Pi puede ser una solución legítima. No es prueba de que la ruta que falta fuera innecesaria. Anota qué dirección ve realmente la red remota y qué camino de vuelta resulta.
La selección de ruta, el permiso de reenvío y la traducción de origen siguen siendo tres trabajos separados. Vaciar una cadena NAT compartida o permitir cada interfaz porque un cliente por cable funciona es como una prueba que funciona se convierte en un reenviador abierto.
Demostrarlo desde una máquina cliente
Envía una petición desde una máquina en la LAN descendente y luego sigue su origen hacia fuera y de vuelta. Un ping lanzado por la Pi nunca ejercita la ruta de vuelta descendente, por eso un ping correcto demuestra menos de lo que parece. Añade una segunda prueba desde un cliente por cable en la propia LAN de la Pi para que se puedan comparar los dos caminos. Repite ambas tras reiniciar cualquiera de los dispositivos.
Las rutas añadidas a mano y las traducciones que nunca se guardaron desaparecen juntas. Entonces la pareja parece una avería nueva en lugar de un trabajo inacabado.
Guarda el modelo de conexión junto con las rutas, el servicio privado permitido y cualquier traducción en una sola nota. Esa nota es lo que impide que la siguiente persona trate la ubicación inalámbrica como una cuestión de política de enrutamiento.