A unidade está en vermello, a interface existe e o túnel funciona na maior parte, que é a combinación máis confusa posible. A configuración é unha secuencia: primeiro créase a interface, despois veñen enderezos, rutas, axustes do resolvedor e calquera orde de hook. Un fallo no cuarto paso deixa os tres primeiros no seu sitio, así que o nome da interface é proba de que o arranque comezou, non de que rematou. Un dato adicional tería aforrado a confusión: o paso que fallou.

O estado parcial é o fallo normal

Ese comportamento convén esperalo en lugar de tratalo como corrupción. A interface é a parte máis barata da configuración e a máis doada de deixar atrás, e tamén é a parte que fai que a máquina pareza medio operativa.

O que aínda non existe é todo o que veu despois do paso que fallou. Se o fallo foi na etapa do resolvedor, os enderezos e as rutas están e o DNS non. Se foi unha ruta, o túnel ten un enderezo e ningún camiño a través del.

A consecuencia é unha máquina que responde a algunhas probas e falla noutras, e por iso a xente conclúe que o servizo parpadea cando en realidade nunca arrancou con éxito. Un servizo que nunca rematou non pode parpadear. Só pode fallar unha e outra vez polo mesmo motivo.

Atopa o primeiro paso que falla

Le o diario da unidade en lugar de só o estado actual, e leo desde o comezo da execución fallida. A última liña diche o código de saída; o primeiro erro diche que reparar.

Estas ordes imprimen o estado da unidade, o diario de arranque desa unidade e o estado vivo do túnel:

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

Un erro do resolvedor, unha ruta que xa existe, un hook que saíu cun código distinto de cero e un fallo de análise da configuración aparecen todos nesa ventá, e cada un nomea o seu propio compoñente. Adiviñar só a partir do estado da interface ignora toda esa información.

Tres condicións que deciden a reparación

Decide se estás limpando, reparando no lugar ou retirando a unidade do camiño de arranque, e decídeo antes de escribir nada.

Se a interface está rota pero a configuración é correcta, limpa e volve comezar. Se a configuración é incorrecta, corríxea e aínda así limpa primeiro, porque arrincar un segundo xestor sobre un estado parcial produce dous donos para unha interface. Se o fallo é un compoñente do sistema que falta, como un asistente de resolvedor que a máquina non ten, instala ou retira a dependencia a propósito en lugar de editar a unidade ata que deixe de queixarse.

Eses tres casos cobren a maior parte do que parece unha unidade vermella misteriosa. A pregunta que distingue é se o mesmo fallo ocorrería nunha máquina con estado limpo, e a resposta adoita vir da primeira liña de erro.

Limpa antes de reintentar

Un reintento sobre un estado existente pode fallar por un motivo novo e ocultar o orixinal. Baixa a interface coa mesma ferramenta que a creou e despois confirma que non queda nada.

Non borres interfaces que non teñen relación nin reinicies a pila de rede do anfitrión. Ambas son accións grandes para arranxar un obxecto pequeno, e converten un só túnel fallido nunha máquina cuxas outras conexións hai que restablecer. O alcance correcto é unha interface e a unidade que a posúe. Calquera cousa máis ampla necesita un motivo escrito antes de que ocorra.

Demostra o túnel, non a unidade

Unha unidade verde significa que a secuencia de arranque saíu con cero. Non significa que un paquete chegase ao outro lado, nin que o resolvedor se configurase como pretendías.

Envía unha petición polo túnel e le o estado que a produciu:

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

Un aperto de mans sen resposta aínda che di que o túnel se formou e que o lado remoto está calado, o que é un problema distinto dunha unidade que nunca arrancou. Garda o estado da unidade, o aperto de mans e o resultado da petición nun só rexistro, porque fallan de forma independente e só a combinación describe o sistema.

Artigos relacionados