Kuidas siduda üks Linuxi rakendus UID-reeglitega VPN-iga

Ühe programmi sidumine VPN-iga Linuxis on peamiselt marsruutimise probleem, ja tulemüüri reegel otsustab ainult selle, mis juhtub pärast marsruudi valimist. Kui sobitad programmi UID-i OUTPUT-is enne, kui tunnel omab vaikimisi marsruuti, siis reegel viskab kõrvale täpselt selle liikluse, mida sa tahtsid kaitsta. Sama reegel ei näe ka resoluri protsessi, mis vastab programmi DNS-päringutele. Sea järjekord õigesti ja üks privileegideta konto muutub jagatud tunneli usaldusväärseks valijaks.

Anna kontole marsruut enne otsust

Omaniku sobitamine vastab ühele küsimusele: kas sellele UID-ile kuuluv kohalik soket ehitas paketi? See ei vali liidest ega suuda liigutada liiklust, mida põhitabel juba saadab füüsilise NIC-i kaudu. Seetõttu blokeerib UID-reegel ilma vastava marsruudita programmi, selle asemel et seda ümber suunata.

Saada konto kõigepealt läbi oma tabeli ja lase seejärel tulemüüril tulemus kinnitada. See töötab hostil, mille iproute2 mõistab uidrange'i, mida ip rule help teatab ühes reas. Tabel 100 hoiab vaikimisi marsruuti läbi tunneli ja reegel saadab ainult UID 1000 sellesse tabelisse. Kõik muu jääb põhitabelisse ja kasutab edasi füüsilist ühendust.

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

Teine konto, mis vajab teist tunnelit, saab tabeli 101 ja oma reegli, sest kaks profiili ei saa mõlemad omada vaikimisi marsruuti samas tabelis. NetworkManageri profiilid on süsteemsed, nii et see osa jääb käsitsi ja reeglid kaovad taaskäivitamisel, kui miski neid ei taasta. Kirjuta tabelid alglaadimisskripti tunneli definitsiooni kõrvale, et ühenduse taastamine ei jätaks üht kontot valele teele.

Miks loopback-erand tunneli tapab

Enamik kopeeritud reegli versioone viskab kõrvale iga paketi, mis ei välju loopbacki kaudu. Tunnel ei ole loopback, nii et see kuju viskab kõrvale ka tunneli liikluse ja tulemus näeb välja nagu surnud VPN, mitte nagu tulemüüri viga.

Kui OUTPUT töötab, on tuum juba valinud väljumisliidese, seega -o võrreldakse marsruudi vastusega, mitte paketi päisega. Omaniku sobitamist konsulteeritakse ainult OUTPUT-is ja POSTROUTING-is ning edastatud paketid ei kanna soketit, mida see lugeda saaks. See kombinatsioon tähendab, et erand peab nimetama tunneli liidese ja eitama selle sobitamise, mitte eitama loopbacki.

Loopback väärib endiselt oma ACCEPT-i DROP-i kohal, sest programmi esimene DNS-pakett läheb kohalikku stubi läbi lo. Pane kaks reeglit sellesse järjekorda ja konto jõuab stubini, seejärel tunnelini ja mitte kuhugi mujale.

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 on eraldi reeglistik ja ainult v4 jaoks mõeldud paar jätab ip6tables puutumata. Programm, mis eelistab AAAA-kirjeid, väljuks siis füüsilise ühenduse kaudu ilma kunagi DROP-ini jõudmata. Peegelda mõlemad reeglid ip6tables-s või keela hostil IPv6, kui tunnel ei kanna ühtegi v6-aadressi. Käsitsi lisatud reeglid kaovad samuti taaskäivitamisel, seega salvesta need netfilter-persistent save abil või ehita sama loogika uuesti nftables-tabelina, mille alglaadimisüksus laeb.

DNS-vastused tulevad teisest protsessist

Programmi päring 127.0.0.53-le läbib loopback-ACCEPT-i ja täpselt seal UID-i sobitamine lõpeb. Stub-resolver edastab päringu edasi oma teenuskonto alt, seega reegel, mis on seotud vpnapp-ga, ei näe kunagi teist päringut. Kui resolver valib ühenduse jaoks LAN-serveri, tulevad vastused tagasi füüsilise NIC-i kaudu, samal ajal kui programmi enda paketid jäävad tunnelisse. Nähtav tulemus on töötav tunnel katkiste nimedega või nimed, millele vastab server, mida sa ei valinud.

Paranda nimede lahendamine tunneli ühendusel, mitte rakenduses. Anna tunneliprofiilile DNS-server ja marsruutimisdomeen ning kinnita seejärel resolvectl query ja resolvectl status tun0 abil, et resolver kasutab seda nimede jaoks, mis loevad. Võrgu nimeruumis kaob probleem, sest nimeruumi resolver teab ainult tunnelit.

Kontrolli reeglit konto enda seest

Küsi tuumalt, millise marsruudi UID saab, seejärel tee päring selle kontona ja võrdle väljumisaadressi oma konto omaga. Kui mõlemad teatavad sama aadressi, sobitub reegel millegi muuga kui see liiklus, mida sa testisid. Esimene käsk allpool näitab marsruudi otsingut ilma paketti saatmata, mis eraldab marsruutimisvea tulemüüriveast.

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

Loendurid näitavad, kas reegel kunagi rakendus. Käivita iptables -vnL OUTPUT, loe paketiarv iga reegli kõrval ja käsitle nulli DROP-i kõrval pärast tõelist liiklust sobitusveana.

Edastatud liiklus jääb sellest kavandist välja. Konteineril või VM-il silla taga pole kohalikku soketit, mis kuuluks vpnapp-le, seega omaniku sobitamine ei rakendu kunagi ja need paketid järgivad hoopis FORWARD-poliitikat. Kui see töökoormus tuleb katta, testi seda eraldi ja kirjuta poliitika, mis on seotud silla või konteineri aadressiga. Kavand peab vastu, kui tabel, liidese erand, resolver ja v6 reeglid osutavad kõik samasse suunda; jäta kas või üks neist välja ja konto kas lekib või kaotab ühenduse.