Verificar uma VPN sem interface: um fluxo de cada vez, com evidência
Uma caixa sem interface precisa de um pedido cuja resposta possa ler. Teste cada família de endereços, contexto e destino e registe depois o que o resultado não cobriu.
Numa caixa sem interface não há navegador para abrir nem cadeado para olhar, por isso a verificação tem de ser um pedido cuja resposta possa ler. Parece trivial até reparar que um único resultado de endereço de saída é usado para certificar um dispositivo que executa uma dúzia de serviços, duas famílias de endereços e um proxy. O percurso abaixo constrói uma peça de evidência limitada de cada vez, no mesmo contexto em que a carga de trabalho realmente corre.
Decida o que o teste tem de provar
Antes de executar seja o que for, escreva a expectativa numa linha: que fluxo, por que interface, para que destino e o que deve ser observado no outro extremo. Um teste sem expectativa declarada produz um número que ninguém consegue interpretar.
A versão mais útil nomeia um ponto final aprovado que relata o endereço de origem que viu.
Esse ponto final é a única parte que tem de preparar. Tudo o resto é uma observação do lado do cliente, e as observações do lado do cliente falham de formas interessantes.
Execute a observação no contexto correto
A shell de um administrador não é o ambiente da carga de trabalho. Pode transportar outra variável de proxy, outra tabela de rotas noutro espaço de nomes ou o ficheiro de ambiente de outro utilizador. Execute o teste no mesmo contexto de anfitrião, contentor, espaço de nomes ou serviço que aquilo que verifica. Caso contrário, está a medir a sua shell.
Num anfitrião normal isso significa o mesmo utilizador e a mesma unidade. Num ambiente de contentores significa entrar no espaço de nomes de rede do contentor em vez de testar a partir do anfitrião. Num serviço systemd pode significar uma unidade transitória com as mesmas definições.
O pedido seguinte só faz sentido quando estiver no contexto correto.
Verifique as famílias de endereços em separado
Peça cada família explicitamente, porque um pedido IPv4 bem-sucedido não exercita de todo um caminho IPv6. Os seletores --ipv4 e --ipv6 forçam a escolha, e a diferença entre os dois resultados é ela própria informação.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceUm pedido IPv6 falhado não é prova de um bloqueio eficaz. Pode significar que o ponto final não tem endereço IPv6, que o DNS não devolveu nada utilizável ou que o dispositivo não tem qualquer rota IPv6. Leia a falha antes de tirar uma conclusão. Um pedido IPv6 bem-sucedido através do túnel é o único resultado que prova que o caminho IPv6 está coberto.
Registe ambas as respostas lado a lado. Uma delas sozinha é metade de um facto.
Acrescente as quatro coisas que uma verificação de saída não vê
Um endereço de saída responde a uma pergunta. Mais quatro decidem se o túnel se comporta como foi desenhado.
| Check | What it proves | What it does not |
|---|---|---|
| Included and excluded destinations | The split behaves as designed for those flows | Coverage of any other destination |
| Resolver path | Where a fresh lookup actually travelled | Where a cached answer came from |
| Tunnel-down behaviour | The failure policy for a new request | What an already open connection does |
| Reconnect and restart | The requirement survives the lifecycle event | Behaviour under load or partial failure |
A política de destinos vem primeiro: teste um fluxo que devia ser incluído e outro que devia ser excluído, quando o desenho tem uma divisão. Depois o DNS, onde inspeciona o caminho real do resolvedor em vez do valor configurado, porque uma resposta em cache ou uma definição impressa não diz nada sobre onde foi uma nova consulta.
O comportamento em caso de falha precisa de um plano e de um caminho de recuperação preservado. Observe um pedido novo enquanto o túnel não está disponível, e lembre-se de que uma ligação aberta antiga não é evidência sobre a política de falha. O ciclo de vida vem por último: repita a observação após uma reconexão ou um reinício do serviço se esses eventos afetarem o requisito.
Registe evidência, não um veredicto
Para cada resultado guarde o contexto do processo, o destino, a família de endereços, a hora e a origem observada. Esse conjunto é evidência limitada sobre os fluxos que exercitou, e é defensável precisamente porque diz o que cobriu.
Não é uma auditoria dos registos do operador de VPN, nem um certificado para cada aplicação futura no dispositivo.
Escreva os limites ao lado do resultado. Um teste que declara o que não cobriu sobrevive à revisão, enquanto um que afirma que o dispositivo está verificado não sobrevive. Mantenha o manual do curl ao lado dos seletores de família que usou, e mantenha a tabela de quatro linhas junto aos resultados.