Regler for port 80 og 443 sender ikke browseren gennem en VPN

Nogen beder om, at browseren skal bruge tunnelen, og svaret kommer tilbage som en firewallregel, der matcher destinationsportene 80 og 443. Det ser præcist ud og er det ikke. Et portmatch vælger pakker ud fra deres transportheader, ikke ud fra hvilket program der åbnede soklen, og moderne browsing begrænser sig ikke til de to porte på TCP. Reglen vil overse noget trafik, du ville medtage, og fange trafik, du aldrig havde tænkt dig at røre. Inden du skriver den, skal du beslutte, hvilken af tre forskellige grænser du egentlig vil have.

Reglen beskriver en transportklasse, ikke en applikation

På Linux undersøger et destinationsportmatch TCP-headeren og intet oven over den. At markere de pakker og styre dem med en policyrute virker præcis som beskrevet, og ingen af de mekanismer ved, hvad nyttelasten betyder, eller hvilken proces der sendte den. Mærket er et nummer knyttet til en pakke, ikke en identitet knyttet til en applikation.

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 100

To konsekvenser følger med det samme. En softwareopdatering, der kontakter TCP 443, får samme behandling som browseren, hvilket kan være fint eller kan være et nedbrud, der venter på næste opdateringscyklus. Og en webtjeneste, der bevidst er udgivet på en anden port, f.eks. 8443, falder helt uden for reglen, selvom det stadig er den webtrafik, brugeren var interesseret i.

Tallene er legitime selektorer, når kravet virkelig handler om de porte. De bliver en fiktion, når der står »browser« i opgaven, og der implementeres et portinterval i regelsættet. Den kløft er ikke en dokumentationsdetalje. Det er forskellen mellem en regel, du kan forsvare i en gennemgang, og en, ingen kan teste.

HTTP/3 forlader stille din TCP-regel

HTTP/3 kører over QUIC, og QUIC bæres i UDP. En regel, der kun matcher TCP, kan ikke se det, så den samme browser, der består din testside, kan sende en senere anmodning over UDP og omgå tunnelen, uden at nogen ændrer en indstilling. RFC 9114 beskriver HTTP/3 som en QUIC-baseret protokol, og QUIC bruger UDP med en standardport på 443 i den almindelige udrulning.

Om en given browser prøver HTTP/3 afhænger af dens konfiguration, af webstedet og af, om et tidligere forsøg lykkedes. Det gør det dårligt at ræsonnere om fra hukommelsen. Spørg værktøjet i stedet:

curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'

curl-linjen udskriver den forhandlede version, så et 3 bekræfter, at UDP-vejen blev brugt. Sokellisten viser derefter, om forbindelsen er bundet til tunnelets grænseflade eller til den fysiske. Hvis HTTP/3 ikke findes i dit curl-build, fejler flaget højt i stedet for stille at falde tilbage, hvilket er dets egen lille nåde.

DNS er en særskilt beslutning, du skal træffe

En portregel for webtrafik siger intet om navneopløsning. Browseren kan bruge systemets resolver, en resolver konfigureret inde i browseren eller en, som den sidste forbindelse har skubbet ind. Hver af dem kan sende forespørgsler ad en anden vej end den, din regel vælger, og det giver den klassiske kløft: siden indlæses, navnet opløses et sted, du ikke forventede, og det interne websted opløses til en offentlig adresse eller slet ikke.

Beslut det eksplicit. Hvis interne navne skal opløses gennem tunnelen, skal resolveren være inde i den, og regelsættet skal tillade DNS til den resolver, mens andre forespørgsler holdes ude. Hvis browseren bruger DNS over HTTPS til en offentlig udbyder, omgår forespørgslen din resolver helt, og portreglen kan ikke hjælpe. Skriv valget i samme ændringsrekord som routingreglen, fordi de to læses sammen af den, der fejlfinder den næste fejl.

Bekræft det derefter med resolveren i stedet for med siden:

resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'

Et manglende svar er et opløsningsproblem, selv når browserens fejlmeddelelse giver netværket skylden. De to fejl ser identiske ud for en bruger og er helt forskellige opgaver.

Tre grænser, tre forskellige mekanismer

Det meste af forvirringen forsvinder, når du navngiver den grænse, du vil have. De er ikke udskiftelige, og hver især har en anden fejltilstand under et tunneludfald.

En separat browserprofil er fælden i midterste række. Den adskiller cookies og historik og ændrer intet ved værtens routingtabel, så begge profiler tager samme vej. Isolation kræver noget, som kernen håndhæver, altså et namespace, en container eller et program, der ejer sin egen tunnelgrænseflade.

Uanset hvilken række der gælder, så skriv ned, hvad der skal ske, når tunnelen falder. En mærkebaseret rute, der forsvinder med grænsefladen, falder normalt tilbage til den fysiske standardrute, hvilket er fail-open-adfærd. Det kan være acceptabelt til browsing og uacceptabelt til alt andet, og det er en beslutning, ikke en implementeringsdetalje.

Test de strømme, du påstår at dække

Accepttesten skal følge den grænse, du skrev ned, ikke de portnumre, der var bekvemme. Vælg én strøm, der skal gennem tunnelen, én der ikke må, og én der bruger en transport, du ikke havde tænkt på:

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'

Ruteopslaget fortæller, hvilken grænseflade en destination faktisk bruger, og det er det faktum, de fleste rapporter tager fejl af. curl-linjen bekræfter den forhandlede version og adressefamilien. Regelsættets dump fanger den regel, du tilføjede under testen og glemte at afgrænse, og det er sådan et midlertidigt mærke bliver permanent fail-open-routing.

Registrér alle tre output med et tidsstempel, og opbevar dem sammen med ændringen. Når nogen senere rapporterer, at »VPN'en ødelagde intranettet«, vil forskellen mellem den tilsigtede og den implementerede grænse være synlig i den registrering, og rettelsen bliver en regelændring i stedet for en diskussion.