Teste o roteamento VPN em namespaces sem tocar nas rotas do host

Dois laboratórios podem modelar a mesma topologia VPN e falhar de formas completamente diferentes: um vive em namespaces de rede, o outro nas rotas do próprio host. A versão com namespaces mantém cada interface, rota e socket num contexto que você pode apagar, enquanto a versão no host arranca mais depressa e deixa estado atrás. Esse estado residual é a razão pela qual o segundo laboratório é difícil de repetir um mês depois. Compare primeiro a limpeza, porque é ela que decide se você pode executar a experiência duas vezes.

Duas formas de construir o mesmo laboratório, e quando cada uma ganha

Num laboratório de rotas do host, você adiciona uma interface de túnel e rotas à máquina em que trabalha, por isso a experiência partilha o destino com a sua shell, o seu gestor de pacotes e qualquer outra ligação. Num laboratório de namespaces, cada papel recebe a sua própria pilha de interfaces, endereços, rotas e sockets, e apagar o namespace remove tudo isso. Nenhum dos modelos é mais correto, porque respondem a perguntas diferentes. Escolha namespaces quando o tema é o roteamento e o encaminhamento, e um laboratório no host quando o tema é como um cliente de ambiente de trabalho se integra.

Misturar os dois é o erro habitual: um laboratório de namespaces testado contra um cliente que só existe no host não prova nada sobre nenhuma das duas disposições. Decida que pergunta está a fazer antes de criar a primeira ligação.

Um contexto por papel, ligado de propósito

Crie um namespace por papel e mova cada extremidade de cada par veth para o contexto que o possui. Os primeiros quatro comandos bastam para ver a forma:

ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns client

Dê ao laboratório intervalos que não se sobreponham a nada no host, e anote antes de começar que namespace possui que endereço. Um laboratório que funcione precisa de dois caminhos separados: um exterior para o ponto final VPN chegar ao seu par, e um caminho de regresso para o recurso que é protegido. Modela-os como duas decisões, porque um laboratório que só constrói a metade de saída passa um teste de aperto de mão e falha um teste de aplicação.

O papel de encaminhamento é onde os laboratórios ficam interessantes

Um papel tem de encaminhar, o que significa ativar o encaminhamento dentro desse namespace e acrescentar a regra de que o desenho precisa. O estado de encaminhamento é por namespace, por isso a configuração do host é irrelevante para o laboratório e a configuração do laboratório não escapa para fora, como descreve a documentação sobre namespaces de rede. O WireGuard documenta que uma interface e o seu socket exterior podem viver em namespaces diferentes, o que é um truque útil e uma excelente forma de se confundir. Não assuma que mover uma interface move cada parte da ligação da mesma maneira.

Verifique o contador de encaminhamento depois de um pacote de teste, porque uma regra que nunca correspondeu e uma regra que descartou parecem idênticas na tabela de rotas. Só os contadores as separam.

Registe uma linha de base, depois quebre uma rota

Comece por registar o que existe, com o contexto escrito ao lado de cada linha. Leia os namespaces, depois a rota que um destino de teste tomaria dentro de um deles, depois os contadores na ligação que a transporta:

ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-g

O terceiro comando é aquele que as pessoas saltam, e é aí que vive a evidência: os contadores de descartes e erros dizem se um pacote chegou sequer ao papel de encaminhamento. Registe as mesmas três vistas depois de uma alteração, e deixe o diff ser a evidência em vez da sua memória. Depois quebre exatamente uma coisa, seja apagando uma rota ou acrescentando uma regra de negação no caminho de encaminhamento, e confirme o sintoma que previu: um aperto de mão concluído sem resposta, ou uma falha de resolução em vez de um tempo limite. Um laboratório que só demonstra sucesso ensina muito pouco.

A limpeza é o que torna a execução seguinte repetível

Mantenha a limpeza limitada aos recursos que nomeou, porque um reinício geral da firewall ou a remoção de uma rota do host não é reprodutibilidade, é um segundo incidente. Guarde a topologia, os comandos exatos e as observações que esperava, para que a execução seguinte reproduza a mesma falha em vez de adivinhar que contexto tinha o estado anterior. Sem esse registo o laboratório é uma história e não um procedimento.

Use credenciais geradas localmente para o laboratório e mantenha as contas de produção fora dos exemplos partilhados. Depois apague cada namespace e confirme que a vista do host não mudou, que é toda a razão para escolher este modelo. Um laboratório que não consegue remover de forma limpa é uma alteração ao host com passos extra.