O servidor web desaparece quando o cliente VPN se liga

Um serviço que desaparece no momento em que um cliente VPN se liga normalmente não está bloqueado, está a responder pela interface errada. O pedido chega à placa de rede física, o daemon escreve uma resposta e a tabela de encaminhamento entrega essa resposta ao túnel, uma vez que o túnel assumiu a rota predefinida. O cliente remoto nunca vê uma resposta a uma ligação que abriu, por isso espera e depois comunica um tempo limite. Nenhuma regra de firewall intervém em qualquer ponto dessa sequência.

O sintoma: pedidos para dentro, respostas pela porta errada

O indício é uma ligação de entrada que falha enquanto tudo o resto no host funciona. Outro indício é um host acessível a partir da LAN mas não da internet, ou um que funciona até o túnel se voltar a ligar e depois para. Em cada caso a direção de ida comportava-se bem e a de volta não, o que aponta para uma assimetria de encaminhamento e não para uma política.

Confirme-o observando para onde vai a resposta, não observando como chega o pedido.

Capture em simultâneo na interface física e no dispositivo do túnel. Se o pedido aparecer na interface física e a resposta no túnel, o diagnóstico está concluído. Uma resposta que não aparece em lado nenhum significa que o serviço nunca aceitou a ligação, o que é uma investigação separada com uma causa separada.

Duas rotas predefinidas e uma decisão de encaminhamento

Um cliente que instala uma rota predefinida acrescenta uma segunda entrada com uma métrica melhor do que a do gateway da LAN. Alguns clientes instalam, em vez disso, duas rotas de meio intervalo, que cobrem o mesmo espaço de forma mais específica e ganham a procura da mesma maneira. Ambas as técnicas deixam os pacotes de saída comuns escolher a interface do túnel.

Essa escolha é feita apenas pelo destino. O kernel não pergunta de onde veio um pacote a menos que uma regra de política lho ordene. Assim, a resposta para um endereço público de cliente é entregue ao túnel, cujo extremo remoto recebe um pacote com um endereço de origem que não possui e o descarta ou o reencaminha para um local inútil. No Linux, a filtragem estrita do caminho inverso também pode descartar o pedido original antes de o seu serviço o ver, o que do exterior parece idêntico. Ambos os sintomas vêm da mesma associação em falta entre um fluxo de entrada e a sua resposta.

O túnel comporta-se corretamente o tempo todo. Foi-lhe dito para transportar a rota predefinida e faz exatamente isso.

Corrija o caminho de volta sem quebrar o túnel

Existem três formas duradouras de reparação, e a escolha depende de quanto do tráfego próprio do host deve ficar dentro do túnel. Excluir o destino ou a porta do serviço é a alteração mais pequena. O encaminhamento por política segundo a origem ou a marca é o mais preciso. A tradução de origem é a mais grosseira e a mais fácil de explicar dois anos depois.

Escolha pelo que o host tem de fazer, não pelo fragmento que encontrou primeiro.

Excluir um destino serve para um serviço com um endereço público estável, e ligar o daemon ao endereço físico em vez de a todos os endereços torna essa exclusão mais segura. Uma regra de política que escolhe uma tabela pela origem mantém as ligações próprias do host dentro do túnel ao mesmo tempo que devolve as respostas do serviço pelo gateway WAN. Mascarar as respostas na interface WAN chega ao mesmo caminho à custa de esconder o endereço do cliente dos registos do serviço. Uma alteração ad hoc da rota predefinida é um diagnóstico e não uma configuração, porque o cliente reescreve as rotas em cada reconexão.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Quando o host também encaminha para uma LAN atrás de si

Um salto mais para fora, a mesma assimetria regressa com mais peças móveis. O tráfego chega ao router a partir da internet, é reencaminhado para um dispositivo interno, e o único caminho de volta desse dispositivo é o túnel, pelo que a resposta chega ao cliente original a partir do endereço do próprio fornecedor. O rastreio de ligações encontra então uma resposta para um fluxo cujo início não viu, e descarta-a. O cliente, entretanto, não vê absolutamente nada.

Duas alterações corrigem isso: tradução de destino para que a ligação de entrada chegue ao dispositivo interno, e tradução de origem para que a resposta desse dispositivo pareça vir do próprio router.

No firmware do router a expressão habitual é uma regra de política que fixa o reencaminhamento de portas do lado WAN enquanto o tráfego próprio do router viaja pelo túnel. Sem tradução de origem, essa resposta é endereçada ao cliente externo e o dispositivo interno simplesmente não tem rota para ela. Teste três coisas em separado, porque falham por razões diferentes: uma ligação que vem de fora, uma que o host inicia e uma consulta de nome.