Hvernig festa á einu Linux forriti við VPN með UID reglum

Að festa eitt forrit við VPN á Linux er aðallega leiðaval vandamál, og eldveggjarreglan ræður aðeins því sem gerist eftir að leiðin er valin. Ef þú passar UID forritsins í OUTPUT áður en göngin eiga sjálfgefnu leiðina, sleppir reglan einmitt þeim umferð sem þú vildir vernda. Sama regla sér heldur ekki resolver ferlið sem svarar DNS fyrirspurnum forritsins. Komdu röðinni rétt og einn reikningur án sérréttinda verður áreiðanlegur veljandi fyrir skipta göngin.

Gefðu reikningnum leið fyrir dóm

Eiganda samsvörunin svarar einni spurningu: byggði staðbundið socket sem tilheyrir þessu UID pakkann? Hún velur ekki tengi og getur ekki fært umferð sem aðaltöflan sendir þegar út um líkamlega NIC. Þess vegna lokar UID regla án samsvarandi leiðar forritinu í stað þess að beina því annað.

Sendu reikninginn fyrst í gegnum eigin töflu og leyfðu eldveggnum svo að staðfesta niðurstöðuna. Þetta virkar á vél sem iproute2 hennar skilur uidrange, sem ip rule help greinir frá í einni línu. Tafla 100 heldur sjálfgefinni leið í gegnum göngin, og reglan sendir aðeins UID 1000 í þá töflu. Allt annað er á aðaltöflunni og heldur áfram að nota líkamlegu tenginguna.

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

Annar reikningur sem þarf önnur göng fær töflu 101 og sína eigin reglu, því tvö prófíl geta ekki bæði átt sjálfgefnu leiðina í sömu töflu. NetworkManager prófílar eru kerfisvíðir, svo þessi hluti verður áfram handvirkur, og reglurnar hverfa við endurræsingu nema eitthvað endurheimti þær. Skrifaðu töflurnar í ræsiskrift við hlið gönguskilgreiningarinnar svo endurtenging geti ekki skilið einn reikning eftir á röngu leiðinni.

Hvers vegna loopback undantekningin drepur göngin

Flestar afritaðar útgáfur reglunnar sleppa hverjum pakka sem fer ekki út um loopback. Göngin eru ekki loopback, svo sú mynd sleppir líka umferð gagnanna, og niðurstaðan lítur út eins og dautt VPN frekar en eldveggja villa.

Þegar OUTPUT keyrir hefur kjarninn þegar valið útgangstengi, svo -o er borið saman við svar leiðarinnar, ekki við haus pakkans. Eiganda samsvörunin er aðeins skoðuð í OUTPUT og POSTROUTING, og framsendir pakkar bera ekkert socket fyrir hana að lesa. Þessi samsetning þýðir að undantekningin verður að nefna tengi ganganna og afneita þeirri samsvörun, í stað þess að afneita loopback.

Loopback á enn sinn eigin ACCEPT yfir DROP, því fyrsti DNS pakki forritsins fer til staðbundins stub yfir lo. Setja skal tvær reglurnar í þessa röð, og reikningurinn nær stub, svo göngunum, og engu öðru.

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 er sér reglusett, og par sem er aðeins fyrir v4 lætur ip6tables ósnortið. Forrit sem kýs AAAA færslur myndi þá fara út um líkamlegu tenginguna án þess að ná nokkurn tíma DROP. Speglaðu báðar reglurnar í ip6tables, eða slökktu á IPv6 á vélinni þegar göngin bera ekkert v6 vistfang. Reglur sem eru bætt við í höndunum hverfa líka við endurræsingu, svo vistaðu þær með netfilter-persistent save eða byggðu sömu rökfræði upp sem nftables töflu sem ræsieiningin hleður.

DNS svör koma frá öðru ferli

Fyrirspurn forritsins til 127.0.0.53 fer í gegnum loopback ACCEPT, og þar stöðvast UID samsvörunin. Stub resolver sendir fram á við frá eigin þjónustureikningi, svo regla sem er lykluð að vpnapp sér aldrei aðra fyrirspurn. Ef resolver velur LAN þjón fyrir tenginguna koma svörin til baka um líkamlega NIC á meðan eigin pakkar forritsins vera í göngunum. Sýnilega niðurstaðan er vinnandi göng með brotnum nöfnum, eða nöfn sem þjónn sem þú valdir ekki svarar.

Lagaðu nafnaupplausn á tengingu ganganna, ekki í forritinu. Gefðu gagnaprófílnum DNS þjón og leiðaval lén, og staðfestu svo með resolvectl query og resolvectl status tun0 að resolver noti hann fyrir nöfnin sem skipta máli. Innan netnafnrýmis hverfur vandamálið, því resolver rýmisins þekkir aðeins göngin.

Athugaðu regluna frá reikningnum sjálfum

Spurðu kjarnann hvaða leið UID fær, gerðu svo beiðni sem sá reikningur og berðu útgönguvistfangið saman við vistfang þíns eigin reiknings. Ef bæði tilkynna sama vistfang passar reglan eitthvað annað en umferðina sem þú prófaðir. Fyrsta skipunin hér fyrir neðan sýnir leiðarleitina án þess að senda pakka, sem aðgreinir leiðaval villa frá eldveggja villu.

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

Teljarar sýna hvort regla hefur nokkurn tíma kviknað. Keyrðu iptables -vnL OUTPUT, lestu pakkafjöldann við hverja reglu, og meðhöndlaðu núll við DROP eftir raunverulega umferð sem samsvörunarvillu.

Framsend umferð er utan þessarar hönnunar. Gámur eða VM bak við brú hefur ekkert staðbundið socket í eigu vpnapp, svo eiganda samsvörunin kviknar aldrei og þeir pakkar fylgja FORWARD stefnunni í staðinn. Ef þarf að ná yfir það vinnuálag skal prófa það sérstaklega og skrifa stefnu sem er lykluð að brúnni eða vistfangi gámsins. Hönnunin heldur þegar taflan, tengi undantekningin, resolver og v6 reglurnar benda allar í sömu átt; slepptu einhverri þeirra og reikningurinn lekur eða missir tengingu.