Pordureeglid 80 ja 443 ei saada brauserit VPN-i kaudu

Keegi palub, et brauser kasutaks tunnelit, ja vastuseks tuleb tulemüürireegel, mis vastab sihtportidele 80 ja 443. See näeb täpne välja ja ei ole. Pordivaste valib pakette nende transpordipäise järgi, mitte selle järgi, milline programm pesa avas, ja kaasaegne veebisirvimine ei piirdu TCP-l nende kahe pordiga. Reegel jätab vahele osa liiklusest, mille soovisid kaasata, ja püüab liikluse, mida sa ei kavatsenudki puutuda. Enne selle kirjutamist otsusta, millist kolmest erinevast piirist sa tegelikult tahad.

Reegel kirjeldab transpordiklassi, mitte rakendust

Linuxis vaatab sihtpordi vaste TCP-päist ja mitte midagi sellest kõrgemat. Nende pakettide märgistamine ja poliitikamaršruudiga suunamine töötab täpselt nii, nagu on dokumenteeritud, ja ükski neist mehhanismidest ei tea, mida kasulik koormus tähendab ega milline protsess selle saatis. Märk on paketi külge kinnitatud number, mitte rakenduse külge kinnitatud identiteet.

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

Kohe järgneb kaks tagajärge. Tarkvaravärskendaja, mis võtab ühendust TCP 443-ga, saab sama kohtlemise nagu brauser, mis võib olla korras või olla katkestus, mis ootab järgmist värskendustsüklit. Ja veebiteenus, mis on teadlikult avaldatud teisel pordil, ütleme 8443, jääb reeglist täiesti välja, kuigi see on endiselt see veebiliiklus, millest kasutajal oli hool.

Numbrid on õiguspärased valijad, kui nõue on tõesti nende portide kohta. Neist saab väljamõeldis, kui piletil on kirjas «brauser» ja reeglistikus rakendatakse pordivahemik. See lünk ei ole dokumentatsiooni peensus. See on vahe reegli vahel, mida saad ülevaatusel kaitsta, ja sellise vahel, mida keegi ei saa testida.

HTTP/3 jätab sinu TCP-reegli vaikselt maha

HTTP/3 töötab QUIC-i peal ja QUIC-i kantakse UDP-s. Reegel, mis vastab ainult TCP-le, ei näe seda, nii et sama brauser, mis läbib sinu testilehe, võib hilisema päringu saata UDP kaudu ja tunnelist mööda minna, ilma et keegi seadet muudaks. RFC 9114 kirjeldab HTTP/3-d QUIC-põhise protokollina ja QUIC kasutab UDP-d, mille vaikimisi port on tavapärases juurutuses 443.

Kas antud brauser proovib HTTP/3-e, sõltub selle konfiguratsioonist, saidist ja sellest, kas varasem katse õnnestus. Seetõttu on sellest halb mälu järgi arutleda. Küsi hoopis tööriistalt:

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

curl-i rida väljastab läbiräägitud versiooni, nii et 3 kinnitab, et UDP-teed kasutati. Seejärel näitab pesade loend, kas see ühendus on seotud tunneli liidesega või füüsilisega. Kui HTTP/3 pole sinu curli koostes saadaval, ebaõnnestub lipp valjusti, mitte ei tagane vaikselt, mis on selle oma väike halastus.

DNS on eraldi otsus, mille pead tegema

Veebiliikluse pordireegel ei ütle nimede lahendamise kohta midagi. Brauser võib kasutada süsteemi lahendajat, brauseri sees seadistatud lahendajat või seda, mille lükkas sisse viimati ühendunud. Igaüks neist võib saata päringuid teist teed kui see, mille sinu reegel valib, mis tekitab klassikalise lõhe: leht laaditakse, nimi lahendatakse kuskil, kus sa ei oodanud, ja sisemine sait lahendatakse avalikuks aadressiks või üldse mitte.

Otsusta see selgesõnaliselt. Kui sisemised nimed peavad lahenduma tunneli kaudu, peab lahendaja olema selle sees ja reeglistik peab lubama DNS-i selle lahendajani, hoides muud päringud väljas. Kui brauser kasutab avaliku pakkuja juures DNS over HTTPS-i, möödub päring sinu lahendajast täielikult ja pordireegel ei saa aidata. Kirjuta valik samasse muudatuse kirjesse kui marsruutimisreegel, sest mõlemat loeb koos see, kes järgmist tõrget silub.

Seejärel kontrolli lahendajaga, mitte lehega:

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

Puuduv vastus on lahendamise probleem ka siis, kui brauseri veateade süüdistab võrku. Need kaks tõrget näevad kasutaja jaoks identsed välja ja on täiesti erinevad piletid.

Kolm piiri, kolm erinevat mehhanismi

Suurem osa segadusest kaob, kui nimetad piiri, mida tahad. Need ei ole vahetatavad ja igaühel on tunneli katkemise ajal erinev tõrkerežiim.

Eraldi brauseriprofiil on keskmise rea lõks. See eraldab küpsised ja ajaloo ega muuda hosti marsruutimistabelis midagi, nii et mõlemad profiilid lähevad sama teed. Isolatsioon nõuab midagi, mida tuum jõustab, see tähendab nimeruumi, konteinerit või rakendust, millel on oma tunnelliides.

Ükskõik milline rida kehtib, kirjuta üles, mis peab juhtuma, kui tunnel langeb. Märgil põhinev marsruut, mis kaob koos liidesega, langeb tavaliselt tagasi füüsilisele vaikemarsruudile, mis on fail-open-käitumine. See võib olla sirvimise jaoks vastuvõetav ja kõige muu jaoks vastuvõetamatu, ja see on otsus, mitte rakendamise detail.

Testi vooge, mida väidad katvat

Vastuvõtutest peab järgima piiri, mille kirjutasid, mitte pordinumbreid, mis olid mugavad. Vali üks voog, mis peab tunnelist läbi minema, üks, mis ei tohi, ja üks, mis kasutab transporti, mille peale sa ei mõelnud:

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'

Marsruudiotsing ütleb, millist liidest sihtkoht tegelikult kasutab, ja see on fakt, mille enamik aruandeid vale saab. curl-i rida kinnitab läbiräägitud versiooni ja aadressiperekonna. Reeglistiku väljavõte püüab reegli, mille lisasid testimise ajal ja unustasid piiramata jätta, ja nii muutub ajutine märk püsivaks fail-open-marsruutimiseks.

Registreeri kõik kolm väljundit ajatempliga ja hoia neid muudatuse juures. Kui keegi hiljem teatab, et «VPN lõhkus sisevõrgu», on kavandatud ja rakendatud piiri erinevus selles kirjes nähtav ning parandus saab olema reeglimuudatus, mitte vaidlus.