Zein iturburu-helbide ikusten du STUN-ek routerreko VPN-rekin?
Bideak, iturburuaren hautaketak eta itzulpenak erabakitzen dute islatzaileak jakinarazten duen helbidea. Hiru gertaera idazteko, gero zein bide nagusitzen den baieztatzeko kontsulta bat.
Galdera bilaketa bakar bat dirudi eta benetan hiru erabaki dira. Binding request-ek zein bide hartzen duen, kernelak bide horretarako zein iturburu hautatzen duen eta bidean zerbait iturburu hori berridazten duen. Horietako bat aldatuta, STUN zerbitzariak jakinarazten duen helbidea ere aldatzen da. Horregatik, VPN-a routerrean dagoela esateak berez ia ezer ez du esaten.
Erabakia hiru gertaeratan oinarritzen da
Lehenik bidea: politika-arauak eta bideratze-taula arduratzen dira eskaera tunelatik edo ohiko WAN-etik irteten den, eta baztertutako helburuak bigarren bidea hartzen du tunela aktibo egonda ere. Gero iturburua: kernelak iturburu bat hautatzen du hautatutako biderako, eta hautaketa hori bidearen iturburu hobetsiaren eta bat etorri den edozein arauren araberakoa da. Azkenik itzulpena: bidean NAT-ek hautatutako iturburua ordezkatzen du. Islatutako helbidea hiru horien biderkadura da, ez tunelaren ezaugarria.
Hiru horietako bat aldatu eta erantzuna aldatzen da, osagai bakoitzak bere erregistroan osasuntsu dirudien arren. Hori da diagnostiko hau trabatuta geratzeko ohiko arrazoia.
Idatzi hiru gertaerak probatzen ari zaren fluxurako hasi aurretik. Interfazea, bidea eta itzulpen-araua nahikoa dira emaitza iragartzeko, eta iragarpenak berak egiten du sorpresa informatiboa. Hiruretako bat bete ezin baduzu, hutsune hori da benetako aurkikuntza.
Jarraitu binding request bat bidean zehar
STUN-en binding request batek zerbitzariari eskatzen dio behatu duen iturburu-garraio helbidea jakinarazteko. Erantzunak eskaerak hartu duen bidea deskribatzen du, ez bezeroaren makinako interfazeen zerrenda. Bi bideetatik datozen bi eskaerek zintzo bi helbide desberdin jakinaraziko dituzte.
| 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 |
Irakurri taula hori baldintza-multzo gisa, ez hornitzaileen menu gisa. Erdiko ilarak eskatzen du islatzaile pribatua tunelaren beraren bideratzearen eta kide-politikaren pean irisgarria izatea; hori egiaztatu dezakezun konfigurazio-gertaera da, ez kontu-mailak iradokitzen duen zerbait. Beheko ilara izaten da normalean politikarako garrantzitsuena, trafiko hori tunelaren barruan geratu behar zelako. Bien artean ohiko kasua dago, irteerak itzultzen duenean eta islatzaileak irteera baino ez duenean ikusten.
Ostalariko hautagaiak eta zerbitzari-isla ihes-hautagaiak mekanismo desberdinetatik datoz, beraz hautagaien zerrendak ez du esaten medioek benetan zein bide erabili zuten. Irakurri hautatutako bikotea, ez biltze-erregistroa, saioa nora joan zen jakin nahi duzunean.
Zer ez den routerraren tunel-helbidea
Routerrari esleitutako tunel-helbidea routerreko interfaze bati dagokio. LAN ostalari bateko arakatzaileak bere interfaze-helbideak ditu eta ez du routerraren tunel-interfazea zuzenean ikusten. Biak trukagarri gisa tratatzeak web orrialde batek zer ikas dezakeen buruzko erantzun okerrak ematen ditu, segurtasun handiz gainera.
Birbidalketa da biak lotzen dituena. Eskaerak routerra zeharkatzen du bideratutako trafiko gisa, eta haren iturburua bideratzeak eta itzulpenak sortutakoa da.
Tunelaren bideak LAN iturburua mantentzen badu, islatzaile pribatuak LAN helbide hori ikas dezake, eta hori benetako agerpena da, tunel-helbidearen desberdina. Bideak tunel-helbidera itzultzen badu, islatzaileak tunel-helbidea ikasiko du horren ordez. Bi emaitzak host bereko arakatzaile berarekin bat datoz, beraz behaketa fluxu zehatz bati lotu behar zaio. Galdetu kernelari zein iturburu erabiliko lukeen aplikazioari errua eman aurretik.
Agerpena versus saihestea: bi aurkikuntza, bi konponketa
Islatutako tunel-helbideak barne-identifikatzaile bat agerian uzten du baimendu duzun bide batean. WAN-etik zuzenean egindako eskaerak behartu nahi zenuen bidea saihesten du. Lehena informazio-kontua da, bigarrena betearazpen-kontua, eta leku desberdinetan konpontzen dira. Biak hitz batean batzeak ez bata ez bestea konpontzen ez duen konponketa sortzen du.
WebRTC-k hau ikusgarriago egiten du oker bihurtu gabe, hautagai bat biltzea ez baita hura hautatzearen berdina.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showExekutatu bide-kontsulta baimendutako islatzaile-helbide bakoitzeko, fluxu horrek eramango duela espero duzun iturburuarekin, eta gero exekutatu berriro baztertutako barrutietarako, ordezko aukerak zer hautatzen duen ikusteko. Alderatu bi erantzunak idatzi duzun politikarekin. Zure asmoa ez zen moduan desberdintzen badira, konponketa-puntua aurkitu duzu arakatzailearen hautagai-zerrenda interpretatu beharrik gabe.