D'Regele fir Port 80 an 443 schécken de Browser net duerch eng VPN
Eng Portübereestëmmung wielt TCP-Flëss, net e Browser. HTTP/3 leeft iwwer UDP, DNS kann en anere Wee huelen, an en Updater trëfft déi selwecht Regel, déi Dir geschriwwen hutt.
Een freet, datt de Browser den Tunnel soll benotzen, an d'Äntwert kënnt als Firewallregel zréck, déi op d'Destinatiounsporte 80 an 443 passt. Si gesäit präzis aus an ass et net. Eng Portübereestëmmung wielt Paketen no hirem Transportheader, net no deem, wéi engem Programm de Socket opgemaach huet, an dat modernt Surfen ass net op déi zwee Porte iwwer TCP beschränkt. D'Regel wäert en Deel vum Verkéier verpassen, deem Dir wëllt abezéien, an de Verkéier fänken, deen Dir ni wëllt beréieren. Ier Dir se schreift, entscheet, wat fir eng vun dräi verschiddene Grenzen Dir wierklech wëllt.
D'Regel beschreift eng Transportklass, net eng Applikatioun
Op Linux ënnersicht eng Destinatiounsportübereestëmmung den TCP-Header an näischt driwwer. Dës Pakete markéieren an se mat enger Politikroute leede funktionnéiert genee wéi dokumentéiert, an keng vun dëse Maschinnen weess, wat d'Payload bedeit oder wéi ee Prozess se geschéckt huet. D'Mark ass eng Zuel, déi un e Paket ugehaangen ass, net eng Identitéit, déi un eng Applikatioun ugehaangen ass.
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 100Zwee Konsequenzen entstinn direkt. En Software-Updater, deen TCP 443 kontaktéiert, kritt déi selwecht Behandlung wéi de Browser, wat ka gutt sinn oder en Ausfall, deen op den nächsten Updatezyklus waart. An e Websservice, dee bewosst op engem aneren Port publizéiert ass, soe mir 8443, fält komplett aus der Regel, obwuel et nach ëmmer de Webverkéier ass, deen den Notzer intresséiert huet.
D'Zuele sinn legitim Selektoren, wann d'Ufuerderung wierklech déi Porten betrëfft. Si ginn eng Fiktioun, wann am Ticket „Browser“ steet an am Reegelset en Portberäich ëmgesat gëtt. Dëse Gruef ass keng Dokumentatiouns-Klengelei. Et ass den Ënnerscheed tëscht enger Regel, déi Dir an enger Iwwerpréiwung verdeedege kënnt, an enger, déi kee ka testen.
HTTP/3 verléisst Är TCP-Regel roueg
HTTP/3 leeft iwwer QUIC, an QUIC gëtt an UDP gedroen. Eng Regel, déi nëmmen TCP entsprécht, kann et net gesinn, also kann dee selwechte Browser, deen Är Testsäit erfëllt, eng spéider Ufro iwwer UDP schécken an den Tunnel ëmgoen, ouni datt een eng Astellung ännert. RFC 9114 beschreift HTTP/3 als en QUIC-baséierte Protokoll, an QUIC benotzt UDP mat engem Standardport 443 an der üblecher Ausrollung.
Ob en bestëmmte Browser HTTP/3 probéiert, hänkt vunenger Konfiguratioun, vun der Säit an dovun of, ob en früheren Versuch gelungen ass. Dat mécht et eng schlecht Saach, aus dem Gediechtnes driwwer ze raisonéieren. Frot d'Instrument amplaz:
curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'D'curl-Linn dréckt déi ausgehandelt Versioun, also bestätegt eng 3, datt den UDP-Wee benotzt gouf. D'Socketlëscht weist duerno, ob déi Verbindung un d'Tunnelschnittstell oder un déi physesch gebonnen ass. Wann HTTP/3 net an Ärem curl-Build verfügbar ass, schléit de Fändel haart fehl, amplaz roueg zréckzefalen, wat seng eege kleng Barmhäerzegkeet ass.
DNS ass eng separat Entscheedung, déi Dir musst huelen
Eng Portregel fir Webverkéier seet näischt iwwer Nummopléisung. De Browser ka den Systemresolver benotzen, e Resolver deen am Browser konfiguréiert ass, oder een deen déi lescht Verbindung eragedréckt huet. Jiddwereen dovun ka Froen iwwer en anere Wee schécken wéi deen, deen Är Regel auswielt, wat déi klassesch Spléckung produzéiert: d'Säit lued, den Numm gëtt enger anerer Plaz opgeléist wéi Dir erwaart hutt, an déi intern Säit léist op eng ëffentlech Adress op oder guer net.
Entscheet et explizit. Wann intern Nimm duerch den Tunnel musse opgeléist ginn, muss de Resolver dobannen sinn, an de Reegelset muss DNS zu deem Resolver erlaben, während aner Froen dobaussen bleiwen. Wann de Browser DNS over HTTPS zu engem ëffentleche Fournisseur benotzt, geet d'Fro komplett un Ärem Resolver laanscht an d'Portregel ka net hëllefen. Schreift d'Wiel an dee selwechte Ännerungsrekord wéi d'Routingregel, well béid zesumme vun deem gelies ginn, deen de nächste Feeler debuggët.
Verifizéiert et duerno mam Resolver amplaz mat der Säit:
resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'Eng fehlend Äntwert ass en Opléisungsproblem, och wann d'Fehlermeldung vum Browser d'Netzwierk beschëllegt. Déi zwee Feeler gesinn identesch aus fir en Notzer a sinn komplett verschidde Ticketen.
Dräi Grenzen, dräi verschidde Mechanismen
De meeschte Verwirrung verschwënnt, soubal Dir d'Grenz nennt, déi Dir wëllt. Si si net austauschbar, an jiddwereen huet wärend engem Tunnelausfall en anere Feeler-Modus.
| 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 |
En separate Browserprofil ass d'Fal an der mëttlerer Zeil. Et trennt Cookies an Historique, an et ännert näischt um Routingstabell vum Host, also huelen béid Profiler dee selwechte Wee. Isolatioun erfuerdert eppes, wat de Kernel duerchsetzt, dat heescht en Nummraum, e Container oder eng Applikatioun, déi hir eege Tunnelschnittstell huet.
Wéi eng Zeil och ëmmer gëllt, schreift op, wat soll geschéien, wann den Tunnel fält. Eng markbaséiert Route, déi mat der Schnittstell verschwënnt, fält meeschtens op déi physesch Standardroute zréck, wat Fail-open-Verhalen ass. Dat kann akzeptabel fir Surfen an inakzeptabel fir alles anescht sinn, an et ass eng Entscheedung, keen Implementatiounsdetail.
Test d'Flëss, déi Dir behaaptt ofzedecken
Den Akzeptanztest muss der Grenz follegen, déi Dir opgeschriwwen hutt, net de Portnummeren, déi bequem waren. Wielt ee Floss, deen duerch den Tunnel muss, een, deen net däerf, an een, deen en Transport benotzt, un deen Dir net geduecht hutt:
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'D'Routequery seet Iech, wéi eng Schnittstell en Destinatioun tatsächlech benotzt, an dat ass d'Fakt, deen déi meescht Rapporten falsch hunn. D'curl-Linn bestätegt déi ausgehandelt Versioun an d'Adressfamill. Den Dump vum Reegelset fänkt d'Regel, déi Dir beim Testen derbäigesat hutt an vergiess hutt ofzegrenzen, an esou gëtt eng temporär Mark permanent Fail-open-Routing.
Registréiert all dräi Ausgaben mat engem Zäitstempel a behält se bei der Ännerung. Wann duerno een mëllt, datt „d'VPN den Intranet futti gemaach huet“, wäert den Ënnerscheed tëscht der beabsichtigter an der ëmgesater Grenz an deem Rekord siichtbar sinn, an de Fix wäert eng Regelännerung sinn an net eng Diskussioun.