A 80-as és 443-as port szabályai nem küldik a böngészőt VPN-en át

Valaki azt kéri, hogy a böngésző használja az alagutat, és a válasz egy tűzfalszabályként jön vissza, amely a 80-as és 443-as célportra illeszkedik. Pontosnak tűnik, és nem az. A portegyezés a csomagokat a szállítási fejlécük alapján választja ki, nem aszerint, melyik program nyitotta a socketet, és a modern böngészés nem korlátozódik erre a két portra TCP-n. A szabály kihagyja a forgalom egy részét, amelyet be akartál vonni, és elkap olyan forgalmat, amelyet soha nem akartál érinteni. Mielőtt megírod, döntsd el, a három különböző határ közül melyiket akarod valójában.

A szabály szállítási osztályt ír le, nem alkalmazást

Linuxon a célport-egyezés a TCP-fejlécet vizsgálja, és semmit felette. E csomagok megjelölése és házirend-útvonallal való terelése pontosan a dokumentált módon működik, és e mechanizmusok egyike sem tudja, mit jelent a hasznos teher, vagy melyik folyamat küldte. A jelölés a csomaghoz csatolt szám, nem alkalmazáshoz csatolt identitás.

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

Két következmény azonnal adódik. A TCP 443-at elérő szoftverfrissítő ugyanazt a bánásmódot kapja, mint a böngésző, ami rendben lehet, vagy lehet a következő frissítési ciklusra váró kiesés. És egy másik porton, mondjuk 8443-on szándékosan közzétett webszolgáltatás teljesen kiesik a szabályból, holott továbbra is az a webforgalom, amely a felhasználót érdekelte.

A számok legitim szelektorok, amikor a követelmény valóban ezekről a portokról szól. Fikcióvá válnak, amikor a jegyben „böngésző” áll, és a szabálykészletben porttartományt valósítanak meg. Ez a rés nem dokumentációs finomság. Ez a különbség egy szabály között, amelyet meg tudsz védeni egy felülvizsgálaton, és egy között, amelyet senki nem tud tesztelni.

A HTTP/3 csendben elhagyja a TCP-szabályodat

A HTTP/3 QUIC felett fut, a QUIC-et pedig UDP szállítja. A csak TCP-re illeszkedő szabály nem látja, ezért ugyanaz a böngésző, amely megfelel a tesztoldaladnak, későbbi kérést küldhet UDP-n és megkerülheti az alagutat, anélkül hogy bárki beállítást változtatna. RFC 9114 a HTTP/3-at QUIC-alapú protokollként írja le, és a QUIC a szokásos telepítésben 443-as alapértelmezett porttal használ UDP-t.

Hogy egy adott böngésző megpróbálja-e a HTTP/3-at, a konfigurációjától, az oldaltól és attól függ, hogy egy korábbi kísérlet sikerült-e. Emiatt rossz dolog emlékezetből érvelni róla. Kérdezd inkább az eszközt:

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

A curl sor kiírja az egyeztetett verziót, így a 3 megerősíti, hogy az UDP-útvonalat használták. A socket-lista ezután megmutatja, hogy az a kapcsolat az alagút interfészéhez vagy a fizikaihoz kötődik-e. Ha a HTTP/3 nem érhető el a curl-építésedben, a kapcsoló hangosan meghiúsul ahelyett, hogy csendben visszaesne, ami a maga kis kegyelme.

A DNS külön döntés, amelyet meg kell hoznod

A webforgalom portszabálya semmit nem mond a névfeloldásról. A böngésző használhatja a rendszer feloldóját, a böngészőn belül beállított feloldót vagy azt, amelyet az utoljára csatlakozó betolt. Ezek bármelyike más útvonalon küldheti a lekérdezéseket, mint amelyet a szabályod kiválaszt, és ez hozza létre a klasszikus hasadást: az oldal betöltődik, a név olyan helyen oldódik fel, ahol nem vártad, és a belső oldal nyilvános címre oldódik fel, vagy egyáltalán nem.

Döntsd el kifejezetten. Ha a belső neveket az alagúton keresztül kell feloldani, a feloldónak azon belül kell lennie, és a szabálykészletnek engednie kell a DNS-t ahhoz a feloldóhoz, miközben a többi lekérdezést kívül tartja. Ha a böngésző DNS over HTTPS-t használ egy nyilvános szolgáltatóhoz, a lekérdezés teljesen megkerüli a feloldódat, és a portszabály nem segíthet. Írd a választást ugyanabba a változásrekordba, mint az útválasztási szabályt, mert a kettőt együtt olvassa az, aki a következő hibát hibakeresi.

Utána a feloldóval ellenőrizd, ne az oldallal:

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

A hiányzó válasz névfeloldási probléma akkor is, amikor a böngésző hibaüzenete a hálózatot hibáztatja. Ez a két hiba a felhasználónak azonosnak látszik, és teljesen különböző jegyek.

Három határ, három különböző mechanizmus

A zavar nagy része eltűnik, amint megnevezed a kívánt határt. Ezek nem cserélhetők fel, és mindegyiknek más a meghibásodási módja az alagút kiesésekor.

A külön böngészőprofil a középső sor csapdája. Elválasztja a sütiket és az előzményeket, és semmit nem változtat a gazdagép útválasztási táblázatán, így mindkét profil ugyanazt az útvonalat járja. Az elkülönítéshez valami kell, amit a kernel kényszerít, azaz névtér, konténer vagy olyan alkalmazás, amely saját alagút-interfésszel rendelkezik.

Bármelyik sor érvényes, írd le, mi történjen, amikor az alagút leesik. Az interfésszel eltűnő jelölésalapú útvonal általában visszaesik a fizikai alapértelmezett útvonalra, ami fail-open viselkedés. Ez elfogadható lehet böngészéshez és elfogadhatatlan minden másra, és ez döntés, nem megvalósítási részlet.

Teszteld azokat a folyamokat, amelyeket lefedni állítasz

Az átvételi tesztnek a leírt határt kell követnie, nem a kényelmes portszámokat. Válassz egy folyamot, amelynek az alagúton kell mennie, egyet, amelynek nem szabad, és egyet, amely olyan szállítást használ, amelyre nem gondoltál:

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'

Az útvonal-lekérdezés megmondja, melyik interfészt használja egy cél valójában, és ez az a tény, amelyet a legtöbb jelentés eltéveszt. A curl sor megerősíti az egyeztetett verziót és a címcsaládot. A szabálykészlet kiírása elkapja a tesztelés közben hozzáadott és korlátozni elfelejtett szabályt, és így lesz az ideiglenes jelölésből állandó fail-open útválasztás.

Rögzítsd mindhárom kimenetet időbélyeggel, és tartsd a változás mellett. Amikor később valaki jelenti, hogy „a VPN elrontotta az intranetet”, a szándékolt és a megvalósított határ közötti különbség látható lesz abban a feljegyzésben, és a javítás szabályváltozás lesz, nem vita.