En almindelig Linux-app bruger VPN’en uden at røre TUN

En browser, der bruger en allerede etableret Linux-VPN, åbner ikke /dev/net/tun. Den åbner en socket, og kernen afgør, hvilken grænseflade den sockets pakker forlader via. Den proces, der oprettede tunnelen, udfører et andet arbejde end den proces, hvis trafik den bærer. At holde de to roller adskilt besvarer de fleste tilladelsesspørgsmål, før de stilles.

Følg én pakke fra socket til tunnel

En almindelig applikation kalder connect eller send, og kernen slår en rute op til destinationen. Hvis den valgte rute peger på tunnelens grænseflade, sættes pakken i kø til den enhed, VPN-daemonen læser. Daemonen krypterer den og sender den ud gennem den fysiske grænseflade. Hver pil i den beskrivelse er et sted, hvor et tilladelsesspørgsmål kan besvares.

Intet på den vej kræver, at applikationen kender til enheden. Daemonen holder filbeskriveren og udfører grænsefladeoperationerne, mens applikationen kun ser et almindeligt netværks-API.

Tegn de to halvdele én gang, og tilladelsesspørgsmål bliver lettere at placere. Den øverste halvdel er applikationsverdenen, og den nederste tilhører daemonen.

Afgør, hvem der har brug for enheden, og hvem der ikke har

Oprettelse af eller tilslutning til en TUN-grænseflade kræver adgang til enheden plus rettigheden til at konfigurere den, og derfor starter en understøttet VPN-tjeneste med netværksadministrationsautoritet eller bruger en privilegeret hjælper. Det krav tilhører daemonen. Det siger intet om browseren, databaseklienten eller filoverførselsværktøjet. En tjeneste, der har brug for rettigheden, har brug for den til sit eget opsætningstrin, ikke til sine klienter.

Når ruten og politikken er på plads, bruger en almindelig proces den resulterende vej gennem sine sædvanlige socket-kald. Den har ikke brug for enhedsknudepunktet og ikke brug for root.

At ændre enhedstilladelser er ikke en måde at give en applikation adgang til en destination. Det flytter kun enhedens grænse et andet sted hen.

Kontrollér, hvilket navnerum applikationen faktisk kører i

En container eller et andet netværksnavnerum giver sine processer et separat sæt grænseflader og en separat rutetabel. En tunnel på værten vises ikke der automatisk, og ingen ændring af enhedstilladelser ændrer det. Applikationen ruter ganske enkelt gennem det, navnerummet tilbyder. Derfor kan et container-image ikke ved et uheld arve en tunnel fra værten.

Kontrollér med ip netns list og ip -n NAME route eller ved at inspicere processens navnerumslink. Svaret er normalt synligt i én kommando.

To brugere på samme vært kan også få forskellige veje via politik. Det er en netværksbeslutning snarere end bevis for enhedsejerskab.

Adskil rettigheder fra netværkspolitik

Nogle værktøjer har brug for mere end en socket. Pakkeoptagelse kræver en rå socket, og ændring af ruter kræver administrationsautoritet. Det er separate operationer med separate bevillinger, og bevilling af den ene bør ikke læses som et generelt krav for at bruge VPN’en.

Et program, der implementerer sin egen tunnel, er det tredje tilfælde. Det åbner faktisk TUN, fordi det overtager daemonens rolle, og derfor har det brug for daemonens privilegier.

Navngiv operationen, før du navngiver privilegiet. De to er normalt lettere at adskille, end de ser ud.

Bekræft opdelingen med to konti

Forbind tunnelen som tjenesten, kør derefter applikationen som en almindelig bruger, og bekræft, at den når den private ressource. Kontrollér ip route get for destinationen fra den brugers shell for at se, hvilken grænseflade der blev valgt. Hvis ruten er rigtig, og forbindelsen stadig fejler, er problemet politik snarere end privilegium.

Det resulterende design er mindst privilegium med en eksplicit grænse: én komponent ejer opsætning og tunnelressourcer, arbejdsbelastninger beholder deres normale konti, og netværkspolitikken afgør, hvad der må passere. At køre alt som root kollapser de roller uden at forklare noget.