Kiel ligi unu Linux-programon al VPN per UID-reguloj

Ligi unu programon al VPN en Linux estas ĉefe enkursiga problemo, kaj la fajroŝirma regulo decidas nur, kio okazas post kiam la vojo estas elektita. Se vi kongruigas la UID-on de la programo en OUTPUT antaŭ ol la tunelo posedas la defaŭltan vojon, la regulo faligas ĝuste la trafikon, kiun vi volis protekti. La sama regulo ankaŭ ne vidas la solvigan procezon, kiu respondas la DNS-demandojn de la programo. Ordigi ĝin ĝuste kaj unu konto sen privilegioj fariĝas fidinda elektilo por la dividita tunelo.

Donu al la konto vojon antaŭ verdikto

La posedanto-kongruo responas unu demandon: ĉu loka soketo apartenanta al ĉi tiu UID konstruis la paketon? Ĝi ne elektas interfacon, kaj ĝi ne povas movi trafikon, kiun la ĉefa tabelo jam sendas tra la fizika NIC. Tial UID-regulo sen kongrua vojo blokas la programon anstataŭ redirekti ĝin.

Sendu la konton unue tra sia propra tabelo, poste lasu la fajroŝirmon konfirmi la rezulton. Ĉi tio funkcias sur gastiganto, kies iproute2 komprenas uidrange, kion ip rule help raportas en unu linio. Tabelo 100 tenas defaŭltan vojon tra la tunelo, kaj la regulo sendas nur UID 1000 al tiu tabelo. Ĉio alia restas en la ĉefa tabelo kaj daŭre uzas la fizikan ligilon.

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

Dua konto bezonanta malsaman tunelon ricevas tabelon 101 kaj sia propra regulo, ĉar du profiloj ne povas ambaŭ posedi la defaŭltan vojon en la sama tabelo. NetworkManager-profiloj estas sistema, do ĉi tiu parto restas mana, kaj la reguloj malaperas ĉe restarti se io ne restarigas ilin. Skribu la tabelojn en startan skripton apud la tunela difino, por ke rekonekto ne lasu unu konton sur la malĝusta vojo.

Kial la loopback-escepto mortigas la tunelon

La plej multaj kopiitaj versioj de la regulo faligas ĉiun paketon, kiu ne eliras tra loopback. La tunelo ne estas loopback, do tiu formo faligas ankaŭ la tunelan trafikon, kaj la rezulto similas mortan VPN anstataŭ fajroŝirman eraron.

Kiam OUTPUT funkcias, la kerno jam elektis eligan interfacon, do -o estas komparata kun la respondo de la vojo, ne kun la paketa kapo. La posedanto-kongruo estas konsultata nur en OUTPUT kaj POSTROUTING, kaj plusenditaj pakaĵoj ne portas soketon, kiun ĝi povus legi. Tiu kombino signifas, ke la escepto devas nomi la tunelan interfacon kaj nei tiun kongruon, anstataŭ nei loopback.

Loopback ankoraŭ meritas propran ACCEPT super la DROP, ĉar la unua DNS-paketo de la programo iras al la loka stubo tra lo. Metu la du regulojn en ĉi tiu ordo, kaj la konto atingas la stubon, poste la tunelon, kaj nenion alian.

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 estas aparta regul-aro, kaj duopo nur por v4 lasas ip6tables netuŝita. Programo, kiu preferas AAAA-recordojn, tiam elirus tra la fizika ligilo sen iam atingi la DROP. Spegulu ambaŭ regulojn en ip6tables, aŭ malŝaltu IPv6 sur la gastiganto, kiam la tunelo portas neniun v6-adreson. Mane aldonitaj reguloj ankaŭ malaperas ĉe restarti, do konservu ilin per netfilter-persistent save aŭ rekonstruu la saman logikon kiel nftables-tabelo ŝarĝita de la starta unuo.

DNS-respondoj venas el alia procezo

La demando de la programo al 127.0.0.53 trapasas la loopback-ACCEPT, kaj tie la UID-kongruo haltas. La stuba solvilo plusendas supren el sia propra servokonto, do regulo ŝlosita al vpnapp neniam vidas la duan demandon. Se la solvilo elektas LAN-servilon por la ligilo, respondoj revenas tra la fizika NIC dum la propraj pakaĵoj de la programo restas en la tunelo. La videbla rezulto estas funkcianta tunelo kun rompitaj nomoj, aŭ nomoj responditaj de servilo, kiun vi ne elektis.

Riparu nomrezolucion sur la tunela ligilo, ne en la aplikaĵo. Donu al la tunela profilo DNS-servilon kaj enkursigan domajnon, poste konfirmu per resolvectl query kaj resolvectl status tun0 ke la solvilo uzas ĝin por la nomoj, kiuj gravas. Ene de reta nomspaco la problemo malaperas, ĉar la nomspaca solvilo konas nur la tunelon.

Kontrolu la regulon el la konto mem

Demandu la kernon, kiun vojon UID ricevas, poste faru peton kiel tiu konto kaj komparu la eligan adreson kun tiu de via propra konto. Se ambaŭ raportas la saman adreson, la regulo kongruas ion krom la trafiko, kiun vi testis. La unua ordono sube montras la vojserĉon sen sendi paketon, kio apartigas enkursigan eraron de fajroŝirma eraro.

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

Nombriloj montras, ĉu regulo iam ekfunkciis. Rulu iptables -vnL OUTPUT, legu la pakan nombron apud ĉiu regulo, kaj traktu nulon apud la DROP post reala trafiko kiel kongrueraron.

Plusendita trafiko staras ekster ĉi tiu desegno. Ujo aŭ VM malantaŭ ponto ne havas loka soketon posedatan de vpnapp, do la posedanto-kongruo neniam ekfunkcias kaj tiuj pakaĵoj sekvas la FORWARD-politikon. Se tiu laborŝarĝo devas esti kovrita, testu ĝin aparte kaj skribu politikon ŝlositan al la ponto aŭ la uja adreso. La desegno tenas, kiam la tabelo, la interfaca escepto, la solvilo kaj la v6-reguloj ĉiuj montras la saman direkton; lasu for iun ajn el ili kaj la konto aŭ likas aŭ perdas konektecon.