Interfejs jest podniesiony, ale wg-quick zawiódł: co dalej

Jednostka jest czerwona, interfejs istnieje, a tunel w większości działa, co jest najbardziej mylącą kombinacją, jaka może być. Konfiguracja to sekwencja: najpierw powstaje interfejs, potem pojawiają się adresy, trasy, ustawienia resolvera i dowolne polecenia hook. Błąd na czwartym kroku zostawia pierwsze trzy na miejscu, więc nazwa interfejsu jest dowodem, że uruchamianie się zaczęło, a nie że się skończyło. Jeden dodatkowy fakt oszczędziłby zamieszania: krok, który zawiódł.

Stan częściowy to normalna porażka

Takiego zachowania należy się spodziewać, a nie traktować go jako uszkodzenia. Interfejs jest najtańszą częścią konfiguracji i najłatwiejszą do pozostawienia, a to właśnie on sprawia, że maszyna wygląda na na wpół działającą.

To, czego jeszcze nie ma, to wszystko, co przyszło po nieudanym kroku. Jeśli błąd wystąpił na etapie resolvera, adresy i trasy są, a DNS nie. Jeśli to była trasa, tunel ma adres i żadnej drogi przez niego.

Skutkiem jest maszyna, która odpowiada na jedne testy, a inne oblewa, dlatego ludzie wnioskują, że usługa migocze, choć nigdy nie wystartowała pomyślnie. Usługa, która nigdy się nie zakończyła, nie może migotać. Może tylko wielokrotnie zawodzić z tego samego powodu.

Znajdź pierwszy nieudany krok

Czytaj dziennik jednostki, a nie tylko bieżący stan, i czytaj go od początku nieudanego przebiegu. Ostatnia linia podaje kod wyjścia; pierwszy błąd mówi, co naprawić.

Te polecenia wypisują stan jednostki, dziennik rozruchu tej jednostki i bieżący stan tunelu:

systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0

Błąd resolvera, trasa, która już istnieje, hook zakończony kodem innym niż zero i błąd analizy konfiguracji pojawiają się w tym oknie, a każdy z nich nazywa własny komponent. Zgadywanie wyłącznie ze stanu interfejsu ignoruje całą tę informację.

Trzy warunki, które rozstrzygają naprawę

Zdecyduj, czy czyścisz, naprawiasz na miejscu, czy usuwasz jednostkę ze ścieżki rozruchu, i zdecyduj to przed wpisaniem czegokolwiek.

Jeśli interfejs jest zepsuty, ale konfiguracja jest poprawna, wyczyść i zacznij od nowa. Jeśli konfiguracja jest błędna, popraw ją i mimo to najpierw wyczyść, bo uruchomienie drugiego menedżera nad stanem częściowym daje dwóch właścicieli jednego interfejsu. Jeśli błąd to brakujący komponent systemu, na przykład pomocnik resolvera, którego maszyna nie ma, zainstaluj lub usuń zależność świadomie, zamiast edytować jednostkę, aż przestanie się skarżyć.

Te trzy przypadki pokrywają większość tego, co wygląda jak tajemnicza czerwona jednostka. Rozstrzygające pytanie brzmi, czy ten sam błąd wystąpiłby na maszynie z czystym stanem, a odpowiedź zwykle pochodzi z pierwszej linii błędu.

Wyczyść, zanim spróbujesz ponownie

Ponowna próba nad istniejącym stanem może zawieść z nowego powodu i ukryć pierwotny. Opuść interfejs tym samym narzędziem, które go utworzyło, a potem potwierdź, że nic nie zostało.

Nie usuwaj niepowiązanych interfejsów i nie resetuj stosu sieciowego hosta. Jedno i drugie to duże działania dla naprawy małego obiektu, i zamieniają jeden nieudany tunel w maszynę, której pozostałe połączenia trzeba odtworzyć. Właściwy zakres to jeden interfejs i jednostka, która go posiada. Cokolwiek szerszego wymaga zapisanego powodu, zanim się wydarzy.

Udowodnij tunel, nie jednostkę

Zielona jednostka oznacza, że sekwencja rozruchu zakończyła się zerem. Nie oznacza, że pakiet dotarł na drugą stronę, ani że resolver został ustawiony tak, jak zamierzałeś.

Wyślij żądanie przez tunel i odczytaj stan, który je wytworzył:

systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.net

Uścisk dłoni bez odpowiedzi nadal mówi, że tunel się uformował, a druga strona milczy, co jest innym problemem niż jednostka, która nigdy nie wystartowała. Trzymaj stan jednostki, uścisk dłoni i wynik żądania w jednym zapisie, bo zawodzą niezależnie i tylko ich kombinacja opisuje system.