Bežná aplikácia Linux používa VPN bez dotyku TUN

Prehliadač, ktorý používa už zavedenú Linux VPN, neotvára /dev/net/tun. Otvára socket a jadro rozhoduje, cez ktoré rozhranie vychádzajú pakety tohto socketu. Proces, ktorý vytvoril tunel, robí inú prácu než proces, ktorého premávku prenáša. Oddelenie týchto dvoch rolí odpovedá na väčšinu otázok o oprávneniach skôr, než sú položené.

Sledujte jeden paket od socketu k tunelu

Bežná aplikácia volá connect alebo send a jadro hľadá trasu k cieľu. Ak zvolená trasa ukazuje na rozhranie tunela, paket sa zaradí do fronty zariadenia, ktoré číta VPN démon. Démon ho zašifruje a odošle von fyzickým rozhraním. Každá šípka v tomto opise je miesto, kde sa dá odpovedať na otázku o oprávneniach.

Nič na tej ceste nevyžaduje, aby aplikácia poznala zariadenie. Démon drží deskriptor súboru a vykonáva operácie rozhrania, zatiaľ čo aplikácia vidí iba bežné sieťové API.

Nakreslite obe polovice raz a otázky o oprávneniach sa budú ľahšie umiestňovať. Horná polovica je svet aplikácií a dolná patrí démonovi.

Rozhodnite, kto potrebuje zariadenie a kto nie

Vytvorenie rozhrania TUN alebo pripojenie k nemu vyžaduje prístup k zariadeniu a navyše schopnosť ho konfigurovať, preto podporovaná VPN služba začína s oprávnením správy siete alebo používa privilegovaného pomocníka. Táto požiadavka patrí démonovi. Nehovorí nič o prehliadači, databázovom klientovi ani nástroji na prenos súborov. Služba, ktorá schopnosť potrebuje, ju potrebuje pre svoj vlastný krok nastavenia, nie pre svojich klientov.

Keď sú trasa a politika na mieste, bežný proces používa výslednú cestu cez svoje obvyklé volania socketu. Nepotrebuje uzol zariadenia a nepotrebuje root.

Zmena oprávnení zariadenia nie je spôsob, ako dať aplikácii prístup k cieľu. Iba presúva hranicu zariadenia niekam inam.

Skontrolujte, v ktorom mennom priestore aplikácia skutočne beží

Kontajner alebo druhý sieťový menný priestor dáva svojim procesom samostatnú sadu rozhraní a tabuľku trás. Tunel na hostiteľovi sa tam automaticky neobjaví a žiadna zmena oprávnení zariadenia to nezmení. Aplikácia bude jednoducho smerovať cez to, čo tento menný priestor poskytuje. Preto obrázok kontajnera nemôže omylom zdediť tunel hostiteľa.

Skontrolujte pomocou ip netns list a ip -n NAME route, alebo prezretím odkazu menného priestoru procesu. Odpoveď je zvyčajne viditeľná v jedinom príkaze.

Dvom používateľom na tom istom hostiteľovi možno politikou prideliť aj rôzne cesty. Je to sieťové rozhodnutie, nie dôkaz o vlastníctve zariadenia.

Oddeľte schopnosti od sieťovej politiky

Niektoré nástroje potrebujú viac ako socket. Zachytávanie paketov potrebuje surový socket a zmena trás potrebuje administratívne oprávnenie. Sú to oddelené operácie s oddelenými povoleniami a udelenie jednej sa nemá čítať ako všeobecná požiadavka na používanie VPN.

Program, ktorý implementuje vlastný tunel, je tretí prípad. Skutočne otvára TUN, pretože preberá rolu démona, a preto potrebuje jeho oprávnenia.

Pomenujte operáciu skôr, než pomenujete oprávnenie. Zvyčajne je ľahšie ich oddeliť, než sa zdá.

Overte rozdelenie dvoma účtami

Pripojte tunel ako službu, potom spustite aplikáciu ako bežného používateľa a potvrďte, že dosiahne na súkromný zdroj. Skontrolujte ip route get pre cieľ z shellu tohto používateľa, aby ste videli, ktoré rozhranie bolo zvolené. Ak je trasa správna a spojenie stále zlyháva, problémom je politika, nie oprávnenie.

Výsledný dizajn je minimálne oprávnenie s výslovnou hranicou: jeden komponent vlastní nastavenie a zdroje tunela, pracovné zaťaženia si zachovávajú bežné účty a sieťová politika rozhoduje, čo môže prejsť. Spúšťanie všetkého ako root zrúti tieto roly bez toho, aby čokoľvek vysvetlilo.