Aling source address ang nakikita ng STUN kapag may VPN sa router?
Ang ruta, pagpili ng source at pagsasalin ang nagtatakda ng address na iniuulat ng reflector. Tatlong katotohanang dapat itala, pagkatapos ay isang query para kumpirmahin kung aling landas ang nananalo.
Ang tanong ay parang isang paghahanap lamang at talagang tatlong desisyon. Aling ruta ang tinatahak ng binding request, aling source ang pinipili ng kernel para sa rutang iyon, at may nagre-rewrite ba ng source na iyon sa daan. Baguhin ang alinman sa tatlo at nagbabago rin ang address na iniuulat ng STUN server. Kaya ang pagsabing nasa router ang VPN ay halos walang sinasabi nang mag-isa.
Nakasalalay ang desisyon sa tatlong katotohanan
Una ang ruta: ang mga patakaran ng patakaran at ang routing table ang nagtatakda kung lalabas ang kahilingan sa tunnel o sa ordinaryong WAN, at ang ibinukod na destinasyon ay tumatahak sa pangalawang landas kahit aktibo ang tunnel. Ikalawa ang source: pumipili ang kernel ng source para sa napiling ruta, at ang pagpiling iyon ay nakadepende sa gustong source ng ruta at sa anumang patakarang tumugma. Ikatlo ang pagsasalin: pinapalitan ng NAT sa daan ang napiling source. Ang na-reflect na address ay produkto ng tatlo, hindi katangian ng tunnel.
Baguhin ang isa sa tatlo at nagbabago ang sagot habang mukhang malusog pa rin ang bawat bahagi sa sarili nitong log. Ito ang karaniwang dahilan kung bakit natigil ang diagnosis na ito.
Itala ang tatlong katotohanan para sa daloy na sinusubukan mo bago magsimula. Sapat ang interface, ruta at patakaran ng pagsasalin para mahulaan ang resulta, at ang hula mismo ang nagpapaging makabuluhan ng isang sorpresa. Kung hindi mo mapunan ang isa sa tatlo, ang puwang na iyon ang tunay na natuklasan.
Sundan ang isang binding request sa buong landas
Hinihiling ng isang binding request ng STUN sa server na iulat ang source transport address na naobserbahan nito. Inilalarawan ng sagot ang landas na tinahak ng kahilingan, hindi imbentaryo ng mga interface sa client machine. Ang dalawang kahilingan sa dalawang landas ay tapat na mag-uulat ng dalawang magkaibang address.
| 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 |
Basahin ang talahanayang iyon bilang isang set ng kundisyon, hindi bilang menu ng provider. Ang gitnang hilera ay nangangailangan na maabot ang pribadong reflector sa ilalim ng sariling routing at patakaran ng peer ng tunnel; ito ay katotohanan ng configuration na maaari mong i-verify, hindi isang bagay na ipinahihiwatig ng antas ng account. Ang ilalim na hilera ang karaniwang mahalaga para sa patakaran, dahil ang trapikong iyon ay dapat manatili sa loob ng tunnel. Sa pagitan ng dalawa ay ang ordinaryong kaso, kung saan nagsasalin ang exit at ang reflector ay nakikita lamang ang exit.
Ang mga host candidate at server-reflexive candidate ay nagmumula sa magkaibang mekanismo, kaya hindi sinasabi ng listahan ng candidate kung aling landas ang aktwal na ginamit ng media. Basahin ang napiling pares, hindi ang log ng pagkolekta, kapag gusto mong malaman kung saan nagpunta ang session.
Ano ang hindi ang tunnel address ng router
Ang tunnel address na itinalaga sa router ay pag-aari ng isang interface sa router. Ang browser sa isang host sa LAN ay may sariling mga interface address at walang direktang pananaw sa tunnel interface ng router. Ang pagtrato sa dalawa bilang mapagpapalit ay gumagawa ng kumpiyansang maling sagot tungkol sa kung ano ang maaaring matutunan ng isang web page.
Ang pagpapasa ang nag-uugnay sa dalawa. Dumadaan ang kahilingan sa router bilang rutadong trapiko, at ang source nito ay ang nilikha ng routing at pagsasalin.
Kung pinapanatili ng landas ng tunnel ang source ng LAN, maaaring matutunan ng pribadong reflector ang LAN address na iyon, na tunay na paghahayag at iba sa tunnel address. Kung nagsasalin ang landas sa tunnel address, natututunan ng reflector ang tunnel address sa halip. Pareho ang dalawang resulta ay tugma sa parehong browser sa parehong host, kaya dapat itali ang isang obserbasyon sa isang partikular na daloy. Tanungin ang kernel kung aling source ang gagamitin bago sisihin ang application.
Paghahayag kumpara sa paglampas: dalawang natuklasan, dalawang pag-aayos
Ang na-reflect na tunnel address ay naghahayag ng panloob na identifier sa isang landas na pinayagan mo. Ang direktang kahilingan sa WAN ay lumalampas sa landas na gusto mong ipatupad. Ang una ay tanong ng impormasyon, ang pangalawa ay tanong ng pagpapatupad, at inaayos ang mga ito sa magkaibang lugar. Ang pagsasama sa kanila sa isang salita ay gumagawa ng pag-aayos na hindi tumutugon sa alinman.
Ginagawang mas nakikita ito ng WebRTC nang hindi ito ginagawang mali, dahil ang pagkolekta ng candidate ay hindi katulad ng pagpili nito.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showPatakbuhin ang query ng ruta para sa bawat reflector address na pinapayagan mo, gamit ang source na inaasahan mong dadalhin ng daloy na iyon, pagkatapos ay patakbuhin muli para sa mga ibinukod na saklaw upang makita kung ano ang pinipili ng fallback. Ihambing ang dalawang sagot sa patakarang itinala mo. Kapag nagkaiba ang mga ito sa paraang hindi mo sinadya, natagpuan mo ang punto ng pag-aayos nang hindi kailangang bigyang-kahulugan ang listahan ng candidate ng browser.