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 ички тармакты бузду» деп билдиргенде, көздөлгөн жана ишке ашырылган чектин айырмасы ошол жазууда көрүнөт, ал эми оңдоо эрежени өзгөртүү болот, талаш эмес.