Azure P2S VPN grįžtamasis srautas veikia tik viena kryptimi

Tunelio piktograma žalia, NSG atrodo leidžianti, efektyvūs maršrutai atrodo teisingi, tačiau VM vis tiek negali atidaryti ryšio atgal į prijungtą klientą. Įprasta prielaida, kad veikiantis point-to-site tunelis yra simetriškas: jei klientas pasiekia VM, VM pasiekia klientą. Ši prielaida yra mąstymo, o ne konfigūracijos klaida. Tunelis gali perduoti vieną neprašyto srauto kryptį ir numesti kitą, o taisymas priklauso nuo to, kuris sluoksnis ją numeta.

Mitas: prijungtas tunelis yra dvikryptis tunelis

VPN tunelis yra politikos kelias, o ne laidas. Kiekviena kryptis lyginama su selektoriais, maršrutais ir filtrais, ir bet kuris iš jų gali leisti vieną kryptį, blokuodamas kitą.

Praktiškai asimetrija yra tokia įprasta, kad kryptis turi būti pirmame teste, o ne paskutiniame. Klientas inicijuoja, šliuzas seka srautą, o atsakymas seka sukurtą būseną. VM, pradedanti naują srautą, neturi tokios būsenos, todėl priklauso nuo to, ar grįžtamasis kelias yra aiškiai maršrutizuojamas ir leidžiamas. Kai to kelio nėra, ryšio bandymas žūva dar prieš tai, kai jį pamato kuri nors programa.

Patikrinkite kryptį prieš tikrindami pasiekiamumą

Pasirinkite vieną kliento adresą, vieną VM adresą ir vieną protokolą. Prisijunkite iš kliento ir užrašykite rezultatą; tada pradėkite tą patį testą iš VM ir jį taip pat užrašykite. Jei pirmasis pavyksta, o antrasis nepavyksta, klientų telkinys, šliuzo susiejimas ir kelias nuo kliento iki VNet visi veikia.

Kitas žingsnis yra įrodymai, o ne daugiau taisyklių. Patikrinkite NSG VM potinklyje abiem kryptimis, perskaitykite efektyvius maršrutus VM NIC ir fiksuokite paketus VM, kol klientas siunčia srautą. Užklausa, kuri atvyksta be atsakymo, yra filtro arba grįžtamojo maršruto problema; užklausa, kuri niekada neatvyksta, yra kelio problema. Nelaikykite nepavykusio ping įrodymu, kad VM nepasiekiama, nes ICMP politika gali numesti atsakymą, kol TCP veikia.

IKEv2 point-to-site grįžtamasis kelias yra įprastas įtariamasis

Azure ataskaitoje, kuria grindžiamas šis straipsnis, klientas pasiekė VM per IKEv2, tačiau gaunamas ICMP iš VM į klientą nepavykdavo, kol šliuzo tunelio tipas nebuvo perjungtas į OpenVPN. Ataskaitos autorius teigia, kad Microsoft patvirtino IKEv2 point-to-site kelio apribojimą: grįžtamasis srautas iš VM į klientą nėra maršrutizuojamas simetriškai, nebent sesiją pradėjo klientas. IKEv2 remiasi srauto selektoriais, o šliuzas tuo atveju nepaisė grįžtamosios krypties.

Tai nepadaro OpenVPN apskritai geresniu tunelio tipu. Tai paverčia tunelio tipą šio darbo krūvio testavimo matricos kintamuoju.

Tunelio tipo keitimas yra paslaugos pokytis, o ne jungiklis. Kiekvienam klientui reikia suderinamo profilio, o šliuzui gali prireikti kito sertifikato ar autentifikavimo nustatymo. Atkurkite vienkryptį elgesį su vienu bandomuoju klientu ir viena bandomąja VM, pakeiskite tipą pagal patvirtintą grafiką ir tada pakartokite tuos pačius krypties testus. Jei elgsena išlieka po pakeitimo, tunelio tipas nebuvo priežastis, ir jūs susiaurinote problemą neliesdami produkcijos.

Mitas: broadcast aptikimas kerta VNet ribą

Antroji prielaida nepavyksta dėl nesusijusios priežasties. Azure virtualusis tinklas neperduoda broadcast srauto, todėl VM negali gauti broadcast kadrų iš vietinio tinklo per site-to-site ar point-to-site ryšį. Programos, kurios randa partnerius per broadcast, pavyzdžiui, senesnė failų naršymo funkcija ar kai kurie įrenginių aptikimo protokolai, niekada nematys tolimosios pusės, kad ir kaip būtų parašyti maršrutai.

Pakeiskite broadcast aptikimą DNS vardais, katalogo paslauga arba aiškiu partnerių sąrašu. Jei programa neturi unicast alternatyvos, dizainui reikia kito aptikimo mechanizmo, o ne platesnio tunelio.

Ką keisti ir kaip tai įrodyti

Jei krypties testas nepavyksta tik su IKEv2, užrašykite šliuzo tunelio tipą, klientų adresų telkinį ir tikslų ICMP arba TCP testą, tada įvertinkite patvirtintą OpenVPN profilį paveiktiems klientams. Jei jis nepavyksta su visais tunelio tipais, dirbkite su grįžtamuoju keliu: kliento adresas turi būti maršrutizuojamas iš VM potinklio, bet kuris vartotojo apibrėžtas maršrutas turi rodyti į galiojantį kitą šuolį, o kliento ugniasienė turi priimti gaunamą srautą. Pridėkite NSG ir maršrutų įrodymus prie bilieto.

Tikrinkite su programa, o ne su ping. Sėkmingas ICMP pasikeitimas po pakeitimo nieko nesako apie paslaugos prievadą, jos autentifikavimą ar vardų skiriamąją gebą. Pakartokite testą po pakartotinio prisijungimo, nes klientas, gaunantis kitą telkinio adresą, gali pakeisti rezultatą. Tada pakartokite dar kartą, kai klientas užmiega ir pabunda, nes būtent atnaujintoje sesijoje vienkryptis elgesys dažnai vėl pasirodo.