Kako pripeti eno aplikacijo Linux na VPN s pravili UID

Pripeti en program na VPN v Linuxu je predvsem problem usmerjanja, pravilo požarnega zidu pa odloči le, kaj se zgodi po izbiri poti. Če v OUTPUT uskladite UID programa, preden tunel dobi privzeto pot, pravilo zavrže prav tisti promet, ki ste ga hoteli zaščititi. Isto pravilo ne vidi niti procesa resolverja, ki odgovarja na DNS poizvedbe programa. Nastavite vrstni red pravilno in en račun brez pravic postane zanesljiv izbirnik razdeljenega tunela.

Dajte računu pot pred razsodbo

Ujemanje lastnika odgovori na eno vprašanje: je paket zgradila lokalna vtičnica, ki pripada temu UID? Ne izbere vmesnika in ne more premakniti prometa, ki ga glavna tabela že pošilja skozi fizično NIC. Zato pravilo UID brez ustrezne poti program blokira, namesto da bi ga preusmerilo.

Pošljite račun najprej skozi njegovo lastno tabelo, nato pustite požarnemu zidu, da potrdi rezultat. To deluje na gostitelju, katerega iproute2 razume uidrange, kar ip rule help sporoči v eni vrstici. Tabela 100 drži privzeto pot skozi tunel, pravilo pa pošlje samo UID 1000 v to tabelo. Vse ostalo ostane v glavni tabeli in še naprej uporablja fizično povezavo.

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

Drugi račun, ki potrebuje drug tunel, dobi tabelo 101 in svoje pravilo, ker dva profila ne moreta oba imeti privzete poti v isti tabeli. Profili NetworkManager so sistemski, zato ta del ostane ročen, pravila pa ob ponovnem zagonu izginejo, če jih nekaj ne obnovi. Zapišite tabele v zagonsko skripto ob definiciji tunela, da ponovna povezava ne bo pustila enega računa na napačni poti.

Zakaj izjema za loopback ubije tunel

Večina kopiranih različic pravila zavrže vsak paket, ki ne pride ven skozi loopback. Tunel ni loopback, zato ta oblika zavrže tudi promet tunela in rezultat je videti kot mrtev VPN, ne kot napaka požarnega zidu.

Ko OUTPUT teče, je jedro že izbralo izhodni vmesnik, zato -o se primerja z odgovorom poti in ne z glavo paketa. Ujemanje lastnika se preverja samo v OUTPUT in POSTROUTING, posredovani paketi pa ne nosijo vtičnice, ki bi jo lahko prebralo. Ta kombinacija pomeni, da mora izjema poimenovati vmesnik tunela in zanikati to ujemanje, namesto da zanika loopback.

Loopback si še vedno zasluži lasten ACCEPT nad DROP, ker prvi DNS paket iz programa gre do lokalnega stub-a skozi lo. Postavite obe pravili v ta vrstni red in račun doseže stub, nato tunel, in nikamor drugam.

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 je ločen niz pravil in par samo za v4 pusti ip6tables nedotaknjen. Program, ki daje prednost zapisom AAAA, bi potem šel ven skozi fizično povezavo, ne da bi kdaj dosegel DROP. Zrcalite obe pravili v ip6tables, ali onemogočite IPv6 na gostitelju, ko tunel ne nosi nobenega naslova v6. Ročno dodana pravila prav tako izginejo ob ponovnem zagonu, zato jih shranite s netfilter-persistent save ali znova zgradite isto logiko kot tabelo nftables, ki jo naloži zagonska enota.

DNS odgovori prihajajo iz drugega procesa

Poizvedba programa na 127.0.0.53 preide ACCEPT za loopback in prav tam se ujemanje UID ustavi. Stub resolver posreduje navzgor iz svojega servisnega računa, zato pravilo, vezano na vpnapp nikoli ne vidi druge poizvedbe. Če resolver za povezavo izbere LAN strežnik, se odgovori vrnejo skozi fizično NIC, medtem ko lastni paketi programa ostanejo v tunelu. Viden rezultat je delujoč tunel s pokvarjenimi imeni, ali imena, na katera odgovarja strežnik, ki ga niste izbrali.

Popravite razreševanje imen na povezavi tunela, ne v aplikaciji. Dajte profilu tunela strežnik DNS in usmerjevalno domeno, nato potrdite s resolvectl query in resolvectl status tun0 da resolver uporablja ta strežnik za imena, ki so pomembna. Znotraj omrežnega imenskega prostora težava izgine, ker resolver prostora pozna samo tunel.

Preverite pravilo iz samega računa

Vprašajte jedro, katero pot dobi UID, nato pošljite zahtevo kot ta račun in primerjajte izhodni naslov z naslovom svojega računa. Če oba poročata isti naslov, se pravilo ujema z nečim drugim kot s prometom, ki ste ga preizkusili. Prvi ukaz spodaj pokaže iskanje poti brez pošiljanja paketa, kar loči napako usmerjanja od napake požarnega zidu.

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

Števci pokažejo, ali se je pravilo kdaj sprožilo. Zaženite iptables -vnL OUTPUT, preberite število paketov ob vsakem pravilu in ničlo ob DROP po resničnem prometu obravnavajte kot napako ujemanja.

Posredovani promet ostaja zunaj te zasnove. Vsebnik ali VM za mostom nima lokalne vtičnice v lasti vpnapp, zato se ujemanje lastnika nikoli ne sproži in ti paketi sledijo politiki FORWARD. Če je treba to obremenitev pokriti, jo preizkusite ločeno in napišite politiko, vezano na most ali naslov vsebnika. Zasnova drži, ko tabela, izjema vmesnika, resolver in pravila v6 kažejo v isto smer; izpustite katero koli od njih in račun bodisi pušča bodisi izgubi povezljivost.