As regras dos portos 80 e 443 non levan o navegador por unha VPN
Unha coincidencia de porto selecciona fluxos TCP, non un navegador. HTTP/3 funciona sobre UDP, o DNS pode tomar outro camiño e un actualizador coincide coa mesma regra que escribiu.
Alguén pide que o navegador use o túnel, e a solicitude volve como unha regra de cortalumes que coincide cos portos de destino 80 e 443. Parece precisa e non o é. Unha coincidencia de porto selecciona paquetes pola súa cabeceira de transporte, non por que programa abriu o socket, e a navegación moderna non se limita a eses dous portos sobre TCP. A regra omitirá tráfico que quería incluír e capturará tráfico que nunca pensou tocar. Antes de escribila, decida cal de tres fronteiras distintas quere en realidade.
A regra describe unha clase de transporte, non unha aplicación
En Linux, unha coincidencia de porto de destino inspecciona a cabeceira TCP e nada por riba. Marcar eses paquetes e dirixilos cunha ruta de política funciona exactamente como está documentado, e ningunha desas maquinarias sabe que significa a carga útil nin que proceso a enviou. A marca é un número pegado a un paquete, non unha identidade pegada a unha aplicación.
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 100Seguen dúas consecuencias de inmediato. Un actualizador de software que contacta TCP 443 recibe o mesmo trato que o navegador, o que pode estar ben ou pode ser unha caída que espera o seguinte ciclo de actualización. E un servizo web publicado a propósito noutro porto, digamos 8443, queda por completo fóra da regra aínda que siga sendo o tráfico web que lle importaba ao usuario.
Os números son selectores lexítimos cando o requisito trata realmente deses portos. Vólvense ficción cando no tícket está escrito «navegador» e no conxunto de regras se implementa un rango de portos. Esa fenda non é un detalle de documentación. É a diferenza entre unha regra que pode defender nunha revisión e outra que ninguén pode probar.
HTTP/3 abandona en silencio a súa regra de TCP
HTTP/3 funciona sobre QUIC, e QUIC viaxa en UDP. Unha regra que só coincide con TCP non pode velo, así que o mesmo navegador que aproba a súa páxina de proba pode enviar unha solicitude posterior por UDP e saltar o túnel sen que ninguén cambie un axuste. RFC 9114 describe HTTP/3 como un protocolo baseado en QUIC, e QUIC usa UDP cun porto predeterminado 443 no despregamento habitual.
Que un navegador concreto probe HTTP/3 depende da súa configuración, do sitio e de se un intento anterior tivo éxito. Iso fai que sexa mal asunto para razoar de memoria. Pregúntelle á ferramenta:
curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'A liña de curl imprime a versión negociada, así que un 3 confirma que se usou o camiño UDP. A listaxe de sockets mostra despois se esa conexión está ligada á interface do túnel ou á física. Se HTTP/3 non está dispoñible na súa compilación de curl, a opción falla ruidosamente en lugar de retroceder en silencio, o cal é a súa propia pequena misericordia.
O DNS é unha decisión aparte que debe tomar
Unha regra de porto para tráfico web non di nada sobre a resolución de nomes. O navegador pode usar o resolutor do sistema, un resolutor configurado dentro do navegador ou un que empuxase a última conexión. Cada un deles pode enviar consultas por un camiño distinto do que selecciona a súa regra, o que produce a escisión clásica: a páxina carga, o nome resólvese nun lugar que non esperaba e o sitio interno resólvese a un enderezo público ou non se resolve en absoluto.
Decídao explicitamente. Se os nomes internos deben resolverse a través do túnel, o resolutor ten que estar dentro del, e o conxunto de regras debe permitir DNS cara a ese resolutor mentres mantén fóra as demais consultas. Se o navegador usa DNS over HTTPS cara a un provedor público, a consulta evita por completo o seu resolutor e a regra de porto non pode axudar. Escriba a elección no mesmo rexistro de cambio que a regra de encamiñamento, porque quen depure o próximo fallo lerá ambos xuntos.
Logo verifique co resolutor e non coa páxina:
resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'Unha resposta ausente é un problema de resolución mesmo cando a mensaxe de erro do navegador culpa a rede. Eses dous fallos vense idénticos para un usuario e son tickets completamente distintos.
Tres fronteiras, tres mecanismos distintos
A maior parte da confusión desaparece en canto nomea a fronteira que quere. Non son intercambiables, e cada unha ten un modo de fallo distinto durante unha caída do 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 separado é a trampa da fila central. Separa cookies e historial, e non cambia nada da táboa de encamiñamento do equipo, así que ambos os perfís toman o mesmo camiño. O illamento require algo que impoña o núcleo, é dicir, un espazo de nomes, un contedor ou unha aplicación que posúa a súa propia interface de túnel.
Sexa cal sexa a fila que aplique, escriba que debe ocorrer cando o túnel caia. Unha ruta baseada en marca que desaparece coa interface adoita volver á ruta predeterminada física, que é un comportamento fail-open. Pode ser aceptable para navegar e inaceptable para calquera outra cousa, e é unha decisión, non un detalle de implementación.
Probe os fluxos que di cubrir
A proba de aceptación debe seguir a fronteira que escribiu, non os números de porto que resultaban cómodos. Escolla un fluxo que deba ir polo túnel, un que non deba e un que use un transporte no que non pensou:
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'A consulta de ruta dille que interface usa realmente un destino, e ese é o feito que máis informes equivocan. A liña de curl confirma a versión negociada e a familia de enderezos. O volcado do conxunto de regras atrapa a regra que engadiu durante as probas e esqueceu acoutar, e así é como unha marca temporal se converte en encamiñamento fail-open permanente.
Rexistre as tres saídas cunha marca de tempo e gárdeas co cambio. Cando máis tarde alguén informe de que «a VPN rompeu a intranet», a diferenza entre a fronteira prevista e a implementada será visible nese rexistro, e a solución será un cambio de regra e non unha discusión.