Rregullat për portat 80 dhe 443 nuk e dërgojnë shfletuesin përmes VPN
Përputhja e portës zgjedh rrjedha TCP, jo një shfletues. HTTP/3 punon mbi UDP, DNS mund të marrë një rrugë tjetër, dhe përditësuesi përputhet me të njëjtin rregull që keni shkruar.
Dikush kërkon që shfletuesi të përdorë tunelin, dhe përgjigjja vjen si një rregull muri zjarri që përputhet me portat e destinacionit 80 dhe 443. Duket i saktë dhe nuk është. Përputhja e portës zgjedh paketat sipas kokës së transportit, jo sipas programit që hapi socket-in, dhe shfletimi modern nuk kufizohet te ato dy porta në TCP. Rregulli do të humbasë një pjesë të trafikut që donit të përfshinit dhe do të kapë trafik që nuk kishit ndërmend ta prekni. Para se ta shkruani, vendosni cilën nga tre kufijtë e ndryshëm dëshironi vërtet.
Rregulli përshkruan një klasë transporti, jo një aplikacion
Në Linux, përputhja e portës së destinacionit shqyrton kokën TCP dhe asgjë mbi të. Shënimi i atyre paketave dhe drejtimi i tyre me një rrugë politike punon saktësisht siç është dokumentuar, dhe asnjë prej këtyre makinerive nuk e di çfarë kupton ngarkesa ose cili proces e dërgoi. Shenja është një numër i bashkangjitur një pakete, jo një identitet i bashkangjitur një aplikacioni.
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 100Menjëherë vijojnë dy pasoja. Një përditësues softueri që kontakton TCP 443 merr të njëjtin trajtim si shfletuesi, gjë që mund të jetë në rregull ose mund të jetë një ndërprerje që pret ciklin e ardhshëm të përditësimit. Dhe një shërbim web i publikuar qëllimisht në një portë tjetër, të themi 8443, bie plotësisht jashtë rregullit, ndonëse është ende trafiku web për të cilin interesohej përdoruesi.
Numrat janë përzgjedhës legjitimë kur kërkesa është vërtet për ato porta. Ata bëhen trillim kur në biletë shkruhet «shfletues» dhe në grupin e rregullave zbatohet një interval portash. Ai hendek nuk është një hollësi dokumentacioni. Është ndryshimi midis një rregulli që mund ta mbroni në një rishikim dhe një tjetri që askush nuk mund ta testojë.
HTTP/3 e braktis në heshtje rregullin tuaj TCP
HTTP/3 punon mbi QUIC, dhe QUIC transportohet në UDP. Një rregull që përputhet vetëm me TCP nuk mund ta shohë, kështu që i njëjti shfletues që kalon faqen tuaj të testimit mund të dërgojë një kërkesë të mëvonshme përmes UDP dhe të anashkalojë tunelin pa ndryshuar askush një cilësim. RFC 9114 përshkruan HTTP/3 si një protokoll të bazuar në QUIC, dhe QUIC përdor UDP me portën e parazgjedhur 443 në vendosjen e zakonshme.
Nëse një shfletues i caktuar provon HTTP/3 varet nga konfigurimi i tij, nga sajti dhe nga fakti nëse një përpjekje e mëparshme doli me sukses. Kjo e bën atë një gjë të keqe për të arsyetuar nga kujtesa. Pyesni mjetin në vend të kësaj:
curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'Rreshti curl shtyp versionin e negociuar, kështu që një 3 konfirmon se u përdor rruga UDP. Lista e socket-eve tregon më pas nëse ai lidhje është e lidhur me ndërfaqen e tunelit ose me atë fizike. Nëse HTTP/3 nuk është i disponueshëm në ndërtimin tuaj të curl, flamuri dështon me zë në vend që të tërhiqet në heshtje, gjë që është mëshira e tij e vogël.
DNS është një vendim i veçantë që duhet ta merrni
Një rregull porte për trafikun web nuk thotë asgjë për zgjidhjen e emrave. Shfletuesi mund të përdorë zgjidhësin e sistemit, një zgjidhës të konfiguruar brenda shfletuesit, ose një të shtyrë nga lidhja e fundit. Secili prej tyre mund të dërgojë pyetje në një rrugë të ndryshme nga ajo që zgjedh rregulli juaj, gjë që prodhon ndarjen klasike: faqja ngarkohet, emri zgjidhet diku ku nuk e prisnit, dhe sajti i brendshëm zgjidhet në një adresë publike ose aspak.
Vendoseni shprehimisht. Nëse emrat e brendshëm duhet të zgjidhen përmes tunelit, zgjidhësi duhet të jetë brenda tij, dhe grupi i rregullave duhet të lejojë DNS drejt atij zgjidhësi duke i mbajtur jashtë pyetjet e tjera. Nëse shfletuesi përdor DNS over HTTPS drejt një ofruesi publik, pyetja e anashkalon plotësisht zgjidhësin tuaj dhe rregulli i portës nuk mund të ndihmojë. Shkruani zgjedhjen në të njëjtin regjistër ndryshimi si rregulli i rrugëzimit, sepse të dy i lexon bashkë ai që do të korrigjojë dështimin e ardhshëm.
Më pas verifikoni me zgjidhësin, jo me faqen:
resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'Një përgjigje që mungon është problem zgjidhjeje edhe kur mesazhi i gabimit të shfletuesit fajëson rrjetin. Këto dy dështime duken njësoj për përdoruesin dhe janë bileta krejt të ndryshme.
Tre kufij, tre mekanizma të ndryshëm
Pjesa më e madhe e konfuzionit zhduket sapo emërtoni kufirin që dëshironi. Ata nuk janë të këmbyeshëm, dhe secili ka një mënyrë tjetër dështimi gjatë një ndërprerjeje të tunelit.
| 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 |
Një profil i veçantë shfletuesi është kurthi i rreshtit të mesëm. Ai ndan cookie-t dhe historikun, dhe nuk ndryshon asgjë në tabelën e rrugëzimit të hostit, kështu që të dy profilet marrin të njëjtën rrugë. Izolimi kërkon diçka që e imponon kerneli, domethënë një hapësirë emrash, një kontejner ose një aplikacion që zotëron ndërfaqen e vet të tunelit.
Cili rresht të zbatohet, shkruani çfarë duhet të ndodhë kur tuneli bie. Një rrugë e bazuar në shenjë që zhduket me ndërfaqen zakonisht kthehet në rrugën e parazgjedhur fizike, që është sjellje fail-open. Kjo mund të jetë e pranueshme për shfletim dhe e papranueshme për çdo gjë tjetër, dhe është një vendim, jo një hollësi zbatimi.
Testoni rrjedhat që pretendoni se mbuloni
Testi i pranimit duhet të ndjekë kufirin që keni shkruar, jo numrat e portave që ishin të përshtatshëm. Zgjidhni një rrjedhë që duhet të kalojë nëpër tunel, një që nuk duhet, dhe një që përdor një transport për të cilin nuk keni menduar:
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'Kërkimi i rrugës ju tregon cilën ndërfaqe përdor vërtet një destinacion, dhe ky është fakti që shumica e raporteve e gabojnë. Rreshti curl konfirmon versionin e negociuar dhe familjen e adresave. Shkarkimi i grupit të rregullave kap rregullin që shtuat gjatë testimit dhe harruat ta kufizoni, dhe kështu një shenjë e përkohshme bëhet rrugëzim fail-open i përhershëm.
Regjistroni të tre daljet me një vulë kohe dhe mbajini me ndryshimin. Kur më vonë dikush raporton se «VPN-ja prishi intranetin», ndryshimi midis kufirit të synuar dhe atij të zbatuar do të jetë i dukshëm në atë regjistër, dhe rregullimi do të jetë një ndryshim rregulli, jo një debat.