Azure P2S VPN-ren itzulera-trafikoak norabide bakarrean soilik egiten du lan

Tunelaren ikonoa berdea da, NSG baimengarria dirudi, ibilbide eraginkorrak zuzenak dirudite, eta hala ere VMak ezin du konexio bat ireki konektatutako bezeroaren aldera. Ohiko assumptioa da funtzionatzen duen point-to-site tunel bat simetrikoa dela: bezeroak VMa iristen bada, VMak bezeroa iristen du. Assumptio hori arrazoibideko akatsa da, ez konfiguraziokoa. Tunel batek eskatutako gabeko fluxu baten norabide bat eraman dezake eta bestea baztertu, eta konponketa zein geruzak baztertzen duen araberakoa da.

Mitoa: konektatutako tunel bat norabide biko tunela da

VPN tunel bat politika-bidea da, ez kablea. Norabide bakoitza hautatzaile, ibilbide eta iragazkiekin alderatzen da, eta horietako edozeinek norabide bat onar dezake bestea blokeatuz.

Praktikan asimetria nahiko ohikoa da norabidea lehen proban egon dadin, ez azkenen. Bezeroak hasten du, gatewayak fluxua jarraitzen du, eta erantzunak sortu den egoerari jarraitzen dio. Fluxu berri bat hasten duen VMak ez du halako egoerarik, beraz itzulera-bidea esplizituki bideragarria eta baimenduta egotearen mende dago. Bide hori falta denean, konexio-saiakera edozein aplikaziok ikusi baino lehen hiltzen da.

Probatu norabidea irisgarritasuna probatu aurretik

Hautatu bezero helbide bat, VM helbide bat eta protokolo bat. Konektatu bezerotik eta erregistratu emaitza; gero hasi proba bera VMtik eta erregistratu hori ere. Lehena arrakastatsua bada eta bigarrena huts egiten badu, bezeroen poolak, gatewayaren elkartzeak eta bezerotik VNeterako bideak denek funtzionatzen dute.

Hurrengo urratsa frogak dira, ez arau gehiago. Egiaztatu VMaren azpisareko NSGa bi norabideetan, irakurri ibilbide eraginkorrak VMaren NICean, eta harrapatu paketeak VMan bezeroak trafikoa bidaltzen duen bitartean. Erantzunik gabe iristen den eskaera iragazki edo itzulera-ibilbide arazoa da; inoiz iristen ez den eskaera bide arazoa da. Ez hartu huts egindako ping VMa iristezina delako frogatzat, ICMP politikak erantzuna bazter baititzake TCPk funtzionatzen duen bitartean.

IKEv2 point-to-site itzulera-bidea da susmagarri ohikoa

Artikulu honen atzean dagoen Azure txostenean, bezero batek IKEv2 bidez iristen zituen VMak, baina VMtik bezeroara sarrerako ICMPak huts egiten zuen gatewayaren tunel mota OpenVPNera aldatu arte. Txostenaren egileak dio Microsoftek IKEv2 point-to-site bidean muga bat berretsi zuela: VMtik bezeroara itzulera-trafikoa ez da modu simetrikoan bideratzen bezeroak saioa hasi ez badu. IKEv2 trafiko-hautatzaileen mende dago, eta gatewayak ez zuen itzulera-norabidea errespetatu kasu horretan.

Horrek ez du OpenVPN bihurtzen oro har tunel mota hobea. Horrek tunel mota lan-karga honetako proba-matrizean aldagai bihurtzen du.

Tunel mota aldatzea zerbitzu-aldaketa da, ez etengailua. Bezero bakoitzak profil bateragarria behar du, eta gatewayak ziurtagiri edo autentikazio-konfigurazio desberdina behar izan dezake. Erreproduzitu norabide bakarreko portaera probako bezero batekin eta probako VM batekin, aldatu mota onartutako egutegi baten arabera, eta gero errepikatu norabide-proba berak. Portaerak aldaketa gainditzen badu, tunel mota ez zen arrazoia eta arazoa mugatu duzu produkzioa ukitu gabe.

Mitoa: broadcast bidezko aurkikuntzak VNeten ertza zeharkatzen du

Bigarren assumptio batek huts egiten du lotu gabeko arrazoi batengatik. Azure sare birtualak ez du broadcast trafikoa eramaten, beraz VMak ezin ditu broadcast markoak jaso sare lokal batetik site-to-site edo point-to-site konexio baten bidez. Broadcast bidez kideak aurkitzen dituzten aplikazioek, hala nola fitxategi arakatze zaharra edo gailuen aurkikuntza protokolo batzuk, ez dute inoiz urruneko aldea ikusiko, ibilbideak nola idatzita egon ere.

Ordeztu broadcast bidezko aurkikuntza DNS izenekin, direktorio zerbitzu batekin edo kideen zerrenda esplizitu batekin. Aplikazioak unicast alternatibarik ez badu, diseinuak beste aurkikuntza mekanismo bat behar du, ez tunel zabalagoa.

Zer aldatu, eta nola frogatu

Norabide-probak IKEv2n soilik huts egiten badu, erregistratu gatewayaren tunel mota, bezeroen helbide-poola eta ICMP edo TCP proba zehatza, gero ebaluatu OpenVPN profil onartu bat eragindako bezeroentzat. Tunel mota guztietan huts egiten badu, landu itzulera-bidea: bezeroaren helbidea VMaren azpisaretik bideragarria izan behar da, erabiltzaileak definitutako edozein ibilbide hurrengo jauzi baliozko batera joan behar da, eta bezeroaren firewallak sarrerako fluxua onartu behar du. Erantsi NSG eta ibilbideen frogak tiketeari.

Egiaztatu aplikazioarekin, ez pingarekin. Aldaketa baten ondorengo ICMP truke arrakastatsuak ez du ezer esaten zerbitzuaren portuari, autentikazioari edo izen-ebazpenari buruz. Errepikatu proba berriz konektatu ondoren, pooltik helbide desberdin bat jasotzen duen bezeroak emaitza alda baitezake. Gero errepikatu beste behin bezeroa lo egiten eta esnatzen denean, saio berreskuratu batean norabide bakarreko portaera berriro agertzen baita sarritan.