Jinsi ya kufunga programu moja ya Linux kwenye VPN kwa sheria za UID

Kufunga programu moja kwenye VPN kwenye Linux ni tatizo la uelekezaji hasa, na sheria ya firewall huamua tu kile kinachotokea baada ya njia kuchaguliwa. Ukilinganisha UID ya programu katika OUTPUT kabla handaki halimiliki njia ya msingi, sheria hiyo hutupa trafiki ile ile uliyokusudia kuilinda. Sheria hiyo hiyo haioni pia mchakato wa resolver unaojibu maswali ya DNS ya programu. Rekebisha mpangilio, na akaunti moja isiyo na ruhusa inakuwa kiteuzi cha kuaminika cha handaki lililogawanywa.

Ipe akaunti njia kabla ya hukumu

Ulinganifu wa mmiliki hujibu swali moja: je, soketi ya ndani inayomilikiwa na UID hii ndiyo iliyounda pakiti? Haichagui kiolesura, na haiwezi kuhamisha trafiki ambayo jedwali kuu tayari inaituma kupitia NIC halisi. Ndiyo sababu sheria ya UID isiyo na njia inayolingana huzuia programu badala ya kuielekeza upya.

Pitisha akaunti kwanza kupitia jedwali lake yenyewe, kisha acha firewall ithibitishe matokeo. Hii inafanya kazi kwenye mwenyeji ambaye iproute2 yake inaelewa uidrange, jambo ambalo ip rule help huripoti kwa mstari mmoja. Jedwali 100 linashikilia njia ya msingi kupitia handaki, na sheria hutuma UID 1000 pekee kwenye jedwali hilo. Kila kitu kingine kinabaki kwenye jedwali kuu na kuendelea kutumia kiungo halisi.

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

Akaunti ya pili inayohitaji handaki lingine hupata jedwali 101 na sheria yake, kwa sababu wasifu wawili hawawezi wote kumiliki njia ya msingi katika jedwali moja. Wasifu wa NetworkManager ni wa mfumo mzima, kwa hivyo sehemu hii inabaki ya mkono, na sheria hutoweka kwenye kuwasha upya isipokuwa kitu kizirejeshe. Andika majedwali kwenye skripti ya kuwasha kando ya ufafanuzi wa handaki, ili kuunganisha upya kusiweze kuacha akaunti moja kwenye njia isiyo sahihi.

Kwa nini msamaha wa loopback unaua handaki

Visa vingi vilivyonakiliwa vya sheria hutupa kila pakiti isiyotoka kupitia loopback. Handaki si loopback, kwa hivyo umbo hilo hutupa pia trafiki ya handaki, na matokeo yanaonekana kama VPN iliyokufa badala ya kosa la firewall.

OUTPUT inapofanya kazi, kerneli tayari imechagua kiolesura cha kutoka, kwa hivyo -o hulinganishwa na jibu la njia badala ya kichwa cha pakiti. Ulinganifu wa mmiliki huzingatiwa katika OUTPUT na POSTROUTING pekee, na pakiti zinazopitishwa hazibeba soketi ya kuusoma. Mchanganyiko huo unamaanisha kuwa msamaha lazima utaje kiolesura cha handaki na kukanusha ulinganifu huo, badala ya kukanusha loopback.

Loopback bado inastahili ACCEPT yake juu ya DROP, kwa sababu pakiti ya kwanza ya DNS kutoka programu inakwenda kwenye stub ya ndani kupitia lo. Weka sheria mbili kwa mpangilio huu, na akaunti inafikia stub, kisha handaki, na hakuna kingine.

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 ni seti tofauti ya sheria, na jozi ya v4 pekee inaacha ip6tables bila kuguswa. Programu inayopendelea rekodi za AAAA wakati huo ingetoka kupitia kiungo halisi bila kufikia DROP kamwe. Akisi sheria zote mbili katika ip6tables, au zima IPv6 kwenye mwenyeji wakati handaki halibebi anwani ya v6. Sheria zilizoongezwa kwa mkono pia hutoweka kwenye kuwasha upya, kwa hivyo zihifadhi kwa netfilter-persistent save au jenga upya mantiki hiyo hiyo kama jedwali la nftables linalopakiwa na kitengo cha kuwasha.

Majibu ya DNS yanakuja kutoka mchakato mwingine

Swali la programu kwa 127.0.0.53 hupita ACCEPT ya loopback, na hapo ndipo ulinganifu wa UID unapoishia. Resolver ya stub hupeleka juu kutoka akaunti yake ya huduma, kwa hivyo sheria iliyofungwa kwa vpnapp haioni swali la pili kamwe. Ikiwa resolver itachagua seva ya LAN kwa kiungo, majibu hurudi kupitia NIC halisi wakati pakiti za programu yenyewe zinabaki kwenye handaki. Matokeo yanayoonekana ni handaki linalofanya kazi na majina yaliyovunjika, au majina yanayojibiwa na seva ambayo hukuchagua.

Rekebisha utatuzi wa majina kwenye kiungo cha handaki, si kwenye programu. Ipe wasifu wa handaki seva ya DNS na kikoa cha uelekezaji, kisha thibitisha kwa resolvectl query na resolvectl status tun0 kwamba resolver inaitumia kwa majina muhimu. Ndani ya nafasi ya majina ya mtandao tatizo hutoweka, kwa sababu resolver ya nafasi inajua handaki pekee.

Kagua sheria kutoka kwa akaunti yenyewe

Uliza kerneli ni njia gani UID hupata, kisha fanya ombi kama akaunti hiyo na linganisha anwani ya kutoka na ya akaunti yako mwenyewe. Ikiwa zote mbili zinaripoti anwani moja, sheria inalingana na kitu kingine badala ya trafiki uliyojaribu. Amri ya kwanza hapa chini inaonyesha utafutaji wa njia bila kutuma pakiti, jambo linalotenganisha kosa la uelekezaji na kosa la firewall.

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

Vihesabu vinaonyesha kama sheria iliwahi kuwaka. Endesha iptables -vnL OUTPUT, soma idadi ya pakiti kando ya kila sheria, na chukua sifuri kando ya DROP baada ya trafiki halisi kama kosa la ulinganifu.

Trafiki inayopitishwa iko nje ya muundo huu. Kontena au VM nyuma ya daraja haina soketi ya ndani inayomilikiwa na vpnapp, kwa hivyo ulinganifu wa mmiliki hauwaki kamwe na pakiti hizo hufuata sera ya FORWARD badala yake. Ikiwa mzigo huo unapaswa kufunikwa, ujaribu kando na uandike sera iliyofungwa kwa daraja au anwani ya kontena. Muundo unashikilia wakati jedwali, msamaha wa kiolesura, resolver na sheria za v6 zote zinaelekeza upande mmoja; acha moja wapo nje na akaunti itavuja au itapoteza muunganisho.