Windowsin NAT-T-rekisteriarvo: tarkista topologia ensin

Windowsin VPN-yhteys epäonnistuu, haku palauttaa rekisteriarvon ja arvo syötetään uudelleenkäynnistyksen kanssa. Tämä järjestys joskus toimii eikä koskaan selitä mitään. Kyseinen asetus vastaa yhteen kysymykseen siitä, missä palvelin on suhteessa NAT-laitteeseen, ja se on merkityksetön, kunnes tiedät, mikä protokolla ja missä vaiheessa epäonnistui.

Mitä arvo itse asiassa valitsee

AssumeUDPEncapsulationContextOnSendRule määrittää, yrittääkö Windowsin IPsec-toteutus muodostaa assosiaatioita NAT-laitteen takana olevan vastapuolen kanssa. Dokumentoitu oletusarvo 0 ei salli tätä tapausta, 1 sallii sen, kun palvelin on NATin takana oleva puoli, ja 2 kattaa molempien päiden käännön. Ne ovat topologiaväitteitä siitä, kuka on missä.

Jaksona luettuna numerot kuvaavat yhä enemmän käännöstä, eivät yhä suurempaa luotettavuutta. Arvon 2 asettaminen verkossa, jossa mitään ei käännetä, ei tee yhteydestä nopeampaa tai vakaampaa eikä korjaa todennusvirhettä. Microsoftin NAT-ohje L2TP/IPsecille dokumentoi käytännön ja sen historiallisen alustaympäristön. Vertaa tätä ympäristöä Windows-versioon ja rooliin, jota todella käytät, sillä useita julkaisuja selvinnyt asiakirja ei ole väite jokaisesta nykyisestä koontiversiosta.

Sovita topologia ennen numeroa

Piirrä polku ja merkitse käännöspisteet: onko asiakas kotireitittimen takana, onko palvelin kuormantasaimen tai osoitteita uudelleenkirjoittavan palomuurin takana, ja onko jompikumpi pää sellaisen operaattorin käännöksen takana, jota et hallitse. Vasta piirroksen jälkeen voit päättää, soveltuuko arvo ja kummalle päälle.

Väite, että nykyiset Windows Server -versiot yksinkertaisesti toimitetaan NAT-läpäisy poistettuna käytöstä, on liian laaja toimenpiteiden perustaksi. Ratkaisevaa on järjestelmäsi käytäntö, sen edessä oleva topologia ja epäonnistunut vaihto, tässä järjestyksessä. Jos molemmilla päillä on julkiset osoitteet, asetus ei ole ongelmasi. Katso sen sijaan ehdotusta, varmennetta tai tiliä ja jätä rekisteri rauhaan.

Tarkista ensin epäonnistumisen vaihe

L2TP/IPsec tuottaa vähintään kolme erilaista epäonnistumista: vastapuoli ei ole tavoitettavissa, IPsec-suojausta ei voi muodostaa ja PPP-käyttäjän todennus hylätään, kun tunneli on olemassa. Hylättyä tiliä ei korjata NAT-käytäntöä muuttamalla, eikä ehdotusten ristiriitaa korjata uudelleenkäynnistyksellä.

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

Vastaajaton aikakatkaisu viittaa tavoitettavuuteen tai suodatukseen eikä käytäntöön. Nopea hylkäys ehdotusviestillä viittaa algoritmeihin. Tunnelin pystytyksen jälkeinen epäonnistuminen kuuluu todennusvaiheeseen, joka on eri omistaja ja eri korjaus.

SSTP HTTPS:n yli ja natiivi IKEv2 ovat omia lokejaan ja omia kontrollejaan. Mikään niistä ei muutu NAT-läpäisytapaukseksi vain siksi, että nekin toimivat Windowsissa.

Tee muutos paluutie mukana

Jos dokumentoitu käytäntö ja havaittu topologia molemmat sitä vaativat, kirjaa edellinen arvo, käytä muutos hallitun konfiguraation kautta eikä profiilikohtaisella skriptillä ja suunnittele uudelleenkäynnistys. Palvelimella, joka tukee muita työkuormia, tämä ei ole vaaraton muokkaus.

NAT-laitteen on edelleen kuljetettava kapseloitu liikenne ja paluuliikenne. Rekisteriarvo ei luo välityssääntöä, kohdista ehdotuksia eikä validoi identiteettiä, joten yhteys, joka alkaa toimia muutoksen jälkeen, voi toimia täysin eri syystä. Testaa alkuperäinen protokolla alkuperäisellä topologialla ja kirjoita sitten, mikä vaihe epäonnistui ja miksi arvon odotettiin ratkaisevan sen. Juuri tuo lause muuttaa internet-huhun konfiguraatioksi, jota voit puolustaa.