Pravidlá pre porty 80 a 443 neposielajú prehliadač cez VPN

Niekto požiada, aby prehliadač používal tunel, a odpoveď príde ako pravidlo firewallu zodpovedajúce cieľovým portom 80 a 443. Vyzerá presne a nie je. Zhoda portu vyberá pakety podľa ich transportnej hlavičky, nie podľa toho, ktorý program otvoril socket, a moderné prehliadanie sa na TCP neobmedzuje na tieto dva porty. Pravidlo vynechá časť premávky, ktorú ste chceli zahrnúť, a zachytí premávku, ktorú ste nikdy nechceli zasiahnuť. Skôr než ho napíšete, rozhodnite, ktorú z troch rôznych hraníc vlastne chcete.

Pravidlo opisuje triedu transportu, nie aplikáciu

V Linuxe zhoda cieľového portu skúma TCP hlavičku a nič nad ňou. Označenie tých paketov a ich smerovanie pomocou politickej trasy funguje presne tak, ako je zdokumentované, a žiadny z týchto mechanizmov nevie, čo užitočné zaťaženie znamená ani ktorý proces ho odoslal. Značka je číslo pripojené k paketu, nie identita pripojená k aplikácii.

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

Hneď vyplývajú dva dôsledky. Aktualizátor softvéru, ktorý kontaktuje TCP 443, dostane rovnaké zaobchádzanie ako prehliadač, čo môže byť v poriadku alebo to môže byť výpadok čakajúci na ďalší cyklus aktualizácie. A webová služba zámerne publikovaná na inom porte, povedzme 8443, úplne vypadáva z pravidla, hoci je to stále tá webová premávka, na ktorej používateľovi záležalo.

Čísla sú legitímne selektory, keď sa požiadavka skutočne týka tých portov. Stanú sa fikciou, keď je v tikete napísaný „prehliadač“ a v sade pravidiel je implementovaný rozsah portov. Tá medzera nie je dokumentačná drobnosť. Je to rozdiel medzi pravidlom, ktoré obhájite pri revízii, a takým, ktoré nikto nedokáže otestovať.

HTTP/3 ticho opúšťa vaše pravidlo TCP

HTTP/3 beží nad QUIC a QUIC sa prenáša v UDP. Pravidlo, ktoré zodpovedá iba TCP, ho nevidí, takže ten istý prehliadač, ktorý prejde vašou testovacou stránkou, môže poslať neskoršiu požiadavku cez UDP a obísť tunel, pričom nikto nezmení nastavenie. RFC 9114 opisuje HTTP/3 ako protokol založený na QUIC a QUIC používa UDP s predvoleným portom 443 v obvyklom nasadení.

Či daný prehliadač skúsi HTTP/3, závisí od jeho konfigurácie, od stránky a od toho, či predchádzajúci pokus uspel. Preto je zlé o tom uvažovať po pamäti. Spýtajte sa nástroja:

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

Riadok curl vypíše vyjednanú verziu, takže 3 potvrdzuje, že bola použitá cesta cez UDP. Výpis socketov potom ukáže, či je toto spojenie viazané na rozhranie tunela, alebo na fyzické. Ak vo vašom zostavení curl nie je HTTP/3, prepínač hlasno zlyhá namiesto tichého ústupu, čo je jeho vlastné malé milosrdenstvo.

DNS je samostatné rozhodnutie, ktoré musíte urobiť

Pravidlo portu pre webovú premávku nehovorí nič o preklade mien. Prehliadač môže použiť systémový resolver, resolver nakonfigurovaný vnútri prehliadača alebo ten, ktorý pretlačilo posledné pripojenie. Každý z nich môže posielať dopyty inou cestou, než akú vyberá vaše pravidlo, čo vytvára klasické rozdvojenie: stránka sa načíta, meno sa preloží niekde, kde ste to nečakali, a interná stránka sa preloží na verejnú adresu alebo vôbec.

Rozhodnite to výslovne. Ak sa interné mená musia prekladať cez tunel, resolver musí byť vnútri neho a sada pravidiel musí povoliť DNS k tomuto resolveru a ostatné dopyty držať vonku. Ak prehliadač používa DNS over HTTPS k verejnému poskytovateľovi, dopyt úplne obchádza váš resolver a pravidlo portu nemôže pomôcť. Zapíšte voľbu do toho istého záznamu o zmene ako pravidlo smerovania, pretože oboje číta spolu ten, kto bude ladiť ďalšie zlyhanie.

Potom overte resolverom, nie stránkou:

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

Chýbajúca odpoveď je problém prekladu, aj keď chybová správa prehliadača obviňuje sieť. Tieto dve zlyhania vyzerajú pre používateľa rovnako a sú úplne rôzne tikety.

Tri hranice, tri rôzne mechanizmy

Väčšina zmätku zmizne, keď pomenujete hranicu, ktorú chcete. Nie sú zameniteľné a každá má iný režim zlyhania pri výpadku tunela.

Samostatný profil prehliadača je pasca v strednom riadku. Oddeľuje cookies a históriu a nič nemení v smerovacej tabuľke hostiteľa, takže oba profily idú tou istou cestou. Izolácia vyžaduje niečo, čo vynúti jadro, teda menný priestor, kontajner alebo aplikáciu, ktorá vlastní vlastné rozhranie tunela.

Nech platí ktorýkoľvek riadok, zapíšte, čo sa má stať, keď tunel padne. Trasa založená na značke, ktorá zmizne s rozhraním, zvyčajne spadne späť na fyzickú predvolenú trasu, čo je správanie fail-open. To môže byť prijateľné na prehliadanie a neprijateľné pre všetko ostatné, a je to rozhodnutie, nie detail implementácie.

Otestujte toky, o ktorých tvrdíte, že ich pokrývate

Akceptačný test musí sledovať hranicu, ktorú ste zapísali, nie čísla portov, ktoré boli pohodlné. Vyberte jeden tok, ktorý musí ísť cez tunel, jeden, ktorý nesmie, a jeden, ktorý používa transport, na ktorý ste nemysleli:

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'

Vyhľadanie trasy vám povie, ktoré rozhranie cieľ skutočne používa, a to je fakt, ktorý väčšina správ uvádza nesprávne. Riadok curl potvrdí vyjednanú verziu a rodinu adries. Výpis sady pravidiel zachytí pravidlo, ktoré ste pridali počas testovania a zabudli obmedziť, a tak sa z dočasnej značky stane trvalé smerovanie fail-open.

Zaznamenajte všetky tri výstupy s časovou pečiatkou a uchovajte ich pri zmene. Keď neskôr niekto nahlási, že „VPN pokazila intranet“, rozdiel medzi zamýšľanou a implementovanou hranicou bude v tom zázname viditeľný a oprava bude zmena pravidla, nie hádka.