El túnel completo en strongSwan necesita 0.0.0.0/0 en ambos extremos

Una conexión strongSwan que funciona para una sola subred privada no transportará tráfico de internet solo porque alguien haya editado una línea. Un túnel completo es un acuerdo entre dos extremos sobre qué direcciones protege la child SA, y cada extremo nombra al otro respecto de sí mismo. Acierte un lado y falle el otro, y la child SA o no levanta o levanta más estrecha de lo previsto. Las cinco comprobaciones siguientes siguen ese acuerdo desde el cliente, a través de la puerta de enlace, hasta internet.

Compruebe primero el selector del cliente

El cliente describe lo que quiere proteger en el lado remoto como remote_ts, y todo lo que envía parte de su propia dirección asignada. Para el tráfico de internet ese valor debe cubrir los destinos que el usuario alcanzará realmente, lo que en la práctica significa todo el espacio IPv4. Un cliente que todavía enumera una subred pide un túnel dividido, se llame como se llame el perfil en la interfaz. El lado de origen suele ser dynamic porque la dirección se asigna al conectar. Una fuente fija escrita ahí se rompe en cuanto cambia el grupo de direcciones.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

El fragmento no es un archivo de conexión completo, y este supone que la autenticación, las identidades y el grupo de direcciones virtuales ya están configurados. El selector de origen del cliente y la dirección que asigna el servidor aún deben coincidir, o la child SA levanta con un alcance que ninguno de los dos lados esperaba. Cárguelo con swanctl --load-all y lea la salida antes de suponer éxito. Un archivo que se analiza puede seguir siendo rechazado por un selector que no se solapa con la propuesta del otro extremo.

Compruebe el selector de la puerta de enlace en su propio lado

La puerta de enlace lee el mismo concepto desde la dirección opuesta. Los destinos de internet son locales para la puerta de enlace, así que su local_ts es el amplio y su remote_ts describe el grupo de clientes. Esa inversión es el error más común en una configuración de túnel completo, y sobrevive a la revisión porque ambas líneas parecen plausibles por separado.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Copiar el fragmento del cliente al archivo de la puerta de enlace produce un par de selectores que no describe nada útil, porque ambos lados reclamarían el mismo papel. La guía de reenvío de strongSwan documenta explícitamente el emparejamiento de cliente y puerta de enlace, y vale la pena leerla junto al archivo de conexión en lugar de después del fallo. El archivo de la puerta de enlace también necesita la definición del grupo al que hace referencia remote_ts. Un selector que nombra un grupo inexistente se carga sin queja y falla al conectar.

El antiguo ipsec.conf usa roles izquierdo y derecho con claves distintas, y una línea rightsubnet no es un reemplazo directo del valor de swanctl. Mantenga las dos sintaxis en archivos separados en lugar de pegar una dentro de la otra. Mezclarlas en un mismo directorio es cómo una conexión que funciona vuelve en silencio tras un reinicio.

Compruebe la child SA negociada, no el archivo

Una configuración guardada demuestra la intención y nada más. El otro extremo puede estrechar lo solicitado, y una child SA existente no se reemplaza solo porque el archivo bajo ella haya cambiado. Confirme qué hay realmente instalado antes de cambiar cualquier otra cosa.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

El primer comando muestra lo que cargó el demonio, el segundo muestra las child SA establecidas y el tercero las políticas que aplicará el núcleo. Si el archivo dice 0.0.0.0/0 y el listado muestra una sola subred, la negociación estrechó el alcance y releer el archivo no lo explicará. Termine la child, vuelva a iniciarla y compare las tres salidas de nuevo. Una child que vuelve con el mismo alcance estrecho está siendo estrechada por el otro extremo y no por el archivo local, y eso es una conversación con el otro administrador en lugar de una edición local.

Lea ambas direcciones en el listado de políticas, porque un túnel que instala una dirección y no la otra es un problema de enrutamiento disfrazado de configuración. Las políticas de ida y vuelta deben nombrar el mismo par de selectores en imagen espejo, y un espejo ausente es un defecto del demonio o de la propuesta, no del texto del selector.

Compruebe el reenvío y la ruta de retorno

Un selector admite tráfico hacia la puerta de enlace; no hace que la puerta de enlace enrute ese tráfico más allá. El reenvío debe estar habilitado, el cortafuegos debe permitir el flujo y la respuesta debe encontrar el camino de vuelta al grupo de clientes. Son tres requisitos separados, y cada uno falla con un síntoma distinto. Una regla de reenvío ausente se comporta como un agujero negro, mientras que una ruta de retorno ausente se comporta como un túnel de un solo sentido.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Las direcciones privadas de los clientes suelen necesitar una traducción de origen deliberada antes de salir por una interfaz pública, mientras que una asignación enrutada explícitamente requiere otro trato. Si hay NAT, mantenga las excepciones que admite la implementación para que el tráfico que una política de seguridad debe inspeccionar no se traduzca por encima de ella. Una regla masquerade amplia copiada de otra puerta de enlace cambia muchos más flujos de los que su autor pretendía. Escriba la regla solo para el grupo de clientes y deje un comentario explicando por qué existe.

En el cliente, confirme las rutas que instaló el backend en lugar de las rutas que supuso. Un gestor con la instalación de rutas desactivada necesita un diseño de enrutamiento mantenido a mano, y ese diseño debe actualizarse siempre que cambie el túnel. Compruebe la tabla de enrutamiento tras reconectar, no solo tras un arranque limpio.

Compruebe qué sigue sin cubrir el túnel

El par de selectores cubre IPv4 y nada más. IPv6, DNS y cualquier política a nivel de aplicación son decisiones separadas que un selector IPv4 amplio ignora en silencio. Un túnel que transporta cada paquete IPv4 aún puede filtrar cada consulta de nombre.

Declare explícitamente la ruta DNS prevista, porque un túnel completo que aún resuelve nombres por el resolutor local filtra consultas fuera del túnel y rompe nombres privados. Si al cliente se le asigna una dirección IPv6, esa familia de direcciones necesita el mismo trato, o el host preferirá una ruta que el túnel no protege. Pruebe con un nombre que solo el lado privado pueda responder, y trate una respuesta pública como una fuga.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Confirme la cadena con esos dos comandos más los selectores negociados del listado anterior. Si el traceroute muestra el router local como primer salto, el tráfico no usa el túnel, digan lo que digan los selectores. El acceso a internet está completo solo cuando el tráfico elegido se admite, se reenvía y vuelve por la puerta de enlace diseñada. Encontrar 0.0.0.0/0 en un perfil es el comienzo de esa cadena, no su prueba.