Vienas Linux lietotnes piesaiste VPN ar UID noteikumiem

Vienas programmas piesaiste VPN Linux vidē galvenokārt ir maršrutēšanas problēma, un ugunsmūra noteikums izlemj tikai to, kas notiek pēc maršruta izvēles. Ja OUTPUT sasaistīsiet programmas UID pirms tam, kad tunelim piederēs noklusējuma maršruts, noteikums izmetīs tieši to satiksmi, kuru gribējāt aizsargāt. Tas pats noteikums neredz arī resolver procesu, kas atbild uz programmas DNS vaicājumiem. Sakārtojiet secību pareizi, un viens konts bez privilēģijām kļūs par uzticamu sadalītā tuneļa atlasītāju.

Dodiet kontam maršrutu pirms sprieduma

Īpašnieka atbilstība atbild uz vienu jautājumu: vai paketi veidoja vietējā ligzda, kas pieder šim UID? Tā neizvēlas saskarni un nevar pārvietot satiksmi, ko galvenā tabula jau sūta pa fizisko NIC. Tāpēc UID noteikums bez atbilstoša maršruta bloķē programmu, nevis pārvirza to.

Vispirms laižiet kontu cauri tā paša tabulai, un tad ļaujiet ugunsmūrim apstiprināt rezultātu. Tas darbojas uz resursdatora, kura iproute2 saprot uidrange, ko ip rule help ziņo vienā rindā. 100. tabula tur noklusējuma maršrutu caur tuneli, un noteikums sūta tikai UID 1000 uz šo tabulu. Viss pārējais paliek galvenajā tabulā un turpina izmantot fizisko saiti.

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

Otrs konts, kam vajadzīgs cits tunelis, iegūst 101. tabulu un savu noteikumu, jo divi profili nevar abi piederēt noklusējuma maršrutam vienā tabulā. NetworkManager profili ir sistēmas līmenī, tāpēc šī daļa paliek manuāla, un noteikumi pazūd pārstartēšanas laikā, ja vien kaut kas tos neatjauno. Ierakstiet tabulas palaišanas skriptā blakus tuneļa definīcijai, lai atkārtota savienošanās neatstātu vienu kontu nepareizajā ceļā.

Kāpēc loopback izņēmums nogalina tuneli

Lielākā daļa nokopēto noteikuma versiju izmet katru paketi, kas neiziet caur loopback. Tunelis nav loopback, tāpēc šī forma izmet arī tuneļa satiksmi, un rezultāts izskatās kā miris VPN, nevis ugunsmūra kļūda.

Kad OUTPUT darbojas, kodols jau ir izvēlējies izejas saskarni, tāpēc -o tiek salīdzināts ar maršruta atbildi, nevis ar paketes galveni. Īpašnieka atbilstība tiek apskatīta tikai OUTPUT un POSTROUTING, un pārsūtītajām paketēm nav ligzdas, ko tā varētu nolasīt. Šī kombinācija nozīmē, ka izņēmumam ir jānosauc tuneļa saskarne un jānoliedz šī atbilstība, nevis jānoliedz loopback.

Loopback joprojām ir pelnījis savu ACCEPT virs DROP, jo pirmais programmas DNS pakets dodas uz vietējo stub caur lo. Ievietojiet abus noteikumus šajā secībā, un konts sasniedz stub, tad tuneli, un neko citu.

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 ir atsevišķs noteikumu kopums, un pāris tikai v4 atstāj ip6tables neskartu. Programma, kas dod priekšroku AAAA ierakstiem, tad izietu pa fizisko saiti, tā arī nesasniedzot DROP. Atspoguļojiet abus noteikumus ip6tables, vai atspējojiet IPv6 resursdatorā, kad tunelis nenes v6 adresi. Ar roku pievienotie noteikumi arī pazūd pārstartēšanas laikā, tāpēc saglabājiet tos ar netfilter-persistent save vai pārbūvējiet to pašu loģiku kā nftables tabulu, ko ielādē palaišanas vienība.

DNS atbildes nāk no cita procesa

Programmas vaicājums uz 127.0.0.53 iziet caur loopback ACCEPT, un tieši tur UID atbilstība apstājas. Stub resolver pārsūta uz augšu no sava servisa konta, tāpēc noteikums, kas piesaistīts vpnapp nekad neredz otro vaicājumu. Ja resolver saitei izvēlas LAN serveri, atbildes atgriežas pa fizisko NIC, kamēr pašas programmas paketes paliek tunelī. Redzamais rezultāts ir strādājošs tunelis ar salauztiem nosaukumiem, vai nosaukumi, uz kuriem atbild serveris, ko neizvēlējāties.

Labojiet nosaukumu izšķiršanu tuneļa saitē, nevis lietotnē. Piešķiriet tuneļa profilam DNS serveri un maršrutēšanas domēnu, tad apstipriniet ar resolvectl query un resolvectl status tun0 ka resolver to izmanto svarīgajiem nosaukumiem. Tīkla nosaukumu telpā problēma pazūd, jo telpas resolver zina tikai tuneli.

Pārbaudiet noteikumu no paša konta

Pajautājiet kodolam, kādu maršrutu iegūst UID, tad veiciet pieprasījumu kā šis konts un salīdziniet izejas adresi ar sava konta adresi. Ja abi ziņo to pašu adresi, noteikums atbilst kaut kam citam, nevis pārbaudītajai satiksmei. Pirmā komanda zemāk parāda maršruta meklēšanu, nenosūtot paketi, kas atdala maršrutēšanas kļūdu no ugunsmūra kļūdas.

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

Skaitītāji parāda, vai noteikums kādreiz ir iedarbojies. Palaidiet iptables -vnL OUTPUT, nolasiet pakešu skaitu blakus katram noteikumam, un nulli blakus DROP pēc reālas satiksmes uzskatiet par atbilstības kļūdu.

Pārsūtītā satiksme atrodas ārpus šīs konstrukcijas. Konteineram vai VM aiz tilta nav vietējas ligzdas, kas piederētu vpnapp, tāpēc īpašnieka atbilstība nekad neiedarbojas un šīs paketes seko FORWARD politikai. Ja šī slodze ir jāpārklāj, pārbaudiet to atsevišķi un ierakstiet politiku, kas piesaistīta tiltam vai konteinera adresei. Konstrukcija turas, kad tabula, saskarnes izņēmums, resolver un v6 noteikumi visi rāda vienā virzienā; izlaidiet kaut vienu no tiem, un konts vai nu noplūst, vai zaudē savienojumu.