Ee Linux-Programm mat UID-Regele mat engem VPN verbannen

Een eenzelt Programm op Linux mat engem VPN ze verbannen ass virun allem e Routingproblem, an d'Firewall-Reeg entscheet just, wat geschitt nodeems d'Route gewielt gouf. Wann Dir d'UID vum Programm an OUTPUT ofgläicht, ier den Tunnel d'Standardroute huet, da werft d'Reeg genau de Verkéier ewech, deen Dir wollt schützen. Déi selwecht Reeg gesäit och net de Resolverprozess, deen d'DNS-Ufroe vum Programm beäntwert. Setzt d'Reiefolleg richteg, an ee Konto ouni Privilegien gëtt en zouverlässegen Auswieler fir den gedeelten Tunnel.

Gitt dem Konto eng Route virun engem Uerteel

D'Eegentümer-Ofgläichung beäntwert eng Fro: huet e lokale Socket, deen zu dëser UID gehéiert, de Pak gebaut? Si wielt keng Schnëttstell an kann de Verkéier net réckelen, deen d'Haapttabell schonn iwwer den physeschen NIC schéckt. Dofir blockéiert eng UID-Reeg ouni passend Route de Programm, amplaz en ëmzuleeden.

Schéckt de Konto d'éischt duerch seng eege Tabell, an da loosst d'Firewall d'Resultat bestätegen. Dëst funktionéiert op engem Host, deem säin iproute2 uidrange versteet, wat ip rule help an enger Zeil mellen. Tabell 100 hält eng Standardroute duerch den Tunnel, an d'Reeg schéckt just UID 1000 an déi Tabell. Alles anescht bleift op der Haapttabell a benotzt weider de physesche Link.

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

En zweete Konto, deen en aneren Tunnel brauch, kritt Tabell 101 a seng eege Reeg, well zwee Profiler net béid d'Standardroute an der selwechter Tabell kënnen hunn. NetworkManager-Profiler sinn systemwäit, dofir bleift dësen Deel manuell, an d'Reegele verschwannen beim Neistart, wann net eppes se restauréiert. Schreift d'Tabellen an e Bootskript nieft der Tunneldefinitioun, sou datt eng Reconnectioun ee Konto net um falsche Wee ka loossen.

Firwat d'Loopback-Ausnam den Tunnel ëmbréngt

Déi meescht kopéiert Versiounen vun der Reeg verwerfen all Pak, deen net duerch Loopback erausgeet. Den Tunnel ass keen Loopback, dofir verwerft déi Form och den Tunnelverkéier, an d'Resultat gesäit aus wéi en doudege VPN an net wéi e Firewall-Fehler.

Wann OUTPUT leeft, huet de Kernel schonn eng Ausgangsschnëttstell gewielt, dofir -o gëtt mat der Äntwert vun der Route verglach, net mam Pakkopf. Déi Eegentümer-Ofgläichung gëtt nëmmen an OUTPUT an POSTROUTING consultéiert, an duerchgelooss Pakke droen kee Socket, deen se liese kéint. Dës Kombinatioun bedeit, datt d'Ausnam d'Tunnelschnëttstell nenne muss an déi Ofgläichung negéiere muss, amplaz Loopback ze negéieren.

Loopback verdéngt nach ëmmer säin eegenen ACCEPT iwwer dem DROP, well den éischten DNS-Pak vum Programm iwwer lo op de lokale Stub geet. Setzt déi zwou Reegele an dëser Reiefolleg, an de Konto erreecht de Stub, dann den Tunnel, an soss näischt.

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 ass en eegene Reegelsatz, an e Puer just fir v4 léisst ip6tables onberéiert. E Programm, dat AAAA-Recorde bevorzugt, géif dann iwwer de physesche Link erausgoen, ouni je den DROP z'erreechen. Spigelt béid Reegele an ip6tables, oder deaktivéiert IPv6 um Host, wann den Tunnel keng v6-Adress dréit. Reegele vun Hand derbäi verschwannen och beim Neistart, dofir späichert se mat netfilter-persistent save oder baut déiselwecht Logik als nftables-Tabell nei, déi vun der Bootseenheet gelueden gëtt.

DNS-Äntwerten komme vun engem anere Prozess

D'Ufro vum Programm un 127.0.0.53 geet duerch den Loopback-ACCEPT, an do hält d'UID-Ofgläichung op. De Stub-Resolver leet no uewen aus sengem eegene Servicekonto weider, dofir gesäit eng Reeg, déi op vpnapp geschlësselt ass, déi zweet Ufro ni. Wann de Resolver fir de Link e LAN-Server wielt, komme d'Äntwerten iwwer den physeschen NIC zréck, wärend d'Pak vum Programm selwer am Tunnel bleiwen. Déi sichtbar Resultat ass en Tunnel, dee mat gebrachen Nimm funktionéiert, oder Nimm, déi e Server beäntwert, deen Dir net gewielt hutt.

Fleckt d'Nimmopzielung um Tunnellink, net an der Applikatioun. Gitt dem Tunnelprofil en DNS-Server an eng Routingdomän, an da bestätegt mat resolvectl query an resolvectl status tun0 datt de Resolver en fir déi Nimm benotzt, déi zielen. Bannen engem Netzwierk-Nummraum verschwënnt de Problem, well de Resolver vum Nummraum just den Tunnel kennt.

Préift d'Reeg vum Konto selwer

Frot de Kernel, wéi eng Route eng UID kritt, maacht dann eng Ufro als dee Konto a vergläicht d'Ausgangsadress mat där vun Ärem eegene Konto. Wann béid déiselwecht Adress mellen, gläicht d'Reeg eppes anescht wéi de Verkéier, deen Dir getest hutt. Déi éischt Kommando hei drënner weist d'Routesich ouni e Pak ze schécken, wat e Routingfehler vun engem Firewallfehler trennt.

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

Zähler weisen, ob eng Reeg je ausgeléist huet. Fëllt iptables -vnL OUTPUT aus, liest d'Päckzuel nieft all Reeg, a behandelt eng Null nieft dem DROP no richtegem Verkéier als Ofgläichungsfehler.

Weidergeleet Verkéier steet ausserhalb vun dësem Design. E Container oder eng VM hannert enger Bréck huet kee lokale Socket am Besëtz vum vpnapp, dofir léist d'Eegentümer-Ofgläichung ni aus, an déi Pak follegen amplaz der FORWARD-Politik. Wann déi Aarbecht misst ofgedeckt ginn, test se separat a schreift eng Politik, déi un d'Bréck oder d'Containeradress gebonnen ass. D'Design hält, wann d'Tabell, d'Schnëttstell-Ausnam, de Resolver an d'v6-Reegele all an déi selwecht Richtung weisen; loosst eng dovun ewech, an de Konto leckt oder verléiert d'Verbindung.