Encamiñar só un servizo web local fóra da VPN segundo o porto

Un servizo do host ten que responder a internet pola ligazón ascendente física mentres todo o demais da máquina segue usando o túnel. Tres condicións deciden se o encamiñamento baseado en políticas pode soportar esa carga, e cada unha é barata de comprobar antes de escribir unha regra. O servizo debe terminar neste host e non detrás dun DNAT ou dun porto reenviado, as propias regras da VPN deben permitir a excepción, e hai que facer coincidir a resposta en lugar da petición. Se falla calquera das tres, os comandos de abaixo cárganse sen erros pero non fan nada útil.

Comprobe as tres condicións antes de escribir unha regra

Un contedor que publica un porto mediante DNAT, ou un servidor detrás dun reenvío de porto, xera paquetes que non se orixinan neste host. Eses paquetes reenvíanse, así que unha regra baseada na entrada local do host nunca os ve e o tráfico segue tomando a ruta predeterminada. Confirme onde se executa realmente o servizo antes de continuar, porque é a condición que a xente adoita acertar menos.

A segunda condición é política e non mecánica. Calquera ruta que evite o túnel é unha excepción ao propósito do túnel, e nun host xestionado esa decisión corresponde a quen posúe a política, non a quen depura un tempo de espera.

Faga coincidir a resposta, non o porto de destino do cliente

A resposta dun servidor que escoita en TCP 443 sae do host co porto de orixe 443. Un navegador do mesmo host que se conecta a un sitio HTTPS remoto envía un porto de orixe efémero e un porto de destino 443. Ambos son tráfico do porto 443 e só un deles debería usar a táboa WAN, por iso unha coincidencia de porto de destino atraparía a metade equivocada.

A dirección da resposta é o que pode distinguir. Faga coincidir o porto de orixe, limite a regra a paquetes xerados localmente, e a regra cobre as respostas do propio servizo sen tocar as peticións do navegador.

Constrúa unha táboa de retorno completa antes de que a regra apunte a ela

Unha táboa baleira significa ningunha ruta, o que parece un servizo roto máis ca unha política rota. Enchénaa primeiro, cun número de táboa e unha prioridade que nada máis 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

Lea os números do host en vivo en lugar de copialos. ip -4 rule show dille que prioridades están ocupadas, e engadir unha regra nunha prioridade que xa existe cambia en silencio a orde de dúas regras que por separado parecen correctas.

Dous selectores fan o traballo real aquí. iif lo é como o núcleo informa dos paquetes que o host xerou el mesmo, así que a regra non pode capturar por accidente tráfico reenviado que chega de fóra. ipproto tcp sport 443 redúceo a un transporte e un porto, que é tan axustado como o requisito permite. Quite o selector de protocolo e a regra tamén atrapará UDP 443, que é outro servizo con outro comportamento.

Manteña as respostas privadas dentro do túnel

Se o mesmo oínte tamén responde a clientes do lado privado, unha ruta WAN predeterminada que o atrapa todo na táboa 100 tentará devolver esas respostas pola ligazón ascendente. Engada os prefixos privados que non deben seguir a ruta WAN predeterminada, ou déixeos caer á seguinte regra de política:

ip -4 route add table 100 throw 10.90.0.0/24

Unha ruta throw termina a busca nesta táboa e devolve o paquete á lista de regras, así que a política VPN que segue ten a súa oportunidade. Non encamiña nada ao túnel por si mesma, e se ningunha regra posterior ten unha ruta coincidente o paquete segue fallando; verifique a política seguinte en lugar de supoñer que o throw é unha solución.

O filtrado de ruta inversa e as regras da devasa do host seguen aplicándose á petición que chega. Mire os seus veredictos reais antes de afrouxar a validación, porque unha excepción de encamiñamento non fai que rp_filter acepte unha ruta de retorno que considera imposible.

Probe TCP, despois QUIC, despois un reinicio

Abra unha conexión desde un cliente externo autorizado e outra desde o lado privado, e logo inspeccione a busca de resposta coas direccións e os portos reais. Se a resposta externa toma a táboa 100 e a privada non, a política fai o que pediu.

HTTP/3 sérvese por UDP e unha regra TCP non o fará coincidir, así que un oínte QUIC necesita o seu propio selector ou seguirá usando o túnel mentres HTTPS funciona. Persista as regras que elixa co compoñente que posúe a interface, e confírmelas tras unha reconexión ou unha renovación DHCP. Cando un xestor competidor elimina unha ruta en tempo de execución tras un reinicio, iso é un problema de propiedade que hai que arranxar na orixe, non un motivo para engadir regras NAT máis amplas enriba.