Añadir una segunda subred a una VPN de sitio a sitio: dos caminos
Los túneles basados en políticas necesitan selectores coincidentes en ambos extremos; los basados en rutas, una ruta. Elija el camino correcto y arregle primero la ruta de retorno.
Añadir una segunda subred a un túnel de sitio a sitio que funciona lleva cinco minutos en un diseño y casi toda la tarde en el otro. Cuando el túnel instala rutas para los prefijos que usted nombra, añade una ruta y el tráfico la sigue. Cuando negocia un par fijo de selectores, el prefijo nuevo queda sin protección hasta que ambos extremos acuerdan un par coincidente. Tres cosas deciden el caso: qué describe realmente la configuración de cada extremo, si el tráfico negociado se estrecha al par coincidente más pequeño y quién es dueño de la ruta de retorno del nuevo rango.
Lea el núcleo, no la etiqueta de estado
Un túnel que informa de conexión ha instalado al menos una asociación hija, pero no necesariamente la que usted cree. En Linux el núcleo muestra lo que se aplica: ip xfrm policy lista los pares de selectores y swanctl --list-sas (o el antiguo ipsec statusall) muestra lo que negociaron los extremos, incluidos los selectores de tráfico en cada dirección. Si el prefijo nuevo no aparece en ninguno, está sin protección diga lo que diga el archivo de configuración.
Compárelo con la tabla de rutas. En un diseño basado en rutas el dispositivo del túnel es el siguiente salto de los prefijos protegidos. Un diseño basado en políticas a menudo no tiene ruta específica para la subred remota, solo la ruta por defecto, porque la política elige el tráfico y no la tabla.
Túneles basados en políticas: ambos extremos deben listar el prefijo nuevo
En términos de strongSwan el selector vive en local_ts y remote_ts dentro de la configuración hija, sucesores de leftsubnet y rightsubnet. El prefijo nuevo debe aparecer en ambos extremos en espejo: lo que el sitio A llama local, el sitio B lo llama remoto. Una discrepancia rara vez da un error limpio. Los extremos se estrechan a la intersección, el prefijo antiguo sigue funcionando y solo el nuevo falla en silencio.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyEn pfSense u OPNsense eso significa una segunda entrada Phase 2 que empareja la nueva subred local con la nueva remota y luego aplicar. Conserve la entrada antigua; sustituirla mueve la subred original en lugar de añadirla. Si una Phase 2 existente ya cubre una superred como 0.0.0.0/0 o un rango resumido, no añada una entrada más estrecha al lado: los selectores solapados instalan políticas competidoras y el orden de evaluación decide cuál gana.
IKEv1 hace que cada par de subredes sea su propia Phase 2, y un extremo que acepta un par por intercambio descarta el resto. IKEv2 puede llevar varios pares de selectores en una hija, pero solo si ambas implementaciones los aceptan. La lista de swanctl --list-sas es la verdad; lo que usted escribió es una petición.
Túneles basados en rutas: la ruta es la política
Una interfaz XFRM o un dispositivo VTI lleva el tráfico según la tabla de rutas. Apunte el prefijo nuevo al dispositivo en ambos sitios y se aplica el estado ligado a la transformación de la interfaz. No hay par de selectores que sincronizar, por eso este diseño escala mejor cuando se multiplican las subredes. La guía de reenvío de strongSwan detalla el lado del núcleo.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard lleva la idea más lejos. AllowedIPs es a la vez la lista blanca criptográfica y, mediante wg-quick, la entrada de la tabla de rutas. Añada el prefijo solo en un extremo y obtendrá un handshake, paquetes salientes y silencio, porque el otro lado descarta los paquetes cuya origen no está en su lista. La forma wg set sustituye toda la lista, así que repita los prefijos que ya funcionaban o los cortará:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0Ese segundo comando no es opcional cuando usó wg set en lugar de wg-quick. El núcleo acepta la lista nueva de inmediato, pero nada añade una ruta para ella, así que el tráfico generado localmente sigue saliendo por la puerta de enlace por defecto. Es la razón más común de que una subred WireGuard nueva funcione desde el host del túnel y no desde un portátil.
La ruta de retorno falla más a menudo que el túnel
Los hosts de la nueva subred remota deben enviar las respuestas por la puerta de enlace VPN. Cuando esa puerta no es su router por defecto, la respuesta va al router de la LAN, que la descarta o la reenvía a internet con una dirección de origen privada. Pruebe desde un host del lado remoto y no desde la puerta: ip route get 10.30.20.15 en Linux o Find-NetRoute -RemoteIPAddress 10.30.20.15 en PowerShell muestra el siguiente salto que el host usará de verdad. Si la respuesta no es el extremo del túnel, añada allí una ruta estática para el prefijo nuevo.
El NAT de origen en el sitio que carece de la ruta de retorno es una alternativa legítima y la forma en que muchos despliegues hub-and-spoke evitan tocar cada servidor. Aplíquelo también al prefijo nuevo en la puerta del lado de destino:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEEl coste es real. Los registros remotos dejan de mostrar direcciones de origen individuales y las reglas de cortafuegos ligadas a la subred original se funden en una sola regla para la puerta. Elíjalo a propósito, no porque faltara una ruta.
Los cortafuegos son la otra mitad de la ruta de retorno. Los dispositivos por zonas no extienden automáticamente la zona de una interfaz de túnel existente a una subred nueva, y una regla escrita para el prefijo antiguo no coincidirá. Añada la subred nueva a la zona o al par de reglas en ambos sentidos antes de culpar a IPsec.
Decida con tres preguntas y verifique con tráfico
La versión rápida: ¿la configuración del extremo nombra prefijos (basada en políticas) o el tráfico se enruta hacia una interfaz (basada en rutas)? ¿Listan ambos extremos el prefijo nuevo? ¿Hay un camino de vuelta desde la subred nueva al rango de origen original?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
La verificación es donde la mayoría de los cambios se cierran demasiado pronto. Un ping desde la puerta prueba poco, porque la puerta envía desde sí misma y a menudo coincide con una política distinta a la de un host. Haga ping desde un host de la subred nueva, luego ejecute la aplicación que motivó el cambio y mire contadores, no un icono de estado.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showEn un túnel basado en políticas los contadores de ip xfrm state deben subir en ambos sentidos; contadores planos significan que el paquete se enruta pero no se selecciona. En WireGuard, wg show informa de la transferencia por extremo, y un handshake con cero bytes recibidos apunta a la lista blanca del lado remoto o a su ruta de retorno.
Termine registrando el prefijo, el selector o la ruta del extremo, la decisión sobre la ruta de retorno y la entrada del cortafuegos junto con el resto del inventario del túnel. Luego reinicie una puerta de enlace y pruebe otra vez: una ruta añadida a mano desaparece y la siguiente persona no debería tener que redescubrirlo.