Linux програмыг UID дүрмээр VPN-д бэхлэх арга

Нэг програмыг Linux дээр VPN-д бэхлэх нь гол төлөв чиглүүлэлтийн асуудал, firewall-ийн дүрэм зөвхөн зам сонгогдсоны дараа юу болохыг шийднэ. Хэрэв туннель анхдагч замыг эзэмшихээс өмнө OUTPUT дотор програмын UID-г тааруулбал, дүрэм таны хамгаалахыг хүссэн урсгалыг яг таг хаяна. Мөн энэ дүрэм програмын DNS асуулгад хариулдаг resolver процессын харуулахгүй. Дарааллыг зөв болгоход нэг давуу эрхгүй бүртгэл найдвартай хуваагдсан туннелийн сонгогч болно.

Шийдвэрээс өмнө бүртгэлд зам өг

Эзэмшигчийн тааруулга нэг асуултад хариулна: энэ UID-д хамаарах локал сокет пакетыг бүтээсэн үү? Энэ нь интерфейс сонгохгүй бөгөөд үндсэн хүснэгт физик NIC-ээр аль хэдийн илгээж буй урсгалыг зөөж чадахгүй. Тиймээс тохирох замгүй UID дүрэм програмыг чиглүүлэхийн оронд блоклодог.

Бүртгэлийг эхлээд өөрийн хүснэгтээр нь дамжуулж, дараа нь firewall үр дүнг баталгаажуулна. Энэ нь iproute2 нь uidrange-г ойлгодог хост дээр ажилладаг бөгөөд үүнийг ip rule help нэг мөрөнд мэдээлдэг. 100-р хүснэгт туннелиар дамжих анхдагч замыг хадгалж, дүрэм зөвхөн UID 1000-г тэр хүснэгт рүү илгээдэг. Бусад бүх зүйл үндсэн хүснэгтэд үлдэж, физик холбоосыг үргэлжлүүлэн ашиглана.

ip rule add uidrange 1000-1000 table 100
ip route add default dev tun0 table 100

Өөр туннель хэрэгтэй хоёр дахь бүртгэл 101-р хүснэгт болон өөрийн дүрмийг авна, учир нь хоёр профайл нэг хүснэгтэд анхдагч замыг зэрэг эзэмшиж чадахгүй. NetworkManager профайлууд системийн түвшнийх тул энэ хэсэг гар аргаар үлдэж, дахин ачаалахад дүрмүүд алга болно, хэрэв ямар нэг зүйл тэдгээрийг сэргээхгүй бол. Хүснэгтүүдийг туннелийн тодорхойлолтын хажууд ачаалах скриптэд бичээрэй, ингэснээр дахин холбогдоход нэг бүртгэл буруу зам дээр үлдэхгүй.

loopback үл хамаарах зүйл туннелийг яагаад алдаг

Дүрмийн хуулбарлагдсан хувилбаруудын ихэнх нь loopback-оор гардаггүй бүх пакетыг хаядаг. Туннель нь loopback биш тул энэ хэлбэр туннелийн урсгалыг ч хаяж, үр дүн нь firewall-ийн алдаа биш харин үхсэн VPN мэт харагдана.

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

loopback нь DROP-ийн дээр өөрийн ACCEPT-д одоо ч хүртэх ёстой, учир нь програмын эхний DNS пакет lo -р дамжин локал stub руу явдаг. Хоёр дүрмийг энэ дарааллаар тавьбал бүртгэл stub-д хүрч, дараа нь туннельд, өөр хаана ч хүрэхгүй.

iptables -I OUTPUT 1 -o lo -m owner --uid-owner vpnapp -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner vpnapp ! -o tun0 -j DROP

IPv6 нь тусдаа дүрмийн багц бөгөөд зөвхөн v4-д зориулсан хос ip6tables -г хөндөхгүй үлдээдэг. AAAA бичлэгийг илүүд үздэг програм тэгвэл DROP-д хэзээ ч хүрэлгүй физик холбоосоор гарна. Хоёр дүрмийг ip6tables -д тусгах, эсвэл туннель v6 хаяг агуулаагүй үед хост дээр IPv6-г унтраа. Гараар нэмсэн дүрмүүд ч дахин ачаалахад алга болдог тул тэдгээрийг netfilter-persistent save -р хадгалах эсвэл ижил логикийг ачаалах нэгж ачаалдаг nftables хүснэгт болгон дахин бүтээ.

DNS хариултууд өөр процессоос ирдэг

Програмын 127.0.0.53 рүү чиглэсэн асуулга loopback ACCEPT-ээр дамжиж, яг тэнд UID-ийн тааруулга зогсдог. Stub resolver өөрийн үйлчилгээний бүртгэлээс дээш илгээдэг тул vpnapp -д холбогдсон дүрэм хоёр дахь асуулгыг хэзээ ч хардаггүй. Хэрэв resolver холбоосд LAN сервер сонговол хариултууд физик NIC-ээр буцаж ирэх бөгөөд програмын өөрийн пакетууд туннельд үлдэнэ. Харагдах үр дүн нь нэр нь эвдэрсэн ажиллаж буй туннель, эсвэл таны сонгоогүй сервер хариулсан нэрс юм.

Нэрийн шийдвэрийг програмад биш, туннелийн холбоос дээр засаарай. Туннелийн профайлд DNS сервер болон чиглүүлэлтийн домэйн өгөөд, дараа нь resolvectl query болон resolvectl status tun0 -р resolver үүнийг чухал нэрст хэрэглэж буйг баталгаажуул. Сүлжээний нэрийн орон зайн дотор асуудал арилна, учир нь орон зайн resolver зөвхөн туннелийг мэддэг.

Дүрмийг бүртгэлийн өөрөөс нь шалга

UID ямар зам авдгийг цөмөөс асууж, дараа нь тэр бүртгэлээр хүсэлт гаргаж, гарах хаягийг өөрийн бүртгэлийн хаягтай харьцуул. Хэрэв хоёулаа ижил хаяг мэдээлбэл, дүрэм таны туршсан урсгалаас өөр зүйлтэй таарч байна. Доорх эхний команд пакет илгээхгүйгээр замын хайлтыг харуулдаг бөгөөд энэ нь чиглүүлэлтийн алдааг firewall-ийн алдаанаас ялгадаг.

ip route get 1.1.1.1 uid 1000
sudo -u vpnapp curl -s https://ifconfig.co

Тоолуурууд дүрэм хэзээ нэгэн ажилласан эсэхийг харуулна. iptables -vnL OUTPUT -г ажиллуулж, дүрэм бүрийн хажууд пакетын тоог уншиж, бодит урсгалын дараа DROP-ийн хажууд байгаа тэгийг тааруулгын алдаа гэж үзээрэй.

Дамжуулсан урсгал энэ загвараас гадуур байна. Гүүрний ард байгаа контейнер эсвэл VM-д vpnapp -д хамаарах локал сокет байхгүй тул эзэмшигчийн тааруулга хэзээ ч ажиллахгүй бөгөөд тэдгээр пакет FORWARD бодлогыг дагана. Хэрэв тэр ачааллыг хамрах шаардлагатай бол тусдаа туршиж, гүүр эсвэл контейнерийн хаягт холбосон бодлого бичээрэй. Загвар нь хүснэгт, интерфейсийн үл хамаарах зүйл, resolver болон v6 дүрмүүд бүгд нэг чиглэл рүү зааж байвал л тогтоно; аль нэгийг нь орхивол бүртгэл нэвчих эсвэл холболтоо алдана.