Reglur um port 80 og 443 senda ekki vafrann í gegnum VPN

Einhver biður um að vafrinn noti göngin, og beiðnin kemur til baka sem eldveggjarregla sem passar við áfangaport 80 og 443. Hún lítur nákvæm út og er það ekki. Portasamsvörun velur pakka eftir flutningshausnum, ekki eftir því hvaða forrit opnaði sökklinn, og nútíma vafranotkun takmarkar sig ekki við þessi tvö port á TCP. Reglan mun sleppa hluta af umferðinni sem þú vildir hafa með og grípa umferð sem þú ætlaðir aldrei að snerta. Áður en þú skrifar hana skaltu ákveða hvaða af þremur mismunandi mörkum þú vilt í raun.

Reglan lýsir flutningsflokki, ekki forriti

Á Linux skoðar áfangaportsamsvörun TCP-hausinn og ekkert fyrir ofan hann. Að merkja þessa pakka og stýra þeim með stefnuleið virkar nákvæmlega eins og skjalfest er, og engin þessara vélbúnaðar veit hvað gagnið þýðir eða hvaða ferli sendi það. Merkið er tala sem er fest við pakka, ekki auðkenni sem er fest við forrit.

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

Tvær afleiðingar koma strax. Uppfærsluforrit hugbúnaðar sem hefur samband við TCP 443 fær sömu meðferð og vafrinn, sem kann að vera í lagi eða vera bilun sem bíður næstu uppfærslulotu. Og veffþjónusta sem er viljandi birt á öðru porti, segjum 8443, fellur alveg utan reglunnar þótt hún sé enn sú veftumferð sem notandanum var annt um.

Tölurnar eru lögmætir valar þegar krafan snýst raunverulega um þessi port. Þær verða skáldskapur þegar „vafri“ er skrifað í miðann og portabilið er útfært í reglusafninu. Þetta bil er ekki skjölunarsmáatriði. Það er munurinn á reglu sem þú getur varið í yfirferð og reglu sem enginn getur prófað.

HTTP/3 yfirgefur TCP-regluna þína hljóðlaust

HTTP/3 keyrir á QUIC, og QUIC er flutt í UDP. Regla sem passar aðeins við TCP getur ekki séð það, svo sami vafri og stenst prófunarsíðuna þína getur sent seinna beiðni um UDP og farið fram hjá göngunum án þess að nokkur breyti stillingu. RFC 9114 lýsir HTTP/3 sem samskiptareglum byggðum á QUIC, og QUIC notar UDP með sjálfgefnu porti 443 í venjulegri uppsetningu.

Hvort tiltekinn vafri reynir HTTP/3 fer eftir stillingum hans, vefnum og hvort fyrri tilraun tókst. Það gerir hann að lélegum hlut til að rökræða um eftir minni. Spurðu tólið í staðinn:

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

curl-línan prentar samningsbundna útgáfu, svo 3 staðfestir að UDP-leiðin var notuð. Sökklalistinn sýnir þá hvort sú tenging er bundin við tengi göngunnar eða hið líkamlega. Ef HTTP/3 er ekki tiltækt í curl-útgáfunni þinni mistekst fáninn hávært í stað þess að hörfa hljóðlaust, sem er hans eigin litla miskunn.

DNS er sérstök ákvörðun sem þú verður að taka

Portregla fyrir veftumferð segir ekkert um nafnupplausn. Vafrinn getur notað uppflettingu kerfisins, uppflettingu sem er stillt inni í vafranum eða þá sem síðasta tengingin ýtti inn. Sérhver þeirra getur sent fyrirspurnir eftir annarri leið en sú sem reglan þín velur, sem skapar hina klassísku klofningu: síðan hleðst, nafnið er leyst á stað sem þú bjóst ekki við, og innri vefurinn leysist í opinbert vistfang eða alls ekki.

Ákveddu það skýrt. Ef innri nöfn verða að leysast í gegnum göngin verður uppflettingin að vera inni í þeim, og reglusafnið verður að leyfa DNS til þeirrar uppflettingar og halda öðrum fyrirspurnum úti. Ef vafrinn notar DNS over HTTPS til opinbers þjónustuaðila fer fyrirspurnin alveg fram hjá uppflettingunni þinni og portreglan getur ekki hjálpað. Skrifaðu valið í sama breytingaskrá og leiðarregluna, því bæði les saman sá sem kembir næstu bilun.

Staðfestu það svo með uppflettingunni frekar en síðunni:

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

Svar sem vantar er upplausnarvandamál jafnvel þótt villuboð vafrans kenni netinu um. Þessar tvær bilanir líta eins út fyrir notanda og eru gjörólík mál.

Þrjú mörk, þrjár mismunandi aðferðir

Mest af ruglinu hverfur um leið og þú nefnir markið sem þú vilt. Þau eru ekki skiptanleg, og hvert hefur annan bilanahátt þegar göngin detta.

Sérstakt vafraprófíll er gildran í miðri röðinni. Hann aðskilur vafrakökur og feril og breytir engu um leiðartöflu hýsilsins, svo báðir prófílar fara sömu leið. Einangrun krefst eitthvað sem kjarninn framfylgir, það er nafnrými, gám eða forrit sem á sitt eigið göngutengi.

Hvaða röð sem á við, skrifaðu niður hvað eigi að gerast þegar göngin falla. Merkjabundin leið sem hverfur með tenginu fellur venjulega aftur á líkamlegu sjálfgefnu leiðina, sem er fail-open hegðun. Það getur verið ásættanlegt fyrir vafranotkun og óásættanlegt fyrir allt annað, og það er ákvörðun, ekki útfærsluatriði.

Prófaðu streymin sem þú segist ná yfir

Móttökuprófið verður að fylgja markinu sem þú skrifaðir, ekki portnúmerunum sem voru þægileg. Veldu eitt streymi sem verður að fara í gegnum göngin, eitt sem má ekki, og eitt sem notar flutning sem þú hugsaðir ekki um:

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'

Leiðarleitin segir þér hvaða tengi áfangastaður notar í raun, og það er sú staðreynd sem flestar skýrslur fá rangt. curl-línan staðfestir samningsbundnu útgáfuna og vistfangafjölskylduna. Útprentun reglusafnsins grípur regluna sem þú bættir við í prófun og gleymdir að afmarka, og þannig verður tímabundið merki að varanlegri fail-open leiðarstýringu.

Skráðu allar þrjár útkomurnar með tíma og geymdu þær með breytingunni. Þegar einhver tilkynnir síðar að „VPN-ið hafi brotið innra netið“ verður munurinn á fyrirhuguðu og útfærðu marki sýnilegur í þeirri skrá, og lagfæringin verður reglubreyting en ekki rökræða.