Enheten er rød, grensesnittet finnes, og tunnelen virker stort sett, som er den mest forvirrende kombinasjonen som finnes. Oppsettet er en sekvens: først opprettes grensesnittet, deretter følger adresser, ruter, resolver-innstillinger og eventuelle hook-kommandoer. En feil på fjerde trinn lar de tre første stå, så grensesnittnavnet er bevis på at oppstarten begynte, ikke at den ble fullført. Én ekstra opplysning ville ha spart forvirringen: trinnet som feilet.

Delvis tilstand er den normale feilen

Den oppførselen er verdt å forvente i stedet for å behandle den som korrupsjon. Grensesnittet er den billigste delen av oppsettet og den letteste å etterlate, og det er også delen som får maskinen til å se halvfunksjonell ut.

Det som ennå ikke finnes, er alt som kom etter det feilende trinnet. Hvis feilen var i resolver-trinnet, finnes adresser og ruter, og DNS gjør det ikke. Hvis det var en rute, har tunnelen en adresse og ingen vei gjennom den.

Konsekvensen er en maskin som svarer på noen tester og feiler på andre, og derfor konkluderer folk med at tjenesten blafrer når den aldri startet vellykket. En tjeneste som aldri ble fullført, kan ikke blafre. Den kan bare feile gang på gang av samme grunn.

Finn det første trinnet som feiler

Les journalen for enheten i stedet for bare gjeldende status, og les den fra toppen av den feilede kjøringen. Den siste linjen forteller deg utgangskoden; den første feilen forteller hva som skal repareres.

Disse kommandoene skriver ut enhetens tilstand, oppstartsjournalen for den enheten og tunnelens live-tilstand:

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

En resolverfeil, en rute som allerede finnes, en hook som avsluttet med en kode ulik null og en feil i konfigurasjonsparsingen vises alle i det vinduet, og hver av dem navngir sin egen komponent. Å gjette bare ut fra grensesnittets tilstand ignorerer all den informasjonen.

Tre betingelser som avgjør reparasjonen

Avgjør om du rydder, reparerer på stedet eller fjerner enheten fra oppstartsstien, og avgjør det før du skriver noe.

Hvis grensesnittet er ødelagt men konfigurasjonen er riktig, rydder du og starter på nytt. Hvis konfigurasjonen er feil, retter du den og rydder likevel først, fordi å starte en andre behandler over delvis tilstand gir to eiere til ett grensesnitt. Hvis feilen er en manglende systemkomponent som en resolver-hjelper maskinen ikke har, installerer eller fjerner du avhengigheten med vilje i stedet for å redigere enheten til den slutter å klage.

Disse tre tilfellene dekker det meste av det som ser ut som en mystisk rød enhet. Det avgjørende spørsmålet er om den samme feilen ville oppstå på en maskin med ren tilstand, og svaret kommer vanligvis fra den første feillinjen.

Rydd før du prøver igjen

Et nytt forsøk over eksisterende tilstand kan feile av en ny grunn og skjule den opprinnelige. Ta grensesnittet ned med samme verktøy som opprettet det, og bekreft deretter at ingenting er igjen.

Ikke slett urelaterte grensesnitt og ikke tilbakestill vertens nettverksstakk. Begge er store handlinger for å reparere et lite objekt, og de gjør én feilet tunnel om til en maskin der andre tilkoblinger må gjenopprettes. Riktig omfang er ett grensesnitt og enheten som eier det. Alt videre krever en grunn skrevet ned før det skjer.

Bevis tunnelen, ikke enheten

En grønn enhet betyr at oppstartssekvensen avsluttet med null. Det betyr ikke at en pakke nådde den andre siden, og ikke at resolveren ble satt slik du mente.

Send en forespørsel gjennom tunnelen og les tilstanden som skapte den:

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

Et håndtrykk uten svar forteller deg fortsatt at tunnelen ble dannet og at den fjerne siden er stille, som er et annet problem enn en enhet som aldri startet. Hold enhetens tilstand, håndtrykket og forespørselens resultat i én registrering, fordi de feiler uavhengig og bare kombinasjonen beskriver systemet.

Relaterte artikler