Kiun fontadreson vidas STUN kun enkursistema VPN?
Itinero, fonta elekto kaj traduko decidas la adreson, kiun raportas reflektoro. Tri faktoj notindaj, poste unu peto por konfirmi, kiu vojo gajnas.
La demando sonas kiel unu serĉo kaj fakte estas tri decidoj. Kiun itineron prenas la binding request, kiun fonton la kerno elektas por tiu itinero, kaj ĉu io survoje reskribas tiun fonton. Ŝanĝu unu el la tri kaj la adreso, kiun STUN-servilo raportas, ŝanĝiĝas kun ĝi. Tial diri, ke la VPN sidas sur la enkursigilo, preskaŭ nenion diras per si mem.
La decido ripozas sur tri faktoj
Unue la itinero: politikaj reguloj kaj la itinera tabelo decidas, ĉu la peto eliras tra la tunelo aŭ tra la ordinara WAN, kaj ekskludita celo prenas la duan vojon eĉ dum tunelo estas aktiva. Due la fonto: la kerno elektas fonton por la elektita itinero, kaj tiu elekto dependas de la preferata fonto de la itinero kaj de ĉiu regulo, kiu kongruis. Trie la traduko: NAT survoje anstataŭas la elektitan fonton. La reflektita adreso estas la produkto de ĉiuj tri, ne eco de la tunelo.
Ŝanĝu unu el la tri kaj la respondo ŝanĝiĝas, dum ĉiu komponanto ankoraŭ aspektas sana en sia propra protokolo. Tio estas la kutima kialo, kial ĉi tiu diagnozo haltas.
Notu la tri faktojn por la fluo, kiun vi testas, antaŭ ol komenci. Interfaco, itinero kaj traduka regulo sufiĉas por antaŭdiri la rezulton, kaj ĝuste la antaŭdiro igas surprizon informa. Se vi ne povas plenigi unu el la tri, tiu manko estas la reala trovaĵo.
Sekvu unu binding request laŭ la vojo
STUN-binding-request petas servilon raporti la observitan fontan transportadreson. La respondo priskribas la vojon, kiun prenis la peto, ne inventaron de interfacoj sur la klienta maŝino. Du petoj laŭ du vojoj honeste raportos du malsamajn adresojn.
| 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 |
Legu tiun tabelon kiel aron da kondiĉoj, ne kiel menuon de provizantoj. La meza vico postulas, ke la privata reflektoro estu atingebla sub la propra itinera kaj samtavola politiko de la tunelo; tio estas agorda fakto, kiun vi povas kontroli, kaj ne io, kion implicas konta nivelo. La malsupra vico kutime estas la grava por politiko, ĉar tiu trafiko devis resti ene de la tunelo. Inter ili kuŝas la ordinara kazo, en kiu la elirejo tradukas kaj la reflektoro vidas nur la elirejon.
Gastigantaj kandidatoj kaj servil-reflektaj kandidatoj venas de malsamaj mekanismoj, do kandidata listo ne diras, kiun vojon la aŭdovidaĵoj fakte uzis. Legu la elektitan paron, ne la kolektan protokolon, kiam vi volas scii, kien iris la seanco.
Kio la tunela adreso de la enkursigilo ne estas
Tunela adreso atribuita al la enkursigilo apartenas al interfaco sur la enkursigilo. Retumilo sur LAN-gastiganto havas proprajn interfacajn adresojn kaj neniun rektan vidon al la tunela interfaco de la enkursigilo. Trakti la du kiel interŝanĝeblajn produktas certajn malĝustajn respondojn pri tio, kion retpaĝo povas lerni.
Plusendado estas tio, kio ligas ilin. La peto trapasas la enkursigilon kiel itinera trafiko, kaj ĝia fonto estas tio, kion produktis itinera kaj traduka procezoj.
Se la tunela vojo konservas la LAN-fonton, privata reflektoro povas lerni tiun LAN-adreson, kio estas vera malkaŝo kaj malsama ol la tunela adreso. Se la vojo tradukas al la tunela adreso, la reflektoro lernas anstataŭe la tunelan adreson. Ambaŭ rezultoj kongruas kun la sama retumilo sur la sama gastiganto, kaj tial observo devas esti ligita al specifa fluo. Demandu la kernon, kiun fonton ĝi uzus, antaŭ ol kulpigi la aplikaĵon.
Malkaŝo kontraŭ preteriro: du trovaĵoj, du riparoj
Reflektita tunela adreso malkaŝas internan identigilon laŭ vojo, kiun vi permesis. Petaĵo rekte laŭ la WAN preteriras vojon, kiun vi intencis postuli. La unua estas informa demando, la dua plenuma demando, kaj ili ripariĝas en malsamaj lokoj. Kunfandi ilin en unu vorton produktas riparon, kiu traktas nek unu nek la alian.
WebRTC igas tion pli videbla sen igi ĝin malĝusta, ĉar kolekti kandidaton ne samas al elekti ĝin.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showRulu la itineran peton por ĉiu reflektora adreso, kiun vi permesas, kun la fonto, kiun vi atendas, ke tiu fluo portu, poste rulu ĝin denove por la ekskluditaj intervaloj por vidi, kion elektas la rezerva vojo. Komparu la du respondojn kun la politiko, kiun vi notis. Kiam ili malsamas tiel, kiel vi ne intencis, vi trovis la riparpunkton sen eĉ bezoni interpreti kandidatan liston de retumilo.