Handshake działa, adres zniknął: trzy stany WireGuard
Świeży handshake dowodzi, że peer odpowiedział, a nie że interfejs zachowuje swój adres albo że następny pakiet pójdzie zamierzonym łączem wyjściowym.
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.
| Observation | Which layer it belongs to | Wrong conclusion it invites |
|---|---|---|
| Handshake a few seconds old | Peer and keys | The tunnel is usable for application traffic |
Address present on wg0 | Interface configuration | Traffic actually egresses through it |
Route points at wg0 | Forwarding table | The 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.