Welche Quelladresse sieht STUN bei einem Router-VPN?
Route, Quellwahl und Übersetzung bestimmen die Adresse, die ein Reflektor meldet. Drei Fakten notieren, dann mit einer Abfrage bestätigen, welcher Pfad gewinnt.
Die Frage klingt nach einem einzigen Nachschlagen und ist in Wahrheit drei Entscheidungen. Welchen Weg die Binding Request nimmt, welche Quelle der Kernel für diesen Weg wählt und ob unterwegs jemand diese Quelle umschreibt. Ändert man eines davon, ändert sich auch die Adresse, die ein STUN-Server meldet. Deshalb sagt die Aussage, das VPN sitze auf dem Router, für sich genommen fast nichts.
Die Entscheidung beruht auf drei Fakten
Erstens die Route: Policy-Regeln und die Routing-Tabelle entscheiden, ob die Anfrage über den Tunnel oder über das gewöhnliche WAN hinausgeht, und ein ausgenommenes Ziel nimmt den zweiten Weg, selbst wenn ein Tunnel aktiv ist. Zweitens die Quelle: Der Kernel wählt für die gewählte Route eine Quelle, und diese Wahl hängt von der bevorzugten Quelle der Route und von jeder passenden Regel ab. Drittens die Übersetzung: NAT unterwegs ersetzt die gewählte Quelle. Die reflektierte Adresse ist das Produkt aller drei und keine Eigenschaft des Tunnels.
Ändere eines der drei, und die Antwort ändert sich, während jede Komponente in ihrem eigenen Log weiter gesund aussieht. Das ist der übliche Grund, warum diese Diagnose stockt.
Notiere die drei Fakten für den Fluss, den du testest, bevor du beginnst. Schnittstelle, Route und Übersetzungsregel genügen, um das Ergebnis vorherzusagen, und gerade diese Vorhersage macht eine Überraschung informativ. Wenn du einen der drei nicht eintragen kannst, ist diese Lücke der eigentliche Befund.
Eine Binding Request durch den Pfad verfolgen
Eine STUN-Binding-Request fordert einen Server auf, die beobachtete Quell-Transportadresse zu melden. Die Antwort beschreibt den Pfad, den die Anfrage genommen hat, nicht eine Bestandsaufnahme der Schnittstellen auf dem Client-Rechner. Zwei Anfragen über zwei Pfade melden ehrlich zwei verschiedene Adressen.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
Lies diese Tabelle als eine Menge von Bedingungen, nicht als Menü von Anbietern. Die mittlere Zeile setzt voraus, dass der private Reflektor unter dem eigenen Routing und der Peer-Policy des Tunnels erreichbar ist; das ist ein Konfigurationsfakt, den du prüfen kannst, und nichts, was eine Account-Stufe impliziert. Die untere Zeile ist für die Policy meist die entscheidende, denn dieser Verkehr sollte im Tunnel bleiben. Dazwischen liegt der Normalfall, in dem der Exit übersetzt und der Reflektor nur den Exit sieht.
Host-Kandidaten und server-reflexive Kandidaten entstehen aus verschiedenen Mechanismen; eine Kandidatenliste sagt daher nicht, welchen Pfad die Medien tatsächlich genutzt haben. Lies das ausgewählte Paar, nicht das Gathering-Log, wenn du wissen willst, wohin die Sitzung ging.
Was die Tunneladresse des Routers nicht ist
Eine dem Router zugewiesene Tunneladresse gehört zu einer Schnittstelle auf dem Router. Ein Browser auf einem LAN-Host hat eigene Schnittstellenadressen und keine direkte Sicht auf die Tunnel-Schnittstelle des Routers. Behandelt man beide als austauschbar, entstehen sichere falsche Antworten darauf, was eine Webseite erfahren kann.
Weiterleitung ist das, was beide verbindet. Die Anfrage durchquert den Router als gerouteten Verkehr, und ihre Quelle ist das, was Routing und Übersetzung erzeugt haben.
Wenn der Tunnelpfad die LAN-Quelle erhält, kann ein privater Reflektor diese LAN-Adresse erfahren, was eine echte Offenlegung ist und eine andere als die Tunneladresse. Übersetzt der Pfad auf die Tunneladresse, erfährt der Reflektor stattdessen die Tunneladresse. Beide Ergebnisse passen zum selben Browser auf demselben Host, deshalb muss eine Beobachtung an einen bestimmten Fluss gebunden sein. Frage den Kernel, welche Quelle er verwenden würde, bevor du die Anwendung beschuldigst.
Offenlegung versus Umgehung: zwei Befunde, zwei Reparaturen
Eine reflektierte Tunneladresse legt eine interne Kennung über einen Pfad offen, den du erlaubt hast. Eine Anfrage direkt über das WAN umgeht einen Pfad, den du verlangen wolltest. Das erste ist eine Informationsfrage, das zweite eine Durchsetzungsfrage, und sie werden an verschiedenen Stellen behoben. Fasst man sie in einem Wort zusammen, entsteht eine Reparatur, die keines von beiden adressiert.
WebRTC macht das sichtbarer, ohne es falsch zu machen, denn einen Kandidaten zu sammeln ist nicht dasselbe wie ihn auszuwählen.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showFühre die Routenabfrage für jede Reflektoradresse aus, die du erlaubst, mit der Quelle, die dieser Fluss deiner Erwartung nach trägt, und dann noch einmal für die ausgenommenen Bereiche, um zu sehen, was der Fallback wählt. Vergleiche die beiden Antworten mit der Policy, die du notiert hast. Weichen sie auf eine Art ab, die du nicht beabsichtigt hast, hast du den Reparaturpunkt gefunden, ohne überhaupt eine Kandidatenliste des Browsers deuten zu müssen.