Ein vanleg Linux-app brukar VPN utan å røre TUN

Ein nettlesar som brukar ein etablert Linux-VPN, opnar ikkje /dev/net/tun. Han opnar ein socket, og kjernen avgjer kva grensesnitt pakkane frå den socketen går ut gjennom. Prosessen som laga tunnelen, gjer ein annan jobb enn prosessen han fraktar trafikken for. Å halde desse to rollene skilde svarar på dei fleste løyvespørsmåla før dei blir stilte.

Følg éin pakke frå socket til tunnel

Ein vanleg app kallar connect eller send, og kjernen slår opp ei rute til målet. Viss den valde ruta peikar på tunnegrensesnittet, blir pakken sett i kø til eininga VPN-dæmonen les frå. Dæmonen krypterer han og sender han ut gjennom det fysiske grensesnittet. Kvar pil i den skildringa er ein stad der eit løyvespørsmål kan svarast på.

Ingenting på den vegen krev at appen kjenner eininga. Dæmonen held filskildringa og utfører grensesnittoperasjonane, medan appen berre ser eit vanleg nettverks-API.

Teikn dei to halvdelane éin gong, og løyvespørsmåla blir lettare å plassere. Den øvre halvdelen er appane si verd, og den nedre høyrer til dæmonen.

Avgjer kven som treng eininga og kven som ikkje gjer det

Å lage eller kople til eit TUN-grensesnitt krev einingstilgang og i tillegg evna til å konfigurere det, og difor startar ein støtta VPN-teneste med nettverksadministrasjonsmyndigheit eller brukar ein privilegert hjelpar. Det kravet høyrer til dæmonen. Det seier ingenting om nettlesaren, databaseklienten eller filoverføringsverktøyet. Ei teneste som treng evna, treng ho for sitt eige oppsettsteg, ikkje for klientane sine.

Når ruta og policyen er på plass, brukar ein vanleg prosess vegen som oppstår, gjennom sine vanlege socket-kall. Han treng ikkje einingknutepunktet, og han treng ikkje root.

Å endre einingløyva er ikkje ein måte å gje ein app måltilgang. Det flyttar berre eininggrensa ein annan stad.

Sjekk namnerommet appen faktisk køyrer i

Ein container, eller eit andre nettverksnamnerom, gjev prosessane sine eit eige grensesnittsett og ei eiga rutetabell. Ein tunnel på verten dukkar ikkje opp der automatisk, og inga mengd endringar i einingløyve endrar det. Appen rutar rett og slett gjennom det namnerommet tilbyr. Difor kan eit containerbilete ikkje arve ein vertstunnel ved eit uhell.

Sjekk med ip netns list og ip -n NAME route, eller ved å sjå på namneromslenkja for prosessen. Svaret er vanlegvis synleg i éin kommando.

To brukarar på same vert kan òg få ulike vegar gjennom policy. Det er ei nettverksavgjerd, ikkje prov på einingseige.

Skil evner frå nettverkspolicy

Nokre verktøy treng meir enn ein socket. Pakkefangst treng ein rå socket, og ruteendringar treng administrasjonsmyndigheit. Det er skilde operasjonar med skilde tildelingar, og å gje éin bør ikkje lesast som eit generelt krav for å bruke VPN.

Eit program som implementerer sin eigen tunnel, er eit tredje tilfelle. Det opnar verkeleg TUN fordi det tek på seg rolla til dæmonen, og difor treng det privilegia til dæmonen.

Namngje operasjonen før du namngjev privilegiet. Dei to er vanlegvis lettare å skilje enn dei ser ut.

Stadfest skiljet med to kontoar

Kople tunnelen som tenesta, køyr deretter appen som ein vanleg brukar og stadfest at han når den private ressursen. Sjekk ip route get for målet frå skalet til den brukaren for å sjå kva grensesnitt som vart valt. Viss ruta er rett og tilkoplinga framleis feilar, er problemet policy og ikkje privilegium.

Designet som følgjer, er minst privilegium med ei eksplisitt grense: éin komponent eig oppsettet og tunnelressursane, arbeidslastar held sine vanlege kontoar, og nettverkspolicyen avgjer kva som slepp gjennom. Å køyre alt som root får desse rollene til å kollapse utan å forklare noko.