Reglar for port 80 og 443 sender ikkje nettlesaren gjennom ein VPN

Nokon ber om at nettlesaren skal bruke tunnelen, og svaret kjem tilbake som ein brannmurregel som treff målportane 80 og 443. Han ser presis ut og er det ikkje. Eit porttreff vel pakkar etter transportoverskrifta, ikkje etter kva program som opna sokkelen, og moderne nettsurfing avgrensar seg ikkje til dei to portane på TCP. Regelen vil oversjå noko av trafikken du ville ta med og fange trafikk du aldri meinte å røre. Før du skriv han, må du avgjere kva av tre ulike grenser du eigenleg vil ha.

Regelen skildrar ein transportklasse, ikkje ein applikasjon

På Linux granskar eit målporttreff TCP-overskrifta og ingenting over henne. Å merke desse pakkane og styre dei med ei policyrute verkar nøyaktig som dokumentert, og ingen av desse maskineria veit kva nyttelasta tyder eller kva prosess som sende henne. Merket er eit nummer fest til ein pakke, ikkje ein identitet fest til ein applikasjon.

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 følgjer kjem straks. Ein programvareoppdaterar som kontaktar TCP 443 får same handsaming som nettlesaren, noko som kan vere greitt eller kan vere eit avbrot som ventar på neste oppdateringsrunde. Og ein netteneste som med vilje er publisert på ein annan port, seie 8443, fell heilt utanfor regelen sjølv om det framleis er netttrafikken brukaren var oppteken av.

Tala er legitime selektorar når kravet verkeleg gjeld dei portane. Dei blir fiksjon når det står «nettlesar» i saka og eit portområde blir implementert i regelsettet. Det gapet er ikkje ein dokumentasjonsdetalj. Det er skilnaden mellom ein regel du kan forsvare i ein gjennomgang og ein ingen kan teste.

HTTP/3 forlèt TCP-regelen din stille

HTTP/3 køyrer over QUIC, og QUIC blir boren i UDP. Ein regel som berre treff TCP kan ikkje sjå det, så den same nettlesaren som klarer testsida di kan sende ei seinare førespurnad over UDP og gå utanom tunnelen utan at nokon endrar ei innstilling. RFC 9114 skildrar HTTP/3 som ein QUIC-basert protokoll, og QUIC brukar UDP med standardport 443 i vanleg utrulling.

Om ein gitt nettlesar prøver HTTP/3 kjem an på konfigurasjonen, på nettstaden og på om eit tidlegare forsøk lukkast. Det gjer det dårleg eigna til å resonnere om frå minnet. Spør verktøyet i staden:

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

curl-linja skriv ut den forhandla versjonen, så ein 3 stadfester at UDP-vegen vart brukt. Så viser sokkel-lista om sambandet er bunde til tunellgrensesnittet eller det fysiske. Viss HTTP/3 ikkje finst i curl-bygget ditt, feilar flagget høgt i staden for å falle stille tilbake, noko som er hans eiga vesle nåde.

DNS er ei eiga avgjerd du må ta

Ein portregel for netttrafikk seier ingenting om namneoppslag. Nettlesaren kan bruke systemresolveren, ein resolver som er sett opp inne i nettlesaren, eller ein som den siste sambindinga dytta inn. Kvar av dei kan sende spørjingar over ein annan veg enn den regelen din vel, noko som gir den klassiske splittinga: sida blir lasta, namnet blir løyst eit stad du ikkje venta, og den interne sida blir løyst til ei offentleg adresse eller ikkje i det heile.

Avgjer det eksplisitt. Viss interne namn må løysast gjennom tunnelen, må resolveren vere inne i han, og regelsettet må tillate DNS til den resolveren medan andre spørjingar blir haldne ute. Viss nettlesaren brukar DNS over HTTPS til ein offentleg leverandør, går spørjinga heilt utanom resolveren din, og portregelen kan ikkje hjelpe. Skriv valet i same endringsrekord som rutingsregelen, fordi dei to blir lesne saman av den som feilsøkjer neste feil.

Stadfest det deretter med resolveren i staden for med sida:

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

Eit manglande svar er eit oppløysingsproblem sjølv når feilmeldinga frå nettlesaren gir nettet skulda. Desse to feila ser like ut for ein brukar og er heilt ulike saker.

Tre grenser, tre ulike mekanismar

Det meste av forvirringa forsvinn når du namngir grensa du vil ha. Dei er ikkje utbyttbare, og kvar av dei har ein annan feilmodus under eit tunellutfall.

Ein separat nettlesarprofil er fella i midtre rad. Han skil informasjonskapslar og historikk og endrar ingenting i rutetabellen til verten, så begge profilane tek same veg. Isolasjon krev noko kjernen handhevar, altså eit namnerom, ein container eller eit program som eig sitt eige tunellgrensesnitt.

Kva rad som gjeld, skriv ned kva som skal skje når tunnelen fell. Ei merkebasert rute som forsvinn med grensesnittet, fell vanlegvis tilbake til den fysiske standardruta, noko som er fail-open-åtferd. Det kan vere akseptabelt for surfing og uakseptabelt for alt anna, og det er ei avgjerd, ikkje ein implementasjonsdetalj.

Test straumane du hevdar å dekkje

Akseptansetesten må følgje grensa du skreiv ned, ikkje portnumra som var praktiske. Vel ein straum som må gå gjennom tunnelen, ein som ikkje må, og ein som brukar ein transport du ikkje tenkte 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'

Ruteoppslaget fortel kva grensesnitt ein destinasjon faktisk brukar, og det er det faktumet dei fleste rapportane tek feil av. curl-linja stadfester den forhandla versjonen og adressefamilien. Utskrifta av regelsettet fangar regelen du la til under testinga og gløymde å avgrense, og slik blir eit mellombels merke permanent fail-open-ruting.

Logg alle tre utdata med tidsstempel og ta vare på dei saman med endringa. Når nokon seinare rapporterer at «VPN-en øydela intranettet», vil skilnaden mellom den tiltenkte og den implementerte grensa vere synleg i den loggen, og rettinga blir ei regelendring i staden for ein diskusjon.