Trafiku i kthimit i Azure P2S VPN funksionon vetëm në një drejtim

Ikona e tunelit është e gjelbër, NSG duket lejues, rrugët efektive duken të sakta, dhe megjithatë VM nuk mund të hapë një lidhje përsëri drejt klientit të lidhur. Supozimi i zakonshëm është se një tunel point-to-site që funksionon është simetrik: nëse klienti arrin VM, VM arrin klientin. Ky supozim është gabimi në arsyetim, jo në konfigurim. Një tunel mund të mbajë një drejtim të një rrjedhe të pakërkuar dhe të hedhë poshtë tjetrin, dhe rregullimi varet nga ajo se cila shtresë e hedh poshtë.

Miti: një tunel i lidhur është tunel dykahësh

Një tunel VPN është një rrugë politike, jo një tel. Çdo drejtim krahasohet me përzgjedhës, rrugë dhe filtra, dhe secili prej tyre mund të lejojë një drejtim duke bllokuar tjetrin.

Në praktikë asimetria është mjaft e zakonshme saqë drejtimi i takon provës së parë, jo të fundit. Klienti nis, gateway ndjek rrjedhën dhe përgjigja ndjek gjendjen që u krijua. Një VM që nis një rrjedhë të re nuk ka një gjendje të tillë, prandaj varet nga fakti që rruga e kthimit të jetë eksplicit e rrugëtueshme dhe e lejuar. Kur ajo rrugë mungon, përpjekja për lidhje vdes para se ta shohë ndonjë aplikacion.

Testoni drejtimin para se të testoni aksesueshmërinë

Zgjidhni një adresë klienti, një adresë VM dhe një protokoll. Lidhuni nga klienti dhe regjistroni rezultatin; më pas nisni të njëjtën provë nga VM dhe regjistroni edhe atë. Nëse e para ka sukses dhe e dyta dështon, grupi i klientëve, shoqërimi i gateway dhe rruga nga klienti në VNet funksionojnë të gjitha.

Hapi tjetër janë provat, jo më shumë rregulla. Kontrolloni NSG në nënrrjetin e VM në të dy drejtimet, lexoni rrugët efektive në NIC e VM dhe kapni paketa në VM ndërsa klienti dërgon trafik. Një kërkesë që arrin pa përgjigje është problem filtri ose rruge kthimi; një kërkesë që nuk arrin kurrë është problem rruge. Mos e merrni një ping të dështuar si provë që VM është e paarritshme, sepse politika ICMP mund të hedhë poshtë përgjigjen ndërsa TCP funksionon.

Rruga e kthimit IKEv2 point-to-site është i dyshuari i zakonshëm

Në raportin Azure pas këtij artikulli, një klient mund të arrinte VM-të përmes IKEv2, por ICMP në hyrje nga VM drejt klientit dështonte derisa lloji i tunelit të gateway u ndërrua në OpenVPN. Raportuesi thotë se Microsoft konfirmoi një kufizim në rrugën IKEv2 point-to-site, ku trafiku i kthimit nga VM drejt klientit nuk rrugëtohet në mënyrë simetrike nëse klienti nuk e ka nisur sesionin. IKEv2 mbështetet te përzgjedhësit e trafikut, dhe gateway nuk e respektoi drejtimin e kthimit në atë rast.

Kjo nuk e bën OpenVPN llojin më të mirë të tunelit në përgjithësi. Kjo e bën llojin e tunelit një variabël në matricën e provave për këtë ngarkesë pune.

Ndryshimi i llojit të tunelit është ndryshim shërbimi, jo çelës. Çdo klient ka nevojë për një profil të përputhshëm, dhe gateway mund të ketë nevojë për një certifikatë ose konfigurim tjetër vërtetimi. Riprodhoni sjelljen njëkahëshe me një klient testues dhe një VM testuese, ndryshoni llojin sipas një plani të miratuar dhe më pas përsëritni të njëjtat prova drejtimi. Nëse sjellja i mbijeton ndryshimit, lloji i tunelit nuk ishte shkaku dhe e kufizuat problemin pa prekur prodhimin.

Miti: zbulimi përmes broadcast kalon kufirin e VNet

Një supozim i dytë dështon për një arsye të palidhur. Një rrjet virtual Azure nuk transporton trafik broadcast, kështu që një VM nuk mund të marrë kuadro broadcast nga një rrjet lokal përmes një lidhjeje site-to-site ose point-to-site. Aplikacionet që gjejnë homologë përmes broadcast, si shfletimi i vjetër i skedarëve ose disa protokolle zbulimi pajisjesh, nuk do ta shohin kurrë anën e largët, pavarësisht se si janë shkruar rrugët.

Zëvendësoni zbulimin përmes broadcast me emra DNS, një shërbim drejtorie ose një listë të qartë homologësh. Nëse aplikacioni nuk ka alternativë unicast, dizajni ka nevojë për një mekanizëm tjetër zbulimi, jo për një tunel më të gjerë.

Çfarë të ndryshohet dhe si të vërtetohet

Nëse prova e drejtimit dështon vetëm në IKEv2, regjistroni llojin e tunelit të gateway, grupin e adresave të klientëve dhe provën e saktë ICMP ose TCP, më pas vlerësoni një profil OpenVPN të miratuar për klientët e prekur. Nëse dështon në çdo lloj tuneli, punoni rrugën e kthimit: adresa e klientit duhet të jetë e rrugëtueshme nga nënrrjeti i VM, çdo rrugë e përcaktuar nga përdoruesi duhet të tregojë një hop të vlefshëm të radhës, dhe firewalls i klientit duhet të pranojë rrjedhën në hyrje. Bashkëngjitni provat e NSG dhe të rrugëve në tiketë.

Verifikoni me aplikacionin, jo me ping. Një shkëmbim ICMP i suksesshëm pas një ndryshimi nuk thotë asgjë për portin e shërbimit, vërtetimin e tij ose zgjidhjen e emrave. Përsëriteni provën pas një rilidhjeje, sepse një klient që merr një adresë tjetër nga grupi mund ta ndryshojë rezultatin. Më pas përsëriteni edhe një herë pasi klienti të flejë dhe të zgjohet, sepse është pikërisht në një sesion të rifilluar që sjellja njëkahëshe shpesh rishfaqet.