Liides on üleval, aga wg-quick ebaõnnestus: mida edasi teha

Unit on punane, liides on olemas ja tunnel enamasti töötab, mis on kõige segadust tekitavam võimalik kombinatsioon. Seadistamine on jada: kõigepealt luuakse liides, seejärel tulevad aadressid, marsruudid, resolveri seaded ja kõik konkskäsklused. Neljanda sammu ebaõnnestumine jätab esimesed kolm paigale, seega liidese nimi tõestab, et käivitamine algas, mitte et see lõppes. Üks lisaandmetükk oleks segaduse säästnud: samm, mis ebaõnnestus.

Osaline olek on tavaline ebaõnnestumine

Seda käitumist tasub oodata, mitte käsitleda rikkena. Liides on seadistamise odavaim osa ja kõige kergemini mahajäetav, ja just see osa paneb masina pooleldi töötavana paistma.

Seda, mida veel ei ole, on kõik see, mis tuli pärast ebaõnnestunud sammu. Kui ebaõnnestumine oli resolveri etapis, siis aadressid ja marsruudid on olemas ja DNS ei ole. Kui see oli marsruut, on tunnelil aadress ja mitte mingit teed sellest läbi.

Tagajärg on masin, mis vastab mõnele testile ja ebaõnnestub teistel, mistõttu inimesed järeldavad, et teenus vilgub, kuigi see ei käivitunud kunagi edukalt. Teenus, mis ei lõpetanud kunagi, ei saa vilkuda. See saab ainult korduvalt samal põhjusel ebaõnnestuda.

Leidke esimene ebaõnnestunud samm

Lugege uniti logi, mitte ainult praegust olekut, ja lugege seda ebaõnnestunud käivituse algusest. Viimane rida ütleb väljumiskoodi; esimene viga ütleb, mida parandada.

Need käsud trükivad uniti oleku, selle uniti alglaadimislogi ja tunneli reaalajas oleku:

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

Resolveri viga, juba olemasolev marsruut, nullist erineva koodiga väljunud konks ja konfiguratsiooni parsimise tõrge ilmuvad kõik selles aknas, ja igaüks nimetab oma komponendi. Ainult liidese olekust oletamine eirab kogu seda teavet.

Kolm tingimust, mis otsustavad paranduse

Otsustage, kas puhastate, parandate kohapeal või eemaldate uniti alglaadimise teelt, ja otsustage see enne, kui midagi trükite.

Kui liides on katki, aga konfiguratsioon on õige, puhastage ja alustage uuesti. Kui konfiguratsioon on vale, parandage see ja puhastage ikkagi kõigepealt, sest teise halduri käivitamine osalise oleku peal loob ühele liidesele kaks omanikku. Kui tõrge on puuduv süsteemikomponent, näiteks resolveri abiline, mida masinal ei ole, siis paigaldage või eemaldage sõltuvus teadlikult, selle asemel et unitit muuta, kuni see kaebamise lõpetab.

Need kolm juhtumit katavad enamiku sellest, mis näeb välja nagu salapärane punane unit. Eristav küsimus on, kas sama tõrge tekiks puhta olekuga masinal, ja vastus tuleb tavaliselt esimesest veareast.

Puhastage enne uut katset

Uus katse olemasoleva oleku peal võib uuel põhjusel ebaõnnestuda ja algse peita. Tooge liides alla sama tööriistaga, mis selle lõi, ja kinnitage seejärel, et midagi ei jäänud alles.

Ärge kustutage kõrvalisi liideseid ja ärge lähtestage hosti võrgupinu. Mõlemad on suured toimingud väikese objekti parandamiseks ja muudavad ühe ebaõnnestunud tunneli masinaks, mille muud ühendused tuleb uuesti luua. Õige ulatus on üks liides ja seda omav unit. Kõik laiem vajab põhjust, mis on enne kirja pandud.

Tõestage tunnelit, mitte unitit

Roheline unit tähendab, et käivitusjada väljus nulliga. See ei tähenda, et pakett jõudis teisele poole, ega seda, et resolver seadistati nii, nagu kavatsesite.

Saatke päring läbi tunneli ja lugege olekut, mis selle tekitas:

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

Käepigistus ilma vastuseta ütleb ikkagi, et tunnel tekkis ja vastaspool on vaikne, mis on teine probleem kui unit, mis ei käivitunud kunagi. Hoidke uniti olek, käepigistus ja päringu tulemus ühes kirjes, sest need ebaõnnestuvad sõltumatult ja ainult kombinatsioon kirjeldab süsteemi.