En vanlig Linux-app använder VPN utan att röra TUN

En webbläsare som använder en etablerad Linux-VPN öppnar inte /dev/net/tun. Den öppnar en socket, och kärnan avgör vilket gränssnitt paketen från den socketen lämnar via. Processen som skapade tunneln gör ett annat arbete än processen vars trafik den transporterar. Att hålla dessa två roller åtskilda besvarar de flesta behörighetsfrågor innan de ställs.

Följ ett paket från socket till tunnel

En vanlig applikation anropar connect eller send, och kärnan slår upp en rutt till målet. Om den valda rutten pekar på tunnelgränssnittet köas paketet till enheten som VPN-daemonen läser. Daemonen krypterar det och skickar ut det via det fysiska gränssnittet. Varje pil i den beskrivningen är en plats där en behörighetsfråga kan besvaras.

Ingenting på den vägen kräver att applikationen känner till enheten. Daemonen håller filbeskrivningen och utför gränssnittsoperationerna, medan applikationen bara ser ett vanligt nätverks-API.

Rita de två halvorna en gång, och behörighetsfrågorna blir lättare att placera. Den övre halvan är applikationernas värld, och den nedre tillhör daemonen.

Bestäm vem som behöver enheten och vem som inte gör det

Att skapa eller ansluta till ett TUN-gränssnitt kräver enhetsåtkomst och dessutom förmågan att konfigurera det, därför börjar en stödd VPN-tjänst med nätverksadministrationsbehörighet eller använder en privilegierad hjälpare. Det kravet tillhör daemonen. Det säger ingenting om webbläsaren, databasklienten eller filöverföringsverktyget. En tjänst som behöver förmågan behöver den för sitt eget installationssteg, inte för sina klienter.

När rutten och policyn är på plats använder en vanlig process den resulterande vägen genom sina vanliga socket-anrop. Den behöver inte enhetsnoden och den behöver inte root.

Att ändra enhetens behörigheter är inte ett sätt att ge en applikation åtkomst till målet. Det flyttar bara enhetsgränsen någon annanstans.

Kontrollera namnutrymmet som applikationen faktiskt kör i

En container, eller ett andra nätverksnamnutrymme, ger sina processer en separat uppsättning gränssnitt och en routingtabell. En tunnel på värden dyker inte upp där automatiskt, och ingen mängd ändringar av enhetsbehörigheter ändrar det. Applikationen dirigerar helt enkelt genom det namnutrymmet erbjuder. Därför kan en containerbild inte ärva en värdtunnel av misstag.

Kontrollera med ip netns list och ip -n NAME route, eller genom att inspektera processens namnutrymmeslänk. Svaret syns oftast i ett enda kommando.

Två användare på samma värd kan också få olika vägar via policy. Det är ett nätverksbeslut, inte bevis om enhetsägande.

Separera förmågor från nätverkspolicy

Vissa verktyg behöver mer än en socket. Paketinfångning behöver en rå socket, och ruttändringar behöver administrationsbehörighet. Det är separata operationer med separata tilldelningar, och att ge en bör inte läsas som ett generellt krav för att använda VPN.

Ett program som implementerar sin egen tunnel är ett tredje fall. Det öppnar verkligen TUN eftersom det tar på sig daemonens roll, därför behöver det daemonens privilegier.

Namnge operationen innan du namnger privilegiet. De två är oftast lättare att separera än de ser ut.

Verifiera uppdelningen med två konton

Anslut tunneln som tjänsten, kör sedan applikationen som en vanlig användare och bekräfta att den når den privata resursen. Kontrollera ip route get för målet från den användarens skal för att se vilket gränssnitt som valdes. Om rutten är rätt och anslutningen fortfarande misslyckas är problemet policy och inte privilegium.

Designen som följer är minsta privilegium med en explicit gräns: en komponent äger installationen och tunnelresurserna, arbetsbelastningar behåller sina vanliga konton, och nätverkspolicyn avgör vad som får passera. Att köra allt som root kollapsar dessa roller utan att förklara något.