Ühe Linuxi konto suunamine OpenVPN-i kaudu UID-reegliga

Kontopõhine marsruutimine sobib siis, kui iga ühe Linuxi kasutaja omandis olev IPv4-pesa peab väljuma olemasoleva tunneli kaudu, ja ei sobi siis, kui vajate isolatsiooni programmi tasandil. See valib UID-i järgi, seega kõik, mis selle konto all töötab, on ulatuses, kaasa arvatud pakett-töö, mille unustasite. Lahendage see küsimus enne, kui puudutate ühtki ip rule.

Allolev näide eeldab UID 1500 juures eraldatud brauserikontot, kohalikku aadressi 10.80.0.11 kandvat tunneliseadet tun-office ja VPN-i, mis lubab kõnealuseid sihtkohti. Deemon ise töötab sellest UID-ist väljaspool.

Kolm tingimust, mis valivad mehhanismi

Valige UID-reegel, kui tööd tegev identiteet on konto, kui kogu selle liikluse liigutamine on vastuvõetav ja kui namespace oleks raskem, kui ülesanne väärib. Valige võrgu namespace, kui töökoormus vajab oma liideseid, resolverit ja marsruutimistabelit. Valige puhverserver või protsessipõhine sidumine kui täpselt üks rakendus peab liikuma, samal ajal kui ülejäänud sessioon jääb kohalikule teele. Nende kolme kirjapanek hoiab ära reegli, mis katab vaikselt rohkem, kui kavatseti.

Viga, mida vältida, on eeldus, et käivitaja määrab omaniku. Brauser, millele teise kasutaja sessioon URL-i andis, ei ole UID 1500 all pesasid loonud ja ükski reegel ei liiguta selle tekitatud liiklust.

Tabel, reegel ja valvur

Pärast olemasolevate reeglite kontrollimist ja kasutamata tabeli- ning prioriteedinumbrite valimist on korraldus lühike: tunneli lähteaadressi kandev vaikemarsruut eraldatud tabelis, reegel, mis saadab konto päringud sellesse tabelisse, ja lõpetav reegel, mis blokeerib varuvariandi. Kirja panduna on see idempotentne marsruudi asendus, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, millele järgneb ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Valvur on ip -4 rule add priority 12101 uidrange 1500-1500 unreachable ja see loeb rohkem, kui selle pikkus vihjab. Ilma selleta kukub tabelis 51820 puuduv marsruut tavalisse ühenduvasse ja konto lekib vaikselt liiklust, mille poliitika pidi kinni püüdma. Sellega muutub sama tõrge aegumiseks, st blokeerimiseks, mitte varuvariandiks.

Hoidke tavaline kohaliku aadressi reegel nende ees ja otsustage teadlikult, kas LAN-i või halduse erandid kuuluvad valitud tabeli ette. Seal leitud vaikemarsruut ei konsulteeri hiljem main-i täpsema LAN-i marsruudi osas, mis üllatab neid, kes eeldavad, et pikima prefiksi sobivus kehtib tabelite vahel. Kirjutage kavatsetud erandite loend muudatuse märkmikku, kuni põhjendus on veel värske.

Mida UID-marsruutimine välja jätab: DNS

Resolveri deemon avab oma ülesvoolu pesad oma UID-i all, seega 1500 valimine ei liiguta neid päringuid tabelisse 51820. DNS-i integreerimine on eraldi otsus: suunake konto tunneli kaudu kättesaadava resolveri poole või leppige sellega, et nimeotsing järgib hosti teed, liiklus aga mitte.

Loopback-päring kohaliku stubi vastu ei ole tõestus, et ülesvoolu päring kasutas brauseri marsruuti, ja sama ei ole ka edukas lehe laadimine vahemälust.

IPv6 vajab kavandis omaette lauset

Ülaltoodud reeglid katavad ainult IPv4. Kui nõue on IPv4-tunnel ilma otsese IPv6-ta sellest kontost, lisage üle vaadatud lõpetav reegel nagu ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, seejärel kontrollige varasemaid IPv6-reegleid ja loopback-erandeid, mida soovite hoida.

Otsese IPv6 blokeerimine ei ole kahekihiline tunnelimine; see on piir. Selle tunnelimiseks nimetamine ajab segadusse järgmise inimese, kes poliitikat loeb, ja segadus tuleb välja kasutajatoe piletina katkise IPv6-saidi kohta.

Kontrollige päris kontoga ja seejärel võtke elutsükkel üle

Võrrelge päringuid: ip -4 route get 198.51.100.25 uid 1500 sama sihtkoha vastu tavalise UID-iga. Seejärel tehke eraldatud konto all lubatud päring ja kontrollige lähteaadressi, mida kaugem pool näeb. Eelistatud lähteaadress ei ole source NAT ja see ei alista rakendust, mis seob midagi muud. Kui mõlemad päringud annavad sama tee, ei tee reegel seda, mida arvate.

Hoidke tabel, reeglid ja tunneli marsruudi eluiga ühe omaniku all, testige taasühendust ja tunneli kadumist ning poliitika lõpetamisel eemaldage ainult selle täpsed kirjed. Namespace on endiselt saadaval, kui eraldi liidesed ja eraldi olek on see, mida tegelikult vajate.