Sąsaja pakelta, bet wg-quick nepavyko: ką daryti toliau

Unit yra raudonas, sąsaja egzistuoja, o tunelis daugiausia veikia — tai pats painiausias įmanomas derinys. Konfigūravimas yra seka: pirmiausia sukuriama sąsaja, po to ateina adresai, maršrutai, sprendėjo nustatymai ir bet kokios hook komandos. Ketvirtame žingsnyje įvykusi klaida palieka pirmus tris vietoje, tad sąsajos pavadinimas įrodo, kad paleidimas prasidėjo, o ne kad baigėsi. Vienas papildomas faktas būtų išvengęs painiavos: žingsnis, kuriame įvyko klaida.

Dalinė būsena yra įprasta klaida

Šio elgesio verta tikėtis, o ne laikyti jį sugadinimu. Sąsaja yra pigiausia konfigūravimo dalis ir lengviausia palikti, ir būtent ji verčia mašiną atrodyti pusiau veikiančia.

Tai, ko dar nėra, yra viskas, kas atėjo po nepavykusio žingsnio. Jei klaida įvyko sprendėjo etape, adresai ir maršrutai yra, o DNS nėra. Jei tai buvo maršrutas, tunelis turi adresą ir jokio kelio pro jį.

Pasekmė — mašina, kuri atsako į vienus testus ir nepavyksta kituose, todėl žmonės daro išvadą, kad paslauga mirksi, nors ji niekada sėkmingai nepasileido. Paslauga, kuri niekada nebaigė, negali mirksėti. Ji gali tik kartoti klaidą dėl tos pačios priežasties.

Raskite pirmą nepavykusį žingsnį

Skaitykite unit žurnalą, o ne vien dabartinę būseną, ir skaitykite jį nuo nepavykusio paleidimo pradžios. Paskutinė eilutė pasako išėjimo kodą; pirmoji klaida pasako, ką taisyti.

Šios komandos išspausdina unit būseną, to unit įkrovos žurnalą ir gyvą tunelio būseną:

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

Sprendėjo klaida, jau egzistuojantis maršrutas, nuliniu kodu nepasibaigęs hook ir konfigūracijos analizės klaida visi pasirodo tame lange, ir kiekvienas įvardija savo komponentą. Spėjimas vien iš sąsajos būsenos ignoruoja visą tą informaciją.

Trys sąlygos, lemiančios taisymą

Nuspręskite, ar valote, ar taisote vietoje, ar šalinate unit iš įkrovos kelio, ir nuspręskite tai prieš ką nors rašydami.

Jei sąsaja sulaužyta, bet konfigūracija teisinga, išvalykite ir pradėkite iš naujo. Jei konfigūracija neteisinga, pataisykite ją ir vis tiek pirmiausia išvalykite, nes antro valdytojo paleidimas ant dalinės būsenos sukuria du vienos sąsajos savininkus. Jei klaida yra trūkstamas sistemos komponentas, pavyzdžiui, sprendėjo pagalbininkas, kurio mašina neturi, sąmoningai įdiekite arba pašalinkite priklausomybę, o ne redaguokite unit tol, kol jis nustos skųstis.

Tie trys atvejai apima didžiąją dalį to, kas atrodo kaip paslaptingas raudonas unit. Skiriamasis klausimas yra tai, ar ta pati klaida įvyktų mašinoje su švaria būsena, o atsakymas paprastai ateina iš pirmos klaidos eilutės.

Išvalykite prieš bandydami dar kartą

Bandymas iš naujo ant esamos būsenos gali nepavykti dėl naujos priežasties ir paslėpti pirminę. Nuleiskite sąsają tuo pačiu įrankiu, kuris ją sukūrė, tada patvirtinkite, kad nieko neliko.

Netrinkite nesusijusių sąsajų ir neatstatykite pagrindinės mašinos tinklo kamino. Abu tai dideli veiksmai mažam objektui taisyti, ir jie vieną nepavykusį tunelį paverčia mašina, kurios kiti ryšiai turi būti užmegzti iš naujo. Tinkama apimtis yra viena sąsaja ir ją valdantis unit. Viskas platesnio reikalauja prieš tai užrašytos priežasties.

Įrodykite tunelį, o ne unit

Žalias unit reiškia, kad paleidimo seka baigėsi nuliu. Tai nereiškia, kad paketas pasiekė kitą pusę, ir nereiškia, kad sprendėjas buvo nustatytas taip, kaip ketinote.

Siųskite užklausą per tunelį ir perskaitykite būseną, kuri ją sukūrė:

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

Rankos paspaudimas be atsakymo vis tiek pasako, kad tunelis susiformavo, o tolimoji pusė tyli, ir tai yra kita problema nei unit, kuris niekada nepasileido. Laikykite unit būseną, rankos paspaudimą ir užklausos rezultatą viename įraše, nes jie nepavyksta nepriklausomai ir sistemą apibūdina tik jų derinys.