80 және 443 порт ережелері браузерді VPN арқылы өткізбейді

Біреу браузердің туннельді қолдануын сұрайды, ал жауап 80 және 443 межелік порттарына сәйкес келетін желілік қалқан ережесі ретінде қайтады. Ол дәл көрінеді және дәл емес. Порт сәйкестігі пакеттерді олардың көлік тақырыбы бойынша таңдайды, сокетті қай бағдарлама ашқаны бойынша емес, ал заманауи шолу TCP-де осы екі портпен шектелмейді. Ереже қосуды қалаған трафиктің бір бөлігін өткізіп алады және ешқашан қол тигізуді ойламаған трафикті ұстайды. Оны жазбас бұрын үш түрлі шекараның қайсысын шынымен қалайтыныңызды шешіңіз.

Ереже көлік класын сипаттайды, қосымшаны емес

Linux-та межелік порт сәйкестігі TCP тақырыбын тексереді және оның үстінде ештеңе жоқ. Бұл пакеттерді белгілеу және саясат маршрутымен бағыттау дәл құжатталғандай жұмыс істейді, және бұл механизмдердің ешқайсысы жүктің нені білдіретінін немесе оны қай процестің жібергенін білмейді. Белгі — пакетке тіркелген сан, қосымшаға тіркелген бірегейлік емес.

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

Дереу екі салдар туындайды. TCP 443-ке хабарласатын бағдарламалық жаңартушы браузер сияқты қарым-қатынас алады, бұл дұрыс болуы мүмкін немесе келесі жаңарту циклін күтіп тұрған іркіліс болуы мүмкін. Ал басқа портта, айталық 8443-те әдейі жарияланған веб-қызмет ережеден толығымен тыс қалады, бірақ ол әлі де пайдаланушыны қызықтырған веб-трафик.

Сандар талап шынымен сол порттар туралы болғанда заңды таңдаушылар. Билетте «браузер» деп жазылып, ережелер жиынында порт ауқымы іске асырылғанда олар ойдан шығарылған нәрсеге айналады. Бұл алшақтық құжаттаманың ұсақ-түйегі емес. Бұл шолуда қорғай алатын ереже мен ешкім тексере алмайтын ереженің айырмашылығы.

HTTP/3 сіздің TCP ережесін үнсіз тастап кетеді

HTTP/3 QUIC үстінде жұмыс істейді, ал QUIC UDP-де тасымалданады. Тек TCP-ге сәйкес келетін ереже оны көре алмайды, сондықтан сіздің сынақ бетіңізді қанағаттандыратын сол браузер кейінгі сұранысты UDP арқылы жіберіп, туннельден айналып өте алады, ешкім параметрді өзгертпей-ақ. RFC 9114 HTTP/3-ті QUIC негізіндегі протокол деп сипаттайды, ал QUIC әдеттегі орналастыруда әдепкі порты 443 болатын UDP пайдаланады.

Белгілі бір браузердің HTTP/3-ті сынауы оның конфигурациясына, сайтқа және алдыңғы әрекеттің сәтті болғанына байланысты. Бұл оны жадтан пайымдауға жарамсыз етеді. Оның орнына құралдан сұраңыз:

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

curl жолы келісілген нұсқаны басып шығарады, сондықтан 3 UDP жолының пайдаланылғанын растайды. Содан кейін сокеттер тізімі сол қосылымның туннель интерфейсіне немесе физикалық интерфейске байланғанын көрсетеді. Егер сіздің curl жинағыңызда HTTP/3 болмаса, жалауша үнсіз шегінудің орнына қатты сәтсіздікке ұшырайды, бұл оның өзіндік шағын мейірімі.

DNS — өзіңіз қабылдауға тиіс бөлек шешім

Веб-трафикке арналған порт ережесі атауларды шешу туралы ештеңе айтпайды. Браузер жүйелік шешушіні, браузердің ішінде конфигурацияланған шешушіні немесе соңғы қосылған нәрсе итерген шешушіні пайдалануы мүмкін. Олардың әрқайсысы сұраныстарды сіздің ережеңіз таңдаған жолдан басқа жолмен жібере алады, бұл классикалық жарықшақты тудырады: бет жүктеледі, атау күтпеген жерде шешіледі, ал ішкі сайт жария мекенжайға шешіледі немесе мүлдем шешілмейді.

Мұны анық шешіңіз. Ішкі атаулар туннель арқылы шешілуі керек болса, шешуші оның ішінде болуы керек, ал ережелер жиыны сол шешушіге DNS рұқсат етіп, басқа сұраныстарды сыртта ұстауы керек. Егер браузер жария провайдерге DNS over HTTPS қолданса, сұраныс сіздің шешушіңізді толығымен айналып өтеді және порт ережесі көмектесе алмайды. Таңдауды маршруттау ережесімен бірдей өзгеріс жазбасына жазыңыз, өйткені келесі ақауды жөндейтін адам екеуін бірге оқиды.

Содан кейін беттің орнына шешушімен тексеріңіз:

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

Жауаптың болмауы — шешу мәселесі, браузердің қате хабарламасы желіні кінәласа да. Бұл екі ақау пайдаланушыға бірдей көрінеді және мүлдем басқа билеттер.

Үш шекара, үш түрлі механизм

Қалаған шекараны атаған бойда шатасудың көбі жоғалады. Олар бір-бірін алмастыра алмайды, және туннель үзілгенде әрқайсысының сәтсіздік режимі басқа.

Бөлек браузер профилі — ортаңғы қатардағы тұзақ. Ол cookie файлдары мен тарихты бөледі және хосттың маршруттау кестесінде ештеңені өзгертпейді, сондықтан екі профиль де бір жолмен жүреді. Оқшаулау ядро мәжбүрлейтін нәрсені қажет етеді, яғни атаулар кеңістігі, контейнер немесе өзінің туннель интерфейсі бар қосымша.

Қай қатар болса да, туннель құлағанда не болуы керектігін жазыңыз. Интерфейспен бірге жоғалатын белгіге негізделген маршрут әдетте физикалық әдепкі маршрутқа қайтады, бұл fail-open мінез-құлық. Бұл шолу үшін қолайлы, ал қалғанның бәрі үшін қолайсыз болуы мүмкін, және бұл шешім, іске асыру бөлшегі емес.

Қамтитыныңызды айтатын ағындарды сынаңыз

Қабылдау сынағы сіз жазған шекараға сүйенуі керек, ыңғайлы порт нөмірлеріне емес. Туннель арқылы өтуі тиіс бір ағынды, өтпеуі тиіс бір ағынды және ойламаған көлікті қолданатын бір ағынды таңдаңыз:

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'

Маршрутты іздеу межеліктің шын мәнінде қай интерфейсті қолданатынын айтады, және бұл көптеген есептер қате көрсететін факт. curl жолы келісілген нұсқа мен мекенжайлар тобын растайды. Ережелер жиынының шығарылымы сынау кезінде қосып, шектеуді ұмытқан ережені ұстайды, және осылайша уақытша белгі тұрақты fail-open маршруттауға айналады.

Үш шығысты да уақыт белгісімен жазып алыңыз және өзгеріспен бірге сақтаңыз. Кейінірек біреу «VPN ішкі желіні бұзды» деп хабарлағанда, көзделген және іске асырылған шекараның айырмашылығы сол жазбада көрінеді, ал түзету ережені өзгерту болады, дау емес.