Azure helyek közötti VPN NAT mögötti partnerrel: ellenőrzőlista

Végezze el ezeket az ellenőrzéseket sorrendben, és álljon meg az elsőnél, amelyik elbukik. A legtöbb jelentés arról, hogy az Azure nem támogat egy NAT mögötti eszközt, valójában olyan partnercím, amelyet az Azure nem ér el, vagy olyan alagút, amely soha nem a megfelelő oldalról indul. A külső szállítás és a belső útválasztás két különböző probléma, és összekeverésük egy délutánt visz el. Az alábbi lépések mindegyike olyan megfigyelést ad, amelyet átadhat valaki másnak.

1. lépés: erősítse meg, hogy a partner egyáltalán NAT mögött van

Hasonlítsa össze az eszköz WAN-interfészén lévő címet azzal a címmel, amelyet az Azure lát hozzá. Ha eltérnek, valami fordít, és az a fordító mostantól a VPN-terv része. Kérdezze meg a szolgáltatót, hogy a leképezés statikus vagy megosztott, mert a megosztott leképezés megváltoztatja, mire támaszkodhat. Egy privát WAN-címmel rendelkező, továbbítás nélküli eszköz más eset, mint egy szolgáltatói szintű NAT mögötti eszköz stabil nyilvános leképezéssel.

Ha a két cím megegyezik, álljon meg itt: a NAT nem az ön problémája, és a lista többi része nem segít.

Jegyezze fel mindkét címet és a fordító modelljét a jegybe. Az az egy sor megelőzi a következő kérdéskört arról, miért nem válaszol a beállított partner.

2. lépés: egyezzenek meg abban, ki kezdeményez

Az Azure VPN Gateway GYIK említi a NAT-T támogatását, és hozzáteszi, hogy a helyszíni eszköznek kell kezdeményeznie az IPsec-alagutat, ha NAT mögött van. Ez megfelel annak, hogyan működik az állapotot követő fordítás, mivel a fordító azért tart leképezést, mert a belső eszköz küldte az első csomagot. Ha az Azure-tól várják a kezdeményezést, és semmi nem érkezik, ami létrehozná azt a leképezést, az alagút soha nem indul el.

Állítsa be a partnert úgy, hogy a csak-válaszoló hiba nyilvánvaló legyen, és ellenőrizze, hogy az eszköz magától újrapróbál-e, vagy indítójelre van szüksége. Egyes eszközök csak akkor építenek alagutat, amikor érdekes forgalom jelenik meg, ami addig rendben van, amíg az érdekes forgalom egy soha meg nem érkező állapotpróba.

Figyelje az IKE-cserét az eszközön kézi kezdeményezés közben; a csend ott útválasztási vagy tűzfalválasz, nem Azure-válasz.

3. lépés: a partner címe legyen helyes

Az Azure-nak elérhető nyilvános címre van szüksége a partnerhez a helyi hálózati átjáró objektumában, általában a fordító nyilvános címére, nem az eszköz belső címére. Az az azonosság, amellyel az eszköz hitelesíti magát, külön mező, és jogosan eltérhet attól a címtől, amelyet az Azure tárcsáz. Tartsa külön a kettőt, mert felcserélésük olyan hitelesítési hibát okoz, amely pontosan NAT-problémának látszik.

Ha a nyilvános cím megváltozik, annak az objektumnak is változnia kell vele. Egy elavult címre feloldódó név rosszabb, mint egy statikus cím, amelyet kézzel kell frissítenie.

Jegyezze fel mindhárom értéket: az eszköz helyi címét, a lefordított nyilvános címet és a beállított partnerazonosságot.

4. lépés: csak a NAT-T által igényelt portokat nyissa meg

A NAT-T az ESP-t UDP-n belül szállítja, és az RFC 3948 írja le ezt a beágyazást a 4500-as porttal, amelyet az 500-as porton folytatott kezdeti egyeztetés után használnak. A tűzfalnak és a fordítónak is engedélyeznie kell a cserét és annak visszaforgalmát. Egy nem kapcsolódó TCP-port engedélyezése semmit nem bizonyít erről az útvonalról, és a kimenő forgalmat engedélyező, de a választ nem engedő szabály továbbra is elbukik.

Statikus bejövő porttovábbítás nem feltétlenül szükséges, amikor a partner kezdeményez, és a fordító állapotot tart. Akkor válik szükségessé, ha a leképezés instabil, vagy ha valami az útvonalon agresszíven lejáratja az állapotot.

Rögzítsen egyszer a fordító mindkét oldalán; a beágyazás különbsége azonnal látható.

5. lépés: válassza külön a külső szállítást a belső útválasztástól

Az az alagút, amely létrejön és semmit nem szállít, útválasztási probléma, nem NAT-T-probléma. A helyeknek továbbra is szükségük van kompatibilis forgalomválasztókra, egyező címterekre, hozzáférési szabályokra és visszaútra az alkalmazáshálózatokhoz. Ezek egyikét sem biztosítja egy sikeres IKE-csere.

Ha a két hely átfedő privát tartományokat használ, az alagúton belüli fordítás külön terv a saját szabályaival. Ne számozza át az alhálózatot csak azért, mert a külső átjáró éppen egy otthoni router mögött van.

Mielőtt bármit módosítana, sorolja be a hibát szakasz szerint, és tartsa meg ezt a besorolást a jegyben, hogy a következő ember ott kezdje, ahol ön abbahagyta.