En VPN-inloggning på en delad dator: vem får annars rutten?

Att dela en arbetsstation väcker en fråga som en laptop för en användare aldrig behöver besvara: när en person autentiserar tunneln, vem kan annars använda den? Inloggningen identifierar ett subjekt, och rutten den installerar beskriver en omfattning, och de två sakerna är inte samma objekt. Mellan dem ligger operativsystemet, klientens konfiguration och det den privata tjänsten kräver av sig själv. Att jämföra tvingandepunkterna är det enda sättet att svara utan att gissa.

En inloggning, flera omfattningar

Autentisering svarar på vem som släpptes in. Rutten svarar på vilka paket som får lämna genom tunneln. Auktorisering svarar på vilken tjänst som accepterar den resulterande anslutningen, och ingen av de tre förutsätter nästa.

En tunnel för hela värden är standardvalet och gör gapet tydligt. Rutten ligger i kerneltabellen, så varje process som använder den tabellen kan nå det privata nätet, även en som startats av en användare som aldrig sett VPN-dialogen. Det är inte ett fel i tunneln; det är vad en systemomfattande rutt betyder. Den privata tjänsten kan fortfarande avvisa anslutningen, och därför behöver nåbarhet och behörighet varsitt svar.

Att skriva ner de fyra frågorna före testet hindrar granskningen från att kollapsa till en av dem.

Var gränsen faktiskt ligger

Fyra arrangemang täcker de flesta maskiner: en tunnel för hela värden, en anslutning per användare, en tillåtelselista per app och ett separat nätverksnamnrymd eller en virtuell maskin.

Var och en placerar tvingandepunkten någon annanstans, och skillnaderna betyder mer än etiketterna. En anslutning per användare tvingas fram av profilens behörigheter, inte av skrivbordets inloggningsskärm. En tillåtelselista per app tvingas fram inne i klienten, som avgör vad den bär. En namnrymd eller VM tvingar fram vid gränssnittsgränsen, så en process därinne kan inte se värdens rutt alls. Antalet inloggningsskärmar på maskinen säger inget om någon av dem.

Att läsa tabellen rad för rad visar att den verkliga frågan inte är om isolering finns, utan var den är implementerad.

Jämför fyra tvingandepunkter

På Linux är rutttabellen det första att undersöka, eftersom en tunnel för hela värden visas där och en namnrymd inte. Att köra uppslaget som den andra användaren är steget folk hoppar över; svaret skiljer sig från det de fick som sig själva, och det förklarar rapporten.

De två nästa kontrollerna tittar på policy snarare än routning. En brandväggsregel som matchar ett UID gäller för lokalt genererad trafik, så den kan skilja två användare på en värd även när båda delar rutten. En anslutningsprofil med en explicit behörighetslista tvingas fram av nätverkshanteraren vid aktivering. Ingen av kontrollerna kräver att tunneln ändras, och därför är de värda att göra innan något görs om.

ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuid

Om det andra uppslaget visar tunnelrutten är gränsen inte där designen antog.

Regler för samtidiga sessioner är en separat kontroll

Gateways begränsar ofta hur många sessioner ett konto får ha, och den gränsen har inget med lokala användare att göra. Den begränsar kontot, så en andra person som loggar in med samma uppgifter kan avsluta den förstas tunnel.

Läs felet innan du antar ett lokalt isoleringsproblem. En sessionsgräns ger en frånkoppling vid gatewayen, medan ett omfattningsproblem ger en fungerande tunnel som bara inte bär den andra användarens trafik. De två symptomen leder till helt olika rättelser. Spara klientens exakta meddelande, eftersom det oftast namnger regeln. Be profilägaren om det godkända arbetsflödet i stället för att kringgå gränsen.

En virtuell maskin befriar ingen från den regeln och lägger till sin egen nätverks- och kontoinloggningsdesign.

Testa sammanhanget du bryr dig om

Testa den avsedda användaren och applikationen och testa sedan ett sammanhang som borde nekas. En granskning som bara bevisar att det ursprungliga lösenordet fungerar har testat autentisering och inget annat.

sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'

Notera tvingandepunkten bredvid varje resultat: rutttabellen, en UID-regel, en profilbehörighet eller gatewayens sessionspolicy. Den anteckningen gör nästa ändring granskningsbar. Den hindrar också samma fråga från att öppnas igen varje gång någon lägger märke till en andra inloggningsskärm. Nåbarhet är inte auktorisering, och ingen av dem är isolering.