Inspecionar uma interface VPN Linux com ip link, camada por camada

O ícone do cliente diz conectado, a interface existe, e a aplicação continua sem alcançar nada. Essa combinação é comum, porque uma interface virtual pode permanecer presente enquanto o par remoto, os endereços ou as rotas estão ausentes. ip link é a ferramenta inicial correta, e também a mais fácil de sobreinterpretar. Flags e contadores descrevem uma camada, e as camadas acima delas falham de forma independente. É também a ferramenta que as pessoas citam quando querem provar que o túnel está ativo, que é exatamente a afirmação que ela não consegue sustentar sozinha.

Leia a interface antes de ler o ícone

Comece com ip -details link show dev tun0 conforme documentado no manual do ip-link, substituindo a interface pelo nome que o seu cliente realmente possui em vez do nome convencional. Flags, tipo, MTU e identidade da interface são observações úteis. A redação de estado de uma interface virtual não precisa comportar-se como a indicação de portadora de um cabo físico, por isso trate UP como uma declaração sobre a interface e não sobre o túnel.

Essa distinção explica o caso mais confuso: uma interface que persiste enquanto o lado remoto reconecta ou está inalcançável.

Configurações de persistência podem manter o link justamente para que a reconexão não o reconstrua, o que significa que presença não é saúde.

Acrescente contadores e um pedido que deva usá-los

Use a visão de estatísticas suportada, ip -s link show dev tun0, e anote as contagens de pacotes e bytes em ambas as direções. Depois gere um pedido inofensivo que deva atravessar a interface e compare a direção relevante. Um pedido que tomou a rota direta de outra aplicação não moverá esses contadores, e esse é o ponto do exercício.

Se o contador de transmissão se move e o de receção não, o pacote saiu e nada voltou. Esse é um problema diferente de uma interface que nunca transportou nada. Se ambos os contadores se movem e a aplicação ainda falha, a falha está acima da interface, o que é progresso e não um beco sem saída.

Faça a leitura duas vezes, uma antes e uma depois, em vez de confiar numa única captura.

Endereços e rotas são passos separados

Um link pode existir sem o prefixo, a configuração do resolvedor ou a rota de que a aplicação precisa. Verifique o endereço com ip address show dev tun0, e depois verifique qual rota o destino escolheria com ip route get para o alvo real. Essas três observações respondem a três perguntas diferentes, e só a última diz respeito ao encaminhamento.

Para IPsec, a política de segurança e o estado da associação também podem importar, e nem todo desenho IPsec aparece como uma interface tun simples. Procurar um dispositivo tun que nunca ia existir é uma forma rápida de concluir a coisa errada.

Registe o nome exato, o namespace e a hora junto de qualquer saída que guarde, porque o mesmo nome aparente noutro contentor ou numa sessão restaurada representa um contexto completamente diferente.

Não apague aquilo que não identificou

Uma interface desconhecida não é automaticamente obsoleta. Identifique o dono antes de remover o que quer que seja, e use o teardown documentado do cliente ou a configuração gerida quando a remoção for realmente pretendida. Apagar um túnel ativo para ver o que acontece é um teste que responde a uma pergunta que ninguém fez.

Se a interface pertence a um runtime de contentores ou a um namespace de rede que você não criou, o dono está a um comando de distância e vale a pena encontrá-lo primeiro.

Esse cuidado também se aplica a ip link set down, que parece reversível e muitas vezes não é.

O que a inspeção deve deixar consigo

Uma boa inspeção termina com quatro factos: o nome e o namespace da interface, as suas flags e MTU, o delta de contadores de um pedido real, e a rota e o endereço de que a aplicação realmente precisa. Com eles escritos, o passo seguinte é óbvio e pertence a uma camada específica. Sem eles, cada alteração subsequente é um palpite com um plano de reversão.

Compare esses quatro factos com os mesmos quatro de uma sessão funcional. Se o nome e o namespace coincidem mas o delta de contadores é zero, o pedido nunca chegou ao túnel. Se o delta está saudável e a rota aponta para outro lado, o túnel está bem e o encaminhamento não. É essa comparação que transforma uma pilha de saída numa decisão.

Guarde a saída com o ticket, porque uma comparação posterior só é útil se puder ver o que mudou.

Depois feche o ciclo testando a aplicação novamente, porque a interface nunca foi aquilo com que o utilizador se importava.