Pyetja duket si një kërkim i vetëm dhe në të vërtetë janë tri vendime. Cilën rrugë merr binding request, cilin burim zgjedh kerneli për atë rrugë dhe nëse diçka gjatë rrugës e rishkruan atë burim. Ndrysho njërën prej të trejave dhe adresa që raporton një server STUN ndryshon bashkë me të. Prandaj thënia se VPN ndodhet në router nuk të thotë pothuajse asgjë në vetvete.

Vendimi mbështetet në tri fakte

Së pari rruga: rregullat e politikës dhe tabela e rrugëzimit vendosin nëse kërkesa del përmes tunelit apo përmes WAN-it të zakonshëm, dhe një destinacion i përjashtuar merr rrugën e dytë edhe kur një tunel është aktiv. Së dyti burimi: kerneli zgjedh një burim për rrugën e zgjedhur, dhe kjo zgjedhje varet nga burimi i preferuar i rrugës dhe nga çdo rregull që përputhej. Së treti përkthimi: NAT gjatë rrugës zëvendëson burimin që është zgjedhur. Adresa e reflektuar është produkti i të trejave, jo një veti e tunelit.

Ndrysho njërën prej të trejave dhe përgjigja ndryshon ndërsa çdo komponent vazhdon të duket i shëndetshëm në regjistrin e vet. Kjo është arsyeja e zakonshme pse kjo diagnozë ngec.

Shëno tri faktet për fluksin që po teston përpara se të fillosh. Ndërfaqja, rruga dhe rregulli i përkthimit mjaftojnë për të parashikuar rezultatin, dhe pikërisht parashikimi e bën një surprizë informuese. Nëse nuk mund të plotësosh njërën prej të trejave, ajo boshllëk është gjetja e vërtetë.

Ndiq një binding request përgjatë rrugës

Një binding request STUN i kërkon një serveri të raportojë adresën e transportit burimore që vëzhgoi. Përgjigja përshkruan rrugën që mori kërkesa, jo një inventar ndërfaqesh në makinën klient. Dy kërkesa në dy rrugë do të raportojnë sinqerisht dy adresa të ndryshme.

Path takenSource the reflector seesWhat it means
Tunnel to a public exit that translatesThe exit's public addressThe reflector learns nothing about the LAN
Tunnel to a private reflector, translated to the tunnel address, no later translationThat tunnel addressAn internal identifier is disclosed to that reflector
Excluded flow over the ordinary WANThe WAN addressThe tunnel was not used at all

Lexoje atë tabelë si një grup kushtesh, jo si një menu ofruesish. Rreshti i mesëm kërkon që reflektori privat të jetë i arritshëm nën rrugëzimin dhe politikën e kolegëve të tunelit; ky është një fakt konfigurimi që mund ta verifikosh, jo diçka që nënkupton një nivel llogarie. Rreshti i poshtëm është zakonisht ai që ka rëndësi për politikën, sepse ai trafik duhej të mbetej brenda tunelit. Midis tyre ndodhet rasti i zakonshëm, ku dalja përkthen dhe reflektori sheh vetëm daljen.

Kandidatët host dhe kandidatët refleksivë të serverit vijnë nga mekanizma të ndryshëm, prandaj një listë kandidatësh nuk thotë cilën rrugë përdorën në fakt mediat. Lexo çiftin e zgjedhur, jo regjistrin e mbledhjes, kur do të dish se ku shkoi sesioni.

Çfarë nuk është adresa e tunelit të routerit

Një adresë tuneli e caktuar routerit i përket një ndërfaqeje në router. Një shfletues në një host të LAN-it ka adresat e veta të ndërfaqes dhe asnjë pamje të drejtpërdrejtë të ndërfaqes së tunelit të routerit. T'i trajtosh të dyja si të këmbyeshme prodhon përgjigje të gabuara dhe të sigurta për atë që mund të mësojë një faqe web.

Përcjellja është ajo që i lidh. Kërkesa kalon routerin si trafik i rrugëzuar, dhe burimi i saj është ajo që prodhuan rrugëzimi dhe përkthimi.

Nëse rruga e tunelit e ruan burimin e LAN-it, një reflektor privat mund ta mësojë atë adresë LAN, që është një zbulim i vërtetë dhe i ndryshëm nga adresa e tunelit. Nëse rruga përkthen në adresën e tunelit, reflektori mëson adresën e tunelit në vend të saj. Të dyja rezultatet përputhen me të njëjtin shfletues në të njëjtin host, prandaj një vëzhgim duhet të lidhet me një fluks të caktuar. Pyet kernelin cilin burim do të përdorte përpara se ta fajësosh aplikacionin.

Zbulim kundrejt anashkalimit: dy gjetje, dy rregullime

Një adresë tuneli e reflektuar zbulon një identifikues të brendshëm përmes një rruge që e ke lejuar. Një kërkesë direkt në WAN anashkalon një rrugë që doje ta imponoje. E para është çështje informacioni, e dyta çështje zbatimi, dhe rregullohen në vende të ndryshme. Nëse i bashkon në një fjalë të vetme, prodhon një rregullim që nuk trajton asnjërën.

WebRTC e bën këtë më të dukshme pa e bërë të gabuar, sepse mbledhja e një kandidati nuk është e njëjtë me zgjedhjen e tij.

ip route get 203.0.113.7 from 192.0.2.25
ip rule show

Ekzekuto pyetësin e rrugës për çdo adresë reflektori që lejon, me burimin që pret që të mbajë ai fluks, pastaj ekzekutoje përsëri për intervalet e përjashtuara për të parë çfarë zgjedh alternativa. Krahaso dy përgjigjet me politikën që shënove. Kur ndryshojnë në një mënyrë që nuk e kishe synuar, ke gjetur pikën e rregullimit pa pasur nevojë të interpretosh fare listën e kandidatëve të një shfletuesi.

Artikuj të ngjashëm