Geteiltes VPN-Konto: Ein Gerätelimit ist keine Client-Isolation

Acht gleichzeitige Verbindungen sind eine Zahl von einer Lizenzseite und sagen nichts darüber, was diese acht Geräte einander antun können. Ein gemeinsames Login kann mit Schlüsseln pro Sitzung koexistieren, und es kann auch mit einem Gateway koexistieren, das den Verkehr eines Clients fröhlich an einen anderen weiterleitet. Der Fehler ist, das Konto als Sicherheitsgrenze zu behandeln. Stellen Sie stattdessen vier getrennte Fragen: was gekauft wurde, was den Tunnel schützt, was zwischen Peers übertreten darf und was die lokale Strecke kippen kann.

Was ein Verbindungslimit tatsächlich verspricht

Ein Gerätelimit zählt, wie viele Sitzungen der Anbieter für ein Abonnement annimmt. Es ist eine kaufmännische und betriebliche Kontrolle, keine Aussage über Identität oder Isolation. Manche Anbieter stellen pro Gerät ein eigenes Zertifikat unter einem Konto aus; andere verwenden einen einzigen Nachweis für jede Verbindung wieder. Der Unterschied zeigt sich beim Widerruf, denn getrennte Nachweise lassen Sie ein Gerät abschneiden, ein gemeinsamer lässt Ihnen diese Möglichkeit nicht.

Lesen Sie, wie der Anbieter Nachweise ausstellt, bevor Sie irgendetwas über Schlüsseltrennung annehmen. Der Kontoname selbst verrät davon nichts.

Prüfen Sie, ob das Gateway zwischen Clients weiterleitet

Erreichbarkeit zwischen Peers ist eine serverseitige Entscheidung. Bei OpenVPN fehlt der betreffende Schalter, sofern er nicht in der Konfiguration steht, doch moderne Datenebenen-Auslagerung ändert, wo die Regel durchgesetzt wird.

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Eine Konfiguration ohne diese Direktive überlässt Peer-Verkehr der Host-Firewall, die ihn weiterhin erlauben kann. Bei aktiver Auslagerung übernimmt der Kernel die Tunnelschnittstelle statt des Userspace-Prozesses, prüfen Sie also Regelzähler, statt der Datei zu vertrauen. Das Blockieren weitergeleiteten Verkehrs zwischen Tunneladressen isoliert Clients, ohne ihren Zugang zum Gateway anzutasten. Bestätigen Sie es mit einer Probe von einem Client zu einem Dienst auf einem anderen, sowohl vor als auch nach der Regel.

Schützen Sie die Sitzung vor den Peers

Tunnelschutz und Peer-Zugang sind verschiedene Eigenschaften, und eine starke Verschlüsselung bedeutet keine Isolation. Im TLS-Modus leitet jeder Client seine eigenen Sitzungsschlüssel ab, sodass ein Client den Verkehr eines anderen nicht lesen kann, selbst wenn das Gateway ihn weiterleitet. Eine alte statische Schlüsselregelung teilt einen einzigen Schlüssel unter allen, weshalb die Wiederverwendung eines Logins dort weit schlimmere Folgen hat. Prüfen Sie den konfigurierten Modus statt der Marketingseite und beurteilen Sie dann, ob Kontoteilung zu den betroffenen Daten passt.

Die Dienstauthentifizierung auf jedem Host bleibt wichtig, denn der Tunnel beweist nur, dass ein Client das Netz erreicht hat, nicht dass er einen bestimmten Daemon erreichen darf.

Lokale WLAN-Ausfälle sind keine VPN-Kompromittierung

Eine abgebrochene Verbindung beweist, dass die lokale Strecke versagt hat, nicht dass jemand den Tunnel aufgebrochen hat. Störungen, ein verlorenes DHCP-Lease und ein Roaming-Wechsel beenden eine Sitzung, ohne Nachweise oder Chiffrat zu berühren. Behandeln Sie die Trennung als Verfügbarkeitsbefund und halten Sie sie getrennt von Befunden zu Vertraulichkeit und Peer-Zugang. Wo das lokale Netz nicht vertrauenswürdig ist, schützen Sie den Verkehr Ende zu Ende, statt sich allein auf den Tunnel zu verlassen.

Schreiben Sie die vier Antworten auf: Limit, Schlüsselmodell, Peer-Richtlinie und Abhängigkeit von der lokalen Strecke. Diese Aufzeichnung macht aus einer vagen Sorge um ein geteiltes Konto konkrete Kontrollen.