Azure P2S VPN-terugverkeer werk net in een rigting

Die tonnel-ikoon is groen, die NSG lyk toelatend, die effektiewe roetes lyk reg, en die VM kan steeds nie 'n verbinding terug na die gekoppelde kliënt oopmaak nie. Die gewone aanname is dat 'n werkende punt-na-werf-tonnel simmetries is: as die kliënt die VM kan bereik, kan die VM die kliënt bereik. Daardie aanname is die fout in die redenasie, nie in die konfigurasie nie. 'n Tonnel kan een rigting van 'n ongevraagde vloei dra terwyl dit die ander een laat val, en die regstelling hang daarvan af watter laag dit laat val.

Mite: 'n gekoppelde tonnel is 'n tweerigtingtonnel

'n VPN-tonnel is 'n beleidsroete, nie 'n draad nie. Elke rigting word teen kiesers, roetes en filters gepas, en enige van hulle kan een rigting toelaat terwyl dit die ander een blokkeer.

In die praktyk is die asimmetrie algemeen genoeg dat rigting in die eerste toets hoort, nie in die laaste nie. Die kliënt begin, die poort hou die vloei dop, en die antwoord volg die toestand wat geskep is. 'n VM wat 'n nuwe vloei begin, het nie so 'n toestand nie, dus hang dit daarvan af dat die terugpad uitdruklik routeerbaar en toegelaat word. Wanneer daardie pad ontbreek, sterf die verbindingspoging voordat enige toepassing dit sien.

Toets die rigting voordat jy bereikbaarheid toets

Kies een kliëntadres, een VM-adres en een protokol. Maak van die kliënt af verbinding en teken die resultaat aan; begin dan dieselfde toets van die VM af en teken dit ook aan. As die eerste slaag en die tweede misluk, werk die kliëntpoel, die poortassosiasie en die kliënt-na-VNet-pad almal.

Die volgende stap is bewyse, nie meer reëls nie. Kontroleer die NSG op die VM-subnet in beide rigtings, lees die effektiewe roetes op die VM se NIC, en vang pakkette op die VM terwyl die kliënt verkeer stuur. 'n Versoek wat aankom sonder antwoord is 'n filter- of terugroeteprobleem; 'n versoek wat nooit aankom nie is 'n padprobleem. Moenie 'n mislukte ping as bewys beskou dat die VM onbereikbaar is nie, want ICMP-beleid kan die antwoord laat val terwyl TCP werk.

Die IKEv2-punt-na-werf-terugpad is die gewone verdagte

In die Azure-verslag agter hierdie artikel kon 'n kliënt VMs oor IKEv2 bereik, maar inkomende ICMP van die VM na die kliënt het gefaal totdat die poort se tonneltipe na OpenVPN oorgeskakel is. Die verslaggewer sê Microsoft het 'n beperking in die IKEv2-punt-na-werf-pad bevestig, waar terugverkeer van 'n VM na die kliënt nie simmetries gerouteer word nie tensy die kliënt die sessie begin het. IKEv2 maak staat op verkeerskiesers, en die poort het in daardie geval nie die terugrigting geëer nie.

Dit maak nie van OpenVPN in die algemeen die beter tonneltipe nie. Dit maak van tonneltipe 'n veranderlike in die toetsmatriks vir hierdie werklading.

Om tonneltipes te wissel is 'n diensverandering, nie 'n skakelaar nie. Elke kliënt het 'n versoenbare profiel nodig, en die poort het dalk 'n ander sertifikaat of verifikasie-opstelling nodig. Herhaal die eenrigtinggedrag met een toetskliënt en een toets-VM, verander die tipe op 'n goedgekeurde skedule, en herhaal daarna dieselfde rigtingstoetse. As die gedrag die oorskakeling oorleef, was die tonneltipe nie die oorsaak nie en het jy die probleem vernou sonder om produksie aan te raak.

Mite: uitsaaiontdekking steek die VNet-grens oor

'n Tweede aanname faal om 'n onverwante rede. 'n Azure-virtuele netwerk dra nie uitsaiverkeer nie, so 'n VM kan nie uitsaaibele van 'n plaaslike netwerk oor 'n werf-tot-werf- of punt-na-werf-verbinding ontvang nie. Toepassings wat eweknieë deur uitsaai vind, soos ouer lêerblaai of sommige toestelontdekkingsprotokolle, sal die verre kant nooit sien nie, maak nie saak hoe die roetes geskryf is nie.

Vervang uitsaaiontdekking met DNS-name, 'n gidsdiens of 'n eksplisiete eweknie-lys. As die toepassing geen unicast-alternatief het nie, het die ontwerp 'n ander ontdekkingsmeganisme nodig, nie 'n wyer tonnel nie.

Wat om te verander, en hoe om dit te bewys

As die rigtingstoets net op IKEv2 misluk, teken die poort se tonneltipe, die kliëntadrespoel en die presiese ICMP- of TCP-toets aan, en evalueer dan 'n goedgekeurde OpenVPN-profiel vir die geaffekteerde kliënte. As dit op elke tonneltipe misluk, werk aan die terugpad: die kliëntadres moet van die VM-subnet af routeerbaar wees, enige gebruikergedefinieerde roete moet na 'n geldige volgende sprong wys, en die kliënt se firewall moet die inkomende vloei aanvaar. Heg die NSG- en roetebewyse aan die kaartjie.

Verifieer met die toepassing, nie met ping nie. 'n Suksesvolle ICMP-uitruiling ná 'n verandering sê niks oor die dienspoort, sy verifikasie of sy naamresolusie nie. Herhaal die toets ná 'n herverbinding, want 'n kliënt wat 'n ander poeladres kry, kan die resultaat verander. Herhaal dit dan nog een keer nadat die kliënt slaap en wakker word, want 'n hervatte sessie is waar eenrigtinggedrag dikwels weer verskyn.