Porque é que o seu serviço Linux público responde pela VPN

Nada no socket se lembra de qual interface transportou o pedido, por isso uma rota predefinida de VPN de túnel completo pode capturar uma resposta que pertence à WAN. O serviço não está a ignorar a interface de entrada; o Linux encaminha uma resposta gerada localmente por destino e política de origem. Uma regra baseada na origem pode, em vez disso, enviar apenas as respostas do serviço por uma tabela WAN completa, deixando a saída normal no túnel. A porta permanece aberta enquanto a resposta sai pelo caminho errado, e é por isso que o sintoma parece unilateral.

A ideia errada: as respostas seguem a interface por onde chegaram

Parece lógico que um pacote que chega em eth0 deva sair em eth0. Os filtros de pacotes sem estado podem ser escritos assim, e o tcpdump do lado de entrada mostra o pedido exatamente onde é esperado. O encaminhamento não funciona assim para o tráfego que o próprio anfitrião origina.

Assim que o serviço aceita a ligação, a resposta é um novo pacote gerado localmente. O kernel consulta as regras de encaminhamento para o destino e a origem da resposta, e a rota predefinida da VPN é uma resposta perfeitamente válida. Nada no socket se lembra de qual interface transportou o pedido.

É por isso que o sintoma parece unilateral: os pedidos chegam, as respostas desaparecem. É também por isso que acrescentar uma regra de firewall para a porta de entrada não muda nada. O pacote não está a ser bloqueado à entrada; está a ser encaminhado para outro lugar à saída. Siga a resposta com uma pesquisa qualificada pela origem e o desvio torna-se visível.

O que o kernel realmente encaminha: o endereço de origem

A pega de que precisa é o endereço local que o serviço usa para as respostas. Num anfitrião com o endereço eth0 ilustrativo 192.0.2.10/24 e a gateway 192.0.2.1, esse endereço está presente na interface. Numa VM na nuvem, o endereço público pode ser traduzido a montante e estar ausente no convidado, por isso use o endereço que o anfitrião realmente tem.

Inspecione o estado atual antes de reservar um número de tabela ou uma prioridade de regra. As regras de política existentes podem eclipsar uma nova, e uma tabela antiga com o mesmo número pode já transportar rotas não relacionadas:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Depois selecione uma tabela por origem. A regra corresponde às respostas que já transportam 192.0.2.10, exatamente o tráfego terminado localmente que quer isentar. O tráfego reencaminhado e os pacotes de outros endereços locais não correspondem.

Construa uma tabela de retorno completa, não meia rota predefinida

Uma tabela com apenas uma rota predefinida não basta. O kernel ainda tem de resolver a gateway, e essa resolução precisa do prefixo ligado na mesma tabela. Uma tabela à qual falta esse prefixo falha na resolução da gateway mesmo quando a sua rota predefinida parece correta. Acrescente os dois e depois aponte a regra de origem para a tabela:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Use o prefixo e a gateway reais em vez de copiar o exemplo. Uma interface na nuvem configurada como /32 com uma gateway on-link precisa de uma rota ligada diferente, e uma tabela construída a partir do prefixo errado falha no primeiro salto. O atributo src indica a origem preferida para essa rota; não substitui a regra de origem.

A ordem também importa. Uma regra ampla com um número de prioridade mais baixo é avaliada primeiro, por isso a regra de origem tem de ser alcançada antes de qualquer regra que devolvesse este tráfego à tabela principal. Verifique as prioridades com ip rule show depois de a acrescentar, não só no arranque.

Verifique com uma pesquisa qualificada pela origem

Peça ao kernel para encaminhar um destino de teste a partir do endereço do serviço. A resposta deve nomear eth0 e a gateway WAN, não o túnel:

ip -4 route get 198.51.100.25 from 192.0.2.10

Depois estabeleça uma nova ligação autorizada e observe as duas direções. Uma pesquisa que seleciona a tabela certa enquanto a ligação real ainda falha aponta para a filtragem de caminho inverso ou para uma regra de firewall, não para a tabela. Verifique esses controlos antes de desativar algo globalmente.

Coloque as rotas finais e a regra sob o gestor de rede que possui a interface. As alterações de endereço, a renovação de DHCP e as reconexões de VPN reescrevem todo o estado do kernel, e uma regra acrescentada à mão desaparece ou aponta para uma gateway obsoleta após o evento seguinte.

Onde esta exceção termina

A regra isenta o tráfego terminado localmente de um endereço de origem. Não cobre as portas publicadas pelo Docker, o DNAT nem os serviços reencaminhados através do anfitrião, porque esses pacotes são encaminhados como tráfego reencaminhado e nunca transportam a origem local do anfitrião da mesma forma. Esses desenhos costumam precisar de uma marca definida na entrada e de uma regra que corresponda à marca.

Também não faz aparecer o endereço público do anfitrião na interface. Quando um NAT a montante possui esse endereço, a resposta ainda tem de sair pelo caminho que esse NAT espera, e é por isso que a tabela WAN tem de refletir a gateway e o prefixo originais em vez de um intervalo público adivinhado.

Mantenha a exceção documentada com o número de tabela, a prioridade da regra e o endereço de origem exato. A próxima alteração na VPN ou na interface pode quebrá-la em silêncio, e uma nota que nomeie os três valores verifica-se mais depressa do que redescobrir o sintoma num relatório de cliente.

Se o serviço ainda responder pelo caminho errado depois de a pesquisa qualificada pela origem passar, compare o endereço de origem do socket ativo com o da regra. Um serviço ligado a um endereço genérico pode escolher uma origem diferente do endereço que testou, e essa discrepância é a lacuna restante.