Les regles dels ports 80 i 443 no fan passar el navegador per una VPN
Una coincidència de port selecciona fluxos TCP, no un navegador. HTTP/3 funciona sobre UDP, el DNS pot prendre un altre camí i un actualitzador coincideix amb la mateixa regla que heu escrit.
Algú demana que el navegador faci servir el túnel, i la sol·licitud torna com una regla de tallafoc que coincideix amb els ports de destinació 80 i 443. Sembla precisa i no ho és. Una coincidència de port selecciona paquets per la seva capçalera de transport, no per quin programa ha obert el sòcol, i la navegació moderna no es limita a aquests dos ports sobre TCP. La regla deixarà fora part del trànsit que volíeu incloure i capturarà trànsit que no pensàveu tocar mai. Abans d'escriure-la, decidiu quina de les tres fronteres diferents voleu realment.
La regla descriu una classe de transport, no una aplicació
A Linux, una coincidència de port de destinació inspecciona la capçalera TCP i res per sobre. Marcar aquests paquets i encaminar-los amb una ruta de política funciona exactament com està documentat, i cap d'aquests mecanismes sap què significa la càrrega ni quin procés l'ha enviada. La marca és un número enganxat a un paquet, no una identitat enganxada a una aplicació.
nft add rule inet mangle output tcp dport { 80, 443 } meta mark set 0x1
ip rule add fwmark 0x1 table 100
ip route add default dev wg0 table 100Se'n desprenen dues conseqüències de seguida. Un actualitzador de programari que contacta amb TCP 443 rep el mateix tracte que el navegador, cosa que pot estar bé o pot ser una caiguda que espera el següent cicle d'actualització. I un servei web publicat deliberadament en un altre port, diguem-ne 8443, queda completament fora de la regla tot i ser el trànsit web que importava a l'usuari.
Els números són selectors legítims quan el requisit tracta realment d'aquests ports. Esdevenen una ficció quan al tiquet hi ha escrit «navegador» i a la regla s'implementa un interval de ports. Aquest buit no és un refinament de documentació. És la diferència entre una regla que podeu defensar en una revisió i una que ningú no pot provar.
HTTP/3 abandona en silenci la vostra regla de TCP
HTTP/3 funciona sobre QUIC, i QUIC es transporta en UDP. Una regla que només coincideix amb TCP no el pot veure, així que el mateix navegador que satisfà la vostra pàgina de prova pot enviar una sol·licitud posterior per UDP i saltar-se el túnel sense que ningú canviï cap paràmetre. RFC 9114 descriu HTTP/3 com un protocol basat en QUIC, i QUIC fa servir UDP amb un port per defecte 443 en el desplegament habitual.
Que un navegador concret provi HTTP/3 depèn de la seva configuració, del lloc i de si un intent anterior va reeixir. Això el converteix en una cosa difícil de raonar de memòria. Pregunteu-ho a l'eina:
curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'La línia de curl imprimeix la versió negociada, així que un 3 confirma que s'ha utilitzat el camí UDP. La llista de sòcols mostra després si aquesta connexió està lligada a la interfície del túnel o a la física. Si HTTP/3 no és disponible a la vostra compilació de curl, el paràmetre falla sorollosament en lloc de retrocedir en silenci, cosa que és la seva petita mercè.
El DNS és una decisió separada que heu de prendre
Una regla de port per al trànsit web no diu res sobre la resolució de noms. El navegador pot fer servir el resolutor del sistema, un resolutor configurat dins del navegador o un que hagi empès l'última connexió. Cadascun pot enviar consultes per un camí diferent del que selecciona la vostra regla, cosa que produeix l'escissió clàssica: la pàgina es carrega, el nom es resol en un lloc que no esperàveu i el lloc intern es resol a una adreça pública o no es resol de cap manera.
Decidiu-ho explícitament. Si els noms interns s'han de resoldre a través del túnel, el resolutor ha de ser a dins, i el conjunt de regles ha de permetre DNS cap a aquest resolutor mentre manté fora les altres consultes. Si el navegador fa servir DNS over HTTPS cap a un proveïdor públic, la consulta evita del tot el vostre resolutor i la regla de port no hi pot ajudar. Escriviu l'elecció al mateix registre de canvi que la regla d'encaminament, perquè les dues coses les llegeix juntes qui depuri la propera fallada.
Després verifiqueu-ho amb el resolutor i no amb la pàgina:
resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'Una resposta absent és un problema de resolució fins i tot quan el missatge d'error del navegador culpa la xarxa. Aquestes dues fallades semblen idèntiques a l'usuari i són tiquets completament diferents.
Tres fronteres, tres mecanismes diferents
La major part de la confusió desapareix quan anomeneu la frontera que voleu. No són intercanviables, i cadascuna té un mode de fallada diferent durant una caiguda del túnel.
| What you actually want | Mechanism that fits | What it does not cover |
|---|---|---|
| These transport ports use this exit | Firewall mark plus policy route | Applications, HTTP/3 over UDP, DNS |
| This browsing session stays separate | Application-aware VPN, or a separate network namespace plus a proxy | Other applications in the same session |
| Only these private sites are reachable | Destination-based routes with private DNS | Public sites on the same address family |
Un perfil de navegador separat és el parany de la fila del mig. Separa galetes i historial, i no canvia res de la taula d'encaminament de l'equip, així que tots dos perfils prenen el mateix camí. L'aïllament requereix alguna cosa que imposi el nucli, és a dir, un espai de noms, un contenidor o una aplicació que posseeixi la seva pròpia interfície de túnel.
Sigui quina sigui la fila que s'aplica, escriviu què ha de passar quan el túnel caigui. Una ruta basada en marca que desapareix amb la interfície sol retrocedir a la ruta per defecte física, que és un comportament fail-open. Pot ser acceptable per navegar i inacceptable per a qualsevol altra cosa, i és una decisió, no un detall d'implementació.
Proveu els fluxos que dieu que cobriu
La prova d'acceptació ha de seguir la frontera que heu escrit, no els números de port que eren convenients. Triau un flux que ha d'anar pel túnel, un que no hi ha d'anar i un que faci servir un transport en què no pensàveu:
ip route get 203.0.113.40
curl -sS -o /dev/null -w 'v4 %{http_version} %{remote_ip}\n' https://example.com
nft list ruleset | grep -A2 'dport'La consulta de ruta us diu quina interfície fa servir realment una destinació, i aquest és el fet que la majoria d'informes erròniament. La línia de curl confirma la versió negociada i la família d'adreces. L'abocament del conjunt de regles atrapa la regla que vau afegir durant les proves i vau oblidar delimitar, i així és com una marca temporal es converteix en encaminament fail-open permanent.
Registreu les tres sortides amb una marca de temps i guardeu-les amb el canvi. Quan més endavant algú informi que «la VPN ha trencat la intranet», la diferència entre la frontera prevista i la implementada serà visible en aquest registre, i la solució serà un canvi de regla i no una discussió.