Ét VPN-login på en delt pc: hvem får ellers ruten?

At dele en arbejdsstation rejser et spørgsmål, som en laptop til én bruger aldrig skal besvare: når én person godkender tunnelen, hvem kan så ellers bruge den? Loginet identificerer et subjekt, og ruten, det installerer, beskriver et omfang, og de to ting er ikke det samme objekt. Mellem dem ligger styresystemet, klientens konfiguration og det, den private tjeneste kræver af sig selv. At sammenligne håndhævelsespunkterne er den eneste måde at besvare spørgsmålet uden at gætte.

Ét login, flere omfang

Godkendelse svarer på, hvem der blev lukket ind. Ruten svarer på, hvilke pakker der må forlade systemet gennem tunnelen. Autorisation svarer på, hvilken tjeneste der accepterer den resulterende forbindelse, og ingen af de tre forudsætter den næste.

En tunnel for hele værten er standarden og gør forskellen tydelig. Ruten ligger i kernens tabel, så enhver proces, der bruger den tabel, kan nå det private netværk, også en proces startet af en bruger, der aldrig har set VPN-dialogen. Det er ikke en fejl i tunnelen; det er, hvad en systemdækkende rute betyder. Den private tjeneste kan stadig afvise forbindelsen, og derfor har rækkevidde og tilladelse brug for hvert sit svar.

At skrive de fire spørgsmål ned før test forhindrer, at gennemgangen kollapser til et af dem.

Hvor grænsen faktisk ligger

Fire ordninger dækker de fleste maskiner: en tunnel for hele værten, en forbindelse per bruger, en tilladelsesliste per app og et separat netværksnavnerum eller en virtuel maskine.

Hver især sætter håndhævelsespunktet et andet sted, og forskellene betyder mere end navnene. En forbindelse per bruger håndhæves af profilens tilladelser og ikke af skrivebordets loginskærm. En tilladelsesliste per app håndhæves inde i klienten, som afgør, hvad den vil bære. Et navnerum eller en VM håndhæver ved grænsefladen, så en proces indeni slet ikke kan se værtens rute. Antallet af loginskærme på maskinen siger intet om nogen af dem.

At læse tabellen række for række viser, at det egentlige spørgsmål ikke er, om der findes isolering, men hvor den er implementeret.

Sammenlign fire håndhævelsespunkter

På Linux er rutetabellen det første, man skal undersøge, fordi en tunnel for hele værten vises der, og et navnerum gør ikke. At køre opslaget som den anden bruger er det skridt, folk springer over; svaret er et andet end det, de fik som sig selv, og det forklarer rapporten.

De næste to kontroller ser på politik frem for routing. En firewallregel, der matcher en UID, gælder for lokalt genereret trafik, så den kan skille to brugere på én vært, selv når begge deler ruten. En forbindelsesprofil med en eksplicit tilladelsesliste håndhæves af netværksadministratoren ved aktivering. Ingen af kontrollerne kræver, at tunnelen ændres, og derfor er de værd at lave, før man redesigner noget.

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

Hvis det andet opslag viser tunnelruten, er grænsen ikke der, hvor designet antog.

Regler for samtidige sessioner er en separat kontrol

Gateways begrænser ofte, hvor mange sessioner én konto må have, og den grænse har intet med lokale brugere at gøre. Den begrænser kontoen, så en anden person, der logger ind med samme legitimationsoplysninger, kan afslutte den førstes tunnel.

Læs fejlen, før du antager et lokalt isoleringsproblem. En sessionsgrænse giver en afbrydelse ved gatewayen, mens et omfangsproblem giver en fungerende tunnel, som blot ikke bærer den anden brugers trafik. De to symptomer fører til helt forskellige rettelser. Gem klientens præcise besked, da den normalt navngiver reglen. Bed profilejeren om den godkendte arbejdsgang i stedet for at omgå grænsen.

En virtuel maskine fritager ingen for den regel og tilføjer sit eget netværks- og legitimationsdesign.

Test den kontekst, du bekymrer dig om

Test den tilsigtede bruger og applikation, og test derefter en kontekst, der bør afvises. En gennemgang, der kun beviser, at den oprindelige adgangskode virker, har testet godkendelse og intet andet.

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

Noter håndhævelsespunktet ved hvert resultat: rutetabellen, en UID-regel, en profiltilladelse eller gatewayens sessionspolitik. Den registrering gør den næste ændring gennemgåelig. Den forhindrer også, at det samme spørgsmål åbnes igen, hver gang nogen bemærker en anden loginskærm. Rækkevidde er ikke autorisation, og ingen af de to er isolering.