Endurkoma umferð Azure P2S VPN virkar aðeins í aðra áttina

Tunnilhelgimyndin er græn, NSG virðist leyfandi, virku leiðirnar virðast réttar, og samt getur VM ekki opnað tengingu til baka til tengda biðlarans. Venjuleg forsenda er að vinnandi point-to-site-tunnill sé samhverfur: ef biðlarinn nær VM, nær VM biðlaranum. Sú forsenda er mistökin í röksemdafærslunni, ekki í stillingunni. Tunnill getur borið eina átt óskaðs flæðis og sleppt hinni, og viðgerðin fer eftir því hvaða lag sleppir henni.

Goðsögn: tengdur tunnill er tvíátta tunnill

VPN-tunnill er stefnuleið, ekki vír. Hver átt er borin saman við valara, leiðir og síur, og hver þeirra getur leyft aðra áttina á meðan hún lokar hinni.

Í reynd er ósamhverfan nógu algeng til að áttin eigi heima í fyrstu prófun, ekki þeirri síðustu. Biðlarinn byrjar, gáttin fylgist með flæðinu og svarið fylgir því ástandi sem var búið til. VM sem byrjar nýtt flæði hefur ekkert slíkt ástand, svo það veltur á að bakleiðin sé skýrlega leiðanleg og leyfð. Þegar sú leið vantar deyr tengingartilraunin áður en nokkur forrit sér hana.

Prófaðu stefnuna áður en þú prófar aðgengi

Veldu eitt biðlaraheimilisfang, eitt VM-heimilisfang og einn samskiptamáta. Tengdu frá biðlaranum og skráðu niðurstöðuna; byrjaðu svo sömu prófun frá VM og skráðu hana líka. Ef fyrri tekst og seinni mistekst virka biðlarasafnið, gáttartengingin og leiðin frá biðlara að VNet öll.

Næsta skref er sönnunargögn, ekki fleiri reglur. Athugaðu NSG á undirneti VM í báðar áttir, lestu virku leiðirnar á NIC VM og fangaðu pakka á VM á meðan biðlarinn sendir umferð. Beiðni sem kemur án svars er vandamál síu eða bakleiðar; beiðni sem kemur aldrei er vandamál leiðar. Ekki líta á misheppnað ping sem sönnun þess að VM sé óaðgengilegt, því ICMP-stefna getur sleppt svarinu á meðan TCP virkar.

IKEv2 point-to-site bakleiðin er venjulegi grunaði

Í Azure-skýrslunni bak við þessa grein gat biðlari náð VM um IKEv2, en innkomandi ICMP frá VM til biðlarans mistókst þar til tunnilgerð gáttarinnar var skipt yfir í OpenVPN. Skýrsluhöfundur segir Microsoft hafa staðfest takmörkun í IKEv2 point-to-site-leiðinni, þar sem endurkoma umferð frá VM til biðlarans er ekki leiðuð samhverft nema biðlarinn hafi byrjað lotuna. IKEv2 byggir á umferðarvalurum, og gáttin virti ekki bakáttina í því tilviki.

Það gerir OpenVPN ekki að betri tunnilgerð almennt. Það gerir tunnilgerðina að breytu í prófunarfylkinu fyrir þetta vinnuálag.

Að skipta um tunnilgerð er þjónustubreyting, ekki rofi. Sérhver biðlari þarf samhæft snið, og gáttin gæti þurft annað skírteini eða aðra auðkenninguppsetningu. Endurgerðu einstefnuhegðunina með einum prófunarbiðlara og einu prófunar-VM, skiptu um gerð samkvæmt samþykktri áætlun og endurtaktu svo sömu stefnuprófanir. Ef hegðunin lifir skiptin var tunnilgerðin ekki orsökin og þú hefur þrengt vandamálið án þess að snerta framleiðslu.

Goðsögn: broadcast-uppgötvun fer yfir VNet-mörkin

Önnur forsenda mistekst af ótengdri ástæðu. Azure-sýndarnet ber ekki broadcast-umferð, svo VM getur ekki tekið við broadcast-rammum frá staðarneti yfir site-to-site eða point-to-site tengingu. Forrit sem finna jafningja með broadcast, eins og eldri skráarvafur eða sumar tækjauppgötvunarsamskiptareglur, munu aldrei sjá fjarlægu hliðina, hvernig sem leiðirnar eru skrifaðar.

Skiptu broadcast-uppgötvun út fyrir DNS-nöfn, skráarþjónustu eða skýran jafningjalista. Ef forritið hefur enga unicast-kosti þarf hönnunin aðra uppgötvunaraðferð, ekki breiðari tunnil.

Hverju á að breyta, og hvernig á að sanna það

Ef stefnuprófið mistekst aðeins á IKEv2 skaltu skrá tunnilgerð gáttarinnar, biðlarasafnið og nákvæmu ICMP- eða TCP-prófunina, og meta svo samþykkt OpenVPN-snið fyrir viðkomandi biðlara. Ef það mistekst á hverri tunnilgerð skaltu vinna bakleiðina: biðlaraheimilisfangið verður að vera leiðanlegt frá undirneti VM, sérhver notandaskilgreind leið verður að vísa á gilt næsta hopp, og eldveggur biðlarans verður að taka við innkomandi flæði. Láttu NSG- og leiðasönnunargögn fylgja miðanum.

Sannreyndu með forritinu, ekki með ping. Árangursrík ICMP-skipti eftir breytingu segja ekkert um þjónustuhliðið, auðkenningu þess eða nafnupplausn. Endurtaktu prófið eftir endurtengingu, því biðlari sem fær annað safnheimilisfang getur breytt niðurstöðunni. Endurtaktu það svo einu sinni enn eftir að biðlarinn sefur og vaknar, því það er í endurnýjaðri lotu sem einstefnuhegðun kemur oft aftur fram.