Cómo enviar solo una subred privada por la VPN

Una subred privada por el túnel y todo lo demás por su camino habitual es una petición pequeña con muchísimas formas de salir mal. Lo que decide el resultado no es la casilla llamada split tunneling, sino dónde se aplica la decisión: la propia tabla de rutas del cliente, una ruta que empuja el servidor o una política que negocian los dos extremos. Elija la capa equivocada y obtendrá o un túnel completo que nunca quiso, o una ruta hacia un túnel que el otro extremo se niega a aceptar. Yo uso una prueba de tres condiciones antes de abrir cualquier configuración y luego elijo uno de los mecanismos de abajo.

Tres condiciones que fijan el diseño

Primero, necesita el prefijo y la máscara exactos del propietario de la red. La red 10.x no es un prefijo; 10.20.0.0/16 sí lo es. Confirme que no se solapa con su LAN doméstica, con un puente de Docker ni con otra VPN que ejecute, porque un solapamiento vuelve ambigua la ruta y el núcleo elige la entrada que usted no pretendía.

Segundo, quién responde al tráfico de vuelta. Encaminar un paquete hacia el túnel solo lo lleva al servidor VPN. Si la subred está detrás de otro router que no tiene ruta de vuelta hacia su grupo de clientes, el servidor debe enmascarar el tráfico, o ese router debe aprender su grupo. Ninguna ruta del lado del cliente arregla un camino de vuelta que falta.

Tercero, el punto de aplicación. Algunos clientes instalan una ruta y el sistema operativo hace el resto. Otros negocian una política, y una política que la puerta de enlace no acepta no produce ningún túnel: los paquetes se descartan sin un error evidente. Averigüe cuál de los dos es el suyo antes de escribir nada.

WireGuard: AllowedIPs es la tabla de rutas

En el cliente, AllowedIPs enumera los destinos que pueden entrar en el túnel, y wg-quick convierte cada entrada en una ruta ordinaria. Así que la mitad cliente de esta tarea es una sola línea.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Ahora compare la entrada del servidor para ese mismo cliente. Describe lo que el servidor enviará al cliente, que normalmente es la dirección de túnel del cliente, no la subred privada.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Intercambiar esas dos es el error que veo más a menudo. Poner 10.20.0.0/16 bajo la sección peer del servidor afirma que toda la subred vive detrás de ese cliente, lo cual es una pretensión de sitio a sitio y no un permiso. Los paquetes que no coinciden con el AllowedIPs de ningún peer se descartan en silencio, así que una entrada equivocada parece exactamente un problema de cortafuegos.

Si gestiona las rutas usted mismo, ponga Table = off bajo [Interface] y añada la ruta que quiera. Entonces no se añade nada automáticamente, así que la ruta pertenece a lo que levanta la interfaz.

OpenVPN: empuje la ruta y luego asegúrese de que llega

En un servidor normal el cambio es una directiva en la configuración del servidor, junto al grupo de clientes.

push "route 10.20.0.0 255.255.0.0"

El cliente la añade cuando se conecta. El modo de fallo aparece cuando el mismo perfil también empuja redirect-gateway, o cuando alguien ya ha añadido route-nopull: lo primero convierte la sesión en un túnel completo, y lo segundo descarta todas las rutas empujadas, incluida la suya.

Un cliente que necesita un comportamiento estrecho contra un servidor de túnel completo debería ignorar solo las partes que no quiere. En OpenVPN 2.4 y posteriores, pull-filter existe precisamente para eso.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Mantenga las familias de direcciones separadas: una ruta IPv4 empujada no hace nada por un servicio interno que se resuelve a IPv6, y ese servicio falla por el túnel mientras todo lo demás parece correcto.

Cuando la subred privada no está en el servidor VPN sino detrás de otro cliente, hay que avisar al servidor. Añada un archivo por cliente mediante client-config-dir que contenga iroute 10.20.0.0 255.255.0.0, más la route correspondiente para que los demás clientes aprendan el camino. Sin iroute el servidor no tiene motivo para enviar ese prefijo por ese túnel concreto.

IPsec: los selectores de tráfico tienen que ponerse de acuerdo

Con IPsec no hay ruta que empujar. Los dos extremos negocian qué direcciones viven dentro del túnel, y el tráfico fuera de los selectores acordados ni se cifra ni se envía por él. En un cliente strongSwan los selectores son explícitos.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Si la puerta de enlace está configurada con 0.0.0.0/0 en ambos lados, el estrechamiento de IKEv2 suele reducir la SA hija a la intersección de las dos propuestas, que es el resultado que usted quiere. Algunas puertas de enlace, en cambio, rechazan una propuesta que no coincide con sus selectores configurados, y el registro muestra entonces una SA hija fallida en lugar de una queja de enrutamiento. Cuando eso ocurre, el cambio corresponde a la puerta de enlace, porque una ruta en el cliente no puede crear un túnel para un selector que el otro lado no aceptará.

En Windows el cliente integrado esconde la misma decisión detrás de dos ajustes. La división del túnel debe estar activada, y el prefijo debe registrarse en el perfil.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Registrar el prefijo es lo que lo hace sobrevivir a una reconexión, cosa que una ruta añadida a mano no hace.

Mantenga el extremo y el DNS fuera de la decisión

El extremo de la VPN debe seguir siendo alcanzable sin el túnel, o el túnel se derrumba sobre sí mismo. Cuando solo se encamina 10.20.0.0/16 eso es automático, ya que el extremo es una dirección pública. En un perfil de túnel completo no lo es, y el cliente necesita una ruta de host explícita hacia el extremo antes de que suba el túnel.

El DNS es una segunda decisión que el empuje de rutas no toma por usted. Los nombres internos suelen resolverse mediante un resolutor al que solo puede llegar la red privada. Si el servidor empuja un servidor DNS, cada nombre pasa por él; si no lo hace, los nombres internos o fallan o se resuelven públicamente a algo que usted no pretendía. El DNS dividido mantiene un dominio de búsqueda en el resolutor interno, pero depende del soporte del cliente, así que trátelo como una tarea propia y no como un efecto secundario del enrutamiento.

Verifique, reinicie y verifique otra vez

Tres pruebas cubren la cuestión del enrutamiento. Pregunte al núcleo adónde iría una dirección remota, descargue algo desde dentro de la subred y luego confirme que una petición pública ordinaria sigue saliendo por su conexión normal.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

La primera línea nombra una interfaz. Si nombra su interfaz física, la ruta nunca llegó. En Windows, Find-NetRoute -RemoteIPAddress 10.20.5.7 responde a la misma pregunta, y la última prueba debería seguir mostrando su dirección habitual y no la del servidor VPN.

Luego reinicie. Las rutas añadidas a mano desaparecen, mientras que las rutas del perfil, de una configuración empujada o de AllowedIPs vuelven. Si el acceso estrecho funciona antes del reinicio y falla después, el fallo está en cómo arranca el túnel, no en la ruta misma.

Antes de darlo por terminado, confirme cuatro cosas: el prefijo vino del propietario de la red y no se solapa con nada local, el camino de vuelta existe o una regla de enmascaramiento lo sustituye, el mecanismo que configuró es el que aplica el enrutamiento en su plataforma, y las mismas pruebas pasan tras un reinicio limpio. Las notas de reenvío de strongSwan merecen una lectura si el camino de vuelta es la parte que no deja de fallar.