Encamina només un servei web local fora de la VPN segons el port

Un servei de l'amfitrió ha de respondre a internet per l'enllaç ascendent físic mentre tota la resta de la màquina continua usant el túnel. Tres condicions decideixen si l'encaminament basat en polítiques pot suportar aquesta càrrega, i cadascuna és barata de comprovar abans d'escriure una regla. El servei ha d'acabar en aquest amfitrió, no darrere d'un DNAT ni d'un port reenviat, les regles pròpies de la VPN han de permetre l'excepció, i heu de fer coincidir la resposta, no la petició. Si falla qualsevol de les tres, les ordres de sota es carreguen sense errors però no fan res d'útil.

Comproveu les tres condicions abans d'escriure una regla

Un contenidor que publica un port mitjançant DNAT, o un servidor darrere d'un reenviament de port, genera paquets que no s'originen en aquest amfitrió. Aquests paquets es reenvien, així que una regla basada en l'entrada local de l'amfitrió no els veu mai i el trànsit continua agafant la ruta per defecte. Confirmeu on s'executa realment el servei abans de continuar, perquè aquesta és la condició que la gent sol encertar menys.

La segona condició és política, no mecànica. Qualsevol ruta que eviti el túnel és una excepció a la finalitat del túnel, i en un amfitrió gestionat aquesta decisió correspon a qui posseeix la política, no a qui depura un temps d'espera.

Feu coincidir la resposta, no el port de destinació del client

La resposta d'un servidor que escolta a TCP 443 surt de l'amfitrió amb el port d'origen 443. Un navegador del mateix amfitrió que es connecta a un lloc HTTPS remot envia un port d'origen efímer i un port de destinació 443. Tots dos són trànsit del port 443 i només un hauria d'usar la taula WAN, i per això una coincidència de port de destinació agafaria la meitat equivocada.

La direcció de la resposta és el que podeu distingir. Feu coincidir el port d'origen, limiteu la regla als paquets generats localment, i la regla cobreix les respostes del propi servei sense tocar les peticions del navegador.

Construïu una taula de retorn completa abans que la regla hi apunti

Una taula buida vol dir cap ruta, cosa que sembla un servei trencat més que no pas una política trencada. Ompliu-la primer, amb un número de taula i una prioritat que cap altra cosa de l'amfitrió no reclami:

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

Llegiu els números de l'amfitrió en viu en lloc de copiar-los. ip -4 rule show us diu quines prioritats estan ocupades, i afegir una regla en una prioritat que ja existeix canvia en silenci l'ordre de dues regles que per separat semblen correctes.

Dos selectors fan la feina de debò aquí. iif lo és com el nucli informa dels paquets que l'amfitrió ha generat ell mateix, així que la regla no pot capturar per accident trànsit reenviat que arriba de fora. ipproto tcp sport 443 ho estreny a un transport i un port, que és tan ajustat com el requisit permet. Traieu el selector de protocol i la regla també atraparà UDP 443, que és un altre servei amb un altre comportament.

Manteniu les respostes privades dins del túnel

Si el mateix oient també respon clients del costat privat, una ruta WAN per defecte que ho atrapa tot a la taula 100 intentarà retornar aquestes respostes per l'enllaç ascendent. Afegiu els prefixos privats que no han de seguir la ruta WAN per defecte, o feu-los caure cap a la regla de política següent:

ip -4 route add table 100 throw 10.90.0.0/24

Una ruta throw acaba la cerca en aquesta taula i retorna el paquet a la llista de regles, així que la política VPN que segueix té la seva oportunitat. No encamina res al túnel per si mateixa, i si cap regla posterior té una ruta coincident el paquet encara falla; verifiqueu la política següent en lloc d'assumir que el throw és una solució.

El filtratge de camí invers i les regles del tallafoc de l'amfitrió encara s'apliquen a la petició que arriba. Mireu els seus veredictes reals abans d'afluixar la validació, perquè una excepció d'encaminament no fa que rp_filter accepti un camí de retorn que considera impossible.

Proveu TCP, després QUIC, després un reinici

Obriu una connexió des d'un client extern autoritzat i una des del costat privat, i després inspeccioneu la cerca de resposta amb les adreces i els ports reals. Si la resposta externa agafa la taula 100 i la privada no, la política fa el que heu demanat.

HTTP/3 se serveix per UDP i una regla TCP no el farà coincidir, així que un oient QUIC necessita el seu propi selector o continuarà usant el túnel mentre HTTPS funciona. Persistiu les regles que trieu amb el component que posseeix la interfície, i confirmeu-les després d'una reconnexió o una renovació DHCP. Quan un gestor competidor elimina una ruta en temps d'execució després d'un reinici, això és un problema de propietat que cal arreglar a l'origen, no un motiu per afegir regles NAT més àmplies a sobre.