Perfil de WireGuard para una puerta de enlace IPsec: qué pedir en su lugar

Los tiempos de espera del handshake con una puerta de enlace silenciosa suelen significar dos protocolos que nunca se encuentran. Un par de WireGuard habla Noise mientras una puerta de enlace IPsec espera IKE. La dirección y el puerto correctos no cambian eso.

Reutilizar el extremo en un perfil no une a los dos. El siguiente paso es una solicitud a quien opera la puerta de enlace.

Primera solicitud: la versión del protocolo

IPsec designa una familia y no un único flujo de trabajo. IKEv2 e IKEv1 difieren en sus intercambios, sus opciones de autenticación y su comportamiento ante un cambio de red. Una puerta de enlace que solo termina IKEv1 se comportará de forma muy distinta a una que ofrece IKEv2. La configuración del cliente cambia con ello.

Pregunte qué versión termina el servicio y si ejecuta una implementación basada en estándares o una variante de proveedor con su propio cliente. Los menús del sistema operativo suelen esconder esa respuesta tras una sola etiqueta. La etiqueta no es el protocolo.

Segunda solicitud: el método de autenticación del cliente

La autenticación es donde está la mayor parte del trabajo real. El servicio puede esperar un certificado de máquina con un uso extendido de clave concreto, un certificado de usuario, un método EAP sobre IKEv2 o una clave precompartida vinculada a una identidad. Cuál se aplica decide qué necesita el cliente.

Una clave privada de WireGuard no es nada de eso. Es una clave Curve25519 usada en un handshake concreto. Ninguna conversión la convierte en un certificado ni en una credencial EAP. Una herramienta que afirme lo contrario está renombrando el archivo o generando algo que no tiene relación.

La especificación de IKEv2 en el RFC 7296 describe qué debe admitir una implementación de esa versión. Es una referencia para una respuesta vaga del operador, no una guía de configuración del cliente.

Tercera solicitud: la identidad de confianza y los destinos

Pida la identidad de la puerta de enlace tal como el cliente debe verla, más el ancla de confianza que la valida. Después pregunte qué rangos privados y resolutores empuja el servicio. Esas dos respuestas deciden qué transporta realmente el túnel.

Sin ellas, una conexión que funciona puede fallar la tarea. Un túnel levantado sin un resolutor empujado deja los nombres internos sin respuesta. Un selector de tráfico ausente deja el destino fuera del túnel aunque el handshake haya tenido éxito.

Una sonda del extremo responde a una pregunta distinta de la del error del cliente. Un puerto accesible sin asociación apunta a la autenticación, mientras que un puerto inaccesible apunta al camino.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Ejecute esa sonda antes de cambiar nada en el cliente. Si los puertos responden y la asociación sigue fallando, el problema son las credenciales o la política. Si no responden en absoluto, ninguna edición del perfil ayudará.

Cuando ambos protocolos tienen que convivir

Administrar ambas redes es un motivo legítimo para conservar los dos protocolos. El diseño habitual termina WireGuard e IPsec en interfaces separadas o puertas de enlace separadas. El tráfico aprobado se enruta entonces entre ellas.

Ese diseño introduce una frontera de confianza y autorización, y debería dejarse escrita como tal. Qué pares pueden cruzar, en qué dirección y bajo la política de quién es una decisión de enrutamiento y cortafuegos. Ninguno de los dos protocolos la proporciona.

Lo que no es es una conversión transparente. El tráfico que llega por WireGuard se reorigina en el túnel IPsec, y toda política intermedia se le aplica.

Aclare primero los requisitos de protocolo y autenticación del servidor. Después use el cliente y la ruta de inscripción que admite el operador, y mantenga las claves privadas fuera de los conversores web mientras eso ocurre.