Handshake działa, internet nie: co naprawić najpierw w Windows 11

Handshake dowodzi tylko, że wymiana UDP się udała. Ustal, która warstwa zawiodła: trasa wstawiona przez Windows, używany resolver czy wyjście.

W Windows 11 świeże handshaki często stoją obok przeglądarek, które nic nie otwierają. Handshake dowodzi tylko, że wymiana UDP z peerem się zakończyła. Nie mówi nic o trasie wstawionej przez Windows, o używanym resolverze ani o tym, czy wyjście cokolwiek przekazuje.

Cztery warunki decydują, która z tych warstw zawiodła. Przejście ich po kolei zajmuje minuty, a przepisywanie kluczy trwa dłużej i niczego nie zmienia.

Ustal warstwę, zanim dotkniesz kluczy

Przejdź trzy cele w tej kolejności. Zacznij od adresu po stronie tunelu, potem publiczny IP jako liczba, a na końcu nazwa hosta. Tam, gdzie łańcuch się urywa, tam nazywa się warstwę. Niepowodzenie w pierwszym kroku to routing, w drugim przekazywanie lub NAT, a w trzecim rozwiązywanie nazw.

Ta kolejność to cała metoda. Powstrzymuje diagnozowanie awarii DNS jako zepsutego tunelu, co jest tutaj najczęstszym błędnym krokiem.

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

Jeśli czas handshake jest pusty

Gdy czas handshake jest pusty, szyfrowana wymiana nigdy się nie zakończyła. Awaria leży więc wcześniej niż routing. Najpierw sprawdź adres punktu końcowego i port, potem to, czy sieć filtruje UDP. Dostawca hostingu, który wyrzuca ruch WireGuard, daje dokładnie to, podobnie klient, który skopiował punkt końcowy ze starego profilu.

Bajty wychodzące bez żadnego wchodzącego to inny przypadek. Wskazuje to na NAT albo zaporę, która odsyła ruch w złe miejsce.

Jeśli trasa przegrywa z adapterem fizycznym

Dla pełnego tunelu sekcja peera musi obejmować cele, których zamierzasz używać. Windows czasem zachowuje domyślną trasę adaptera fizycznego nawet przy ustawionej regule obejmującej wszystko. Podział reguły obejmującej wszystko na 0.0.0.0/1 plus 128.0.0.0/1 tworzy dwa bardziej konkretne prefiksy, które wygrywają wyszukiwanie. Podział jest udokumentowanym obejściem, nie preferencją.

Potwierdź to przez route print albo wyszukanie publicznego adresu. Wybrany interfejs powinien być adapterem tunelu. Jeśli fizyczny nadal wygrywa, popraw zakresy peera, zanim dotkniesz serwera.

Jeśli adresy działają, a nazwy zawodzą

WireGuard przenosi pakiety IP i nie ma zdania o DNS. Wstaw linię DNS = w sekcji interfejsu albo ustaw adapter przez Windows. Bez niej ping po adresie się udaje, a każda nazwa hosta zawodzi, i użytkownicy zgłaszają to jako brak internetu.

Sprawdź, których serwerów Windows naprawdę używa po połączeniu. Pozostały resolver na adapterze fizycznym wyjaśnia częściową awarię, gdy część nazw się rozwiązuje, a część nie. Wyczyść go, zamiast dodawać drugi na wierzchu.

Jeśli maszyna z Windows jest wyjściem

Internet Connection Sharing przepisuje adresację, gdy jest włączony, co może przenieść udostępniany adapter do innego zakresu. Klient, który nadal wskazuje pierwotny adres, przestaje wtedy działać. Wartości rejestru ScopeAddress i StandaloneDHCPAddress kontrolują ten zakres, a ustawienie może wrócić po restarcie.

Warto spojrzeć na dwa inne konflikty typowe dla Windows. Usługa Routing and Remote Access może przeszkadzać tunelowi. Instalator zbudowany dla złej architektury zawodzi z komunikatem, który nigdy nie wspomina architektury.

Napraw warstwę wskazaną przez test, a potem uruchom ponownie te same trzy cele. Zmiana, która naprawia test nazwy hosta, ale psuje adres tunelu, została zastosowana do złej warstwy.

Powiązane artykuły