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 ережелері бәрі бір бағытты көрсеткенде ғана тұрады; солардың кез келгенін қалдырып кетсеңіз, тіркелгі не ағып кетеді, не байланысын жоғалтады.