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'

Хариу байхгүй байх нь шийдвэрлэлийн асуудал бөгөөд браузерын алдааны мэдэгдэл сүлжээг буруутгасан ч мөн адил. Эдгээр хоёр гэмтэл хэрэглэгчид ижил харагдах боловч огт өөр тасалбар юм.

Гурван хил, гурван өөр механизм

Хүссэн хилээ нэрлэсэн даруйд ихэнх будлиан алга болно. Тэдгээр нь сольж болохгүй бөгөөд туннель унах үед тус бүр өөр бүтэлгүйтлийн горимтой.

Тусдаа браузерын профайл бол дунд эгнээний урхи юм. Энэ нь күүки болон түүхийг тусгаарладаг бөгөөд хостны маршрутжуулалтын хүснэгтэд юу ч өөрчлөхгүй тул хоёр профайл нэг замаар явдаг. Тусгаарлалт нь цөм албаддаг зүйлийг шаарддаг, өөрөөр хэлбэл нэрийн орон зай, контейнер эсвэл өөрийн туннелийн интерфейстэй програм.

Аль эгнээ хамаарах ч, туннель унах үед юу болох ёстойг бичээрэй. Интерфейстэй хамт алга болдог тэмдэгт суурилсан маршрут ихэвчлэн физик анхдагч маршрут руу буцдаг бөгөөд энэ нь 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 дотоод сүлжээг эвдсэн» гэж мэдээлэхэд зорьсон болон хэрэгжүүлсэн хилийн ялгаа тэр бүртгэлд харагдах бөгөөд засвар нь маргаан биш, дүрмийн өөрчлөлт байх болно.