Ihr Server sieht den VPN-Ausgang, nicht den Besucher

Ein Besucher verbindet sich über ein kommerzielles VPN, und Ihre Anwendung protokolliert die Ausgangsadresse. Das ist keine verborgene Identität: Es ist die einzige Quelladresse, die die TCP-Verbindung hat. Alles andere, was Menschen als Erkennung bezeichnen, ist ein Rückschluss, der auf dieser einen Tatsache aufbaut.

Was eine Anfrage tatsächlich trägt

Die Anwendung sieht Quelladresse und Port der Verbindung, den abgeschlossenen Handshake und die Bytes, die der Client zu senden gewählt hat. Bei einem vollständigen Tunnel ist diese Quelle der Ausgang, den alle Nutzer gemeinsam verwenden. Bei einem geteilten Tunnel können Anfragen je nach Ziel aus dem Tunnel oder aus der lokalen Verbindung eintreffen. Wenn Client und Server sich im selben VPN befinden, ist die Quelle die innere Tunneladresse des Clients, die einen Endpunkt und keinen Standort kennzeichnet.

Kein Feld einer gewöhnlichen Anfrage trägt die Adresse, die der Client vor dem Tunnel hatte. Ein Weiterleitungs-Header ist die Behauptung des Clients oder eines Proxys und kann weggelassen oder gefälscht werden.

Erkennung ist Klassifikation, und Klassifikation ist eine Vermutung

Die praktischen Methoden sind Listen bekannter VPN- und Hosting-Bereiche, Latenz, die nicht zu einer behaupteten Region passt, Traceroute-Formen und Kontoverhalten. Jede davon liefert eine Wahrscheinlichkeit. Ein Firmen-VPN kann auf Adressen liegen, die wie Privatanschlüsse aussehen, ein Wohn-Proxy kann wie eine Hausleitung aussehen, und Carrier-NAT kann wie ein Hosting-Bereich aussehen.

Einen gemeinsam genutzten Ausgang zu blockieren blockiert jeden unbeteiligten Nutzer dahinter, was aus einer Erkennungsentscheidung einen Kollateralschaden macht. Ein Vertrauenswert ist keine Identität und sollte niemals die einzige Grundlage für eine Sperr- oder Erstattungsentscheidung sein.

Wenn Ihnen das VPN gehört, haben Sie ein verlässliches Signal, das nichts mit Erkennung zu tun hat: Weisen Sie einen dedizierten Pool zu und gleichen Sie die beobachtete Quelle damit ab. Das funktioniert, weil Sie beide Enden kontrollieren und den Pool dokumentieren können. Es lässt sich aber nicht auf Besucher verallgemeinern, die Sie nicht verwalten, und es ist nicht mehr verlässlich, sobald der Pool mit anderen Diensten geteilt wird.

Lokale Beweise gegenüber serverseitigem Nachweis

Auf dem Rechner selbst ist ein Tunnel sichtbar: ein virtueller Adapter, eine Standardroute, die auf ein Tunnelgerät zeigt, ein geänderter Resolver. Dort laufender Code kann Schnittstellen auflisten und nach PPP, TAP oder einem Herstellertreiber suchen.

Eine Webseite kann davon nichts lesen. Der übliche Umweg lädt eine Ressource, die nur aus dem internen Netz ausgeliefert wird, und wertet den Erfolg als Beweis für eine Tunnelnutzung. Er prüft damit Erreichbarkeit: Ein geteilter Tunnel, eine veraltete zwischengespeicherte Datei oder ein abfangender Proxy liefern in beiden Zuständen dasselbe Ergebnis. Lokale Beweise bleiben lokal.

Wählen Sie Zugriffskontrollen, die die Unklarheit überstehen

Bauen Sie Zugriffskontrolle auf verifizierte Identität, Geräteintegrität und Autorisierung pro Ressource. Diese Prädikate beschreiben, wer fragt und was er erreichen darf, und sie bleiben aussagekräftig, ob ein Tunnel beteiligt ist oder nicht. Ob eine Anfrage über ein VPN kam, ist ein schwaches Signal, das sowohl falsche Zusagen als auch Kollateralsperren erzeugt. Halten Sie Beweis und Entscheidung in getrennten Feldern, damit eine strittige Sperre etwas zum Prüfen hat.

IP-Geolokation ist ein Eingang unter mehreren, und Standortdienste des Browsers können Wi-Fi oder GPS nutzen, die dem Tunnel nie folgen. Eine Karte, die noch die Stadt des Besuchers zeigt, ist ein Beleg über Standortdienste, kein Beweis, dass der Tunnel versagt hat.

Halten Sie fest, welches Signal jede Entscheidung bestimmt hat. Wenn ein Kunde eine Sperre bestreitet, ist dieser Eintrag der Unterschied zwischen einer Prüfung und einer Auseinandersetzung.