Vlera e regjistrit NAT-T në Windows: së pari kontrolloni topologjinë

Një lidhje VPN në Windows dështon, një kërkim kthen një vlerë regjistri dhe vlera futet bashkë me një rindezje. Ai sekuencë ndonjëherë funksionon dhe nuk shpjegon kurrë asgjë. Cilësimi në fjalë i përgjigjet një pyetjeje për vendndodhjen e serverit në raport me një pajisje NAT dhe është i pakuptimtë derisa të dini cili protokoll dështoi dhe në cilën fazë.

Çfarë zgjedh në të vërtetë vlera

AssumeUDPEncapsulationContextOnSendRule përcakton nëse një implementim IPsec i Windows do të përpiqet të krijojë asociacione me një palë pas një pajisjeje NAT. Vlera e paracaktuar e dokumentuar 0 nuk e lejon atë rast, 1 e lejon kur serveri është ana pas NAT, dhe 2 mbulon përkthimin e të dy skajeve. Këto janë deklarata topologjie për kush është ku.

Të lexuara si sekuencë, numrat përshkruajnë gjithnjë e më shumë përkthim, jo gjithnjë e më shumë besueshmëri. Vendosja e 2 në një rrjet ku asgjë nuk përkthehet nuk e bën lidhjen më të shpejtë ose më të qëndrueshme dhe nuk e rregullon një dështim vërtetimi. Udhëzuesi i NAT i Microsoft për L2TP/IPsec dokumenton politikën dhe kontekstin e saj historik të platformës. Krahasoni atë kontekst me versionin dhe rolin e Windows që ekzekutoni në të vërtetë, sepse një dokument që ka mbijetuar disa versione nuk është deklaratë për çdo ndërtim aktual.

Përputhni topologjinë para numrit

Vizatoni rrugën dhe shënoni pikat e përkthimit: a është klienti pas një ruteri shtëpiak, a është serveri pas një balancuesi ngarkese ose një muri zjarri që rishkruan adresat, dhe a është njëri skaj pas një përkthimi të operatorit që ju nuk e kontrolloni. Vetëm pas atij vizatimi mund të vendosni nëse vlera zbatohet dhe për cilin skaj.

Pohimi se versionet aktuale të Windows Server thjesht vijnë me NAT traversal të çaktivizuar është shumë i gjerë për të vepruar sipas tij. Rëndësi ka politika në sistemin tuaj, topologjia përpara tij dhe shkëmbimi që dështoi, në këtë rend. Nëse të dy skajet kanë adresa publike, cilësimi nuk është problemi juaj. Shikoni propozimin, certifikatën ose llogarinë dhe lëreni regjistrin në paqe.

Kontrolloni së pari fazën e dështimit

L2TP/IPsec prodhon të paktën tre dështime të ndryshme: pala nuk është e arritshme, mbrojtja IPsec nuk mund të vendoset, dhe vërtetimi i përdoruesit PPP refuzohet pasi tuneli ekziston. Një llogari e refuzuar nuk rregullohet duke ndryshuar politikën NAT, dhe një mospërputhje propozimesh nuk rregullohet me rindezje.

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

Kohëmbarimi pa përgjigjës sugjeron arritshmëri ose filtrim dhe jo politikë. Një refuzim i shpejtë me mesazh propozimi tregon algoritmet. Një dështim pas ngritjes së tunelit i përket fazës së vërtetimit, që është një pronar tjetër dhe një zgjidhje tjetër.

SSTP mbi HTTPS dhe IKEv2 nativ kanë regjistrat e tyre dhe kontrollet e tyre. Asgjë prej tyre nuk bëhet rast NAT-traversal vetëm sepse funksionon edhe në Windows.

Bëni ndryshimin me një rrugë kthimi

Nëse politika e dokumentuar dhe topologjia e vëzhguar të dyja e kërkojnë, shënoni vlerën e mëparshme, zbatoni ndryshimin përmes konfigurimit të menaxhuar dhe jo me skript për çdo profil, dhe planifikoni rindezjen. Në një server që mbështet ngarkesa të tjera pune, ky nuk është një redaktim i pafajshëm.

Pajisja NAT ende duhet të mbajë transportin e enkapsuluar dhe trafikun e kthimit. Një vlerë regjistri nuk krijon asnjë rregull përcjelljeje, nuk rreshton asnjë propozim dhe nuk vërteton asnjë identitet, kështu që një lidhje që fillon të funksionojë pas ndryshimit mund të funksionojë për një arsye krejt tjetër. Ritestoni protokollin origjinal me topologjinë origjinale, pastaj shkruani cila fazë dështoi dhe pse pritej që vlera ta zgjidhte atë. Ajo fjali është ajo që e kthen një thashethem interneti në një konfigurim që mund ta mbrosh.