Rut én Linux-konto gennem OpenVPN med en UID-regel

Kontobaseret routing passer, når hver IPv4-socket, som én Linux-bruger ejer, skal forlade systemet gennem en eksisterende tunnel, og den passer ikke, når du har brug for isolering på programniveau. Den vælger efter UID, så alt, der kører som den konto, er omfattet, inklusive batchjobbet, du glemte. Afgør det spørgsmål, før du rører ved en enkelt ip rule.

Eksemplet nedenfor forudsætter en dedikeret browserkonto på UID 1500, en tunneleenhed tun-office med lokal adresse 10.80.0.11 og en VPN, der tillader de pågældende destinationer. Selve daemonen kører uden for den UID.

Tre betingelser, der vælger mekanismen

Vælg en UID-regel, når identiteten, der udfører arbejdet, er kontoen, når det er acceptabelt at flytte al dens trafik, og når et namespace ville være tungere, end opgaven fortjener. Vælg et netværksnamespace, når arbejdsbyrden har brug for sine egne interfaces, resolver og routingtabel. Vælg en proxy eller en binding pr. proces når præcis én applikation skal flyttes, mens resten af sessionen bliver på den lokale vej. At skrive de tre ned forhindrer en regel, der stille dækker mere, end det var meningen.

Den fejl, du skal undgå, er at antage, at en launcher definerer ejeren. En browser, der får en URL fra en anden brugers session, har ikke oprettet sockets under UID 1500, og ingen regel flytter den trafik, den genererer.

Tabellen, reglen og værnet

Når du har kontrolleret eksisterende regler og valgt ubrugte tabel- og prioritetsnumre, er opsætningen kort: en standardrute i en dedikeret tabel, der bærer tunnelens kildeaddresse, en regel der sender kontoens opslag til den tabel, og en afsluttende regel, der blokerer fallback. Udspecificeret er det en idempotent ruteudskiftning, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, efterfulgt af ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Værnet er ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, og det betyder mere, end dets længde antyder. Uden det falder en manglende rute i tabel 51820 igennem til den almindelige uplink, og kontoen lækker lydløst trafik, som politikken skulle fange. Med det bliver den samme fejl en timeout, altså blokering i stedet for fallback.

Hold den normale lokaladresseregel foran disse, og afgør bevidst, om LAN- eller administrationsundtagelser hører før den valgte tabel. En standardrute, der findes der, konsulterer ikke senere main for en mere specifik LAN-rute, hvilket overrasker dem, der forventer, at længste-præfiks-matchning gælder på tværs af tabeller. Skriv den tilsigtede undtagelsesliste i ændringsnoten, mens begrundelsen stadig er frisk.

Hvad UID-routing udelader: DNS

En resolverdaemon åbner sine upstream-sockets under sin egen UID, så valget af 1500 flytter ikke de forespørgsler til tabel 51820. DNS-integration er en separat beslutning: peg kontoen mod en resolver, der kan nås gennem tunnelen, eller accepter, at navneopløsning følger værtens vej, mens trafik ikke gør.

En loopback-forespørgsel til en lokal stub er ikke bevis for, at upstream-forespørgslen brugte browserens rute, og en vellykket sideindlæsning fra cache er det heller ikke.

IPv6 kræver sin egen sætning i designet

Reglerne ovenfor dækker kun IPv4. Hvis kravet er en IPv4-tunnel uden direkte IPv6 fra denne konto, skal du tilføje en gennemgået afsluttende regel som ip -6 rule add priority 12101 uidrange 1500-1500 unreachable og derefter kontrollere tidligere IPv6-regler plus de loopback-undtagelser, du vil beholde.

Blokering af direkte IPv6 er ikke dual-stack-tunneling; det er en grænse. At kalde det tunneling vil forvirre den næste, der læser politikken, og forvirringen dukker op som en supportbillet om et ødelagt IPv6-websted.

Verificér med den rigtige konto, og tag derefter ejerskab over livscyklussen

Sammenlign opslag: ip -4 route get 198.51.100.25 uid 1500 mod den samme destination med en almindelig UID. Lav derefter en tilladt anmodning under den dedikerede konto, og kontrollér den kildeadresse, den fjerne ende ser. En foretrukken kildeadresse er ikke source NAT, og den tilsidesætter ikke en applikation, der binder noget andet. Hvis begge opslag returnerer samme vej, gør reglen ikke, hvad du tror.

Hold tabellen, reglerne og tunnelrutens levetid under én ejer, test en genopkobling og et tunneltab, og fjern kun dens præcise poster, når politikken udfases. Et namespace er stadig tilgængeligt, hvis separate interfaces og separat tilstand er det, du faktisk har brug for.