Encaminhar apenas um serviço web local fora da VPN pela porta

Um serviço do host tem de responder à internet pelo enlace ascendente físico enquanto tudo o resto na máquina continua a usar o túnel. Três condições decidem se o encaminhamento baseado em políticas consegue suportar essa carga, e cada uma é barata de verificar antes de escrever uma regra. O serviço tem de terminar neste host e não atrás de um DNAT ou de uma porta reencaminhada, as próprias regras da VPN têm de permitir a exceção, e tem de fazer corresponder a resposta em vez do pedido. Se falhar qualquer das três, os comandos abaixo carregam sem erros mas não fazem nada de útil.

Verifique as três condições antes de escrever uma regra

Um contentor que publica uma porta por DNAT, ou um servidor atrás de um reencaminhamento de porta, gera pacotes que não se originam neste host. Esses pacotes são reencaminhados, por isso uma regra baseada na entrada local do host nunca os vê e o tráfego continua a seguir a rota predefinida. Confirme onde o serviço corre realmente antes de continuar, porque é a condição em que as pessoas erram mais vezes.

A segunda condição é política e não mecânica. Qualquer rota que contorne o túnel é uma exceção ao propósito do túnel, e num host gerido essa decisão pertence a quem detém a política, não a quem depura um tempo limite.

Faça corresponder a resposta, não a porta de destino do cliente

A resposta de um servidor à escuta em TCP 443 sai do host com a porta de origem 443. Um navegador no mesmo host que se liga a um site HTTPS remoto envia uma porta de origem efémera e a porta de destino 443. Ambas são tráfego da porta 443 e só uma delas deve usar a tabela WAN, e é por isso que uma correspondência na porta de destino apanharia a metade errada.

A direção da resposta é o que consegue distinguir. Faça corresponder a porta de origem, limite a regra aos pacotes gerados localmente, e a regra cobre as respostas do próprio serviço sem tocar nos pedidos do navegador.

Construa uma tabela de retorno completa antes de a regra apontar para ela

Uma tabela vazia significa nenhuma rota, o que parece um serviço avariado em vez de uma política avariada. Preencha-a primeiro, com um número de tabela e uma prioridade que nada mais no host reclame:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Leia os números do host em funcionamento em vez de os copiar. ip -4 rule show indica que prioridades estão ocupadas, e acrescentar uma regra a uma prioridade que já existe altera silenciosamente a ordem de duas regras que, por si só, parecem corretas.

Dois seletores fazem aqui o trabalho real. iif lo é a forma como o kernel reporta os pacotes que o próprio host gerou, pelo que a regra não pode capturar acidentalmente tráfego reencaminhado que chega de fora. ipproto tcp sport 443 restringe-o a um transporte e a uma porta, o que é tão apertado quanto o requisito permite. Retire o seletor de protocolo e a regra também apanha UDP 443, que é outro serviço com outro comportamento.

Mantenha as respostas privadas dentro do túnel

Se o mesmo ouvinte também responde a clientes do lado privado, uma rota WAN predefinida que apanha tudo na tabela 100 tentará devolver essas respostas pelo enlace ascendente. Acrescente os prefixos privados que não devem seguir a rota WAN predefinida, ou deixe-os cair para a regra de política seguinte:

ip -4 route add table 100 throw 10.90.0.0/24

Uma rota throw termina a pesquisa nesta tabela e devolve o pacote à lista de regras, pelo que a política VPN que se segue tem a sua oportunidade. Não encaminha nada para o túnel por si mesma, e se nenhuma regra posterior tiver uma rota correspondente o pacote falha na mesma; verifique a política seguinte em vez de assumir que o throw é uma correção.

A filtragem de caminho inverso e as regras da firewall do host continuam a aplicar-se ao pedido que chega. Veja os seus veredictos reais antes de relaxar a validação, porque uma exceção de encaminhamento não faz com que rp_filter aceite um caminho de retorno que considera impossível.

Teste TCP, depois QUIC, depois um reinício

Abra uma ligação de um cliente externo autorizado e outra do lado privado, e depois inspecione a pesquisa da resposta com os endereços e as portas reais. Se a resposta externa usar a tabela 100 e a privada não, a política faz o que pediu.

HTTP/3 é servido por UDP e não será correspondido por uma regra TCP, pelo que um ouvinte QUIC precisa do seu próprio seletor, caso contrário continuará a usar o túnel enquanto o HTTPS funciona. Guarde as regras com que ficar no componente que detém a interface, e confirme-as após uma reconexão ou uma renovação DHCP. Quando um gestor concorrente remove uma rota em tempo de execução após um reinício, isso é um problema de propriedade a corrigir na origem, não um motivo para acrescentar regras NAT mais amplas por cima.