El tráfico de retorno de Azure P2S VPN solo funciona en un sentido

El icono del túnel está en verde, el NSG parece permisivo, las rutas efectivas parecen correctas y, aun así, la VM no puede abrir una conexión de vuelta hacia el cliente conectado. La suposición habitual es que un túnel point-to-site que funciona es simétrico: si el cliente llega a la VM, la VM llega al cliente. Esa suposición es el error del razonamiento, no de la configuración. Un túnel puede transportar una dirección de un flujo no solicitado y descartar la otra, y la solución depende de qué capa la descarta.

Mito: un túnel conectado es un túnel bidireccional

Un túnel VPN es una ruta de política, no un cable. Cada dirección se compara con selectores, rutas y filtros, y cualquiera de ellos puede permitir una dirección mientras bloquea la otra.

En la práctica, la asimetría es lo bastante común como para que la dirección pertenezca a la primera prueba, no a la última. El cliente inicia, la puerta de enlace sigue el flujo y la respuesta sigue el estado que se creó. Una VM que inicia un flujo nuevo no tiene ese estado, así que depende de que la ruta de retorno sea explícitamente enrutable y esté permitida. Cuando esa ruta falta, el intento de conexión muere antes de que lo vea cualquier aplicación.

Pruebe la dirección antes de probar la accesibilidad

Elija una dirección de cliente, una dirección de VM y un protocolo. Conéctese desde el cliente y anote el resultado; después inicie la misma prueba desde la VM y anótelo también. Si la primera funciona y la segunda falla, el grupo de clientes, la asociación de la puerta de enlace y la ruta del cliente a la VNet funcionan todos.

El siguiente paso son pruebas, no más reglas. Revise el NSG de la subred de la VM en ambos sentidos, lea las rutas efectivas en la NIC de la VM y capture paquetes en la VM mientras el cliente envía tráfico. Una petición que llega sin respuesta es un problema de filtro o de ruta de retorno; una petición que nunca llega es un problema de ruta. No tome un ping fallido como prueba de que la VM es inaccesible, porque la política de ICMP puede descartar la respuesta mientras TCP funciona.

La ruta de retorno IKEv2 point-to-site es el sospechoso habitual

En el informe de Azure que hay detrás de este artículo, un cliente podía llegar a las VM por IKEv2, pero el ICMP entrante de la VM al cliente fallaba hasta que el tipo de túnel de la puerta de enlace se cambió a OpenVPN. El autor del informe afirma que Microsoft confirmó una limitación en la ruta IKEv2 point-to-site, donde el tráfico de retorno de una VM al cliente no se enruta de forma simétrica a menos que el cliente haya iniciado la sesión. IKEv2 se basa en selectores de tráfico, y la puerta de enlace no respetó la dirección de retorno en ese caso.

Eso no convierte a OpenVPN en el mejor tipo de túnel en general. Convierte el tipo de túnel en una variable de la matriz de pruebas para esta carga de trabajo.

Cambiar el tipo de túnel es un cambio de servicio, no un interruptor. Cada cliente necesita un perfil compatible, y la puerta de enlace puede necesitar un certificado o una configuración de autenticación distintos. Reproduzca el comportamiento unidireccional con un cliente de prueba y una VM de prueba, cambie el tipo según un calendario aprobado y repita después las mismas pruebas de dirección. Si el comportamiento sobrevive al cambio, el tipo de túnel no era la causa y ha acotado el problema sin tocar producción.

Mito: el descubrimiento por broadcast cruza el borde de la VNet

Una segunda suposición falla por un motivo no relacionado. Una red virtual de Azure no transporta tráfico de broadcast, así que una VM no puede recibir tramas de broadcast de una red local a través de una conexión site-to-site o point-to-site. Las aplicaciones que encuentran pares por broadcast, como la exploración de archivos antigua o algunos protocolos de descubrimiento de dispositivos, nunca verán el lado remoto, por bien escritas que estén las rutas.

Sustituya el descubrimiento por broadcast por nombres DNS, un servicio de directorio o una lista explícita de pares. Si la aplicación no tiene alternativa unicast, el diseño necesita otro mecanismo de descubrimiento, no un túnel más ancho.

Qué cambiar y cómo demostrarlo

Si la prueba de dirección falla solo con IKEv2, anote el tipo de túnel de la puerta de enlace, el grupo de direcciones de clientes y la prueba exacta de ICMP o TCP, y después evalúe un perfil OpenVPN aprobado para los clientes afectados. Si falla con todos los tipos de túnel, trabaje la ruta de retorno: la dirección del cliente debe ser enrutable desde la subred de la VM, cualquier ruta definida por el usuario debe apuntar a un siguiente salto válido y el cortafuegos del cliente debe aceptar el flujo entrante. Adjunte las pruebas del NSG y de las rutas al ticket.

Verifique con la aplicación, no con ping. Un intercambio ICMP correcto después de un cambio no dice nada sobre el puerto del servicio, su autenticación o su resolución de nombres. Repita la prueba tras una reconexión, porque un cliente que recibe una dirección distinta del grupo puede cambiar el resultado. Luego repítala una vez más después de que el cliente se duerma y se despierte, ya que es en una sesión reanudada donde el comportamiento unidireccional suele reaparecer.