80 eta 443 portuetarako arauek ez dute nabigatzailea VPN batetik bidaltzen

Norbaitek nabigatzaileak tunela erabiltzea eskatzen du, eta erantzuna 80 eta 443 helmuga-portuekin bat egiten duen suebaki-arau gisa itzultzen da. Zehatza dirudi eta ez da. Portu-kointzidentziak paketeak garraio-buruaren arabera hautatzen ditu, socket-a zein programak ireki zuen kontuan hartu gabe, eta nabigazio modernoa ez da TCP-ko bi portu horietara mugatzen. Arauak sartu nahi zenuen trafikoaren zati bat galduko du eta inoiz ukitu nahi ez zenuen trafika harrapatuko du. Idatzi aurretik, erabaki hiru muga desberdinetatik zein nahi duzun benetan.

Arauak garraio klase bat deskribatzen du, ez aplikazio bat

Linux-en, helmuga-portuaren koinkidentziak TCP burua aztertzen du eta horren gainetik ezer ez. Pakete horiek markatzea eta politika-bide batekin gidatzea dokumentatuta dagoen bezala funtzionatzen du, eta mekanismo horietako batek ere ez daki karga erabilgarriak zer esan nahi duen edo zein prozesuk bidali zuen. Marka pakete bati itsatsitako zenbaki bat da, ez aplikazio bati itsatsitako identitatea.

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

Berehala datoz bi ondorio. TCP 443-rekin harremanetan jartzen den software-eguneratzaile batek nabigatzaileak beste tratamendu bera jasotzen du, eta hori ondo egon daiteke edo hurrengo eguneratze-zikloaren zain dagoen eten bat izan daiteke. Eta beste portu batean, demagun 8443, berariaz argitaratutako web zerbitzu bat arautik erabat kanpo geratzen da, nahiz eta oraindik erabiltzaileari axola zion web trafikoa izan.

Zenbakiak hautatzaile legitimoak dira eskakizuna benetan portu horiei buruzkoa denean. Fikzio bihurtzen dira txartelean «nabigatzailea» idazten denean eta arau-multzoan portu-tarte bat inplementatzen denean. Hutsune hori ez da dokumentazioaren xehetasuna. Berrikuspen batean defenda dezakezun arau baten eta inork proba ezin dezakeenaren arteko aldea da.

HTTP/3-k isilka uzten du zure TCP araua

HTTP/3 QUIC gainean ibiltzen da, eta QUIC UDP-n garraiatzen da. TCP-rekin soilik bat egiten duen arau batek ezin du ikusi, beraz zure proba-orria betetzen duen nabigatzaile berak geroagoko eskaera bat UDP bidez bidal dezake eta tunela saihets dezake, inork ezarpenik aldatu gabe. RFC 9114 dokumentuak HTTP/3 QUIC-en oinarritutako protokolo gisa deskribatzen du, eta QUIC-k UDP erabiltzen du 443 portu lehenetsiarekin ohiko hedapenean.

Nabigatzaile jakin batek HTTP/3 probatuko duen ala ez haren konfigurazioaren, gunearen eta aurreko saiakera bat lortu zen ala ez araberakoa da. Horrek memoriatik arrazoitzeko gauza txarra bihurtzen du. Galdetu tresnari horren ordez:

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

curl lerroak negoziatutako bertsioa inprimatzen du, beraz 3 batek UDP bidea erabili zela baieztatzen du. Socket zerrendak gero erakusten du konexio hori tunelaren interfazera edo fisikoagora lotuta dagoen. HTTP/3 zure curl eraikinean eskuragarri ez badago, banderak ozenki huts egiten du isilka atzera egin beharrean, eta hori da bere erruki txikia.

DNS bereizi beharreko erabakia da

Web trafikorako portu-arau batek ez du ezer esaten izenen ebazpenari buruz. Nabigatzaileak sistemaren ebazlea, nabigatzailearen barruan konfiguratutako ebazle bat edo azken konexioak bultzatutako bat erabil dezake. Horietako bakoitzak zure arauak hautatzen duen bideaz bestelako bide batetik bidal ditzake kontsultak, eta horrek klasikoa den zatiketa sortzen du: orria kargatzen da, izena ez zenuen lekuan ebazten da, eta barneko gunea helbide publiko batera ebazten da edo ez da batere ebazten.

Erabaki ezazu berariaz. Barne-izenek tunelaren bidez ebaztu behar badute, ebazlea haren barruan egon behar da, eta arau-multzoak DNS baimendu behar dio ebazle horri, beste kontsultak kanpoan utziz. Nabigatzaileak DNS over HTTPS erabiltzen badu hornitzaile publiko batera, kontsultak zure ebazlea erabat saihesten du eta portu-arauak ezin du lagundu. Idatzi aukera bideratze-arauaren aldaketa-erregistro berean, hurrengo hutsegitea araztuko duenak biak elkarrekin irakurriko baititu.

Ondoren egiaztatu ebazlearekin eta ez orriarekin:

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

Falta den erantzun bat ebazpen-arazo bat da, nabigatzailearen errore-mezuak sarea erruduntzen duenean ere. Bi hutsegite horiek berdinak dirudite erabiltzailearentzat eta erabat desberdinak dira txartel gisa.

Hiru muga, hiru mekanismo desberdin

Nahastuen zatirik handiena desagertzen da nahi duzun mugari izena ematen diozunean. Ez dira trukagarriak, eta bakoitzak hutsegite-modu desberdina du tunelaren etenaldian.

Nabigatzaile-profil bereizi bat erdiko errenkadako tranpa da. Cookieak eta historia bereizten ditu, eta ez du ezer aldatzen ostalariaren bideratze-taulan, beraz bi profilek bide bera hartzen dute. Isolamenduak nukleoak inposatzen duen zerbait eskatzen du, hau da, izen-espazio bat, edukiontzi bat edo bere tunel-interfazea duen aplikazio bat.

Zein errenkadak balio duen, idatzi zer gertatu behar den tunela erortzen denean. Interfazearekin desagertzen den markan oinarritutako bide bat fisika lehenetsitako bidera itzultzen da normalean, eta hori fail-open portaera da. Hori onargarria izan daiteke nabigatzeko eta onartezina beste edozertarako, eta erabaki bat da, ez inplementazio-xehetasun bat.

Proba itzazu estaltzen dituzula diozun fluxuak

Onarpen-probak idatzi duzun muga jarraitu behar du, komenigarria zen portu-zenbakiak ez. Hautatu tunelatik igaro behar duen fluxu bat, igaro behar ez duen beste bat, eta pentsatu ez zenuen garraio bat erabiltzen duen beste bat:

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'

Bide-kontsultak helmuga batek benetan zein interfaze erabiltzen duen esaten dizu, eta hori da txosten gehienek gaizki uzten duten datua. curl lerroak negoziatutako bertsioa eta helbide-familia baieztatzen ditu. Arau-multzoaren iraulketak probetan gehitu eta mugatzen ahaztu zenuen araua harrapatzen du, eta horrela marka iragankor bat fail-open bideratze iraunkor bihurtzen da.

Erregistratu hiru irteerak denbora-marka batekin eta gorde itzazu aldaketarekin. Geroago norbaitek «VPNak intraneta hautsi du» salatzen duenean, aurreikusitako eta inplementatutako mugen arteko aldea ikusgai egongo da erregistro horretan, eta konponbidea arau-aldaketa bat izango da, ez eztabaida bat.