Вредност во регистарот за NAT-T во Windows: прво проверете ја топологијата

VPN-врската во Windows не успева, пребарувањето враќа вредност од регистарот и вредноста се внесува заедно со рестартирање. Таа низа понекогаш функционира и никогаш ништо не објаснува. Поставката за која станува збор одговара на едно прашање за тоа каде е серверот во однос на NAT-уред, и таа е бесмислена додека не знаете кој протокол и во која фаза не успеал.

Што всушност избира вредноста

AssumeUDPEncapsulationContextOnSendRule определува дали имплементацијата на IPsec во Windows ќе се обиде да воспостави асоцијации со партнер зад NAT-уред. Документираната стандардна вредност 0 не го дозволува тој случај, 1 го дозволува кога серверот е страната зад NAT, а 2 го покрива случајот кога се преведуваат двата краја. Тоа се тврдења за топологијата — кој каде е.

Читани како низа, броевите опишуваат сѐ повеќе преведување, а не сѐ поголема сигурност. Поставувањето 2 на мрежа каде ништо не се преведува не ја прави врската побрза или постабилна и не поправа неуспех при автентикација. Упатството на Microsoft за NAT при L2TP/IPsec документира политиката и нејзиниот историски контекст на платформата. Проверете го тој контекст наспроти верзијата и улогата на Windows што навистина ги извршувате, бидејќи документ што преживеал неколку изданија не е тврдење за секој тековен build.

Усогласете ја топологијата пред бројот

Нацртајте ја патеката и означете ги точките на преведување: дали клиентот е зад домашен рутер, дали серверот е зад балансер на оптоварување или огнен ѕид што ги препишува адресите, и дали некој крај е зад преведување на операторот што не го контролирате. Само по тој цртеж можете да одлучите дали вредноста се применува и на кој крај.

Тврдењето дека тековните верзии на Windows Server едноставно се испорачуваат со исклучен NAT traversal е премногу широко за да се постапува по него. Важни се политиката на вашиот систем, топологијата пред него и размената што не успеа, по тој редослед. Ако двата краја имаат јавни адреси, поставката не е ваш проблем. Наместо тоа, погледнете го предлогот, сертификатот или сметката и оставете го регистарот на мира.

Прво проверете ја фазата на неуспехот

L2TP/IPsec предизвикува најмалку три различни неуспеси: партнерот е недостапен, заштитата на IPsec не може да се воспостави, и автентикацијата на PPP-корисникот се одбива откако тунелот постои. Одбиена сметка не се поправа со промена на NAT-политиката, а несовпаѓањето на предлозите не се поправа со рестартирање.

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

Истекувањето без одговор укажува на достапност или филтрирање, а не на политика. Брзо одбивање со порака за предлог укажува на алгоритми. Неуспех откако тунелот е подигнат припаѓа на фазата на автентикација, што е друг сопственик и друга поправка.

SSTP преку HTTPS и нативниот IKEv2 имаат свои дневници и свои контроли. Ништо од тоа не станува случај на NAT-traversal само затоа што работат и на Windows.

Направете ја промената со пат за враќање

Ако документираната политика и забележаната топологија и двете го бараат тоа, запишете ја претходната вредност, примените ја промената преку управуваната конфигурација, а не преку скрипта по профил, и планирајте го рестартирањето. На сервер што поддржува други оптоварувања, ова не е безопасно уредување.

NAT-уредот сѐ уште мора да го пренесува инкапсулираниот транспорт и повратниот сообраќај. Вредноста во регистарот не создава правило за препраќање, не усогласува предлози и не проверува идентитет, така што врската што почнува да работи по промената може да работи од сосема друга причина. Повторно тестирајте го оригиналниот протокол со оригиналната топологија, потоа запишете која фаза не успеала и зошто се очекувало вредноста да го реши тоа. Токму таа реченица го претвора интернет-гласината во конфигурација што можете да ја браните.