Eén Linux-account via OpenVPN routeren met een UID-regel

Routing op basis van een account past wanneer elke IPv4-socket van één Linux-gebruiker via een bestaande tunnel moet vertrekken, en het past niet wanneer u isolatie op programmaniveau nodig hebt. Het kiest op UID, dus alles wat onder dat account draait valt binnen bereik, inclusief de batchtaak die u vergat. Los die vraag op voordat u één ip rule aanraakt.

Het onderstaande voorbeeld gaat uit van een eigen browseraccount op UID 1500, een tunnelapparaat tun-office met lokaal adres 10.80.0.11, en een VPN die de betreffende bestemmingen toestaat. De daemon zelf draait buiten die UID.

Drie voorwaarden die het mechanisme kiezen

Kies een UID-regel wanneer de identiteit die het werk doet het account is, wanneer het verplaatsen van al zijn verkeer aanvaardbaar is, en wanneer een namespace zwaarder zou zijn dan de taak verdient. Kies een netwerknamespace wanneer de werkbelasting eigen interfaces, resolver en routingtabel nodig heeft. Kies een proxy of een binding per proces wanneer precies één toepassing moet verhuizen terwijl de rest van de sessie op het lokale pad blijft. Die drie opschrijven voorkomt een regel die stil meer dekt dan bedoeld.

De fout die u moet vermijden is aannemen dat een launcher de eigenaar bepaalt. Een browser die een URL van de sessie van een andere gebruiker krijgt, heeft geen sockets onder UID 1500 gemaakt, en geen regel verplaatst het verkeer dat hij genereert.

De tabel, de regel en de wachter

Na het controleren van bestaande regels en het kiezen van ongebruikte tabel- en prioriteitsnummers is de opzet kort: een standaardroute in een eigen tabel die het bronadres van de tunnel draagt, een regel die de opzoekingen van het account naar die tabel stuurt, en een afsluitende regel die de terugval blokkeert. Uitgeschreven is dat een idempotente routevervanging, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, gevolgd door ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

De wachter is ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, en hij telt meer dan zijn lengte suggereert. Zonder hem valt een ontbrekende route in tabel 51820 door naar de gewone uplink en lekt het account stil verkeer dat het beleid moest vangen. Met hem wordt dezelfde fout een time-out, dus blokkeren in plaats van terugval.

Houd de normale regel voor lokale adressen vóór deze, en beslis bewust of LAN- of beheeruitzonderingen vóór de gekozen tabel horen. Een standaardroute die daar wordt gevonden raadpleegt later niet main voor een specifiekere LAN-route, wat mensen verrast die verwachten dat de langste-prefixovereenkomst tussen tabellen geldt. Schrijf de bedoelde uitzonderingenlijst in de wijzigingsnotitie zolang de redenering nog vers is.

Wat UID-routing weglaat: DNS

Een resolverdaemon opent zijn upstreamsockets onder zijn eigen UID, dus het kiezen van 1500 verplaatst die query s niet naar tabel 51820. DNS-integratie is een aparte beslissing: wijs het account naar een resolver die via de tunnel bereikbaar is, of accepteer dat naamresolutie het pad van de host volgt terwijl het verkeer dat niet doet.

Een loopback-query naar een lokale stub is geen bewijs dat de upstreamquery de route van de browser gebruikte, en een geslaagde paginalading uit de cache ook niet.

IPv6 heeft zijn eigen zin in het ontwerp nodig

De regels hierboven dekken alleen IPv4. Als de eis een IPv4-tunnel zonder directe IPv6 vanaf dit account is, voeg dan een beoordeelde afsluitende regel toe zoals ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, en controleer daarna eerdere IPv6-regels plus de loopback-uitzonderingen die u wilt behouden.

Direct IPv6 blokkeren is geen dual-stacktunneling; het is een grens. Het tunneling noemen zal de volgende persoon die het beleid leest verwarren, en de verwarring komt boven als een servicedeskticket over een kapotte IPv6-site.

Verifieer met het echte account en neem daarna de levenscyclus over

Vergelijk opzoekingen: ip -4 route get 198.51.100.25 uid 1500 tegen dezelfde bestemming met een gewone UID. Doe daarna een toegestaan verzoek onder het eigen account en controleer het bronadres dat de verre kant ziet. Een voorkeursbronadres is geen source NAT, en het overschrijft geen toepassing die iets anders bindt. Als beide opzoekingen hetzelfde pad teruggeven, doet de regel niet wat u denkt.

Houd de tabel, de regels en de levensduur van de tunnelroute onder één eigenaar, test een herverbinding en een tunnelverlies, en verwijder bij het uitfaseren van het beleid alleen de exacte vermeldingen. Een namespace is nog beschikbaar als aparte interfaces en aparte status zijn wat u werkelijk nodig hebt.