Windows NAT-T registra valoro: unue kontrolu la topologion

Windows VPN-konekto malsukcesas, serĉo liveras registran valoron, kaj la valoro enmetiĝas kune kun restarto. Tiu sinsekvo foje funkcias kaj neniam klarigas ion. La koncerna agordo respondas al unu demando pri tio, kie la servilo staras rilate al NAT-aparato, kaj ĝi estas sensignifa ĝis vi scias, kiu protokolo malsukcesis kaj en kiu fazo.

Kion la valoro efektive elektas

AssumeUDPEncapsulationContextOnSendRule decidas, ĉu Windows IPsec-realigo provos establi asociojn kun samtavolano malantaŭ NAT-aparato. La dokumentita defaŭlto 0 ne permesas tiun kazon, 1 permesas ĝin kiam la servilo estas la flanko malantaŭ NAT, kaj 2 kovras tradukadon de ambaŭ finoj. Tiuj estas topologiaj asertoj pri tio, kiu estas kie.

Legitaj kiel sinsekvo, la nombroj priskribas ĉiam pli da tradukado, ne ĉiam pli da fidindeco. Agordi 2 en reto, kie nenio tradukiĝas, ne faras la konekton pli rapida aŭ pli stabila, kaj ĝi ne riparas aŭtentikigan malsukceson. La gvidilo de Microsoft pri NAT por L2TP/IPsec dokumentas la politikon kaj ĝian historian platforman kuntekston. Komparu tiun kuntekston kun la Windows-versio kaj rolo, kiujn vi efektive uzas, ĉar dokumento, kiu travivis plurajn eldonojn, ne estas aserto pri ĉiu nuna konstruo.

Unue akordigu la topologion, poste la nombron

Desegnu la vojon kaj marku la tradukajn punktojn: ĉu la kliento estas malantaŭ hejma enkursigilo, ĉu la servilo estas malantaŭ ŝarĝbalancilo aŭ fajroŝirmilo, kiu reskribas adresojn, kaj ĉu iu fino staras malantaŭ tradukado de la operatoro, kiun vi ne kontrolas. Nur post tiu desegnaĵo vi povas decidi, ĉu la valoro aplikiĝas, kaj al kiu fino.

La aserto, ke nunaj Windows Server-versioj simple liveriĝas kun malŝaltita NAT-traversal, estas tro vasta por agi laŭ ĝi. Gravas la politiko en via sistemo, la topologio antaŭ ĝi kaj la interŝanĝo, kiu malsukcesis, en tiu ordo. Se ambaŭ finoj havas publikajn adresojn, la agordo ne estas via problemo. Rigardu anstataŭe la proponon, la atestilon aŭ la konton, kaj lasu la registron trankvila.

Unue kontrolu la malsukcesan fazon

L2TP/IPsec produktas almenaŭ tri malsamajn malsukcesojn: la samtavolano neatingeblas, IPsec-protektado ne povas esti establita, kaj la PPP-uzanta aŭtentikigo malakceptiĝas post kiam la tunelo ekzistas. Malakceptitan konton oni ne riparas per ŝanĝo de NAT-politiko, kaj proponan malkongruon oni ne riparas per restarto.

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

Tempolimo sen respondanto sugestas atingeblon aŭ filtradon prefere ol politikon. Rapida malakcepto kun propona mesaĝo indikas algoritmojn. Malsukceso post kiam la tunelo staras apartenas al la aŭtentikiga fazo, kiu estas alia posedanto kaj alia riparo.

SSTP super HTTPS kaj denaska IKEv2 havas siajn proprajn protokolojn kaj siajn proprajn kontrolojn. Neniu el ili fariĝas NAT-traversal kazo nur ĉar ili ankaŭ funkcias en Windows.

Faru la ŝanĝon kun revena vojo

Se la dokumentita politiko kaj la observata topologio ambaŭ postulas tion, notu la antaŭan valoron, apliku la ŝanĝon per la administrata agordo anstataŭ per skripto por ĉiu profilo, kaj planu la restartadon. Sur servilo subtenanta aliajn laborŝarĝojn tio ne estas sendanĝera redakto.

La NAT-aparato ankoraŭ devas porti la enkapsuligitan transporton kaj la revenan trafikon. Registra valoro kreas neniun plusendan regulon, akordigas neniujn proponojn kaj validigas neniun identecon, do konekto, kiu ekfunkcias post la ŝanĝo, povas funkcii pro tute alia kaŭzo. Retestu la originan protokolon kun la origina topologio, poste notu, kiu fazo malsukcesis kaj kial oni atendis, ke la valoro solvos tion. Tiu frazo estas tio, kio igas interretan onidiron defendebla agordo.