WireGuard może mieć świeży handshake i jednocześnie nie mieć adresu, a ten stan jest spójny, nie sprzeczny. Handshake jest zdarzeniem peera, adres należy do interfejsu, a trasa decyduje, którym łączem wyjściowym pakiet opuszcza host. Trzy warstwy, trzej właściciele, i każda z nich może zawieść, gdy pozostałe dwie wyglądają zdrowo.

Czytanie ich jako jednego statusu to właśnie to, co zamienia dwuminutową diagnozę w całe popołudnie restartowania usług.

Handshake to zdarzenie peera, a nie zdarzenie adresowania

Handshake WireGuard dowodzi, że skonfigurowany peer odpowiedział ważnym kluczem i że klucze sesji są aktualne. Nie mówi nic o adresie lokalnym interfejsu ani o tym, czy jakakolwiek trasa tam prowadzi. Adres przydziela pomocnik albo menedżer sieci, podczas gdy konfiguracja protokołu jedynie nazywa peery i klucze. Mylenie tych dwóch rzeczy sprawia, że zdrowy handshake czyta się jako działający tunel.

Dlatego wg show może zgłosić handshake sprzed kilku sekund na interfejsie, który nie przyjmie ani jednego pakietu od aplikacji.

Menedżer, który odtwarza interfejs, może zgubić adres, nie dotykając konfiguracji peera, a następny handshake udaje się natychmiast, bo klucze nigdy się nie zmieniły. Wiersz logu o udanym handshake jest dokładny i nieistotny dla awarii.

ObservationWhich layer it belongs toWrong conclusion it invites
Handshake a few seconds oldPeer and keysThe tunnel is usable for application traffic
Address present on wg0Interface configurationTraffic actually egresses through it
Route points at wg0Forwarding tableThe outer packet uses the intended uplink

Adres interfejsu ma własnego właściciela

Adres na urządzeniu tunelowym może pochodzić z wiersza Address pomocnika, od klienta DHCP działającego na interfejsie albo od demona zarządzającego, który tworzy go przy połączeniu. Cokolwiek to jest, ten składnik posiada adres i przywróci go albo nie według własnej logiki. Czytanie adresu bez nazwania jego właściciela zostawia cię bez wyjaśnienia, dlaczego zniknął.

Dwaj właściciele na jednym interfejsie to klasyczna awaria. Uruchomienie pomocnika i menedżera sieci pulpitu na tym samym urządzeniu tworzy wyścig, w którym jeden usuwa to, co drugi właśnie skonfigurował, a punkt końcowy przez cały czas odpowiada.

Wybierz jednego właściciela i pozwól drugiemu narzędziu obserwować, a nie zarządzać. Warto zapisać tę decyzję, bo objaw pojawia się tygodnie później i wygląda jak przypadkowa utrata adresu.

Trasa wybiera łącze wyjściowe, nie interfejs

Trasa wewnętrzna wskazująca na wg0 decyduje, że ruch wchodzi do tunelu. Osobna decyzja wysyła zaszyfrowane pakiety zewnętrzne w stronę peera, a na hoście z kilkoma łączami wyjściowymi ta decyzja pochodzi z tabeli przekazywania i reguł polityki. Roaming Wi-Fi może zmienić ścieżkę zewnętrzną bez dotykania adresu wewnętrznego.

Zatem działający tunel i nieosiągalny peer to stany zgodne, podobnie jak poprawny peer i zepsuta trasa wewnętrzna. Trzy obserwacje trzeba wziąć razem, w tej samej chwili, inaczej porównanie nie ma sensu.

Porównaj trzy stany w jednym przebiegu

Trzy polecenia tylko do odczytu odpowiadają na trzy pytania w kolejności, która najszybciej izoluje awarię. Uruchom je, nie zmieniając niczego pomiędzy nimi.

ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer

Pierwsze pokazuje, czy interfejs ma w ogóle adres, a drugie pokazuje, którego urządzenia użyłby teraz konkretny cel. Trzecie raportuje czas ostatniego handshake i liczniki bajtów, i jako jedyne z trzech opisuje peera, a nie lokalnego hosta.

Czytaj liczniki tak samo jak znacznik czasu. Handshake, który ciągle się odświeża, podczas gdy transfer stoi w miejscu, oznacza, że peer odpowiada, ale nic użytecznego nie przechodzi, co wskazuje na routing albo ACL, a nie na klucze. Znacznik czasu, który przestaje się przesuwać, gdy adres jest obecny, wskazuje raczej w górę. Oba odczyty pochodzą z tej samej linii wyjścia i żaden nie jest widoczny, jeśli sprawdzasz tylko, czy handshake istnieje.

Napraw ten konkretny stan, który jest błędny, a potem przetestuj aplikację, a nie tunel. Świeży handshake jest dowodem o peerze, a dowód o peerze nie jest dowodem, że następne żądanie z twojej przeglądarki znajdzie adres, trasę i działające łącze wyjściowe. podręcznik wg-quick mówi wprost, które z tego ustawia pomocnik, a które należą do protokołu.

Powiązane artykuły