A resposta sai pela LAN, não pelo túnel: porquê e como

Um serviço publicado através de uma gateway funciona a partir da maior parte da internet e falha a partir de um escritório. Alguém verifica o túnel, vê o pedido chegar e conclui que a resposta deve seguir o mesmo caminho de volta. O Linux não funciona assim, e nenhuma inspeção do túnel mudará a resposta. A resposta é encaminhada por destino, e esse único requerente que falha está numa sub-rede que o anfitrião já alcança diretamente.

O que decide realmente um pacote de saída

O kernel procura uma rota para o destino do pacote, consultando as regras de política por ordem de prioridade e depois a tabela que uma regra correspondente seleciona. A interface por onde um pacote chegou não desempenha qualquer papel, a menos que tenha sido escrita uma regra ou marca para tornar isso relevante. É um facto de encaminhamento deste anfitrião, não uma falha no túnel.

Um pedido recebido pelo túnel pode, portanto, produzir uma resposta que sai pela interface física, e o fluxo torna-se unidirecional sem que qualquer dispositivo comunique um erro. Verifique ambos os sentidos antes de tirar uma conclusão sobre o túnel. Uma resposta que sai pelo lado errado desaparece dos contadores do túnel, e é por isso que os dois extremos não concordam sobre se algo foi enviado. Repare em que contador se alterou antes de mexer numa regra.

Porque é que a sub-rede local ganha

Um anfitrião com um endereço numa rede local tem uma rota conectada para esse prefixo na tabela principal, e uma rota conectada é uma correspondência direta. Quando o requerente vem da mesma sub-rede, a pesquisa encontra a ligação local antes de o túnel ser sequer considerado.

É a assimetria que torna o diagnóstico confuso. Os requerentes do resto da internet funcionam porque não correspondem a nenhuma rota local, enquanto o único requerente que partilha o prefixo do escritório falha, e é exatamente esse o requerente com que alguém testa.

A cobertura de pares não é o mesmo que as rotas instaladas

Do lado do túnel, os intervalos permitidos de um par descrevem o que pode ser enviado para o túnel e que fontes são aceites dele. Não dizem nada sobre para onde a tabela de encaminhamento local enviará um pacote.

Se a ferramenta do túnel instalar uma rota predefinida no anfitrião, pode arrastar tráfego não relacionado para o túnel como dano colateral. Onde deveria ser uma regra de política a deter a decisão, a opção de instalação de rotas da ferramenta existe precisamente para o impedir, e os endereços, as chaves e as definições do ponto final permanecem exatamente como estavam. Uma rota predefinida adicionada por conveniência é uma forma comum de um anfitrião perder a sua própria rede local.

Escolha a tabela pelo endereço de origem

Uma regra baseada na origem envia as respostas do endereço do serviço para uma tabela privada cujo valor predefinido é o túnel, enquanto todo o resto continua a usar a tabela principal. Escolha números de tabela e de prioridade que não sejam usados localmente, e leia as regras existentes antes de inserir algo. Leia as regras ativas em vez de um ficheiro guardado, porque os dois podem diferir após um reinício.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

A última linha faz com que uma rota ausente falhe de forma visível em vez de recair na ligação local. A origem tem de estar realmente atribuída ao anfitrião, e as pesquisas locais e principais comuns têm de permanecer nas suas posições anteriores. A regra escolhe uma tabela por origem; não compara comprimentos de prefixo entre tabelas.

Confirme o caminho e depois o serviço

Pergunte ao kernel o que faria em vez de inferir de uma captura, usando o endereço do serviço como seletor de origem. Uma resposta correta aqui poupa todo um rastreio de pacotes.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

A saída deve nomear o túnel. Depois teste uma origem que não tocou e confirme que continua a usar a ligação local, para que a alteração tenha ficado limitada a um endereço. Um seletor mais amplo não provaria nada sobre a queixa original.

O que isto não corrige

Deixe o encaminhamento, as regras da firewall e o comportamento do ICMPv6 na gateway como estavam, porque uma rota de origem não substitui nenhum deles. Uma mensagem Packet Too Big em falta continua a quebrar as respostas grandes, ganhe a pesquisa a tabela que ganhar. Corrija isso antes de acrescentar regras de encaminhamento, ou o sintoma sobreviverá à alteração.

Confirme o modelo de publicação antes de aplicar qualquer coisa disto. Um proxy inverso que abre a sua própria ligação de backend apresenta a sua própria origem e não preserva o requerente, pelo que esta falha não pode ocorrer nesse desenho. Aplicar a regra ali acrescentaria uma exceção de encaminhamento que não resolve nada e esconde a causa real.

Por fim, escreva os números das regras e a tabela na gestão de configuração do anfitrião. Uma regra de política acrescentada à mão desaparece na reconstrução seguinte, e o requerente do escritório volta com a mesma queixa.