La interfaco estas supre, sed wg-quick malsukcesis: kion fari poste

La unuo estas ruĝa, la interfaco ekzistas, kaj la tunelo plejparte funkcias, kio estas la plej konfuza ebla kombino. La agordo estas sinsekvo: unue kreiĝas la interfaco, poste venas adresoj, itineroj, agordoj de la solvilo kaj iuj ajn hokaj komandoj. Malsukceso ĉe la kvara paŝo lasas la unuajn tri en loko, do la nomo de la interfaco pruvas, ke la praŝargo komenciĝis, ne ke ĝi finiĝis. Unu plia fakto estus ŝparinta la konfuzon: la paŝo, kiu malsukcesis.

Parta stato estas la normala malsukceso

Tiun konduton indas atendi anstataŭ trakti ĝin kiel difekton. La interfaco estas la plej malmultekosta parto de la agordo kaj la plej facile lasata malantaŭe, kaj ĝi ankaŭ estas la parto, kiu igas la maŝinon aspekti duone funkcianta.

Tio, kio ankoraŭ ne ekzistas, estas ĉio, kio venis post la malsukcesa paŝo. Se la malsukceso estis ĉe la stadio de la solvilo, adresoj kaj itineroj estas kaj DNS ne. Se ĝi estis itinero, la tunelo havas adreson kaj neniun vojon tra ĝi.

La sekvo estas maŝino, kiu respondas al kelkaj testoj kaj malsukcesas ĉe aliaj, kaj tial homoj konkludas, ke la servo flagras, kvankam ĝi neniam sukcese ekfunkciis. Servo, kiu neniam finiĝis, ne povas flagri. Ĝi povas nur ripete malsukcesi pro la sama kaŭzo.

Trovu la unuan malsukcesan paŝon

Legu la protokolon de la unuo anstataŭ nur la nunan staton, kaj legu ĝin de la komenco de la malsukcesa rulado. La lasta linio diras al vi la elirkodon; la unua eraro diras, kion ripari.

Ĉi tiuj komandoj presas la staton de la unuo, la praŝargan protokolon por tiu unuo kaj la vivan staton de la tunelo:

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

Eraro de la solvilo, itinero, kiu jam ekzistas, hoko, kiu eliris kun ne-nula kodo, kaj malsukceso de analizo de la agordo ĉiuj aperas en tiu fenestro, kaj ĉiu nomas sian propran komponenton. Diveni nur el la stato de la interfaco ignoras ĉiujn tiujn informojn.

Tri kondiĉoj, kiuj decidas la riparon

Decidu, ĉu vi purigas, ĉu vi riparas surloke, ĉu vi forigas la unuon el la praŝarga vojo, kaj decidu tion antaŭ ol tajpi ion ajn.

Se la interfaco estas difektita sed la agordo ĝustas, purigu kaj rekomencu. Se la agordo malĝustas, riparu ĝin kaj tamen unue purigu, ĉar lanĉi duan administrilon super parta stato produktas du posedantojn por unu interfaco. Se la malsukceso estas mankanta sistema komponento, kiel solvila helpanto, kiun la maŝino ne havas, instaligu aŭ forigu la dependecon intence anstataŭ redakti la unuon ĝis ĝi ĉesos plendi.

Tiuj tri kazoj kovras la plej grandan parton de tio, kio aspektas kiel mistera ruĝa unuo. La distinga demando estas, ĉu la sama malsukceso okazus sur maŝino kun pura stato, kaj la respondo kutime venas el la unua erarlinio.

Purigu antaŭ ol reprovi

Nova provo super ekzistanta stato povas malsukcesi pro nova kaŭzo kaj kaŝi la originan. Mallevu la interfacon per la sama ilo, kiu kreis ĝin, kaj poste konfirmu, ke nenio restis.

Ne forigu nenecesajn interfacojn kaj ne restarigu la retan stakon de la gastiganto. Ambaŭ estas grandaj agoj por ripari malgrandan objekton, kaj ili transformas unu malsukcesan tunelon en maŝinon, kies aliaj konektoj devas esti restarigitaj. La ĝusta amplekso estas unu interfaco kaj la unuo, kiu posedas ĝin. Io pli larĝa postulas kaŭzon skribitan antaŭ ol ĝi okazos.

Pruvu la tunelon, ne la unuon

Verda unuo signifas, ke la praŝarga sinsekvo eliris kun nulo. Ĝi ne signifas, ke paketo atingis la alian flankon, nek ke la solvilo agordiĝis tiel, kiel vi intencis.

Sendu peton tra la tunelo kaj legu la staton, kiu produktis ĝin:

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

Manpremo sen respondo tamen diras al vi, ke la tunelo formiĝis kaj la fora flanko silentas, kio estas alia problemo ol unuo, kiu neniam ekfunkciis. Tenu la staton de la unuo, la manpremon kaj la rezulton de la peto en unu rikordo, ĉar ili malsukcesas sendepende kaj nur la kombino priskribas la sistemon.