Wartość rejestru NAT-T w Windows: najpierw topologia

Połączenie VPN w Windows zawodzi, wyszukiwanie zwraca wartość rejestru, a wartość zostaje wpisana wraz z ponownym uruchomieniem. Ta sekwencja czasem działa i nigdy niczego nie wyjaśnia. Omawiane ustawienie odpowiada na jedno pytanie o to, gdzie serwer znajduje się względem urządzenia NAT, i jest bez znaczenia, dopóki nie wiesz, który protokół i na jakim etapie zawiódł.

Co wartość faktycznie wybiera

AssumeUDPEncapsulationContextOnSendRule określa, czy implementacja IPsec w Windows spróbuje utworzyć asocjacje z partnerem za urządzeniem NAT. Udokumentowana wartość domyślna 0 nie pozwala na ten przypadek, 1 pozwala, gdy serwer jest stroną za NAT, a 2 obejmuje tłumaczenie obu końców. To stwierdzenia o topologii — kto jest gdzie.

Czytane jako sekwencja liczby opisują coraz więcej tłumaczenia, a nie coraz większą niezawodność. Ustawienie 2 w sieci, w której nic nie jest tłumaczone, nie przyspiesza ani nie stabilizuje połączenia i nie naprawia błędu uwierzytelniania. Przewodnik Microsoftu dotyczący NAT dla L2TP/IPsec dokumentuje zasady i ich historyczny kontekst platformy. Porównaj ten kontekst z wersją i rolą Windows, które rzeczywiście uruchamiasz, ponieważ dokument, który przetrwał kilka wydań, nie jest stwierdzeniem o każdej bieżącej kompilacji.

Dopasuj topologię przed numerem

Narysuj ścieżkę i zaznacz punkty tłumaczenia: czy klient jest za routerem domowym, czy serwer jest za modułem równoważenia obciążenia albo zaporą przepisującą adresy, i czy któryś koniec jest za tłumaczeniem operatora, którego nie kontrolujesz. Dopiero po tym rysunku możesz zdecydować, czy wartość ma zastosowanie i do którego końca.

Twierdzenie, że obecne wersje Windows Server są po prostu dostarczane z wyłączonym NAT traversal, jest zbyt szerokie, by na nim działać. Liczy się zasada w twoim systemie, topologia przed nim i wymiana, która zawiodła, w tej kolejności. Jeśli oba końce mają adresy publiczne, ustawienie nie jest twoim problemem. Zamiast tego spójrz na propozycję, certyfikat lub konto, a rejestr zostaw w spokoju.

Najpierw sprawdź etap awarii

L2TP/IPsec powoduje co najmniej trzy różne awarie: partner jest nieosiągalny, nie można ustanowić ochrony IPsec, a uwierzytelnianie użytkownika PPP jest odrzucane po powstaniu tunelu. Odrzuconego konta nie naprawia się zmianą zasad NAT, a niezgodności propozycji nie naprawia się ponownym uruchomieniem.

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

Limit czasu bez odpowiadającego wskazuje na osiągalność lub filtrowanie, a nie na zasady. Szybkie odrzucenie z komunikatem o propozycji wskazuje na algorytmy. Awaria po podniesieniu tunelu należy do etapu uwierzytelniania, czyli innego właściciela i innego rozwiązania.

SSTP przez HTTPS i natywny IKEv2 mają własne dzienniki i własne mechanizmy kontroli. Nic z tego nie staje się przypadkiem NAT traversal tylko dlatego, że działa również w Windows.

Wprowadź zmianę z drogą powrotną

Jeśli udokumentowane zasady i zaobserwowana topologia oba tego wymagają, zapisz poprzednią wartość, zastosuj zmianę przez konfigurację zarządzaną, a nie skrypt dla każdego profilu, i zaplanuj ponowne uruchomienie. Na serwerze obsługującym inne obciążenia to nie jest nieszkodliwa edycja.

Urządzenie NAT nadal musi przenosić kapsułkowany transport i ruch powrotny. Wartość rejestru nie tworzy reguły przekazywania, nie wyrównuje propozycji i nie weryfikuje tożsamości, więc połączenie, które zaczyna działać po zmianie, może działać z zupełnie innego powodu. Przetestuj ponownie oryginalny protokół z oryginalną topologią, a następnie zapisz, który etap zawiódł i dlaczego oczekiwano, że wartość to rozwiąże. To zdanie zamienia plotkę z internetu w konfigurację, której możesz bronić.