Rut én Linux-konto gjennom OpenVPN med en UID-regel
En uidrange-regel setter én kontos IPv4-sokler inn i en eksisterende tunnel uten namespace. Bestem DNS, IPv6 og reservevei hver for seg, og verifiser etterpå.
Kontobasert ruting passer når hver IPv4-sokkel som én Linux-bruker eier skal gå ut gjennom en eksisterende tunnel, og det passer ikke når du trenger isolasjon på programnivå. Den velger etter UID, så alt som kjører som den kontoen er omfattet, inkludert batchjobben du glemte. Avgjør det spørsmålet før du rører en eneste ip rule.
Eksempelet nedenfor forutsetter en dedikert nettleserkonto på UID 1500, en tunneleenhet tun-office med lokal adresse 10.80.0.11, og en VPN som tillater de aktuelle destinasjonene. Selve daemonen kjører utenfor den UID-en.
Tre betingelser som velger mekanismen
Velg en UID-regel når identiteten som gjør arbeidet er kontoen, når det er akseptabelt å flytte all trafikken dens, og når et namespace ville være tyngre enn oppgaven fortjener. Velg et nettverksnamespace når arbeidsbelastningen trenger egne grensesnitt, resolver og rutetabell. Velg en proxy eller en binding per prosess når nøyaktig én applikasjon skal flyttes mens resten av økten blir på den lokale veien. Å skrive ned de tre hindrer en regel som stille dekker mer enn tiltenkt.
Feilen du bør unngå er å anta at en oppstarter definerer eieren. En nettleser som får en URL fra en annen brukers økt har ikke opprettet sokler under UID 1500, og ingen regel flytter trafikken den genererer.
Tabellen, regelen og vernet
Etter å ha kontrollert eksisterende regler og valgt ubrukte tabell- og prioritetsnumre, er oppsettet kort: en standardrute i en egen tabell som bærer tunnelens kildeadresse, en regel som sender kontoens oppslag til den tabellen, og en avsluttende regel som blokkerer reserveveien. Skrevet ut er det en idempotent ruteerstatning, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, etterfulgt av ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.
Vernet er ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, og det betyr mer enn lengden antyder. Uten det faller en manglende rute i tabell 51820 gjennom til den vanlige opplenken, og kontoen lekker stille trafikk som policyen skulle fange. Med det blir samme feil en tidsavbrudd, altså blokkering i stedet for reserve.
Hold den vanlige lokaladresseregelen foran disse, og avgjør bevisst om LAN- eller administrasjonsunntak hører før den valgte tabellen. En standardrute som finnes der spør ikke senere main om en mer spesifikk LAN-rute, noe som overrasker dem som forventer at lengste prefiks-samsvar gjelder på tvers av tabeller. Skriv den tiltenkte unntakslisten i endringsnotatet mens begrunnelsen fortsatt er fersk.
Hva UID-ruting utelater: DNS
En resolverdaemon åpner oppstrømssoklene sine under sin egen UID, så valget av 1500 flytter ikke de spørringene til tabell 51820. DNS-integrasjon er en egen beslutning: pek kontoen mot en resolver som er nåbar gjennom tunnelen, eller godta at navneoppslag følger vertens vei mens trafikken ikke gjør det.
En loopback-spørring til en lokal stub er ikke bevis for at oppstrømsspørringen brukte nettleserens rute, og en vellykket sideinnlasting fra cache er det heller ikke.
IPv6 trenger sin egen setning i designet
Reglene ovenfor dekker bare IPv4. Hvis kravet er en IPv4-tunnel uten direkte IPv6 fra denne kontoen, legg til en gjennomgått avsluttende regel som ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, og kontroller deretter tidligere IPv6-regler pluss loopback-unntakene du vil beholde.
Å blokkere direkte IPv6 er ikke dual-stack-tunnelering; det er en grense. Å kalle det tunnelering vil forvirre neste person som leser policyen, og forvirringen dukker opp som en supportbillett om et ødelagt IPv6-nettsted.
Verifiser med den ekte kontoen, og ta deretter eierskap til livssyklusen
Sammenlign oppslag: ip -4 route get 198.51.100.25 uid 1500 mot samme destinasjon med en vanlig UID. Lag deretter en tillatt forespørsel under den dedikerte kontoen og kontroller kildeadressen den fjerne enden ser. En foretrukket kildeadresse er ikke source NAT, og den overstyrer ikke en applikasjon som binder noe annet. Hvis begge oppslagene gir samme vei, gjør regelen ikke det du tror.
Hold tabellen, reglene og levetiden til tunnelruten under én eier, test en gjenoppkobling og et tunneltap, og når policyen avvikles fjerner du bare de nøyaktige oppføringene. Et namespace er fortsatt tilgjengelig hvis separate grensesnitt og separat tilstand er det du faktisk trenger.