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