Pravila za portove 80 i 443 ne šalju preglednik kroz VPN

Neko zatraži da preglednik koristi tunel, a zahtjev se vrati kao pravilo vatrozida koje pogađa odredišne portove 80 i 443. Izgleda precizno i nije. Podudaranje porta bira pakete po njihovom transportnom zaglavlju, a ne po tome koji je program otvorio utičnicu, a moderno pregledanje nije ograničeno na ta dva porta na TCP-u. Pravilo će propustiti dio prometa koji ste htjeli uključiti i uhvatiti promet koji nikada niste namjeravali dotaknuti. Prije nego što ga napišete, odlučite koju od tri različite granice zapravo želite.

Pravilo opisuje transportnu klasu, a ne aplikaciju

Na Linuxu podudaranje odredišnog porta pregleda TCP zaglavlje i ništa iznad njega. Označavanje tih paketa i usmjeravanje političkom rutom radi tačno kako je dokumentirano, i nijedan od tih mehanizama ne zna šta nosivi teret znači ni koji ga je proces poslao. Oznaka je broj pridružen paketu, a ne identitet pridružen aplikaciji.

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

Dvije posljedice slijede odmah. Program za ažuriranje softvera koji kontaktira TCP 443 dobija isti tretman kao preglednik, što može biti u redu ili može biti ispad koji čeka sljedeći ciklus ažuriranja. A web servis namjerno objavljen na drugom portu, recimo 8443, potpuno pada izvan pravila iako je to još uvijek web promet do kojeg je korisniku bilo stalo.

Brojevi su legitimni selektori kada se zahtjev zaista odnosi na te portove. Postaju fikcija kada u ticketu piše „preglednik“, a u skupu pravila se implementira raspon portova. Ta praznina nije dokumentacijska sitnica. To je razlika između pravila koje možete braniti na pregledu i onog koje niko ne može testirati.

HTTP/3 tiho zaobilazi vaše TCP pravilo

HTTP/3 radi preko QUIC-a, a QUIC se prenosi u UDP-u. Pravilo koje pogađa samo TCP ne može ga vidjeti, pa isti preglednik koji zadovolji vašu testnu stranicu može poslati kasniji zahtjev preko UDP-a i zaobići tunel, a da niko ne promijeni postavku. RFC 9114 opisuje HTTP/3 kao protokol zasnovan na QUIC-u, a QUIC koristi UDP sa zadanim portom 443 u uobičajenom postavljanju.

Hoće li dati preglednik pokušati HTTP/3 zavisi od njegove konfiguracije, od sajta i od toga je li prethodni pokušaj uspio. Zato je loše o tome rasuđivati po sjećanju. Pitajte alat umjesto toga:

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

Linija curl ispisuje pregovaranu verziju, pa 3 potvrđuje da je korišten put preko UDP-a. Popis utičnica zatim pokazuje je li ta veza vezana za sučelje tunela ili za fizičko. Ako HTTP/3 nije dostupan u vašoj gradnji curl-a, zastavica glasno pada umjesto da tiho nazaduje, što je njena mala milost.

DNS je zasebna odluka koju morate donijeti

Pravilo porta za web promet ne govori ništa o razrješavanju imena. Preglednik može koristiti sistemski razrješivač, razrješivač konfigurisan unutar preglednika ili onaj koji je gurnuo zadnji spojeni. Svaki od njih može slati upite drugim putem od onog koji bira vaše pravilo, što stvara klasičnu podjelu: stranica se učita, ime se razriješi negdje gdje niste očekivali, a interni sajt se razriješi na javnu adresu ili nikako.

Odlučite to izričito. Ako se interna imena moraju razrješavati kroz tunel, razrješivač mora biti unutar njega, a skup pravila mora dopuštati DNS prema tom razrješivaču uz držanje ostalih upita vani. Ako preglednik koristi DNS over HTTPS prema javnom pružaocu, upit u potpunosti zaobilazi vaš razrješivač i pravilo porta ne može pomoći. Upišite izbor u isti zapis o promjeni kao i pravilo usmjeravanja, jer oboje zajedno čitaju oni koji budu otklanjali sljedeći kvar.

Zatim provjerite razrješivačem, a ne stranicom:

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

Odgovor koji izostane je problem razrješavanja čak i kada poruka o grešci preglednika okrivljuje mrežu. Ta dva kvara korisniku izgledaju identično, a potpuno su različiti tiketi.

Tri granice, tri različita mehanizma

Većina zbrke nestane kada imenujete granicu koju želite. One nisu zamjenjive i svaka ima drugačiji način kvara tokom ispada tunela.

Odvojeni profil preglednika je zamka u srednjem redu. On razdvaja kolačiće i istoriju i ništa ne mijenja u tabeli usmjeravanja hosta, pa oba profila idu istim putem. Izolacija zahtijeva nešto što kernel nameće, što znači imenski prostor, kontejner ili aplikaciju koja posjeduje vlastito sučelje tunela.

Koji god red da važi, zapišite šta treba da se dogodi kada tunel padne. Ruta zasnovana na oznaci koja nestane sa sučeljem obično se vraća na fizičku zadanu rutu, što je fail-open ponašanje. To može biti prihvatljivo za pregledanje i neprihvatljivo za sve drugo, i to je odluka, a ne detalj implementacije.

Testirajte tokove za koje tvrdite da ih pokrivate

Prihvatni test mora slijediti granicu koju ste zapisali, a ne brojeve portova koji su bili zgodni. Odaberite jedan tok koji mora ići kroz tunel, jedan koji ne smije i jedan koji koristi transport o kojem niste razmišljali:

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'

Pretraga rute kaže koje sučelje odredište zaista koristi, a to je činjenica koju većina izvještaja pogrešno navede. Linija curl potvrđuje pregovaranu verziju i porodicu adresa. Ispis skupa pravila uhvati pravilo koje ste dodali tokom testiranja i zaboravili ograničiti, i tako privremena oznaka postaje trajno fail-open usmjeravanje.

Zabilježite sva tri izlaza s vremenskom oznakom i čuvajte ih uz promjenu. Kada neko kasnije prijavi da je „VPN pokvario intranet“, razlika između namjeravane i implementirane granice bit će vidljiva u tom zapisu, a popravka će biti promjena pravila, a ne rasprava.