Ein VPN-Login auf einem gemeinsam genutzten PC: Wer bekommt sonst die Route?

Einen Arbeitsplatz zu teilen wirft eine Frage auf, die ein Laptop für einen einzigen Benutzer nie beantworten muss: Sobald eine Person den Tunnel authentifiziert, wer sonst kann ihn nutzen? Das Login identifiziert ein Subjekt, und die Route, die es installiert, beschreibt einen Geltungsbereich, und diese beiden Dinge sind nicht dasselbe Objekt. Dazwischen liegen das Betriebssystem, die Konfiguration des Clients und das, was der private Dienst von sich aus verlangt. Die Durchsetzungspunkte zu vergleichen ist der einzige Weg, die Frage ohne Raten zu beantworten.

Ein Login, mehrere Geltungsbereiche

Authentifizierung beantwortet, wer zugelassen wurde. Die Route beantwortet, welche Pakete durch den Tunnel hinaus dürfen. Autorisierung beantwortet, welcher Dienst die resultierende Verbindung annimmt, und keines der drei bedingt das nächste.

Ein hostweiter Tunnel ist der übliche Standard und macht die Lücke offensichtlich. Die Route liegt in der Tabelle des Kernels, also kann jeder Prozess, der diese Tabelle nutzt, das private Netz erreichen, auch einer, den ein Benutzer gestartet hat, der den VPN-Dialog nie gesehen hat. Das ist kein Defekt des Tunnels; das bedeutet eine systemweite Route. Der private Dienst kann die Verbindung dennoch ablehnen, und deshalb brauchen Erreichbarkeit und Berechtigung getrennte Antworten.

Die vier Fragen vor dem Testen aufzuschreiben verhindert, dass die Prüfung auf eine davon zusammenfällt.

Wo die Grenze tatsächlich verläuft

Vier Anordnungen decken die meisten Rechner ab: ein hostweiter Tunnel, eine benutzerbezogene Verbindung, eine Positivliste pro Anwendung und ein separater Netzwerk-Namespace oder eine virtuelle Maschine.

Jede setzt den Durchsetzungspunkt woanders hin, und die Unterschiede zählen mehr als die Bezeichnungen. Eine benutzerbezogene Verbindung wird durch die Berechtigungen des Profils durchgesetzt, nicht durch den Anmeldebildschirm des Desktops. Eine Positivliste pro App wird im Client durchgesetzt, der entscheidet, was er trägt. Ein Namespace oder eine VM setzt an der Schnittstellengrenze durch, sodass ein Prozess darin die Route des Hosts gar nicht sieht. Die Anzahl der Anmeldebildschirme auf dem Rechner sagt über keine davon etwas aus.

Die Tabelle Zeile für Zeile zu lesen zeigt, dass die eigentliche Frage nicht ist, ob Isolation existiert, sondern wo sie umgesetzt wird.

Vergleichen Sie vier Durchsetzungspunkte

Unter Linux ist die Routentabelle das Erste, was zu prüfen ist, weil ein hostweiter Tunnel dort erscheint und ein Namespace nicht. Die Suche als zweiter Benutzer auszuführen ist der Schritt, den Leute überspringen; die Antwort unterscheidet sich von der, die sie als sie selbst erhielten, und das erklärt den Bericht.

Die nächsten beiden Prüfungen betrachten Richtlinien statt Routing. Eine Firewall-Regel, die auf eine UID passt, gilt für lokal erzeugten Verkehr, kann also zwei Benutzer auf einem Host trennen, selbst wenn beide die Route teilen. Ein Verbindungsprofil mit ausdrücklicher Berechtigungsliste wird beim Aktivieren vom Netzwerkmanager durchgesetzt. Keine der Prüfungen erfordert eine Änderung am Tunnel, deshalb lohnen sie sich, bevor irgendetwas neu entworfen wird.

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

Zeigt die zweite Suche die Tunnelroute, liegt die Grenze nicht dort, wo das Design sie annahm.

Regeln für gleichzeitige Sitzungen sind eine eigene Kontrolle

Gateways begrenzen oft, wie viele Sitzungen ein Konto halten darf, und diese Grenze hat nichts mit lokalen Benutzern zu tun. Sie beschränkt das Konto, sodass eine zweite Person, die sich mit denselben Zugangsdaten anmeldet, den Tunnel der ersten beenden kann.

Lesen Sie den Fehler, bevor Sie ein lokales Isolationsproblem annehmen. Eine Sitzungsgrenze erzeugt eine Trennung am Gateway, während ein Geltungsbereichsproblem einen funktionierenden Tunnel erzeugt, der den Verkehr des anderen Benutzers einfach nicht trägt. Diese beiden Symptome führen zu völlig unterschiedlichen Korrekturen. Bewahren Sie die genaue Client-Meldung auf, denn sie benennt meist die Regel. Bitten Sie den Profileigentümer um den freigegebenen Ablauf, statt die Grenze zu umgehen.

Eine virtuelle Maschine befreit niemanden von dieser Regel und bringt ihr eigenes Netzwerk- und Anmeldedaten-Design mit.

Testen Sie den Kontext, der Ihnen wichtig ist

Testen Sie den vorgesehenen Benutzer und die Anwendung, dann einen Kontext, der abgelehnt werden sollte. Eine Prüfung, die nur belegt, dass das ursprüngliche Passwort funktioniert, hat die Authentifizierung getestet und sonst nichts.

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

Notieren Sie den Durchsetzungspunkt neben jedem Ergebnis: die Routentabelle, eine UID-Regel, eine Profilberechtigung oder die Sitzungsrichtlinie des Gateways. Diese Aufzeichnung macht die nächste Änderung überprüfbar. Sie verhindert auch, dass dieselbe Frage jedes Mal neu aufgerollt wird, wenn jemand einen zweiten Anmeldebildschirm bemerkt. Erreichbarkeit ist keine Autorisierung, und keines von beiden ist Isolation.