Duas VPN numa só máquina Linux: testa cada uma sem misturar resultados

Dois ícones verdes de ligação parecem uma comparação e costumam ser coincidência. Se o pedido de teste podia ter usado qualquer um dos dois túneis, o resultado descreve no melhor caso um deles e no pior nenhum. Dá a cada observação um contexto de rede, um destino pretendido e uma expectativa escrita antes de o teste correr. Numa máquina Linux gerida por ti, os espaços de nomes de rede com nome são a forma mais barata de comprar essa separação.

Duas luzes verdes não são uma comparação

Um espaço de nomes separa tabelas de encaminhamento, interfaces e o estado da pilha de rede, pelo que um pedido iniciado dentro de um não pode pedir emprestado em silêncio o túnel de outro. O que não separa é um processador, uma ligação física ascendente ou o daemon de resolução em execução no anfitrião. É justamente nesta última lacuna que a maioria destes testes falha sem que ninguém repare. Uma consulta que sai do espaço de nomes e pergunta ao resolutor do anfitrião devolve uma resposta sem qualquer relação com o túnel em teste.

Este procedimento pressupõe dois espaços de nomes de teste já preparados e aprovados, com conetividade exterior funcional e clientes suportados. Não cria nada, não regista nada e não substitui qualquer configuração. As máquinas virtuais separadas continuam a ser a escolha honesta quando um cliente precisa de uma sessão de ambiente de trabalho completa ou se recusa a correr fora dela.

Fixa a expectativa antes da primeira execução

Decide por contexto como é o sucesso: o resolutor, o nome do serviço, o endereço esperado e o comportamento exigido quando o túnel cai. Guarda esses valores planeados na sua própria coluna, porque um registo que mistura plano e observação é ficção com marca temporal. A lista de verificação abaixo é a forma de que o registo precisa, e cada linha tem de poder ser preenchida antes da primeira ligação.

A cablagem do resolutor merece a sua própria linha nesse registo, porque é o campo com mais probabilidade de mentir. Os ficheiros ligados ao espaço de nomes, como /etc/netns/vpn-a/resolv.conf aparecem nos seus caminhos habituais quando um comando corre dentro do espaço de nomes, tal como a referência do iproute2 sobre espaços de nomes descreve, mas a configuração da comutação do serviço de nomes e qualquer resolutor local que esta inicie ainda podem puxar uma consulta de volta para o anfitrião.

Um túnel de cada vez, o outro desligado

Liga A através do seu proprietário existente enquanto B fica em baixo, e depois inspeciona a política, as rotas e o caminho escolhido a partir do contexto de administração. Três dos comandos abaixo leem estado; só o último contacta um serviço de nomes, e nenhum deles envia um pedido de aplicação.

sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internal

Uma consulta de rota responde a uma pergunta hipotética sobre um destino, pelo que não pode mostrar que o serviço aceita tráfego. Guarda esses dois tipos de prova em colunas separadas, porque uma rota saudável ao lado de uma ligação recusada é um resultado real e comum. Depois envia um pedido autorizado e inofensivo com a aplicação real, lançada no contexto de A como o seu utilizador normal sem privilégios com a validação de certificados e a autenticação da aplicação intactas, e registra o resultado em conjunto com o endereço de origem que o serviço observou. Desliga A através do seu proprietário e repete toda a linha de base para B, anotando qualquer alteração de configuração que faças, ou as duas linhas de base deixam de ser comparáveis.

Ambos em cima, depois um em baixo de cada vez

O estado estável é a parte fácil. Com ambos os túneis ligados, repete a consulta e o pedido de aplicação de cada contexto, depois corta um túnel e verifica o outro. Reconecta na sequência inversa quando a própria ordem de ligação é a pergunta.

sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20

A captura resolve discussões que um resultado de aplicação não consegue: mostra se o pedido saiu pela interface que esperavas ou por algo completamente diferente. Para cada transição registra a ação do proprietário, a marca temporal, o resultado da rota, o resultado do nome e o desfecho da aplicação. Depois verifica o requisito de fecho seguro dentro do espaço de nomes afetado, porque o isolamento não é um interruptor de emergência. Um espaço de nomes mantém dois túneis separados; não impede nenhum deles de transportar tráfego quando o seu perfil diz que o tráfego tem de parar.

O que este registo pode e não pode afirmar

Um aprovado prova essas observações para esta disposição, neste anfitrião, naquele momento. Não diz nada sobre dois clientes que partilham uma tabela de encaminhamento de ambiente de trabalho, nem sobre o débito enquanto ambos os túneis transportam carga. São perguntas separadas com testes separados, e uma comparação vale o que valer o contexto anexado a cada linha.

Guarda as falhas no registo ao lado dos sucessos, etiquetadas com o túnel que estava ativo naquele momento. Uma página limpa que esconde o estado no momento da medição é pior do que uma feia que o mostra. O que torna o registo reutilizável mais tarde é o contexto, não a pontuação.

Dois túneis numa máquina podem ser comparados com honestidade, mas só dentro de tantos contextos quantos realmente controlaste. Qualquer coisa além disso é um desejo com um ícone verde ao lado.