Welk bronadres ziet STUN bij een router-VPN?
Route, bronselectie en vertaling bepalen het adres dat een reflector meldt. Drie feiten op schrijven, dan één query om te bevestigen welk pad wint.
De vraag klinkt als één keer opzoeken en is in werkelijkheid drie beslissingen. Welk pad het binding request neemt, welke bron de kernel voor dat pad kiest en of iets onderweg die bron herschrijft. Verandere één daarvan en het adres dat een STUN-server meldt, verandert mee. Daarom zegt de uitspraak dat de VPN op de router staat op zichzelf bijna niets.
De beslissing berust op drie feiten
Ten eerste de route: beleidsregels en de routingtabel beslissen of het verzoek via de tunnel of via het gewone WAN naar buiten gaat, en een uitgesloten bestemming neemt het tweede pad, zelfs terwijl een tunnel actief is. Ten tweede de bron: de kernel kiest een bron voor de gekozen route, en die keuze hangt af van de voorkeursbron van de route en van elke regel die overeenkwam. Ten derde de vertaling: NAT onderweg vervangt welke bron dan ook gekozen is. Het weerspiegelde adres is het product van alle drie, geen eigenschap van de tunnel.
Verander één van de drie en het antwoord verandert, terwijl elke component in zijn eigen log nog gezond lijkt. Dat is de gebruikelijke reden waarom deze diagnose vastloopt.
Schrijf de drie feiten op voor de flow die je test voordat je begint. Interface, route en vertaalregel zijn genoeg om het resultaat te voorspellen, en juist die voorspelling maakt een verrassing informatief. Kun je één van de drie niet invullen, dan is dat gat de eigenlijke bevinding.
Volg één binding request door het pad
Een STUN-binding request vraagt een server om het waargenomen bron-transportadres te melden. Het antwoord beschrijft het pad dat het verzoek heeft genomen, niet een inventaris van interfaces op de clientmachine. Twee verzoeken over twee paden melden eerlijk twee verschillende 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 |
Lees die tabel als een reeks voorwaarden, niet als een menu van aanbieders. De middelste rij vereist dat de private reflector bereikbaar is onder het eigen routing- en peerbeleid van de tunnel; dat is een configuratiegegeven dat je kunt verifiëren en niet iets wat een accountniveau impliceert. De onderste rij is voor het beleid meestal de belangrijkste, want dat verkeer hoorde binnen de tunnel te blijven. Daartussen zit het gewone geval, waarin de exit vertaalt en de reflector alleen de exit ziet.
Hostkandidaten en server-reflexieve kandidaten komen uit verschillende mechanismen, dus een kandidatenlijst zegt niet welk pad de media werkelijk gebruikten. Lees het geselecteerde paar, niet het verzamellog, als je wilt weten waar de sessie heen ging.
Wat het tunneladres van de router niet is
Een tunneladres dat aan de router is toegewezen, hoort bij een interface op de router. Een browser op een LAN-host heeft eigen interfaceadressen en geen direct zicht op de tunnelinterface van de router. Beide als inwisselbaar behandelen levert stellige verkeerde antwoorden op over wat een webpagina kan leren.
Doorsturen is wat hen verbindt. Het verzoek gaat als gerouteerd verkeer door de router, en de bron is wat routing en vertaling hebben opgeleverd.
Als het tunnelpad de LAN-bron behoudt, kan een private reflector dat LAN-adres leren, wat een echte onthulling is en een andere dan het tunneladres. Vertaalt het pad naar het tunneladres, dan leert de reflector in plaats daarvan het tunneladres. Beide uitkomsten passen bij dezelfde browser op dezelfde host, en daarom moet een waarneming aan een specifieke flow gekoppeld zijn. Vraag de kernel welke bron hij zou gebruiken voordat je de toepassing de schuld geeft.
Onthulling versus omzeiling: twee bevindingen, twee reparaties
Een weerspiegeld tunneladres onthult een interne identificatie over een pad dat je hebt toegestaan. Een verzoek rechtstreeks over het WAN omzeilt een pad dat je wilde vereisen. Het eerste is een informatievraag, het tweede een handhavingsvraag, en ze worden op verschillende plaatsen opgelost. Ze in één woord samenvatten levert een reparatie op die geen van beide aanpakt.
WebRTC maakt dit zichtbaarder zonder het fout te maken, want een kandidaat verzamelen is niet hetzelfde als hem selecteren.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showVoer de routequery uit voor elk reflectoradres dat je toestaat, met de bron die die flow volgens jou draagt, en daarna nog eens voor de uitgesloten bereiken om te zien wat de terugval kiest. Vergelijk de twee antwoorden met het beleid dat je hebt opgeschreven. Wijkt het af op een manier die je niet bedoelde, dan heb je het reparatiepunt gevonden zonder überhaupt een kandidatenlijst van de browser te hoeven interpreteren.