Windows NAT-T beállításjegyzék-érték: először a topológiát ellenőrizze

Egy Windows VPN-kapcsolat meghiúsul, egy keresés egy beállításjegyzék-értéket ad vissza, és az érték újraindítással bekerül. Ez a sorrend néha működik, és soha nem magyaráz meg semmit. A szóban forgó beállítás egyetlen kérdésre válaszol: hol helyezkedik el a kiszolgáló egy NAT-eszközhöz képest, és addig értelmetlen, amíg nem tudja, melyik protokoll és melyik szakaszban hibázott.

Mit választ valójában az érték

Az AssumeUDPEncapsulationContextOnSendRule meghatározza, hogy egy Windows IPsec-megvalósítás megkísérel-e társulásokat létrehozni egy NAT-eszköz mögötti partnerrel. A dokumentált 0 alapérték nem engedi ezt az esetet, az 1 engedi, ha a kiszolgáló a NAT mögötti oldal, a 2 pedig lefedi mindkét vég lefordítását. Ezek topológiára vonatkozó kijelentések arról, ki hol van.

Sorként olvasva a számok egyre több fordítást írnak le, nem egyre nagyobb megbízhatóságot. A 2 beállítása olyan hálózaton, ahol semmit nem fordítanak le, nem teszi gyorsabbá vagy stabilabbá a kapcsolatot, és nem javít hitelesítési hibát. A Microsoft NAT-útmutatója az L2TP/IPsec-hez dokumentálja a szabályzatot és annak történelmi platformkontextusát. Hasonlítsa össze ezt a kontextust azzal a Windows-verzióval és -szerepkörrel, amelyet ténylegesen futtat, mert egy több kiadást túlélt dokumentum nem állítás minden jelenlegi buildről.

A topológiát a szám előtt egyeztesse

Rajzolja fel az útvonalat, és jelölje meg a fordítási pontokat: az ügyfél otthoni router mögött van-e, a kiszolgáló terheléselosztó vagy címeket átíró tűzfal mögött van-e, és valamelyik vég az Ön által nem ellenőrzött szolgáltatói fordítás mögött van-e. Csak a rajz után döntheti el, hogy az érték érvényes-e, és melyik végre.

Az az állítás, hogy a jelenlegi Windows Server-verziók egyszerűen kikapcsolt NAT-traversal mellett érkeznek, túl tág ahhoz, hogy cselekedni lehessen rá. Az számít, hogy mi a szabályzat a rendszerén, milyen topológia van előtte, és melyik csere hibázott, ebben a sorrendben. Ha mindkét vég nyilvános címmel rendelkezik, a beállítás nem az Ön problémája. Nézze inkább az ajánlatot, a tanúsítványt vagy a fiókot, és hagyja békén a beállításjegyzéket.

Először a hiba szakaszát ellenőrizze

L2TP/IPsec legalább három különböző hibát produkál: a partner nem érhető el, az IPsec-védelem nem hozható létre, és a PPP-felhasználó hitelesítése az alagút létrejötte után elutasításra kerül. Az elutasított fiókot nem javítja a NAT-szabályzat módosítása, és az ajánlatok eltérését nem javítja az újraindítás.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

A válaszadó nélküli időtúllépés inkább elérhetőségre vagy szűrésre utal, mint szabályzatra. Az ajánlatüzenettel járó gyors elutasítás algoritmusokra mutat. Az alagút felállása utáni hiba a hitelesítési szakaszhoz tartozik, ami más tulajdonos és más javítás.

A HTTPS feletti SSTP és a natív IKEv2 saját naplókkal és saját vezérlésekkel rendelkezik. Egyik sem válik NAT-traversal esetté csak azért, mert Windows alatt is fut.

Végezze el a módosítást visszaúttal

Ha a dokumentált szabályzat és a megfigyelt topológia is ezt kívánja, jegyezze fel az előző értéket, a módosítást a felügyelt konfiguráción keresztül alkalmazza, ne profilonkénti szkripttel, és tervezze meg az újraindítást. Olyan kiszolgálón, amely más számítási feladatokat is kiszolgál, ez nem ártalmatlan szerkesztés.

A NAT-eszköznek továbbra is tovább kell vinnie a beburkolt forgalmat és a visszforgalmat. Egy beállításjegyzék-érték nem hoz létre továbbítási szabályt, nem igazít ajánlatokat és nem hitelesít identitást, ezért a módosítás után működni kezdő kapcsolat teljesen más okból is működhet. Tesztelje újra az eredeti protokollt az eredeti topológiával, majd írja le, melyik szakasz hibázott, és miért várták, hogy az érték azt kezelje. Ez a mondat az, ami egy internetes pletykából védhető konfigurációt csinál.