Die Exit-IP eines VPN ist kein Beweis für einen Tunnel: Was Server sehen

Jemand fragt nach einem Dienst, den nur VPN-Nutzer erreichen können, und die naheliegende Umsetzung ist, eine Liste von Exit-Adressen zu erlauben. Die Liste bewirkt etwas Reales: Sie beschränkt, wer sich verbinden kann. Sie belegt nicht, dass ein Tunnel benutzt wurde, denn die Adresse gehört dem, der den Ausgang betreibt, und dieser Betreiber kann den Verkehr jedes anderen weiterleiten. Die Lücke zwischen diesen Aussagen ist das ganze Designproblem.

Der Server sieht eine Adresse pro Verbindung

Eine Verbindung kommt mit einer Quelladresse und einem Zielport an, und mehr meldet die Netzwerkschicht nicht. Wenn ein Client einen Tunnel nutzt, stammen die Pakete, die Ihren Listener erreichen, vom Ausgang oder von der Übersetzung davor. Die eigene Adresse des Clients, meist privat, erscheint nie. Eine Firewall-Regel für den LAN-Bereich des Clients bewirkt daher überhaupt nichts.

Alles nach dieser Quelladresse sind Anwendungsdaten, und die Anwendung kann ihnen nur so weit trauen, wie sie sie authentifiziert.

Prüfen Sie, wie Ihr Ausgang aussieht

Betrachten Sie den Pfad von beiden Enden, bevor Sie eine Regel schreiben. Die Sicht des Clients auf seinen Ausgang und die Sicht des Servers auf die Verbindung sind die beiden Tatsachen, auf die es ankommt.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

Der erste Befehl meldet die öffentliche Adresse, unter der der Client erscheint, und dieser Wert muss in jeder Erlaubnisliste stehen. Der zweite zeigt bestehende Verbindungen auf dem Server mit ihren Peer-Adressen, und genau damit wird die Regel tatsächlich übereinstimmen. Wenn die beiden nicht zu Ihrem mentalen Modell passen, korrigieren Sie das Modell, bevor Sie die Richtlinie bearbeiten. Eine Firewall für eine Cloud-Datenbank, eine Anwendungs-Erlaubnisliste und ein Load Balancer können jeweils eine andere Übersetzungsschicht sehen.

Nur eine der beiden Exit-Mengen lässt sich auflisten

Der eine Fall ist im Moment der Anfrage prüfbar, der andere nicht, was sehr unterschiedliche Garantien ergibt.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

Die veröffentlichte Tor-Exit-Liste lässt sich abrufen und vergleichen, abhängig vom Alter der Liste und der eigenen Richtlinie jedes Exits, sodass eine Ablehnungsregel gegen bekannte Exits durchsetzbar und überprüfbar ist. Für kommerzielle VPNs gibt es kein vergleichbares Register. Adressen wechseln, viele Anbieter veröffentlichen nichts, und ein Tunnel kann auf einer gemieteten Cloud-Adresse laufen, die nie zu einem VPN gehörte. Eine selbst zusammengestellte Liste ist eine Momentaufnahme beobachteter Adressen, und ihre Ausweitung auf Hosting-Bereiche fügt unzusammenhängende Arbeitslasten hinzu, ohne Beweise hinzuzufügen.

Nutzen Sie Adressen als Eingabe für Richtlinien, nicht als Beweis

Entscheiden Sie, wofür die Regel da ist. Eine Netzwerkbeschränkung sollte eng bleiben, die beobachtete Adresse mit Datum und Grund erfassen und legitimen Nutzern einen Weg zurück geben, wenn sich ihr Ausgang ändert. Zugriffskontrolle braucht ein authentifiziertes Konto oder ein signiertes Token, denn nur diese binden eine Anfrage an eine Identität. Risikobewertung kann die Adresse als einzelnes unzuverlässiges Signal nutzen und dabei ihre Fehlalarme und blinden Flecken akzeptieren. Die Regel als Produktentscheidung zu schreiben ist ehrlich; sie als Nachweis zu schreiben, dass ein Tunnel existiert, nicht.

Die spiegelbildliche Anfrage, die echte Adresse des Nutzers hinter einem VPN zurückzugewinnen, scheitert aus demselben Grund: Eine Verbindung trägt eine Adresse, und eine Änderung zwischen Sitzungen ist mit mehreren Erklärungen vereinbar. Behandeln Sie den früheren Wert als Geschichte, nicht als Wahrheit.