Gränssnittet är uppe men wg-quick misslyckades: vad du gör nu
En misslyckad enhet kan lämna en halvkonfigurerad tunnel efter sig. Läs det första steget som misslyckas, avgör om du ska städa eller reparera, och bevisa det sedan med en begäran.
Enheten är röd, gränssnittet finns och tunneln fungerar till största delen, vilket är den mest förvirrande kombination som finns. Uppsättningen är en sekvens: först skapas gränssnittet, sedan följer adresser, rutter, resolver-inställningar och eventuella hook-kommandon. Ett fel på fjärde steget lämnar de tre första kvar, så gränssnittsnamnet är bevis på att starten började, inte att den blev klar. En extra upplysning hade sparat förvirringen: steget som misslyckades.
Delvis tillstånd är det normala felet
Det beteendet är värt att förvänta sig i stället för att behandla det som korruption. Gränssnittet är den billigaste delen av uppsättningen och den lättaste att lämna kvar, och det är också den del som får maskinen att se halvfungerande ut.
Det som ännu inte finns är allt som kom efter det misslyckade steget. Om felet var i resolver-steget, finns adresser och rutter och DNS gör det inte. Om det var en rutt, har tunneln en adress och ingen väg igenom den.
Följden är en maskin som svarar på några tester och misslyckas på andra, och därför drar folk slutsatsen att tjänsten flimrar när den aldrig startade framgångsrikt. En tjänst som aldrig blev klar kan inte flimra. Den kan bara misslyckas om och om igen av samma skäl.
Hitta det första steget som misslyckas
Läs journalen för enheten i stället för bara aktuell status, och läs den från början av den misslyckade körningen. Den sista raden säger exitkoden; det första felet säger vad som ska repareras.
Dessa kommandon skriver ut enhetens tillstånd, startjournalen för den enheten och tunnelns livedtillstånd:
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0Ett resolverfel, en rutt som redan finns, en hook som avslutades med en kod som inte är noll och ett fel vid tolkning av konfigurationen visas alla i det fönstret, och var och en namnger sin egen komponent. Att gissa enbart utifrån gränssnittets tillstånd ignorerar all den informationen.
Tre villkor som avgör reparationen
Avgör om du städar, reparerar på plats eller tar bort enheten från startvägen, och avgör det innan du skriver något.
Om gränssnittet är trasigt men konfigurationen är korrekt, städa och börja om. Om konfigurationen är fel, rätta den och städa ändå först, eftersom att starta en andra hanterare över ett delvis tillstånd ger två ägare till ett gränssnitt. Om felet är en saknad systemkomponent, som en resolver-hjälpare maskinen inte har, installerar eller tar du bort beroendet medvetet i stället för att redigera enheten tills den slutar klaga.
De tre fallen täcker det mesta av det som ser ut som en mystisk röd enhet. Den avgörande frågan är om samma fel skulle inträffa på en maskin med rent tillstånd, och svaret kommer oftast från den första felraden.
Städa innan du försöker igen
Ett nytt försök över befintligt tillstånd kan misslyckas av en ny anledning och dölja den ursprungliga. Ta ner gränssnittet med samma verktyg som skapade det, och bekräfta sedan att inget är kvar.
Radera inte orelaterade gränssnitt och återställ inte värdens nätverksstack. Båda är stora åtgärder för att reparera ett litet objekt, och de förvandlar en enda misslyckad tunnel till en maskin vars andra anslutningar måste upprättas igen. Rätt omfattning är ett gränssnitt och enheten som äger det. Allt vidare kräver en anledning nedskriven innan det händer.
Bevisa tunneln, inte enheten
En grön enhet betyder att startsekvensen avslutades med noll. Det betyder inte att ett paket nådde andra sidan, och inte att resolvern ställdes in som du avsåg.
Skicka en begäran genom tunneln och läs det tillstånd som skapade den:
systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.netEtt handslag utan svar säger fortfarande att tunneln bildades och att den bortre sidan är tyst, vilket är ett annat problem än en enhet som aldrig startade. Håll enhetens tillstånd, handslaget och begärans resultat i en och samma post, eftersom de misslyckas oberoende av varandra och bara kombinationen beskriver systemet.