En vanlig Linux-app bruker VPN uten å røre TUN

En nettleser som bruker en etablert Linux-VPN, åpner ikke /dev/net/tun. Den åpner en socket, og kjernen avgjør hvilket grensesnitt pakkene fra den socketen forlater gjennom. Prosessen som laget tunnelen, gjør en annen jobb enn prosessen den frakter trafikken for. Å holde disse to rollene atskilt svarer på de fleste tillatelsesspørsmål før de blir stilt.

Følg én pakke fra socket til tunnel

En vanlig app kaller connect eller send, og kjernen slår opp en rute til målet. Hvis den valgte ruten peker på tunnelgrensesnittet, settes pakken i kø til enheten VPN-dæmonen leser fra. Dæmonen krypterer den og sender den ut gjennom det fysiske grensesnittet. Hver pil i den beskrivelsen er et sted der et tillatelsesspørsmål kan besvares.

Ingenting på den veien krever at appen kjenner enheten. Dæmonen holder filbeskrivelsen og utfører grensesnittoperasjonene, mens appen bare ser et vanlig nettverks-API.

Tegn de to halvdelene én gang, og tillatelsesspørsmålene blir lettere å plassere. Den øvre halvdelen er appenes verden, og den nedre tilhører dæmonen.

Bestem hvem som trenger enheten og hvem som ikke gjør det

Å lage eller koble til et TUN-grensesnitt krever enhetstilgang og i tillegg evnen til å konfigurere det, og derfor starter en støttet VPN-tjeneste med nettverksadministrasjonsmyndighet eller bruker en privilegert hjelper. Det kravet tilhører dæmonen. Det sier ingenting om nettleseren, databaseklienten eller filoverføringsverktøyet. En tjeneste som trenger evnen, trenger den for sitt eget oppsettsteg, ikke for klientene sine.

Når ruten og policyen er på plass, bruker en vanlig prosess veien som oppstår, gjennom sine vanlige socket-kall. Den trenger ikke enhetsnoden, og den trenger ikke root.

Å endre enhetstillatelsene er ikke en måte å gi en app måltilgang. Det flytter bare enhetsgrensen et annet sted.

Sjekk navnerommet appen faktisk kjører i

En container, eller et andre nettverksnavnerom, gir prosessene sine et eget grensesnittsett og en egen rutetabell. En tunnel på verten dukker ikke opp der automatisk, og ingen mengde endringer i enhetstillatelser endrer det. Appen ruter ganske enkelt gjennom det navnerommet tilbyr. Derfor kan et containerbilde ikke arve en vertstunnel ved et uhell.

Sjekk med ip netns list og ip -n NAME route, eller ved å inspisere navneromslenken for prosessen. Svaret er vanligvis synlig i én kommando.

To brukere på samme vert kan også få ulike veier gjennom policy. Det er en nettverksbeslutning, ikke bevis om enhetseierskap.

Skill evner fra nettverkspolicy

Noen verktøy trenger mer enn en socket. Pakkefangst trenger en rå socket, og ruteendringer trenger administrasjonsmyndighet. Det er separate operasjoner med separate tildelinger, og å gi én bør ikke leses som et generelt krav for å bruke VPN.

Et program som implementerer sin egen tunnel, er et tredje tilfelle. Det åpner virkelig TUN fordi det tar på seg dæmonens rolle, og derfor trenger det dæmonens privilegier.

Navngi operasjonen før du navngir privilegiet. De to er vanligvis lettere å skille enn de ser ut.

Verifiser skillet med to kontoer

Koble tunnelen som tjenesten, kjør deretter appen som en vanlig bruker og bekreft at den når den private ressursen. Sjekk ip route get for målet fra den brukerens shell for å se hvilket grensesnitt som ble valgt. Hvis ruten er riktig og tilkoblingen fortsatt feiler, er problemet policy og ikke privilegium.

Designet som følger, er minst privilegium med en eksplisitt grense: én komponent eier oppsettet og tunnelressursene, arbeidsbelastninger beholder sine vanlige kontoer, og nettverkspolicyen avgjør hva som slipper gjennom. Å kjøre alt som root kollapser disse rollene uten å forklare noe.