Egy meglévő Linux VPN-t használó böngésző nem nyitja meg a /dev/net/tun fájlt. Socketet nyit, és a kernel dönti el, melyik interfészen hagyják el a csomagok azt a socketet. Az alagutat létrehozó folyamat más munkát végez, mint a folyamat, amelynek a forgalmát továbbítja. E két szerep különválasztása a legtöbb jogosultsági kérdésre válaszol, mielőtt feltennék őket.

Kövess egy csomagot a socketből az alagútig

Egy hétköznapi alkalmazás connectet vagy sendet hív, és a kernel útvonalat keres a célhoz. Ha a választott útvonal az alagút interfészére mutat, a csomag annak az eszköznek a sorába kerül, amelyet a VPN démon olvas. A démon titkosítja, és a fizikai interfészen keresztül kiküldi. A leírás minden nyila olyan hely, ahol jogosultsági kérdésre lehet válaszolni.

Ezen az úton semmi nem követeli meg, hogy az alkalmazás ismerje az eszközt. A démon tartja a fájlleírót és végzi az interfészműveleteket, miközben az alkalmazás csak egy szokásos hálózati API-t lát.

Rajzold fel egyszer a két felet, és a jogosultsági kérdéseket könnyebb lesz elhelyezni. A felső fél az alkalmazások világa, az alsó pedig a démoné.

Döntsd el, kinek kell az eszköz és kinek nem

A TUN-interfész létrehozása vagy csatlakoztatása eszközhozzáférést és emellett a konfigurálás képességét igényli, ezért egy támogatott VPN-szolgáltatás hálózati adminisztrációs jogosultsággal indul, vagy kiemelt segítőt használ. Ez a követelmény a démoné. Semmit nem mond a böngészőről, az adatbázis-kliensről vagy a fájlátviteli eszközről. Egy szolgáltatásnak, amelynek kell a képesség, a saját beállítási lépéséhez kell, nem az ügyfeleihez.

Amint az útvonal és a szabályzat a helyén van, egy hétköznapi folyamat a szokásos socket-hívásain keresztül használja a kapott utat. Nincs szüksége az eszközcsomópontra, és nincs szüksége rootra.

Az eszköz jogosultságainak módosítása nem módja annak, hogy egy alkalmazásnak célhozzáférést adjunk. Csak máshová mozgatja az eszköz határát.

Ellenőrizd, melyik névtérben fut valójában az alkalmazás

Egy konténer vagy egy második hálózati névtér külön interfészkészletet és útvonaltáblát ad a folyamatainak. A gazdagépen lévő alagút nem jelenik meg ott automatikusan, és ezen az eszköz jogosultságainak semmilyen változtatása nem segít. Az alkalmazás egyszerűen azon keresztül irányít, amit az a névtér nyújt. Ezért egy konténerkép nem örökölheti véletlenül a gazdagép alagútját.

Ellenőrizd az ip netns list és az ip -n NAME route paranccsal, vagy a folyamat névtér-hivatkozásának megtekintésével. A válasz általában egyetlen parancsban látható.

Két felhasználónak ugyanazon a gazdagépen szabályzattal különböző utak is adhatók. Ez hálózati döntés, nem az eszköz tulajdonának bizonyítéka.

Válaszd külön a képességeket a hálózati szabályzattól

Egyes eszközöknek többre van szükségük egy socketnél. A csomagelfogás nyers socketet igényel, az útvonalak módosítása adminisztrációs jogosultságot. Ezek külön műveletek külön engedélyekkel, és az egyik megadása nem értelmezhető a VPN használatának általános követelményeként.

A saját alagutat megvalósító program a harmadik eset. Valóban megnyitja a TUN-t, mert átveszi a démon szerepét, ezért kellenek hozzá a démon jogosultságai.

Nevezd meg a műveletet, mielőtt a jogosultságot megneveznéd. A kettőt általában könnyebb szétválasztani, mint látszik.

Ellenőrizd a szétválasztást két fiókkal

Kapcsold össze az alagutat szolgáltatásként, majd futtasd az alkalmazást hétköznapi felhasználóként, és igazold, hogy eléri a privát erőforrást. Ellenőrizd a ip route get parancsot a célra annak a felhasználónak a shelljéből, hogy lásd, melyik interfészt választotta. Ha az útvonal helyes, és a kapcsolat mégis meghiúsul, a probléma a szabályzat, nem a jogosultság.

A kapott kialakítás a legkisebb jogosultság világos határral: egy komponens birtokolja a beállítást és az alagút erőforrásait, a munkaterhelések megtartják szokásos fiókjaikat, és a hálózati szabályzat dönti el, mi haladhat át. Mindent rootként futtatni összeomlasztja ezeket a szerepeket anélkül, hogy bármit megmagyarázna.

Kapcsolódó cikkek