En ordinær Linux-app bruker VPN uten å berøre TUN

En nettleser som bruker en allerede etablert Linux-VPN, åpner ikke /dev/net/tun. Den åpner en socket, og kjernen bestemmer hvilket grensesnitt pakkene fra den socketen forlater gjennom. Prosessen som opprettet tunnelen, utfører en annen oppgave enn prosessen den transporterer trafikken til. Å holde disse to rollene atskilt besvarer de fleste tillatelsesspørsmål før de stilles.

Følg én pakke fra socket til tunnel

En ordinær applikasjon kaller connect eller send, og kjernen slår opp en rute til destinasjonen. Hvis den valgte ruten peker mot tunnelgrensesnittet, legges 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å denne veien krever at applikasjonen kjenner enheten. Dæmonen holder filbeskrivelsen og utfører grensesnittoperasjonene, mens applikasjonen bare ser et vanlig nettverks-API.

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

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

Å opprette 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. Dette 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 oppsettstrinn, ikke for klientene sine.

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

Å endre enhetstillatelser er ikke en måte å gi en applikasjon destinasjonstilgang. Det flytter bare enhetsgrensen et annet sted.

Kontroller navnerommet applikasjonen 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. Applikasjonen ruter ganske enkelt gjennom det navnerommet tilbyr. Derfor kan et containerbilde ikke arve en vertstunnel ved et uhell.

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

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

Skill evner fra nettverkspolicy

Noen verktøy trenger mer enn en socket. Pakkefangst trenger en rå socket, og ruteendringer trenger administrasjonsmyndighet. Det er atskilte operasjoner med atskilte 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 faktisk TUN fordi det påtar 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 applikasjonen som en vanlig bruker og bekreft at den når den private ressursen. Kontroller ip route get for destinasjonen 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 får disse rollene til å kollapse uten å forklare noe.