Watter bronadres sien STUN met 'n router-VPN?
Roete, bronkeuse en vertaling bepaal die adres wat 'n reflektor rapporteer. Drie feite om neer te skryf, dan een navraag om te bevestig watter pad wen.
Die vraag klink soos een opsoeking en is eintlik drie besluite. Watter roete die binding-versoek neem, watter bron die kernel vir daardie roete kies, en of iets op die pad daardie bron herskryf. Verander enigeen van hulle en die adres wat 'n STUN-bediener rapporteer verander saam. Daarom sê die bewering dat die VPN op die router sit op sigself byna niks.
Die besluit berus op drie feite
Eerstens die roete: beleidsreëls en die roetetabel besluit of die versoek deur die tonnel of deur die gewone WAN verlaat, en 'n uitgeslote bestemming neem die tweede pad selfs terwyl 'n tonnel op is. Tweedens die bron: die kernel kies 'n bron vir die gekose roete, en daardie keuse hang af van die roete se voorkeurbron en van enige reël wat gepas het. Derdens die vertaling: NAT op die pad vervang watter bron ook al gekies is. Die weerkaatste adres is die produk van al drie, nie 'n eienskap van die tonnel nie.
Verander een van die drie en die antwoord verander terwyl elke komponent in sy eie log nog gesond lyk. Dit is die gewone rede waarom hierdie diagnose vasval.
Skryf die drie feite neer vir die vloei wat jy toets voordat jy begin. Koppelvlak, roete en vertaalreël is genoeg om die uitkoms te voorspel, en juis die voorspelling maak 'n verrassing insiggewend. As jy een van die drie nie kan invul nie, is daardie gaping die werklike bevinding.
Volg een binding-versoek deur die pad
'n STUN-binding-versoek vra 'n bediener om die waargenome bron-transportadres te rapporteer. Die antwoord beskryf die pad wat die versoek geneem het, nie 'n inventaris van koppelvlakke op die kliëntmasjien nie. Twee versoeke oor twee paaie rapporteer eerlik twee verskillende adresse.
| 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 daardie tabel as 'n stel voorwaardes, nie as 'n spyskaart van verskaffers nie. Die middelste ry vereis dat die private reflektor bereikbaar is onder die tonnel se eie roetering en peer-beleid; dit is 'n konfigurasiefeit wat jy kan verifieer en nie iets wat 'n rekeningvlak impliseer nie. Die onderste ry is gewoonlik die een wat vir beleid saak maak, want daardie verkeer was veronderstel om binne die tonnel te bly. Tussen hulle sit die gewone geval, waar die uitgang vertaal en die reflektor net die uitgang sien.
Gasheerkandidate en bediener-refleksiewe kandidate kom uit verskillende meganismes, so 'n kandidaatlys is nie 'n stelling oor watter pad die media werklik gebruik het nie. Lees die gekose paar, nie die versamellog nie, wanneer jy wil weet waar die sessie heen gegaan het.
Wat die router se tonneladres nie is nie
'n Tonneladres wat aan die router toegewys is, behoort aan 'n koppelvlak op die router. 'n Blaaier op 'n LAN-gasheer het sy eie koppelvlakadresse en geen direkte siening van die router se tonnelkoppelvlak nie. Om die twee as uitruilbaar te behandel, lewer selfversekerde verkeerde antwoorde oor wat 'n webblad kan leer.
Aanstuur is wat hulle verbind. Die versoek kruis die router as geroteerde verkeer, en sy bron is wat roetering en vertaling opgelewer het.
As die tonnelpad die LAN-bron bewaar, kan 'n private reflektor daardie LAN-adres leer, wat 'n werklike openbaarmaking is en 'n ander een as die tonneladres. As die pad na die tonneladres vertaal, leer die reflektor eerder die tonneladres. Beide uitkomste strook met dieselfde blaaier op dieselfde gasheer, en daarom moet 'n waarneming aan 'n spesifieke vloei gekoppel word. Vra die kernel watter bron hy sou gebruik voordat jy die toepassing blameer.
Openbaarmaking teenoor omseiling: twee bevindings, twee herstellings
'n Weerkaatste tonneladres maak 'n interne identifiseerder bekend oor 'n pad wat jy toegelaat het. 'n Versoek direk oor die WAN omseil 'n pad wat jy bedoel het om te vereis. Die eerste is 'n inligtingsvraag, die tweede 'n handhawingsvraag, en hulle word op verskillende plekke reggemaak. Om hulle in een woord saam te val, lewer 'n herstelling op wat nie een van die twee aanspreek nie.
WebRTC maak dit meer sigbaar sonder om dit verkeerd te maak, want om 'n kandidaat te versamel is nie dieselfde as om een te kies nie.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showVoer die roetevraag uit vir elke reflektoradres wat jy toelaat, met die bron wat jy verwag daardie vloei sal dra, en voer dit dan weer uit vir die uitgeslote reekse om te sien wat die terugval kies. Vergelyk die twee antwoorde met die beleid wat jy neergeskryf het. Wanneer hulle verskil op 'n manier wat jy nie bedoel het nie, het jy die herstellingspunt gevind sonder om enigsins 'n blaaier se kandidaatlys te hoef te interpreteer.