Ръкостискане има, интернет няма: какво да оправите първо на Windows 11

Ръкостискането доказва само, че UDP обменът е минал. Определете кой слой е отказал: маршрутът, който Windows е задал, resolver-ът, който използва, или изходът.

Свежите ръкостискания често стоят до браузъри, които не отварят нищо, на Windows 11. Ръкостискането доказва само, че UDP обменът с партньора е завършил. То не казва нищо за маршрута, който Windows е задал, за resolver-а, който използва, нито за това дали изходът препраща нещо.

Четири условия решават кой от тези слоеве е отказал. Преминаването им по ред отнема минути, докато пренаписването на ключове отнема повече време и не променя нищо.

Определете слоя, преди да пипате ключовете

Минете през три дестинации в тази последователност. Започнете с адрес от страната на тунела, после публичен IP като число и завършете с име на хост. Там, където последователността се скъса, се вижда слоят. Отказ на първата стъпка е маршрутизация, на втората е препращане или NAT, а на третата е разрешаване на имена.

Тази подредба е целият метод. Тя пречи DNS дефект да бъде диагностициран като счупен тунел, което е най-честият грешен завой тук.

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

Ако времето на ръкостискането е празно

Когато времето на ръкостискането е празно, криптираният обмен така и не е завършил. Затова дефектът стои по-рано от маршрутизацията. Погледнете първо адреса на крайната точка и порта, после дали мрежата филтрира UDP. Хостинг доставчик, който изхвърля трафик на WireGuard, дава точно това, и също клиент, който е копирал крайна точка от стар профил.

Байтове, които излизат, без да влизат, са друг случай. Това сочи към NAT или защитна стена, която връща трафика на грешното място.

Ако маршрутът губи от физическия адаптер

За пълен тунел секцията за партньора трябва да покрива дестинациите, които очаквате да ползвате. Windows понякога запазва маршрута по подразбиране на физическия адаптер дори при зададено правило за всичко. Разделянето на правилото за всичко на 0.0.0.0/1 плюс 128.0.0.0/1 създава два по-конкретни префикса, които печелят търсенето. Разделянето е документиран заобиколен подход, а не предпочитание.

Потвърдете с route print или със заявка за публичен адрес. Избраният интерфейс трябва да е тунелният адаптер. Ако физическият още печели, оправете диапазоните за партньора, преди да пипате сървъра.

Ако адресите работят, а имената не

WireGuard пренася IP пакети и няма мнение за DNS. Сложете ред DNS = в секцията за интерфейса или задайте адаптера през Windows. Без него ping по адрес минава, докато всяко име на хост се проваля, и потребителите го докладват като липса на интернет.

Проверете кои сървъри Windows наистина използва след свързване. Останал resolver на физическия адаптер обяснява частичен отказ, при който някои имена се разрешават, а други не. Изчистете го, вместо да добавяте втори отгоре.

Ако машината с Windows е изходът

Internet Connection Sharing пренаписва адресирането, когато е включен, което може да премести споделения адаптер в друг диапазон. Клиент, който още сочи към първоначалния адрес, спира да работи. Стойностите в регистъра ScopeAddress и StandaloneDHCPAddress управляват този диапазон и настройката може да се върне след рестарт.

Два други конфликта, специфични за Windows, заслужават поглед. Услугата Routing and Remote Access може да пречи на тунела. Инсталатор, създаден за грешна архитектура, се проваля със съобщение, което никога не споменава архитектура.

Оправете слоя, който тестът посочи, после повторете същите три дестинации. Промяна, която оправя теста с името на хоста, но чупи адреса на тунела, е приложена към грешния слой.

Подобни статии