Azure P2S VPN atgaitas trafiks darbojas tikai vienā virzienā

Tuneļa ikona ir zaļa, NSG izskatās atļaujošs, efektīvie maršruti izskatās pareizi, un tomēr VM joprojām nevar atvērt savienojumu atpakaļ uz pievienoto klientu. Ierastais pieņēmums ir, ka strādājošs point-to-site tunelis ir simetrisks: ja klients sasniedz VM, VM sasniedz klientu. Šis pieņēmums ir domāšanas, nevis konfigurācijas kļūda. Tunelis var pārvadīt vienu nepieprasītas plūsmas virzienu un nomest otru, un labojums ir atkarīgs no tā, kura slānis to nomet.

Mīts: pievienots tunelis ir divvirzienu tunelis

VPN tunelis ir politikas ceļš, nevis vads. Katrs virziens tiek salīdzināts ar selektoriem, maršrutiem un filtriem, un jebkurš no tiem var atļaut vienu virzienu, bloķējot otru.

Praksē asimetrija ir pietiekami izplatīta, lai virziens būtu pirmajā testā, nevis pēdējā. Klients uzsāk, vārteja izseko plūsmu, un atbilde seko izveidotajam stāvoklim. VM, kas uzsāk jaunu plūsmu, šāda stāvokļa nav, tāpēc tā ir atkarīga no tā, vai atgaitas ceļš ir skaidri maršrutējams un atļauts. Ja šī ceļa nav, savienojuma mēģinājums iet bojā, pirms to ierauga jebkura lietojumprogramma.

Pārbaudiet virzienu pirms sasniedzamības pārbaudes

Izvēlieties vienu klienta adresi, vienu VM adresi un vienu protokolu. Piesakieties no klienta un pierakstiet rezultātu; pēc tam sāciet to pašu testu no VM un pierakstiet arī to. Ja pirmais izdodas un otrais neizdodas, klientu kopums, vārtejas asociācija un ceļš no klienta uz VNet visi darbojas.

Nākamais solis ir pierādījumi, nevis vairāk noteikumu. Pārbaudiet NSG VM apakštīklā abos virzienos, izlasiet efektīvos maršrutus VM NIC un tveriet paketes VM, kamēr klients sūta trafiku. Pieprasījums, kas ierodas bez atbildes, ir filtra vai atgaitas maršruta problēma; pieprasījums, kas nekad neierodas, ir ceļa problēma. Neuzskatiet neizdevušos ping par pierādījumu, ka VM nav sasniedzams, jo ICMP politika var nomest atbildi, kamēr TCP darbojas.

IKEv2 point-to-site atgaitas ceļš ir ierastais aizdomās turamais

Azure ziņojumā, uz kuru balstīts šis raksts, klients varēja sasniegt VM ar IKEv2, bet ienākošais ICMP no VM uz klientu neizdevās, līdz vārtejas tuneļa tips tika pārslēgts uz OpenVPN. Ziņojuma autors norāda, ka Microsoft apstiprināja ierobežojumu IKEv2 point-to-site ceļā, kur atgaitas trafiks no VM uz klientu netiek maršrutēts simetriski, ja vien sesiju neuzsāka klients. IKEv2 balstās uz trafika selektoriem, un vārteja šajā gadījumā neievēroja atgaitas virzienu.

Tas nepadara OpenVPN par labāku tuneļa tipu kopumā. Tas padara tuneļa tipu par mainīgo šī darba slodzes testu matricā.

Tuneļa tipa maiņa ir pakalpojuma izmaiņa, nevis slēdzis. Katram klientam ir nepieciešams saderīgs profils, un vārtejai var būt nepieciešams cits sertifikāts vai autentifikācijas iestatījums. Reproducējiet vienvirziena uzvedību ar vienu testa klientu un vienu testa VM, nomainiet tipu saskaņā ar apstiprinātu grafiku un pēc tam atkārtojiet tos pašus virziena testus. Ja uzvedība saglabājas pēc maiņas, tuneļa tips nebija cēlonis, un jūs sašaurinājāt problēmu, neaizskarot ražošanu.

Mīts: broadcast atklāšana šķērso VNet robežu

Otrs pieņēmums neizdodas nesaistīta iemesla dēļ. Azure virtuālais tīkls nepārvada broadcast trafiku, tāpēc VM nevar saņemt broadcast kadrus no vietējā tīkla caur site-to-site vai point-to-site savienojumu. Lietojumprogrammas, kas atrod partnerus ar broadcast, piemēram, vecāka failu pārlūkošana vai daži ierīču atklāšanas protokoli, nekad neredzēs attālo pusi, lai kā arī būtu rakstīti maršruti.

Aizstājiet broadcast atklāšanu ar DNS nosaukumiem, direktoriju pakalpojumu vai skaidru partneru sarakstu. Ja lietojumprogrammai nav unicast alternatīvas, dizainam ir nepieciešams cits atklāšanas mehānisms, nevis plašāks tunelis.

Ko mainīt un kā to pierādīt

Ja virziena tests neizdodas tikai ar IKEv2, pierakstiet vārtejas tuneļa tipu, klientu adrešu kopumu un precīzo ICMP vai TCP testu, pēc tam novērtējiet apstiprinātu OpenVPN profilu skartajiem klientiem. Ja tas neizdodas ar visiem tuneļa tipiem, strādājiet pie atgaitas ceļa: klienta adresei jābūt maršrutējamai no VM apakštīkla, jebkuram lietotāja definētam maršrutam jānorāda uz derīgu nākamo lēcienu, un klienta ugunsmūrim jāpieņem ienākošā plūsma. Pievienojiet NSG un maršrutu pierādījumus biļetei.

Pārbaudiet ar lietojumprogrammu, nevis ar ping. Veiksmīga ICMP apmaiņa pēc izmaiņām neko nepasaka par pakalpojuma portu, tā autentifikāciju vai nosaukumu atrisināšanu. Atkārtojiet testu pēc atkārtotas pieslēgšanās, jo klients, kas saņem citu kopuma adresi, var mainīt rezultātu. Pēc tam atkārtojiet to vēlreiz pēc tam, kad klients aizmieg un pamostas, jo tieši atjaunotā sesijā vienvirziena uzvedība bieži parādās no jauna.