O tráfico de retorno de Azure P2S VPN só funciona nun sentido

A icona do túnel está verde, o NSG parece permisivo, as rutas efectivas parecen correctas e, aínda así, a VM non pode abrir unha conexión de volta cara ao cliente conectado. A suposición habitual é que un túnel point-to-site que funciona é simétrico: se o cliente chega á VM, a VM chega ao cliente. Esa suposición é o erro do razoamento, non da configuración. Un túnel pode transportar unha dirección dun fluxo non solicitado e descartar a outra, e a solución depende de que capa a descarta.

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

Un túnel VPN é unha ruta de política, non un cable. Cada dirección compárase con selectores, rutas e filtros, e calquera deles pode permitir unha dirección mentres bloquea a outra.

Na práctica, a asimetría é o bastante común como para que a dirección pertenza á primeira proba, non á última. O cliente inicia, a pasarela segue o fluxo e a resposta segue o estado que se creou. Unha VM que inicia un fluxo novo non ten ese estado, así que depende de que a ruta de retorno sexa explicitamente encamiñable e estea permitida. Cando esa ruta falta, o intento de conexión morre antes de que o vexa calquera aplicación.

Probe a dirección antes de probar a accesibilidade

Escolla un enderezo de cliente, un enderezo de VM e un protocolo. Conéctese desde o cliente e anote o resultado; despois inicie a mesma proba desde a VM e anóteo tamén. Se a primeira funciona e a segunda falla, o conxunto de clientes, a asociación da pasarela e a ruta do cliente á VNet funcionan todos.

O seguinte paso son probas, non máis regras. Revise o NSG da subrede da VM en ambos os sentidos, lea as rutas efectivas na NIC da VM e capture paquetes na VM mentres o cliente envía tráfico. Unha petición que chega sen resposta é un problema de filtro ou de ruta de retorno; unha petición que nunca chega é un problema de ruta. Non tome un ping fallido como proba de que a VM é inaccesible, porque a política de ICMP pode descartar a resposta mentres TCP funciona.

A ruta de retorno IKEv2 point-to-site é o sospeitoso habitual

No informe de Azure que está detrás deste artigo, un cliente podía chegar ás VM por IKEv2, pero o ICMP entrante da VM ao cliente fallaba ata que o tipo de túnel da pasarela se cambiou a OpenVPN. O autor do informe afirma que Microsoft confirmou unha limitación na ruta IKEv2 point-to-site, onde o tráfico de retorno dunha VM ao cliente non se encamiña de forma simétrica a menos que o cliente iniciase a sesión. IKEv2 baséase en selectores de tráfico, e a pasarela non respectou a dirección de retorno nese caso.

Iso non converte a OpenVPN no mellor tipo de túnel en xeral. Converte o tipo de túnel nunha variable da matriz de probas para esta carga de traballo.

Cambiar o tipo de túnel é un cambio de servizo, non un interruptor. Cada cliente necesita un perfil compatible, e a pasarela pode necesitar un certificado ou unha configuración de autenticación distintos. Reproduza o comportamento unidireccional cun cliente de proba e unha VM de proba, cambie o tipo segundo un calendario aprobado e repita despois as mesmas probas de dirección. Se o comportamento sobrevive ao cambio, o tipo de túnel non era a causa e acoutou o problema sen tocar produción.

Mito: o descubrimento por broadcast cruza a fronteira da VNet

Unha segunda suposición falla por un motivo non relacionado. Unha rede virtual de Azure non transporta tráfico de broadcast, así que unha VM non pode recibir tramas de broadcast dunha rede local a través dunha conexión site-to-site ou point-to-site. As aplicacións que atopan pares por broadcast, como a navegación de ficheiros antiga ou algúns protocolos de descubrimento de dispositivos, nunca verán o lado remoto, por ben escritas que estean as rutas.

Substitúa o descubrimento por broadcast por nomes DNS, un servizo de directorio ou unha lista explícita de pares. Se a aplicación non ten alternativa unicast, o deseño necesita outro mecanismo de descubrimento, non un túnel máis amplo.

Que cambiar e como demostralo

Se a proba de dirección falla só con IKEv2, anote o tipo de túnel da pasarela, o conxunto de enderezos de clientes e a proba exacta de ICMP ou TCP, e despois avalíe un perfil OpenVPN aprobado para os clientes afectados. Se falla con todos os tipos de túnel, traballa a ruta de retorno: o enderezo do cliente debe ser encamiñable desde a subrede da VM, calquera ruta definida polo usuario debe apuntar a un seguinte salto válido e o cortafuegos do cliente debe aceptar o fluxo entrante. Anexe as probas do NSG e das rutas ao tícket.

Verifique coa aplicación, non con ping. Un intercambio ICMP correcto despois dun cambio non di nada sobre o porto do servizo, a súa autenticación ou a súa resolución de nomes. Repita a proba tras unha reconexión, porque un cliente que recibe un enderezo distinto do conxunto pode cambiar o resultado. Logo repítaa unha vez máis despois de que o cliente durma e esperte, xa que é nunha sesión retomada onde o comportamento unidireccional adoita reaparecer.