Porttien 80 ja 443 säännöt eivät lähetä selainta VPN:n läpi
Porttiosuma valitsee TCP-virtoja, ei selainta. HTTP/3 toimii UDP:n päällä, DNS voi kulkea toista reittiä ja päivittäjä osuu samaan sääntöön, jonka kirjoitit.
Joku pyytää, että selain käyttäisi tunnelia, ja pyyntöön vastataan palomuurisäännöllä, joka osuu kohdeportteihin 80 ja 443. Se näyttää täsmälliseltä eikä ole. Porttiosuma valitsee paketit niiden kuljetusotsakkeen perusteella, ei sen perusteella mikä ohjelma avasi pistokkeen, eikä nykyaikainen selailu rajoitu TCP:n kahteen porttiin. Sääntö jättää väliin osan liikenteestä, jonka halusit mukaan, ja nappaa liikennettä, jota et koskaan aikonut koskea. Ennen kuin kirjoitat sen, päätä, minkä kolmesta eri rajasta todella haluat.
Sääntö kuvaa kuljetusluokan, ei sovellusta
Linuxissa kohdeportin osuma tutkii TCP-otsaketta eikä mitään sen yläpuolelta. Näiden pakettien merkitseminen ja ohjaaminen käytäntöreitillä toimii täsmälleen dokumentoidusti, eikä mikään näistä mekanismeista tiedä, mitä hyötykuorma tarkoittaa tai mikä prosessi sen lähetti. Merkki on pakettiin kiinnitetty numero, ei sovellukseen kiinnitetty identiteetti.
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 100Heti seuraa kaksi seurausta. Ohjelmistopäivittäjä, joka ottaa yhteyden TCP 443:een, saa saman kohtelun kuin selain, mikä voi olla hyvä tai voi olla katkos, joka odottaa seuraavaa päivityssykliä. Ja verkkopalvelu, joka on tarkoituksella julkaistu toiselle portille, sanotaan 8443, putoaa säännön ulkopuolelle kokonaan, vaikka se on edelleen se verkkoliikenne, josta käyttäjä välitti.
Numerot ovat laillisia valitsimia, kun vaatimus todella koskee noita portteja. Niistä tulee fiktiota, kun tikettiin kirjoitetaan ”selain” ja sääntökokonaisuudessa toteutetaan porttialue. Tämä kuilu ei ole dokumentaation hienous. Se on ero säännön, jonka voit puolustaa katselmuksessa, ja sellaisen välillä, jota kukaan ei voi testata.
HTTP/3 jättää TCP-sääntösi hiljaa taakseen
HTTP/3 toimii QUIC:n päällä ja QUIC kuljetetaan UDP:ssä. Sääntö, joka osuu vain TCP:hen, ei näe sitä, joten sama selain, joka läpäisee testisivusi, voi lähettää myöhemmän pyynnön UDP:n kautta ja ohittaa tunnelin ilman, että kukaan muuttaa asetusta. RFC 9114 kuvaa HTTP/3:n QUIC-pohjaiseksi protokollaksi, ja QUIC käyttää UDP:tä, jonka oletusportti on tavallisessa käyttöönotossa 443.
Se, yrittääkö tietty selain HTTP/3:a, riippuu sen asetuksista, sivustosta ja siitä, onnistuiko aiempi yritys. Siksi siitä on huono päätellä muistista. Kysy sen sijaan työkalulta:
curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'curl-rivi tulostaa neuvotellun version, joten 3 vahvistaa, että UDP-reittiä käytettiin. Pistokeluettelo näyttää sitten, onko yhteys sidottu tunnelin rajapintaan vai fyysiseen. Jos HTTP/3 ei ole curl-käännöksessäsi saatavilla, lippu epäonnistuu äänekkäästi eikä vetäydy hiljaa, mikä on sen oma pieni armahdus.
DNS on erillinen päätös, joka sinun on tehtävä
Verkkoliikenteen porttisääntö ei kerro nimien selvityksestä mitään. Selain voi käyttää järjestelmän selvittäjää, selaimen sisään asetettua selvittäjää tai sitä, jonka viimeksi yhdistänyt työnsi sisään. Jokainen niistä voi lähettää kyselyitä eri reittiä kuin se, jonka sääntösi valitsee, ja se tuottaa klassisen jaon: sivu latautuu, nimi selvitetään jossain, jota et odottanut, ja sisäinen sivusto selvitetään julkiseksi osoitteeksi tai ei lainkaan.
Päätä se nimenomaisesti. Jos sisäiset nimet on selvitettävä tunnelin kautta, selvittäjän on oltava sen sisällä, ja sääntökokonaisuuden on sallittava DNS kyseiselle selvittäjälle ja pidettävä muut kyselyt ulkona. Jos selain käyttää DNS over HTTPS:ää julkiseen tarjoajaan, kysely ohittaa selvittäjäsi kokonaan eikä porttisääntö voi auttaa. Kirjoita valinta samaan muutostietueeseen kuin reitityssääntö, koska seuraavan vian selvittäjä lukee molemmat yhdessä.
Vahvista sitten selvittäjällä eikä sivulla:
resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'Puuttuva vastaus on selvitysongelma, vaikka selaimen virheilmoitus syyttäisi verkkoa. Nämä kaksi vikaa näyttävät käyttäjälle samalta ja ovat täysin eri tikettejä.
Kolme rajaa, kolme eri mekanismia
Suurin osa sekaannuksesta katoaa, kun nimeät rajan, jonka haluat. Ne eivät ole vaihdettavissa, ja jokaisella on erilainen vikatila tunnelin katketessa.
| What you actually want | Mechanism that fits | What it does not cover |
|---|---|---|
| These transport ports use this exit | Firewall mark plus policy route | Applications, HTTP/3 over UDP, DNS |
| This browsing session stays separate | Application-aware VPN, or a separate network namespace plus a proxy | Other applications in the same session |
| Only these private sites are reachable | Destination-based routes with private DNS | Public sites on the same address family |
Erillinen selainprofiili on keskimmäisen rivin ansa. Se erottaa evästeet ja historian eikä muuta mitään isännän reititystaulusta, joten molemmat profiilit kulkevat samaa reittiä. Eristys vaatii jotain, mitä ydin pakottaa, eli nimiavaruuden, kontin tai sovelluksen, jolla on oma tunnelirajapintansa.
Mikä rivi tahansa päteekin, kirjoita ylös, mitä pitäisi tapahtua, kun tunneli kaatuu. Merkkiin perustuva reitti, joka katoaa rajapinnan mukana, putoaa yleensä fyysiselle oletusreitille, mikä on fail-open-käyttäytymistä. Se voi olla hyväksyttävää selailulle ja ei missään muussa, ja se on päätös, ei toteutuksen yksityiskohta.
Testaa virrat, joiden väität kattavasi
Hyväksyntätestin on seurattava rajaa, jonka kirjoitit, ei porttinumeroita, jotka olivat käteviä. Valitse yksi virta, jonka on mentävä tunnelin läpi, yksi, jonka ei pidä, ja yksi, joka käyttää kuljetusta, jota et ajatellut:
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'Reittihaku kertoo, mitä rajapintaa kohde todella käyttää, ja se on se tosiasia, jonka useimmat raportit saavat väärin. curl-rivi vahvistaa neuvotellun version ja osoiteperheen. Sääntökokonaisuuden tuloste nappaa säännön, jonka lisäsit testauksen aikana ja unohdit rajata, ja niin väliaikaisesta merkistä tulee pysyvä fail-open-reititys.
Kirjaa kaikki kolme tulostetta aikaleimalla ja pidä ne muutoksen mukana. Kun joku myöhemmin raportoi, että ”VPN rikkoi intranetin”, ero aiotun ja toteutetun rajan välillä näkyy siinä tietueessa, ja korjaus on sääntömuutos eikä väittely.