Den Azure P2S VPN-Rückverkéier funktionéiert nëmmen an eng Richtung

D’Tunnelsymbol ass gréng, d’NSG gesäit erlabend aus, d’effektiv Routen gesinn richteg aus, an trotzdeem kann d’VM keng Verbindung zréck zum verbonnene Client opmaachen. D’üblech Unhuel ass, datt en funktionéierenden point-to-site-Tunnel symmetresch ass: wann de Client d’VM erreecht, erreecht d’VM de Client. Déi Unhuel ass de Feeler am Denken, net an der Konfiguratioun. En Tunnel kann eng Richtung vun engem ongefrote Floss droen an déi aner fale loossen, an d’Korrektur hänkt dovun of, wéi eng Schicht se fale léisst.

Mythos: en verbonnenen Tunnel ass en Tunnel an zwou Richtungen

En VPN-Tunnel ass e Richtlinnepfad, keen Draht. All Richtung gëtt mat Selektoren, Routen a Filter verglach, an all eenzel dovun kann eng Richtung erlaben an déi aner blockéieren.

An der Praxis ass d’Asymmetrie sou heefeg, datt d’Richtung an den éischten Test gehéiert, net an den leschten. De Client fänkt un, de Gateway verfollegt de Floss, an d’Äntwert follegt dem Zoustand, dee geschaf gouf. Eng VM, déi en neie Floss ufänkt, huet keen esougen Zoustand, dofir hänkt et dovun of, datt de Réckwee ausdrécklech routbar an erlaabt ass. Wa séi Wee feelt, stierft de Verbindungsversuch, ier eng Applikatioun en gesäit.

Testéiert d’Richtung, ier Dir d’Erreechbarkeet testéiert

Wielt eng Clientadress, eng VM-Adress an ee Protokoll. Verbënnt Iech vum Client a notéiert d’Resultat; fänkt duerno deen selwechten Test vun der VM un a notéiert deen och. Wann deen éischten geléngt an den zweeten net, funktionéieren de Client-Pool, d’Gateway-Zouuerdnung an de Wee vum Client op d’VNet alleguer.

Den nächste Schrëtt sinn Beweiser, net méi Regelen. Kontrolléiert d’NSG um VM-Subnet a béid Richtungen, liest déi effektiv Routen op der VM-NIC, a fänkt Pakete op der VM of, wärend de Client Traffic schéckt. Eng Ufro, déi ouni Äntwert ukënnt, ass e Filter- oder Réckwee-Probleem; eng Ufro, déi ni ukënnt, ass e Wee-Probleem. Hält en duerchgefallene Ping net fir de Beweis, datt d’VM net erreechbar ass, well eng ICMP-Politik d’Äntwert fale loosse kann, wärend TCP funktionéiert.

Den IKEv2 point-to-site-Réckwee ass de gewéinleche Verdächtegen

An dem Azure-Bericht hannert dësem Artikel konnt e Client d’VMen iwwer IKEv2 erreechen, awer den agaangen ICMP vun der VM zum Client ass feelgeschloen, bis den Tunneltyp vum Gateway op OpenVPN ëmgestallt gouf. De Berichter erkläert, datt Microsoft eng Aschränkung am IKEv2 point-to-site-Wee confirméiert huet, wou de Réckverkéier vun enger VM zum Client net symmetresch gerout gëtt, ausser de Client huet d’Sessioun ugefaangen. IKEv2 stäipt sech op Traffic-Selektoren, an de Gateway huet an deem Fall d’Réckrichtung net respektéiert.

Dat mécht OpenVPN net allgemeng zum besseren Tunneltyp. Et mécht den Tunneltyp zu enger Variabel an der Testmatrix fir dës Aarbechtslaascht.

Den Tunneltyp ze wiesselen ass eng Serviceännerung, keen Ëmschalter. All Client brauch e kompatibelt Profil, an de Gateway brauch vläicht en anert Zertifikat oder eng aner Authentifikatiouns-Astellung. Reproduzéiert dat eenrichtungs-Verhalen mat engem Testclient an enger Test-VM, ännert den Typ no engem guttgeheeschtem Plang, a widderhëlt duerno déi selwecht Richtungstester. Wann d’Verhalen den Ëmstellung iwwerlieft, war den Tunneltyp net d’Ursaach an Dir hutt de Problem agegrenzt, ouni d’Produktioun unzepaken.

Mythos: d’Broadcast-Entdeckung iwwerschreift d’VNet-Grenz

Eng zweet Unhuel schléit aus engem onverbonnene Grond feel. En Azure-virtuellt Netzwierk transportéiert keng Broadcast-Traffic, dofir kann eng VM keng Broadcast-Framen aus engem lokalen Netzwierk iwwer eng site-to-site- oder point-to-site-Verbindung empfänken. Applikatiounen, déi Peeren iwwer Broadcast fannen, wéi déi méi al Datei-Navigatioun oder verschidde Gerät-Entdeckungsprotokollen, wäerten déi wäit Säit ni gesinn, egal wéi d’Routen geschriwwe sinn.

Ersetzt d’Broadcast-Entdeckung duerch DNS-Nimm, en Verzeechnes-Service oder eng explizit Peerlëscht. Wann d’Applikatioun keng unicast-Alternativ huet, brauch den Design en aneren Entdeckungsmechanismus, keen méi breeden Tunnel.

Wat änneren, a wéi et beweise

Wann den Richtungstest nëmmen op IKEv2 feel schléit, notéiert den Tunneltyp vum Gateway, de Clientadress-Pool an den exakten ICMP- oder TCP-Test, a bewäert duerno e guttgeheescht OpenVPN-Profil fir déi betraffe Clienten. Wann en op all Tunneltyp feel schléit, schafft um Réckwee: d’Clientadress muss vum VM-Subnet aus routbar sinn, all vu Benotzer definéiert Route muss op en valabelen nächsten Hop weisen, an d’Firewall vum Client muss den agaangene Floss akzeptéieren. Hänkt d’NSG- a Routebeweiser un den Ticket.

Verifizéiert mat der Applikatioun, net mat Ping. En erfollegräichen ICMP-Austausch no enger Ännerung seet näischt iwwer de Serviceport, seng Authentifikatioun oder seng Numm-Opléisung. Widderhëlt den Test no enger Reconnectioun, well e Client, deen eng aner Pooladress kritt, d’Resultat ännere kann. Widderhëlt en duerno nach eng Kéier, nodeems de Client geschlof an erwächt ass, well et an enger weidergefouerter Sessioun ass, wou eenrichtungs-Verhalen dacks erëm erschéngt.