Interfeiss ir uzcelts, bet wg-quick neizdevās: ko darīt tālāk

Unit ir sarkans, interfeiss pastāv, un tunelis lielākoties darbojas — tā ir mulsinošākā iespējamā kombinācija. Iestatīšana ir secība: vispirms tiek izveidots interfeiss, tad nāk adreses, maršruti, atrisinātāja iestatījumi un jebkuras hook komandas. Neveiksme ceturtajā solī atstāj pirmos trīs vietā, tāpēc interfeisa nosaukums pierāda, ka palaišana sākās, nevis ka tā beidzās. Viens papildu fakts būtu ietaupījis apjukumu: solis, kurā notika neveiksme.

Daļējs stāvoklis ir parastā neveiksme

Šādu uzvedību ir vērts gaidīt, nevis uzskatīt par bojājumu. Interfeiss ir lētākā iestatīšanas daļa un visvieglāk atstājamā, un tieši tā liek mašīnai izskatīties daļēji funkcionējošai.

Tas, kas vēl neeksistē, ir viss, kas nāca pēc neveiksmīgā soļa. Ja neveiksme bija atrisinātāja posmā, adreses un maršruti ir, bet DNS nav. Ja tas bija maršruts, tunelim ir adrese un nav nekāda ceļa tam cauri.

Sekas ir mašīna, kas atbild uz dažiem testiem un citos neizdodas, tāpēc cilvēki secina, ka pakalpojums mirgo, lai gan tas nekad nav veiksmīgi palaists. Pakalpojums, kas nekad nav pabeigts, nevar mirgot. Tas var tikai atkārtoti neizdoties tā paša iemesla dēļ.

Atrodiet pirmo neveiksmīgo soli

Lasiet unit žurnālu, nevis tikai pašreizējo statusu, un lasiet to no neizdevušās palaišanas sākuma. Pēdējā rinda pasaka izejas kodu; pirmā kļūda pasaka, ko labot.

Šīs komandas izdrukā unit stāvokli, šī unit palaišanas žurnālu un tunela dzīvo stāvokli:

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

Atrisinātāja kļūda, jau esošs maršruts, hook, kas beidzās ar kodu, kas nav nulle, un konfigurācijas parsēšanas neveiksme visas parādās tajā logā, un katra nosauc savu komponentu. Minējumi tikai no interfeisa stāvokļa ignorē visu šo informāciju.

Trīs nosacījumi, kas izlemj labošanu

Izlemiet, vai jūs tīrāt, labojat uz vietas vai noņemat unit no palaišanas ceļa, un izlemiet to pirms kaut ko ierakstāt.

Ja interfeiss ir salūzis, bet konfigurācija ir pareiza, iztīriet un sāciet no jauna. Ja konfigurācija ir nepareiza, izlabojiet to un tomēr vispirms iztīriet, jo otra pārvaldnieka palaišana virs daļēja stāvokļa rada divus viena interfeisa īpašniekus. Ja neveiksme ir trūkstoša sistēmas komponente, piemēram, atrisinātāja palīgs, kura mašīnai nav, apzināti instalējiet vai noņemiet atkarību, nevis rediģējiet unit, līdz tas pārstāj sūdzēties.

Šie trīs gadījumi nosedz lielāko daļu no tā, kas izskatās pēc noslēpumaina sarkana unit. Atšķirošais jautājums ir, vai tā pati neveiksme notiktu mašīnā ar tīru stāvokli, un atbilde parasti nāk no pirmās kļūdas rindas.

Iztīriet pirms mēģināt vēlreiz

Atkārtots mēģinājums virs esoša stāvokļa var neizdoties jauna iemesla dēļ un paslēpt sākotnējo. Nolaidiet interfeisu ar to pašu rīku, kas to izveidoja, un pēc tam apstipriniet, ka nekas nav palicis.

Nedzēsiet nesaistītus interfeisus un neatiestatiet resursdatora tīkla steku. Abi ir lieli pasākumi maza objekta labošanai, un tie pārvērš vienu neizdevušos tuneli mašīnā, kuras citi savienojumi jāizveido no jauna. Pareizais apjoms ir viens interfeiss un unit, kas to pārvalda. Viss plašāks prasa iepriekš uzrakstītu iemeslu.

Pierādiet tuneli, nevis unit

Zaļš unit nozīmē, ka palaišanas secība beidzās ar nulli. Tas nenozīmē, ka pakete sasniedza otru pusi, un nenozīmē, ka atrisinātājs tika iestatīts tā, kā jūs paredzējāt.

Nosūtiet pieprasījumu pa tuneli un izlasiet stāvokli, kas to radīja:

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

Rokasspiediens bez atbildes tomēr pasaka, ka tunelis izveidojās un tālā puse klusē, un tā ir cita problēma nekā unit, kas nekad nav palaists. Glabājiet unit stāvokli, rokasspiedienu un pieprasījuma rezultātu vienā ierakstā, jo tie neizdodas neatkarīgi un sistēmu apraksta tikai to kombinācija.