Egy Linux-fiók átirányítása az OpenVPN-en UID-szabállyal

A fiók alapú útválasztás akkor illik, ha egy Linux-felhasználó minden IPv4-szoketjének egy meglévő alagúton kell kilépnie, és akkor nem illik, ha programszintű elkülönítésre van szüksége. UID szerint választ, tehát minden, ami ezzel a fiókkal fut, a hatókörbe esik, beleértve az elfelejtett kötegelt feladatot is. Ezt a kérdést még azelőtt tisztázza, hogy egyetlen ip rule-hoz hozzányúlna.

Az alábbi példa egy UID 1500-as dedikált böngészőfiókot, a 10.80.0.11 helyi címet viselő tun-office alagúteszközt és egy VPN-t feltételez, amely engedélyezi a szóban forgó célokat. Maga a démon ezen az UID-n kívül fut.

Három feltétel, amely a mechanizmust kiválasztja

Akkor válasszon UID-szabályt, ha a munkát végző identitás a fiók, ha az egész forgalmának átmozgatása elfogadható, és ha egy namespace nehezebb lenne, mint amit a feladat megérdemel. Akkor válasszon hálózati namespace-t, ha a munkaterhelésnek saját interfészekre, feloldóra és útválasztási táblára van szüksége. Akkor válasszon proxyt vagy folyamatonkénti kötést ha pontosan egy alkalmazásnak kell átmozdulnia, miközben a munkamenet többi része a helyi úton marad. E három leírása megakadályozza az olyan szabályt, amely csendben többet fed le a szándékosnál.

Az elkerülendő hiba az a feltevés, hogy az indító határozza meg a tulajdonost. Az a böngésző, amelynek egy másik felhasználó munkamenete adott URL-t, nem hozott létre szoketeket az UID 1500 alatt, és egyetlen szabály sem mozgatja el az általa létrehozott forgalmat.

A tábla, a szabály és az őr

A meglévő szabályok ellenőrzése és a nem használt tábla- és prioritásszámok kiválasztása után az elrendezés rövid: alapértelmezett útvonal egy dedikált táblában, amely az alagút forrás-címét hordozza, egy szabály, amely a fiók kereséseit abba a táblába küldi, és egy lezáró szabály, amely blokkolja a tartalékot. Kiírva ez idempotens útvonalcserét jelent, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, amelyet ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820 követ.

Az őr ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, és többet számít, mint amit a hossza sugall. Nélküle az 51820-as táblában hiányzó útvonal a szokásos felső kapcsolatra esik, és a fiók csendben szivárogtatja azt a forgalmat, amelyet a szabályzat meg akart fogni. Vele ugyanez a hiba időtúllépéssé válik, tehát blokkolássá a tartalék helyett.

Tartsa a szokásos helyicím-szabályt ezek előtt, és tudatosan döntse el, hogy a LAN- vagy felügyeleti kivételek a kiválasztott tábla elé tartoznak-e. Az ott talált alapértelmezett útvonal később nem kérdezi meg main-öt egy konkrétabb LAN-útvonalért, ami meglepheti azokat, akik a leghosszabb előtag egyezését táblákon át várják érvényesnek. Írja le a szándékolt kivételek listáját a változásjegyzetbe, amíg az indoklás friss.

Amit az UID-útválasztás kihagy: a DNS

A feloldó démon a saját UID-je alatt nyitja a felső szoketjeit, így az 1500 kiválasztása nem mozgatja ezeket a lekérdezéseket az 51820-as táblába. A DNS-integráció külön döntés: irányítsa a fiókot az alagúton át elérhető feloldóhoz, vagy fogadja el, hogy a névfeloldás a gazdagép útját követi, a forgalom viszont nem.

A loopback-lekérdezés egy helyi stubhoz nem bizonyíték arra, hogy a felső lekérdezés a böngésző útvonalát használta, ahogyan egy sikeres gyorsítótárból betöltött oldal sem.

Az IPv6-nak saját mondat kell a tervezésben

A fenti szabályok csak az IPv4-et fedik le. Ha a követelmény IPv4-alagút közvetlen IPv6 nélkül erről a fiókról, adjon hozzá egy átvizsgált lezáró szabályt, például ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, majd ellenőrizze a korábbi IPv6-szabályokat és a megtartani kívánt loopback-kivételeket.

A közvetlen IPv6 blokkolása nem kettős veremű alagútasítás; ez egy határ. Alagútasításnak nevezni összezavarja a szabályzat következő olvasóját, és a zűrzavar egy törött IPv6-oldalról szóló ügyfélszolgálati jegyben jelenik meg.

Ellenőrizze a valódi fiókkal, majd vegye át az életciklust

Hasonlítsa össze a kereséseket: ip -4 route get 198.51.100.25 uid 1500 ugyanarra a célra szokásos UID-del. Ezután tegyen engedélyezett kérést a dedikált fiók alatt, és ellenőrizze a forrás-címet, amelyet a távoli fél lát. Az előnyben részesített forrás-cím nem source NAT, és nem írja felül azt az alkalmazást, amely mást köt. Ha mindkét keresés ugyanazt az utat adja vissza, a szabály nem azt teszi, amit gondol.

Tartsa a táblát, a szabályokat és az alagútútvonal élettartamát egy tulajdonos alatt, teszteljen újracsatlakozást és alagútvesztést, és a szabályzat kivezetésekor csak a pontos bejegyzéseit távolítsa el. A namespace továbbra is elérhető, ha külön interfészek és külön állapot az, amire valóban szüksége van.