Was eine STUN-Antwort verrät, wenn das VPN auf dem Router läuft

Wenn der Tunnel auf dem Router lebt, hat der Rechner, auf dem der Browser läuft, überhaupt keine Tunnelschnittstelle. Fragen Sie diesen Rechner nach seinen lokalen Adressen, und Sie erhalten eine private LAN-Adresse und ein Loopback, nichts, was einer VPN-Adresse ähnelt. Dennoch kann ein STUN-Server auf der Gegenseite noch etwas Aussagekräftiges über den Pfad melden, und was er meldet, hängt vollständig davon ab, wie genau diese Anfrage geroutet und übersetzt wurde.

Das ist der Teil, für den es sich lohnt, langsamer zu werden. „Der Browser besitzt die VPN-Adresse nicht“ beantwortet eine Frage zu Schnittstellen, während eine reflektierte Adresse eine Antwort über einen Pfad durch Übersetzung ist. Beides zu vermengen erzeugt selbstsichere Schlüsse über Offenlegung, die die Belege nicht stützen.

Zwei Geräte, zwei Sätze von Schnittstellen

In einem routerbasierten Aufbau endet der Tunnel auf dem Router, und der LAN-Client schickt gewöhnlichen Verkehr an sein Standardgateway. Die Schnittstellenliste des Clients bleibt kurz: eine private Adresse, vielleicht eine zweite für ein anderes Netz und Loopback. Das Risiko ist nicht, dass eine davon zufällig die Tunneladresse ist; es ist, dass die Anfrage über einen Pfad hinausgeht, den Sie nicht gewählt haben.

Fragen Sie den Client welche Route ein bestimmtes Ziel nehmen würde, statt zu fragen, welche Schnittstellen existieren. Die Antwort nennt ein Gateway und die Quelladresse, die der Kernel verwenden würde, und das ist bereits aufschlussreicher als jede Adressaufstellung.

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

Dokumentationsbereiche eignen sich gut als Testziele, weil sie sich nie in einen echten Dienst auflösen. Vergleichen Sie, was der Client sagt, mit dem, was der Router sagt, und behandeln Sie jede Abweichung als Beleg dafür, dass Policy-Routing, eine Split-Tunnel-Regel oder eine zweite Standardroute etwas tut, das Sie nicht eingeplant haben.

Was eine Binding-Antwort sagen darf

RFC 8489 definiert die Binding-Anfrage und -Antwort, bei der der Server die beobachtete Quelltransportadresse für diese Anfrage meldet. Das ist eine Aussage über ein Quintupel zu einem Zeitpunkt, keine Bestandsaufnahme der Clientschnittstellen. Alles Interessante geschieht daher zwischen dem Client und dem Beobachtungspunkt.

Diese Lücke füllen Routing und Übersetzung. Ein Router, der ausgehenden Verkehr per Quell-NAT übersetzt, ersetzt die private Quelle des Clients durch seine eigene Adresse auf der ausgehenden Schnittstelle. Ist diese Schnittstelle der Tunnel, sieht der Reflektor die Tunneladresse. Wurde das Paket vom Tunnel ausgeschlossen, sieht der Reflektor, was die WAN-Übersetzung erzeugt hat. Derselbe Client, derselbe Reflektor, andere Antwort.

Drei Fälle, die gleich aussehen und es nicht sind

Die nützliche Unterscheidung ist nicht öffentlich gegen privat, sondern welcher Durchsetzungspunkt das Paket behandelt hat. Arbeiten Sie die Fälle mit offenen eigenen Tabellen des Routers durch, denn ein Browser kann alle drei erzeugen, je nach einer Regel, von der Sie vergessen haben, dass Sie sie geschrieben haben.

Nur der zweite Fall verletzt die Anforderung, dass bestimmter Verkehr niemals direkt hinausgeht, und nur der erste und der dritte offenbaren eine Kennung auf der Tunnelseite. Keine der drei Zeilen ist eine Aussage über das Verhalten eines bestimmten Anbieters: ob ein privater Reflektor überhaupt erreichbar ist, hängt vom Routing, den erlaubten IP-Adressen der Gegenseite und der Firewall-Richtlinie an beiden Enden ab.

Ein Konto beim selben Anbieter belegt nichts davon. Es lohnt sich auch zu bedenken, dass eine geroutete Anfrage die LAN-Quelle des Clients behalten kann, wenn nichts sie übersetzt, sodass das Quellfeld nachverfolgt und nicht aus dem Topologiediagramm angenommen werden muss.

Sammeln ist nicht Auswählen

WebRTC sammelt Kandidatenadressen zum Ausprobieren, und ein Kandidat, der in einer Diagnoseliste auftaucht, trägt möglicherweise nie Medien. Die Liste so zu lesen, als sei sie „das, was die Gegenseite gelernt hat“, überzeichnet die Belege. Das ausgewählte Paar ist das, was die Sitzung tatsächlich getragen hat, und es steht in einem anderen Feld.

Eine HTTPS-Ausstiegsprüfung beantwortet noch eine andere Frage: die Quelladresse, die ein Webserver für diese Anfrage gesehen hat. Sie ist gerade deshalb eine nützliche Gegenprobe, weil sie ein anderes Protokoll und oft ein anderes Ziel als ein UDP-Reflektor verwendet, und eine Abweichung zwischen beiden weist meist auf eine Routingregel hin, nicht auf einen Fehler.

Legen Sie die Richtlinie fest, dann lesen Sie die Antwort

Schreiben Sie die Absicht vor dem Test auf: welcher Verkehr den Tunnel nutzen muss, welcher direkt hinausgehen darf, welche Adressfamilien im Umfang sind und was geschehen soll, wenn der Tunnel ausfällt. Ohne diese Grundlinie ist jede Beobachtung mehrdeutig, weil Sie ein Leck nicht von einem Pfad trennen können, den Sie bewusst erlaubt haben.

Stellen Sie dann jeweils eine Frage. Welche Route nimmt dieses Ziel. Welche Adresse meldet dieser Reflektor. Welches Kandidatenpaar hat die Sitzung gewählt. Halten Sie die Antworten neben der Richtlinie fest und datieren Sie sie, denn ein Firmware-Update kann das Standardverhalten so ändern, dass die Schlussfolgerung des Vorjahres still ungültig wird.

Der Router bleibt ein starker Durchsetzungspunkt, weil er Verkehr sieht, den ein Client nicht umgehen kann, ohne sich selbst neu zu konfigurieren. Er ist kein Versprechen, dass jedes Feld in jedem Anwendungsprotokoll nichts offenbart, und kein Ersatz dafür, die Pfade aufzuschreiben, die Sie zugelassen haben.