Rutta ett Linux-konto genom OpenVPN med en UID-regel

Kontobaserad routning passar när varje IPv4-socket som en Linux-användare äger ska lämna genom en befintlig tunnel, och den passar inte när du behöver isolering på programnivå. Den väljer efter UID, så allt som körs som det kontot omfattas, inklusive batchjobbet du glömde. Avgör den frågan innan du rör en enda ip rule.

Exemplet nedan förutsätter ett dedikerat webbläsarkonto på UID 1500, en tunneleenhet tun-office med lokal adress 10.80.0.11 och en VPN som tillåter de aktuella destinationerna. Själva daemonen körs utanför den UID:n.

Tre villkor som väljer mekanismen

Välj en UID-regel när identiteten som utför arbetet är kontot, när det är acceptabelt att flytta all dess trafik och när en namespace skulle vara tyngre än uppgiften förtjänar. Välj en nätverksnamespace när arbetsbelastningen behöver egna gränssnitt, resolver och routingtabell. Välj en proxy eller en bindning per process när exakt en applikation ska flyttas medan resten av sessionen stannar på den lokala vägen. Att skriva ned de tre hindrar en regel som tyst täcker mer än avsett.

Misstaget att undvika är att anta att en startare definierar ägaren. En webbläsare som får en URL från en annan användares session har inte skapat sockets under UID 1500, och ingen regel flyttar trafiken den genererar.

Tabellen, regeln och skyddet

Efter att ha kontrollerat befintliga regler och valt oanvända tabell- och prioritetsnummer är upplägget kort: en standardrutt i en egen tabell som bär tunnels källadress, en regel som skickar kontots uppslagningar till den tabellen och en avslutande regel som blockerar reserven. Utskrivet är det en idempotent rutterättning, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, följd av ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Skyddet är ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, och det betyder mer än dess längd antyder. Utan det faller en saknad rutt i tabell 51820 igenom till den vanliga upplänken och kontot läcker tyst trafik som policyn skulle fånga. Med det blir samma fel en timeout, det vill säga blockering i stället för reserv.

Håll den vanliga lokaladressregeln före dessa, och avgör medvetet om LAN- eller administrationsundantag hör före den valda tabellen. En standardrutt som hittas där frågar inte senare main efter en mer specifik LAN-rutt, vilket överraskar dem som förväntar sig att längsta prefixmatchning gäller mellan tabeller. Skriv den avsedda undantagslistan i ändringsanteckningen medan resonemanget fortfarande är färskt.

Vad UID-routning utelämnar: DNS

En resolverdaemon öppnar sina uppströmssockets under sin egen UID, så valet av 1500 flyttar inte de frågorna till tabell 51820. DNS-integrering är ett eget beslut: peka kontot mot en resolver som nås genom tunneln, eller acceptera att namnmatchning följer värdens väg medan trafiken inte gör det.

En loopback-fråga till en lokal stub är inte bevis för att uppströmsfrågan använde webbläsarens rutt, och en lyckad sidladdning från cachen är det inte heller.

IPv6 behöver sin egen mening i designen

Reglerna ovan täcker bara IPv4. Om kravet är en IPv4-tunnel utan direkt IPv6 från det här kontot, lägg till en granskad avslutande regel som ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, och kontrollera sedan tidigare IPv6-regler plus de loopback-undantag du vill behålla.

Att blockera direkt IPv6 är inte dual stack-tunnelning; det är en gräns. Att kalla det tunnelning förvirrar nästa person som läser policyn, och förvirringen dyker upp som en supportbiljett om en trasig IPv6-webbplats.

Verifiera med det riktiga kontot och ta sedan över livscykeln

Jämför uppslagningar: ip -4 route get 198.51.100.25 uid 1500 mot samma destination med en vanlig UID. Gör sedan en tillåten begäran under det dedikerade kontot och kontrollera källadressen som fjärränden ser. En föredragen källadress är inte source NAT, och den åsidosätter inte en applikation som binder något annat. Om båda uppslagningarna ger samma väg gör regeln inte det du tror.

Håll tabellen, reglerna och tunnelrutens livstid under en ägare, testa en återanslutning och en tunnelförlust, och när policyn avvecklas tar du bara bort dess exakta poster. En namespace finns fortfarande tillgänglig om separata gränssnitt och separat tillstånd är vad du faktiskt behöver.