Az Azure P2S VPN visszatérő forgalma csak egy irányban működik

Az alagút ikonja zöld, az NSG megengedőnek tűnik, az effektív útvonalak helyesnek látszanak, és a VM mégsem tud kapcsolatot nyitni vissza a csatlakozott kliens felé. A szokásos feltevés, hogy egy működő point-to-site alagút szimmetrikus: ha a kliens eléri a VM-et, a VM is eléri a klienst. Ez a feltevés a gondolkodás hibája, nem a konfigurációé. Egy alagút a kéretlen folyam egyik irányát szállíthatja, a másikat pedig eldobhatja, és a javítás attól függ, melyik réteg dobja el.

Mítosz: a csatlakozott alagút kétirányú alagút

A VPN-alagút házirend-útvonal, nem vezeték. Minden irányt szelektorokhoz, útvonalakhoz és szűrőkhöz illesztünk, és bármelyikük engedélyezheti az egyik irányt, miközben blokkolja a másikat.

A gyakorlatban az aszimmetria elég gyakori ahhoz, hogy az irány az első tesztbe tartozzon, nem az utolsóba. A kliens kezdeményez, az átjáró követi a folyamot, és a válasz a létrehozott állapotot követi. Egy új folyamot indító VM-nek nincs ilyen állapota, ezért attól függ, hogy a visszaút kifejezetten útvonalazható és engedélyezett legyen. Ha ez az út hiányzik, a kapcsolódási kísérlet még azelőtt meghal, hogy bármely alkalmazás látná.

Az irányt az elérhetőség tesztelése előtt tesztelje

Válasszon egy klienscímet, egy VM-címet és egy protokollt. Csatlakozzon a kliensről, és jegyezze fel az eredményt; majd indítsa ugyanezt a tesztet a VM-ről, és azt is jegyezze fel. Ha az első sikerül és a második nem, a klienspool, az átjáró-hozzárendelés és a kliens–VNet útvonal is működik.

A következő lépés a bizonyíték, nem a több szabály. Ellenőrizze a VM alhálózatán az NSG-t mindkét irányban, olvassa ki az effektív útvonalakat a VM NIC-jén, és rögzítsen csomagokat a VM-en, miközben a kliens forgalmat küld. A válasz nélkül érkező kérés szűrő- vagy visszaút-probléma; a soha meg nem érkező kérés útvonalprobléma. Ne tekintse egy sikertelen pinget annak bizonyítékaként, hogy a VM elérhetetlen, mert az ICMP-házirend eldobhatja a választ, miközben a TCP működik.

Az IKEv2 point-to-site visszaút a szokásos gyanúsított

A cikk mögötti Azure-jelentésben egy kliens IKEv2-n keresztül elérte a VM-eket, de a VM-ből a kliens felé menő bejövő ICMP addig hibázott, amíg az átjáró alagúttípusát OpenVPN-re nem állították. A jelentés szerzője szerint a Microsoft megerősített egy korlátot az IKEv2 point-to-site útvonalban: a VM-ből a kliens felé menő visszaforgalom nem útvonalazódik szimmetrikusan, hacsak nem a kliens indította a munkamenetet. Az IKEv2 forgalomszelektorokra támaszkodik, és az átjáró ebben az esetben nem tisztelte a visszirányt.

Ez nem teszi az OpenVPN-t általában jobb alagúttípussá. Ez az alagúttípust változóvá teszi a számítási feladat tesztmátrixában.

Az alagúttípus váltása szolgáltatásváltozás, nem kapcsoló. Minden kliensnek kompatibilis profilra van szüksége, és az átjárónak lehet, hogy más tanúsítványra vagy hitelesítési beállításra van szüksége. Reprodukálja az egyirányú viselkedést egy tesztklienssel és egy teszt VM-mel, változtassa meg a típust jóváhagyott ütemterv szerint, majd ismételje meg ugyanazokat az irányteszteket. Ha a viselkedés túléli a váltást, az alagúttípus nem volt az ok, és a termelés érintése nélkül szűkítette a problémát.

Mítosz: a broadcast-felderítés átlépi a VNet határát

Egy második feltevés független okból bukik meg. Az Azure virtuális hálózata nem szállít broadcast-forgalmat, ezért a VM nem tud broadcast-kereteket fogadni egy helyszíni hálózatról site-to-site vagy point-to-site kapcsolaton keresztül. Azok az alkalmazások, amelyek broadcast útján találják meg a partnereket, például a régebbi fájlböngészés vagy egyes eszközfelderítési protokollok, soha nem fogják látni a távoli oldalt, akárhogyan is íródnak az útvonalak.

Cserélje a broadcast-felderítést DNS-nevekre, címtárszolgáltatásra vagy kifejezett partnerlistára. Ha az alkalmazásnak nincs unicast alternatívája, a tervezésnek más felderítési mechanizmusra van szüksége, nem szélesebb alagútra.

Mit kell változtatni, és hogyan kell bizonyítani

Ha az irányteszt csak IKEv2-n bukik meg, jegyezze fel az átjáró alagúttípusát, a klienscím-poolt és a pontos ICMP- vagy TCP-tesztet, majd értékelje az érintett kliensek jóváhagyott OpenVPN-profilját. Ha minden alagúttípuson megbukik, a visszaúton dolgozzon: a klienscímnek a VM alhálózatából útvonalazhatónak kell lennie, minden felhasználó által definiált útvonalnak érvényes következő ugrásra kell mutatnia, és a kliens tűzfalának el kell fogadnia a bejövő folyamot. Csatolja az NSG- és útvonalbizonyítékokat a jegyhez.

Az alkalmazással ellenőrizze, ne pinggel. Egy sikeres ICMP-csere egy változtatás után semmit nem mond a szolgáltatási portról, annak hitelesítéséről vagy névfeloldásáról. Ismételje meg a tesztet újracsatlakozás után, mert egy másik pool-címet kapó kliens megváltoztathatja az eredményt. Majd ismételje meg még egyszer, miután a kliens elaludt és felébredt, mert az egyirányú viselkedés gyakran a folytatott munkamenetben jelenik meg újra.