VPN S2S de Azure conectada pero sin tráfico: lea el registro IKE

El portal dice Connected, el túnel tiene un contador de tiempo de actividad y un trace desde su máquina virtual muere en el segundo salto. El estado de la conexión describe la negociación de IKE e IPsec, no si un solo paquete sobrevive a la capa de directivas en cualquiera de los dos lados. Dos fallos explican la mayoría de estos tickets, y ninguno se repara cambiando una ruta de Azure. Ambos ya están escritos en el registro que generó la puerta de enlace, y por eso empiezo ahí y no en la tabla de rutas.

Qué certifica realmente Connected

Una conexión de sitio a sitio conectada significa que la fase 1 y la fase 2 se completaron y que las asociaciones de seguridad están activas. Es una afirmación sobre la negociación: ambas partes acordaron una propuesta, intercambiaron claves e instalaron el par de SA. No dice nada sobre si los selectores de tráfico coinciden con las subredes que usted cree protegidas, ni sobre si el lado remoto enrutará el paquete a algún sitio después de descifrarlo. Un túnel puede mantenerse activo durante semanas mientras descarta cada flujo interesante, y ese es exactamente el patrón que hace que la gente reconstruya una puerta de enlace sana.

Los dos fallos que conviene revisar primero son un par que propone AH en lugar de ESP, y una red virtual numerada en un espacio que la puerta de enlace no tratará como interno.

Abra el registro exportado antes de tocar rutas

En el portal, abra la puerta de enlace de red virtual y ejecute la operación VPN troubleshoot sobre la conexión, luego descargue el paquete que genera y descomprímalo. Dentro hay un registro IKE con los intercambios de fase 1 y fase 2, con marcas de tiempo y legible como texto plano. Búsquelo por la línea transform en lugar de leerlo de arriba abajo, porque la entrada interesante suele estar unos cientos de líneas más abajo. Si no tiene acceso al portal, los mismos diagnósticos aparecen en el destino de registros de la puerta de enlace cuando los ajustes de diagnóstico están habilitados.

Dos entradas aportan la mayor parte del valor. La primera dice aproximadamente expected ESP with combined authentication and cipher, received AH. La segunda es un error de payload no válido durante el intercambio IKE, que normalmente significa un campo de propuesta mal formado o no admitido.

Ambas describen lo que ofreció el dispositivo local, así que ambas son ajustes del lado del par. Regenerar el lado de Azure de la conexión no cambia la propuesta que envía su cortafuegos, y hacerlo de todos modos es la hora más desperdiciada en este flujo de trabajo. En el par, ponga la fase 2 en ESP con autenticación y cifrado combinados y déjela negociar el algoritmo, luego compruebe si una casilla del fabricante con un nombre como combined mode está seleccionando en silencio una propuesta AH por debajo.

Confirme el espacio de direcciones de la red virtual

La puerta de enlace espera que la red virtual esté en rangos privados. Una red numerada en un bloque público, por ejemplo una que empieza por 111.x, puede levantar el túnel mientras Azure se niega a tratar ese espacio como interno, así que la conexión parece sana y no se acepta ningún flujo. Confirme el espacio de direcciones antes de pasar una tarde con los selectores. Si la numeración es un requisito estricto de una asignación antigua, la solución es un cambio del plan de direcciones y no otra puerta de enlace.

Anote el solapamiento con los rangos locales mientras esté en la hoja de espacio de direcciones, porque los prefijos solapados producen un fallo distinto que desde el cliente parece similar.

Verifique los prefijos en ambas direcciones

El recurso de puerta de enlace de red local contiene los prefijos locales, y deben coincidir con las subredes que el dispositivo remoto protege realmente. Un resumen que incluya direcciones que el dispositivo descarta dejará pasar algunos flujos y fallará en otros, lo que se lee como un fallo de enrutamiento intermitente y no como un desajuste de configuración. Revise también el lado remoto: un extremo que lista una /16 mientras el otro lista tres /24 dentro de ella es el fallo parcial clásico. Ninguna lista es autoritativa por sí sola, así que compárelas una al lado de la otra en lugar de confiar en la que puede ver.

Un cambio de prefijo no siempre se recoge solo, así que planifique volver a guardar o recrear el objeto de conexión y luego confirme que los nuevos prefijos aparecen en ambos lados.

Pruebe una ruta, no un ping

El trace que separa un túnel que funciona de una ruta que funciona es así: el primer salto es la puerta de enlace local, luego unos cuantos saltos que no responden y luego responde el host remoto. Si el trace nunca llega al host, pruebe el puerto TCP que la aplicación usa realmente, porque ICMP se filtra con suficiente frecuencia como para que un ping fallido demuestre muy poco. Ejecute el mismo trace desde un host remoto hacia una máquina virtual en Azure. La asimetría entre los dos resultados es la forma más rápida de encontrar una ruta de retorno que falta o una regla que solo permite una dirección.

Escriba la propuesta del par, ambos espacios de direcciones y la hora de creación de la conexión en el ticket, para que el siguiente ingeniero sepa qué valores se reconstruyeron y cuáles nunca se tocaron.

Si el registro vuelve vacío, puede que la puerta de enlace no esté terminando su conexión en absoluto. Confirme que la dirección del par en la puerta de enlace de red local coincide con el dispositivo desde el que lee el registro, porque dos puertas de enlace en una suscripción se confunden con facilidad durante una reconstrucción. Ese error cuesta un día y no deja rastro en ningún registro.