El trànsit de retorn de l’Azure P2S VPN només funciona en un sentit

La icona del túnel és verda, el NSG sembla permissiu, les rutes efectives semblen correctes i, tot i així, la VM no pot obrir una connexió de tornada cap al client connectat. La suposició habitual és que un túnel point-to-site que funciona és simètric: si el client pot arribar a la VM, la VM pot arribar al client. Aquesta suposició és l’error del raonament, no de la configuració. Un túnel pot transportar una direcció d’un flux no sol·licitat i descartar l’altra, i la solució depèn de quina capa la descarta.

Mite: un túnel connectat és un túnel bidireccional

Un túnel VPN és un camí de política, no un cable. Cada direcció es compara amb selectors, rutes i filtres, i qualsevol d’ells pot permetre una direcció mentre bloqueja l’altra.

A la pràctica, l’asimetria és prou habitual que la direcció pertany a la primera prova, no a l’última. El client inicia, la passarel·la segueix el flux i la resposta segueix l’estat que s’ha creat. Una VM que inicia un flux nou no té aquest estat, així que depèn que el camí de retorn sigui explícitament encaminable i permès. Quan aquest camí falta, l’intent de connexió mor abans que cap aplicació el vegi.

Proveu la direcció abans de provar l’abastabilitat

Trieu una adreça de client, una adreça de VM i un protocol. Connecteu-vos des del client i anoteu el resultat; després inicieu la mateixa prova des de la VM i anoteu-lo també. Si la primera té èxit i la segona falla, el pool de clients, l’associació de la passarel·la i el camí del client a la VNet funcionen tots.

El següent pas són proves, no més regles. Comproveu el NSG de la subxarxa de la VM en tots dos sentits, llegiu les rutes efectives de la NIC de la VM i captureu paquets a la VM mentre el client envia trànsit. Una petició que arriba sense resposta és un problema de filtre o de ruta de retorn; una petició que no arriba mai és un problema de camí. No prengueu un ping fallit com a prova que la VM és inaccessible, perquè la política ICMP pot descartar la resposta mentre el TCP funciona.

El camí de retorn IKEv2 point-to-site és el sospitós habitual

A l’informe d’Azure que hi ha darrere d’aquest article, un client podia arribar a les VM per IKEv2, però l’ICMP d’entrada de la VM al client fallava fins que el tipus de túnel de la passarel·la es va canviar a OpenVPN. L’autor de l’informe afirma que Microsoft va confirmar una limitació al camí IKEv2 point-to-site, on el trànsit de retorn de la VM al client no s’encamina de manera simètrica tret que el client hagi iniciat la sessió. IKEv2 es basa en selectors de trànsit, i la passarel·la no va respectar la direcció de retorn en aquell cas.

Això no fa que OpenVPN sigui el millor tipus de túnel en general. Fa que el tipus de túnel sigui una variable de la matriu de proves per a aquesta càrrega de treball.

Canviar el tipus de túnel és un canvi de servei, no un commutador. Cada client necessita un perfil compatible, i la passarel·la pot necessitar un certificat o una configuració d’autenticació diferents. Reproduïu el comportament unidireccional amb un client de prova i una VM de prova, canvieu el tipus en un calendari aprovat i repetiu després les mateixes proves de direcció. Si el comportament sobreviu al canvi, el tipus de túnel no era la causa i heu acotat el problema sense tocar producció.

Mite: el descobriment per broadcast travessa la vora de la VNet

Una segona suposició falla per un motiu no relacionat. Una xarxa virtual d’Azure no transporta trànsit de broadcast, així que una VM no pot rebre trames de broadcast d’una xarxa local a través d’una connexió site-to-site o point-to-site. Les aplicacions que troben parells per broadcast, com l’exploració antiga de fitxers o alguns protocols de descobriment de dispositius, mai no veuran el costat remot, per molt bé que s’escriguin les rutes.

Substituïu el descobriment per broadcast per noms DNS, un servei de directori o una llista explícita de parells. Si l’aplicació no té cap alternativa unicast, el disseny necessita un mecanisme de descobriment diferent, no un túnel més ampli.

Què cal canviar i com demostrar-ho

Si la prova de direcció falla només amb IKEv2, anoteu el tipus de túnel de la passarel·la, el pool d’adreces de clients i la prova exacta d’ICMP o TCP, i després avalueu un perfil OpenVPN aprovat per als clients afectats. Si falla amb tots els tipus de túnel, treballeu el camí de retorn: l’adreça del client ha de ser encaminable des de la subxarxa de la VM, qualsevol ruta definida per l’usuari ha d’apuntar a un següent salt vàlid, i el tallafoc del client ha d’acceptar el flux d’entrada. Adjunteu les proves del NSG i de les rutes al tiquet.

Verifiqueu amb l’aplicació, no amb ping. Un intercanvi ICMP correcte després d’un canvi no diu res sobre el port del servei, la seva autenticació o la resolució de noms. Repetiu la prova després d’una reconnexió, perquè un client que rep una adreça diferent del pool pot canviar el resultat. Després repetiu-la una vegada més quan el client s’adorm i es desperta, ja que és en una sessió represa on el comportament unidireccional sovint reapareix.