Rut ein Linux-konto gjennom OpenVPN med ein UID-regel
Ein uidrange-regel set IPv4-soklane til ein konto inn i ein eksisterande tunnel utan namespace. Avgjer DNS, IPv6 og reserveveg kvar for seg, og stadfest etterpå.
Kontobasert ruting passar når kvar IPv4-sokkel som ein Linux-brukar eig skal gå ut gjennom ein eksisterande tunnel, og det passar ikkje når du treng isolasjon på programnivå. Ho vel etter UID, så alt som køyrer som den kontoen er omfatta, inkludert batchjobben du gløymde. Avgjer det spørsmålet før du rører ein einaste ip rule.
Dømet nedanfor føreset ein dedikert nettlesarkonto på UID 1500, ei tunneleining tun-office med lokal adresse 10.80.0.11, og ein VPN som tillèt dei aktuelle måla. Sjølve daemonen køyrer utanfor den UID-en.
Tre vilkår som vel mekanismen
Vel ein UID-regel når identiteten som gjer arbeidet er kontoen, når det er akseptabelt å flytte all trafikken hans, og når eit namespace ville vere tyngre enn oppgåva fortener. Vel eit nettverksnamespace når arbeidslasta treng eigne grensesnitt, resolver og rutetabell. Vel ein proxy eller ei binding per prosess når nøyaktig éin applikasjon skal flyttast medan resten av økta blir på den lokale vegen. Å skrive ned dei tre hindrar ein regel som stille dekkjer meir enn tenkt.
Feilen du bør unngå er å tru at ein oppstartar definerer eigaren. Ein nettlesar som får ein URL frå økta til ein annan brukar har ikkje oppretta soklar under UID 1500, og ingen regel flyttar trafikken han genererer.
Tabellen, regelen og vernet
Etter å ha kontrollert eksisterande reglar og valt ubrukte tabell- og prioritetsnummer, er oppsettet kort: ein standardrute i ein eigen tabell som ber kjeldeadressa til tunnelen, ein regel som sender oppslaga til kontoen til den tabellen, og ein avsluttande regel som blokkerer reservevegen. Skrive ut er det ei idempotent ruteerstatning, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, etterfølgd 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 tyder meir enn lengda antydar. Utan det fell ei manglande rute i tabell 51820 gjennom til den vanlege opplenkja, og kontoen lek stille trafikk som policyen skulle fange. Med det blir same feil ein tidsavbrot, altså blokkering i staden for reserve.
Hald den vanlege lokaladresseregelen framom desse, og avgjer medvite om LAN- eller administrasjonsunntak høyrer før den valde tabellen. Ei standardrute som blir funnen der spør ikkje seinare main om ei meir spesifikk LAN-rute, noko som overraskar dei som ventar at lengste prefiks-samsvar gjeld på tvers av tabellar. Skriv den tiltenkte unntakslista i endringsnotatet medan grunngivinga framleis er fersk.
Kva UID-ruting utelèt: DNS
Ein resolverdaemon opnar oppstraumsoksane sine under sin eigen UID, så valet av 1500 flyttar ikkje dei spørjingane til tabell 51820. DNS-integrering er eit eige val: peik kontoen mot ein resolver som er nåbar gjennom tunnelen, eller godta at namneoppslag følgjer vegen til verten medan trafikken ikkje gjer det.
Ei loopback-spørjing til ein lokal stub er ikkje prov på at oppstraumsspørjinga brukte ruta til nettlesaren, og ei vellukka sideinnlasting frå cache er det heller ikkje.
IPv6 treng si eiga setning i designet
Reglane ovanfor dekkjer berre IPv4. Viss kravet er ein IPv4-tunnel utan direkte IPv6 frå denne kontoen, legg til ein gjennomgått avsluttande regel som ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, og kontroller deretter tidlegare IPv6-reglar pluss loopback-unntaka du vil behalde.
Å blokkere direkte IPv6 er ikkje dual-stack-tunnelering; det er ei grense. Å kalle det tunnelering vil forvirre neste person som les policyen, og forvirringa dukkar opp som ein supportbillett om eit øydelagt IPv6-nettstad.
Stadfest med den ekte kontoen, og ta deretter eigarskap til livssyklusen
Samanlikn oppslag: ip -4 route get 198.51.100.25 uid 1500 mot same mål med ein vanleg UID. Lag deretter ein tillaten førespurnad under den dedikerte kontoen og kontroller kjeldeadressa den fjerne enden ser. Ei føretrekt kjeldeadresse er ikkje source NAT, og ho overstyrer ikkje ein applikasjon som bind noko anna. Viss begge oppslaga gir same veg, gjer regelen ikkje det du trur.
Hald tabellen, reglane og levetida til tunnelruta under éin eigar, test ei gjenoppkopling og eit tunneltap, og når policyen blir avvikla fjernar du berre dei nøyaktige oppføringane. Eit namespace er framleis tilgjengeleg viss separate grensesnitt og separat tilstand er det du faktisk treng.