Pravila za vrata 80 in 443 ne pošiljajo brskalnika skozi VPN

Nekdo zahteva, da brskalnik uporabi tunel, in odgovor se vrne kot pravilo požarnega zidu, ki se ujema s ciljnima vratoma 80 in 443. Videti je natančno in ni. Ujemanje vrat izbere pakete po glavi prevoza, ne po tem, kateri program je odprl vtičnico, in sodobno brskanje se ne omejuje na ti dve vrati na TCP. Pravilo bo zgrešilo del prometa, ki ste ga hoteli vključiti, in ujelo promet, ki se ga niste nikoli nameravali dotakniti. Preden ga napišete, se odločite, katero od treh različnih mej v resnici želite.

Pravilo opisuje razred prevoza, ne aplikacije

V Linuxu ujemanje ciljnih vrat pregleda glavo TCP in nič nad njo. Označevanje teh paketov in usmerjanje s politično potjo deluje natanko tako, kot je dokumentirano, in noben od teh mehanizmov ne ve, kaj pomeni koristni tovor ali kateri proces ga je poslal. Oznaka je število, pritrjeno na paket, ne identiteta, pritrjena na aplikacijo.

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

Takoj sledita dve posledici. Posodabljalnik programske opreme, ki se poveže s TCP 443, dobi enako obravnavo kot brskalnik, kar je lahko v redu ali pa izpad, ki čaka na naslednji cikel posodobitve. In spletna storitev, namenoma objavljena na drugih vratih, recite 8443, v celoti pade izven pravila, čeprav je to še vedno spletni promet, ki je uporabnika zanimal.

Števila so zakoniti izbirniki, ko se zahteva res nanaša na ta vrata. Postanejo fikcija, ko v zahtevku piše »brskalnik«, v naboru pravil pa se izvaja razpon vrat. Ta vrzel ni dokumentacijska malenkost. To je razlika med pravilom, ki ga lahko branite na pregledu, in takim, ki ga nihče ne more preizkusiti.

HTTP/3 tiho zapusti vaše pravilo TCP

HTTP/3 teče prek QUIC, QUIC pa se prenaša v UDP. Pravilo, ki se ujema samo s TCP, tega ne more videti, zato lahko isti brskalnik, ki opravi vašo preizkusno stran, pošlje poznejšo zahtevo po UDP in se izogne tunelu, ne da bi kdor koli spremenil nastavitev. RFC 9114 opisuje HTTP/3 kot protokol, ki temelji na QUIC, QUIC pa uporablja UDP s privzetimi vrati 443 v običajni namestitvi.

Ali bo določen brskalnik poskusil HTTP/3, je odvisno od njegove konfiguracije, od mesta in od tega, ali je prejšnji poskus uspel. Zato je slabo o tem razmišljati po spominu. Vprašajte orodje:

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

Vrstica curl izpiše izpogajano različico, zato 3 potrjuje, da je bila uporabljena pot UDP. Nato seznam vtičnic pokaže, ali je ta povezava vezana na vmesnik tunela ali na fizičnega. Če v vaši gradnji curl ni HTTP/3, zastavica glasno odpove, namesto da bi se tiho umaknila, kar je njeno lastno malo usmiljenje.

DNS je ločena odločitev, ki jo morate sprejeti

Pravilo vrat za spletni promet ne pove ničesar o razreševanju imen. Brskalnik lahko uporabi sistemski razreševalnik, razreševalnik, nastavljen znotraj brskalnika, ali tistega, ki ga je potisnila zadnja povezava. Vsak od njih lahko pošilja poizvedbe po drugi poti od tiste, ki jo izbere vaše pravilo, kar ustvari klasičen razkol: stran se naloži, ime se razreši nekje, kjer tega niste pričakovali, notranje mesto pa se razreši na javni naslov ali pa sploh ne.

Odločite se izrecno. Če se morajo notranja imena razreševati skozi tunel, mora biti razreševalnik v njem, nabor pravil pa mora dovoljevati DNS do tega razreševalnika in druge poizvedbe držati zunaj. Če brskalnik uporablja DNS over HTTPS do javnega ponudnika, poizvedba v celoti obide vaš razreševalnik in pravilo vrat ne more pomagati. Zapišite izbiro v isti zapis o spremembi kot pravilo usmerjanja, ker oba skupaj bere tisti, ki bo odpravljal naslednjo napako.

Nato preverite z razreševalnikom, ne s stranjo:

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

Manjkajoč odgovor je težava razreševanja, tudi ko sporočilo o napaki brskalnika krivi omrežje. Ti dve napaki sta za uporabnika videti enaki in sta popolnoma različna zahtevka.

Tri meje, tri različni mehanizmi

Večina zmede izgine, ko poimenujete mejo, ki jo želite. Niso zamenljive in vsaka ima drugačen način odpovedi med izpadom tunela.

Ločen profil brskalnika je past v srednji vrstici. Loči piškotke in zgodovino in ne spremeni ničesar v usmerjevalni tabeli gostitelja, zato oba profila ubereta isto pot. Izolacija zahteva nekaj, kar vsili jedro, torej imenski prostor, vsebnik ali aplikacijo z lastnim vmesnikom tunela.

Katera koli vrstica že velja, zapišite, kaj naj se zgodi, ko tunel pade. Pot, ki temelji na oznaki in izgine z vmesnikom, običajno pade nazaj na fizično privzeto pot, kar je vedenje fail-open. To je lahko sprejemljivo za brskanje in nesprejemljivo za vse drugo, in to je odločitev, ne podrobnost izvedbe.

Preizkusite tokove, za katere trdite, da jih pokrivate

Sprejemni preizkus mora slediti meji, ki ste jo zapisali, ne priročnim številkam vrat. Izberite en tok, ki mora iti skozi tunel, enega, ki ne sme, in enega, ki uporablja prevoz, na katerega niste pomislili:

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'

Iskanje poti vam pove, kateri vmesnik cilj v resnici uporablja, in to je dejstvo, ki ga večina poročil navede napačno. Vrstica curl potrdi izpogajano različico in družino naslovov. Izpis nabora pravil ujame pravilo, ki ste ga dodali med preizkušanjem in pozabili omejiti, in tako začasna oznaka postane trajno usmerjanje fail-open.

Zabeležite vse tri izhode s časovnim žigom in jih hranite pri spremembi. Ko kasneje nekdo poroča, da je »VPN pokvaril intranet«, bo razlika med predvideno in izvedeno mejo vidna v tem zapisu in popravek bo sprememba pravila, ne razprava.