Én VPN-innlogging på en delt PC: hvem får ellers ruten?

Å dele en arbeidsstasjon reiser et spørsmål som en laptop for én bruker aldri må svare på: når én person autentiserer tunnelen, hvem kan ellers bruke den? Innloggingen identifiserer et subjekt, og ruten den installerer beskriver et omfang, og de to tingene er ikke samme objekt. Mellom dem ligger operativsystemet, klientens konfigurasjon og det den private tjenesten krever av seg selv. Å sammenligne håndhevingspunktene er den eneste måten å svare på spørsmålet uten å gjette.

Én innlogging, flere omfang

Autentisering svarer på hvem som ble sluppet inn. Ruten svarer på hvilke pakker som kan forlate gjennom tunnelen. Autorisasjon svarer på hvilken tjeneste som godtar den resulterende forbindelsen, og ingen av de tre forutsetter den neste.

En tunnel for hele verten er standardvalget og gjør gapet tydelig. Ruten ligger i kjernens tabell, så enhver prosess som bruker den tabellen kan nå det private nettet, også en som er startet av en bruker som aldri har sett VPN-dialogen. Det er ikke en feil i tunnelen; det er hva en systemomfattende rute betyr. Den private tjenesten kan fortsatt avvise forbindelsen, og derfor trenger rekkevidde og tillatelse hvert sitt svar.

Å skrive ned de fire spørsmålene før testing hindrer gjennomgangen i å kollapse til ett av dem.

Hvor grensen faktisk ligger

Fire ordninger dekker de fleste maskiner: en tunnel for hele verten, en forbindelse per bruker, en tillatelsesliste per app og et separat nettverksnavnerom eller en virtuell maskin.

Hver av dem plasserer håndhevingspunktet et annet sted, og forskjellene betyr mer enn etikettene. En forbindelse per bruker håndheves av profilens tillatelser, ikke av skrivebordets innloggingsskjerm. En tillatelsesliste per app håndheves inne i klienten, som bestemmer hva den vil bære. Et navnerom eller en VM håndhever ved grensesnittgrensen, så en prosess inni kan ikke se vertens rute i det hele tatt. Antallet innloggingsskjermer på maskinen sier ingenting om noen av dem.

Å lese tabellen rad for rad viser at det egentlige spørsmålet ikke er om isolasjon finnes, men hvor den er implementert.

Sammenlign fire håndhevingspunkter

På Linux er rutetabellen det første som må undersøkes, fordi en tunnel for hele verten vises der og et navnerom ikke. Å kjøre oppslaget som den andre brukeren er trinnet folk hopper over; svaret er et annet enn det de fikk som seg selv, og det forklarer rapporten.

De to neste kontrollene ser på policy fremfor ruting. En brannmurregel som samsvarer med en UID gjelder for lokalt generert trafikk, så den kan skille to brukere på én vert selv når begge deler ruten. En tilkoblingsprofil med en eksplisitt tillatelsesliste håndheves av nettverksbehandleren ved aktivering. Ingen av kontrollene krever at tunnelen endres, og derfor er de verdt å gjøre før noe redesignes.

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 andre oppslaget viser tunnelruten, er grensen ikke der designet antok.

Regler for samtidige økter er en egen kontroll

Gater begrenser ofte hvor mange økter én konto kan holde, og den grensen har ingenting med lokale brukere å gjøre. Den begrenser kontoen, så en andre person som logger på med de samme opplysningene kan avslutte den førstes tunnel.

Les feilen før du antar et lokalt isolasjonsproblem. En øktgrense gir en frakobling ved gaten, mens et omfangsproblem gir en fungerende tunnel som bare ikke bærer den andre brukerens trafikk. De to symptomene fører til helt forskjellige rettelser. Ta vare på klientens nøyaktige melding, for den navngir vanligvis regelen. Be profileieren om den godkjente arbeidsflyten i stedet for å omgå grensen.

En virtuell maskin fritar ingen fra den regelen og legger til sitt eget nettverks- og legitimasjonsdesign.

Test konteksten du bryr deg om

Test den tiltenkte brukeren og applikasjonen, og test deretter en kontekst som bør avvises. En gjennomgang som bare beviser at det opprinnelige passordet virker, har testet autentisering og ingenting annet.

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

Noter håndhevingspunktet ved siden av hvert resultat: rutetabellen, en UID-regel, en profiltillatelse eller gatens øktpolicy. Den registreringen gjør den neste endringen gjennomgåelig. Den hindrer også at det samme spørsmålet åpnes på nytt hver gang noen legger merke til en andre innloggingsskjerm. Rekkevidde er ikke autorisasjon, og ingen av de to er isolasjon.