Milyen forrás címet lát a STUN routeren futó VPN-nel?
Az útvonal, a forrásválasztás és a fordítás dönti el, milyen címet jelent a tükröző. Három tény, amit érdemes felírni, majd egy lekérdezés annak megerősítésére, melyik út nyer.
A kérdés egyetlen keresésnek hangzik, valójában három döntés. Melyik útvonalat veszi a binding request, melyik forrást választja a kernel ehhez az útvonalhoz, és átírja-e valami útközben ezt a forrást. Módosítsa bármelyiket, és a STUN-kiszolgáló által jelentett cím is vele változik. Ezért a kijelentés, hogy a VPN a routeren van, önmagában szinte semmit sem mond.
A döntés három tényn nyugszik
Először az útvonal: a házirend-szabályok és az útválasztási tábla döntik el, hogy a kérés a tunnelen vagy a szokásos WAN-on keresztül lép-e ki, és a kizárt cél a második utat választja akkor is, ha a tunnel aktív. Aztán a forrás: a kernel forrást választ a kiválasztott útvonalhoz, és ez a választás az útvonal preferált forrásától és minden illeszkedő szabálytól függ. Végül a fordítás: az útközbeni NAT lecseréli a választott forrást. A tükrözött cím mindhárom szorzata, nem a tunnel tulajdonsága.
Módosítsa a három közül az egyiket, és a válasz megváltozik, miközben minden komponens a saját naplójában még egészségesnek látszik. Ez a szokásos oka annak, hogy ez a diagnózis elakad.
Írja fel a három tényt a tesztelt folyamathoz, mielőtt elkezdi. Az interfész, az útvonal és a fordítási szabály elég az eredmény előrejelzéséhez, és éppen az előrejelzés teszi tanulságossá a meglepetést. Ha a három közül egyet nem tud kitölteni, az a hiány a valódi lelet.
Kövessen végig egy binding requestet az úton
A STUN binding request megkéri a kiszolgálót, hogy jelentse a megfigyelt forrás-transzportcímet. A válasz leírja az utat, amelyet a kérés megtett, nem az ügyfélgép interfészeinek leltárát. Két kérés két úton őszintén két különböző címet jelent.
| 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 |
Ezt a táblázatot feltételhalmazként olvassa, ne szolgáltatói menüként. A középső sor azt kívánja, hogy a privát tükröző elérhető legyen a tunnel saját útválasztása és peer-házirendje alatt; ez ellenőrizhető konfigurációs tény, és nem valami, amit egy fiókszint implikál. Az alsó sor általában a házirend szempontjából számít, mert annak a forgalomnak a tunnelen belül kellett volna maradnia. Közöttük van a szokásos eset, amikor a kijárat fordít, és a tükröző csak a kijáratot látja.
A host-jelöltek és a kiszolgáló-tükröző jelöltek különböző mechanizmusokból származnak, ezért a jelöltlista nem mondja meg, melyik utat használta a média valójában. A kiválasztott párt olvassa, ne a gyűjtési naplót, ha tudni akarja, hová ment a munkamenet.
Mi nem a router tunnelcíme
A routerhez rendelt tunnelcím a router egyik interfészéhez tartozik. A LAN-host böngészőjének saját interfészcímei vannak, és nincs közvetlen rálátása a router tunnelinterfészére. Ha a kettőt felcserélhetőként kezeljük, magabiztos téves válaszokat kapunk arról, mit tudhat meg egy weboldal.
A továbbítás az, ami összeköti őket. A kérés irányított forgalomként halad át a routeren, és a forrása az, amit az útválasztás és a fordítás létrehozott.
Ha a tunnel útja megőrzi a LAN-forrást, egy privát tükröző megtudhatja ezt a LAN-címet, ami valódi felfedés, és különbözik a tunnelcímtől. Ha az út a tunnelcímre fordít, a tükröző helyette a tunnelcímet tudja meg. Mindkét eredmény összeegyeztethető ugyanazzal a böngészővel ugyanazon a hoston, ezért a megfigyelést egy adott folyamathoz kell kötni. Kérdezze meg a kernelt, melyik forrást használná, mielőtt az alkalmazást hibáztatja.
Felfedés versus megkerülés: két lelet, két javítás
A tükrözött tunnelcím belső azonosítót fed fel egy Ön által engedélyezett úton. A közvetlen WAN-kérés megkerül egy utat, amelyet meg akart követelni. Az első információs kérdés, a második végrehajtási kérdés, és különböző helyeken javítják. Ha egyetlen szóba olvasztja őket, olyan javítást kap, amely egyikkel sem foglalkozik.
A WebRTC láthatóbbá teszi ezt anélkül, hogy tévedé tenné, hiszen jelöltet gyűjteni nem ugyanaz, mint kiválasztani.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showFuttassa le az útvonal-lekérdezést minden engedélyezett tükrözőcímre azzal a forrással, amelyről azt várja, hogy ezt a folyamatot viszi, majd futtassa újra a kizárt tartományokra, hogy lássa, mit választ a tartalék. Hasonlítsa össze a két választ a felírt házirenddel. Amikor olyan módon térnek el, amit nem szándékozott, megtalálta a javítási pontot anélkül, hogy egyáltalán értelmeznie kellene a böngésző jelöltlistáját.