Ang mga patakaran sa port 80 at 443 ay hindi nagpapadaan sa browser sa VPN
Ang pagtutugma ng port ay pumipili ng mga daloy ng TCP, hindi browser. Gumagana ang HTTP/3 sa UDP, maaaring kumuha ng ibang landas ang DNS, at ang updater ay tumutugma sa parehong patakarang isinulat mo.
May humihiling na gamitin ng browser ang tunnel, at bumabalik ang kahilingan bilang patakaran ng firewall na tumutugma sa mga port ng destinasyon 80 at 443. Mukhang tumpak ito at hindi. Ang pagtutugma ng port ay pumipili ng mga packet ayon sa kanilang header ng transport, hindi ayon sa programang nagbukas ng socket, at ang makabagong pagba-browse ay hindi limitado sa dalawang port na iyon sa TCP. Mami-miss ng patakaran ang bahagi ng trapikong gusto mong isama at mahuhuli ang trapikong hindi mo kailanman sinadyang galawin. Bago mo ito isulat, magpasya kung alin sa tatlong magkaibang hangganan ang talagang gusto mo.
Inilalarawan ng patakaran ang isang uri ng transport, hindi application
Sa Linux, sinusuri ng pagtutugma ng port ng destinasyon ang header ng TCP at wala nang iba pa sa itaas nito. Gumagana nang eksakto ayon sa dokumentado ang pagmamarka sa mga packet na iyon at pag-ikot sa kanila gamit ang patakarang ruta, at wala sa mga makinaryang ito ang nakakaalam kung ano ang ibig sabihin ng payload o aling proseso ang nagpadala nito. Ang marka ay isang numero na nakakabit sa packet, hindi pagkakakilanlang nakakabit sa application.
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 100Dalawang kahihinatnan ang agad na sumusunod. Ang updater ng software na kumokontak sa TCP 443 ay tumatanggap ng parehong pagtrato gaya ng browser, na maaaring ayos lang o maaaring isang pagkagambala na naghihintay sa susunod na siklo ng pag-update. At ang serbisyong web na sadyang inilathala sa ibang port, sabihin nating 8443, ay tuluyang nahuhulog sa labas ng patakaran kahit pa ito pa rin ang trapikong web na pinag-aalala ng gumagamit.
Ang mga numero ay lehitimong tagapili kapag ang pangangailangan ay talagang tungkol sa mga port na iyon. Nagiging kathang-isip sila kapag nakasulat sa tiket ang «browser» at may ipinatutupad na saklaw ng port sa hanay ng patakaran. Ang agwat na iyon ay hindi detalye ng dokumentasyon. Ito ang pagkakaiba ng patakarang maipagtatanggol mo sa isang pagsusuri at ng isang walang makapag-subok.
Tahimik na iniiwan ng HTTP/3 ang iyong patakaran sa TCP
Gumagana ang HTTP/3 sa QUIC, at ang QUIC ay dinadala sa UDP. Ang patakarang tumutugma lamang sa TCP ay hindi ito makikita, kaya ang parehong browser na pumasa sa iyong pahina ng pagsubok ay makapagpapadala ng susunod na kahilingan sa UDP at malalampasan ang tunnel nang walang nagbabago ng anumang setting. Inilalarawan ng RFC 9114 ang HTTP/3 bilang protokol na nakabatay sa QUIC, at gumagamit ang QUIC ng UDP na may default na port 443 sa karaniwang deployment.
Kung susubukan ng isang partikular na browser ang HTTP/3 ay nakasalalay sa configuration nito, sa site at sa kung nagtagumpay ang naunang pagtatangka. Dahil dito, mahirap mangatwiran tungkol dito mula sa memorya. Itanong sa tool:
curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'Ang linyang curl ay naglilimbag ng napagkasunduang bersyon, kaya ang 3 ay nagpapatunay na ginamit ang landas ng UDP. Pagkatapos ay ipinapakita ng listahan ng socket kung ang koneksyong iyon ay nakatali sa interface ng tunnel o sa pisikal. Kung wala ang HTTP/3 sa iyong build ng curl, bigong mabibigo ang flag kaysa tahimik na umurong, na siyang sariling maliit na awa nito.
Ang DNS ay hiwalay na desisyon na kailangan mong gawin
Ang patakaran sa port para sa trapikong web ay walang sinasabi tungkol sa paglutas ng pangalan. Maaaring gamitin ng browser ang resolver ng system, isang resolver na naka-configure sa loob ng browser, o isang itinulak ng huling koneksyon. Ang bawat isa sa kanila ay maaaring magpadala ng mga query sa ibang landas kaysa sa pinipili ng iyong patakaran, na lumilikha ng klasikong paghahati: naglo-load ang pahina, nareresolba ang pangalan sa lugar na hindi mo inaasahan, at ang panloob na site ay nareresolba sa pampublikong address o hindi talaga.
Magpasya nang tahasan. Kung ang mga panloob na pangalan ay dapat malutas sa pamamagitan ng tunnel, ang resolver ay dapat nasa loob nito, at ang hanay ng patakaran ay dapat magpahintulot ng DNS patungo sa resolver na iyon habang pinananatiling labas ang iba pang query. Kung gumagamit ang browser ng DNS over HTTPS patungo sa pampublikong provider, tuluyang nilalampasan ng query ang iyong resolver at hindi makakatulong ang patakaran sa port. Isulat ang pinili sa parehong talaan ng pagbabago gaya ng patakaran sa routing, dahil pareho itong binabasa ng sinumang magde-debug sa susunod na pagkasira.
Pagkatapos ay i-verify gamit ang resolver at hindi ang pahina:
resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'Ang nawawalang sagot ay problema sa paglutas kahit pa sinisisi ng mensahe ng error ng browser ang network. Ang dalawang pagkabigong ito ay magkamukha sa gumagamit at ganap na magkaibang tiket.
Tatlong hangganan, tatlong magkaibang mekanismo
Karamihan sa kalituhan ay nawawala kapag pinangalanan mo ang hangganang gusto mo. Hindi sila mapagpapalit, at bawat isa ay may ibang paraan ng pagkabigo kapag bumagsak ang tunnel.
| 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 |
Ang hiwalay na profile ng browser ay ang bitag sa gitnang hilera. Hinihiwalay nito ang cookies at kasaysayan, at wala itong binabago sa talahanayan ng routing ng host, kaya parehong landas ang tinatahak ng dalawang profile. Ang paghihiwalay ay nangangailangan ng isang bagay na ipinapatupad ng kernel, ibig sabihin ay namespace, container o application na may sariling interface ng tunnel.
Aling hilera man ang naaangkop, isulat kung ano ang dapat mangyari kapag bumagsak ang tunnel. Ang rutang nakabatay sa marka na nawawala kasama ng interface ay karaniwang bumabalik sa pisikal na default na ruta, na gawi ng fail-open. Maaaring katanggap-tanggap ito para sa pagba-browse at hindi para sa lahat ng iba pa, at ito ay desisyon, hindi detalye ng implementasyon.
Subukan ang mga daloy na sinasabi mong sakop
Ang pagsubok sa pagtanggap ay dapat sumunod sa hangganang isinulat mo, hindi sa mga numero ng port na maginhawa. Pumili ng isang daloy na dapat dumaan sa tunnel, isa na hindi dapat, at isa na gumagamit ng transport na hindi mo naisip:
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'Sinasabi ng paghahanap ng ruta kung aling interface ang talagang ginagamit ng destinasyon, at iyon ang katotohanang mali ang sinasabi ng karamihan sa mga ulat. Kinukumpirma ng linyang curl ang napagkasunduang bersyon at ang pamilya ng address. Nahuhuli ng dump ng hanay ng patakaran ang patakarang idinagdag mo noong pagsubok at nakalimutan mong limitahan, at ganoon nagiging permanenteng fail-open routing ang isang pansamantalang marka.
Itala ang tatlong output na may timestamp at itago kasama ng pagbabago. Kapag may nag-ulat mamaya na «sinira ng VPN ang intranet», makikita sa talaang iyon ang pagkakaiba ng inilaan at naipatupad na hangganan, at ang pagwawasto ay magiging pagbabago ng patakaran at hindi pagtatalo.