Zer agertzen du STUN erantzun batek VPN bideratzailean doanean
Bideratzailearen tunel helbidea ez da nabigatzailearen helbide lokala. Jarraitu nola bideratzen eta itzultzen den eskaera bakoitza, islatzaile batek zer jakinarazten duen irakurri aurretik.
Tunela bideratzailean dagoenean, nabigatzailea daraman makinak ez du tunel interfazerik batere. Galdetu makina horri bere helbide lokalak eta LAN helbide pribatu bat eta begizta bat lortuko dituzu, VPN helbide baten antzik duen ezer ez. Hala ere, beste aldeko STUN zerbitzari batek oraindik bideari buruzko zerbait esanguratsua jakinaraz dezake, eta jakinarazten duena erabat menpe dago eskaera zehatz hori nola bideratu eta itzuli zen.
Hori da mantsoago eman beharreko zatia. «Nabigatzaileak ez du VPN helbidea bere» interfazeen inguruko galdera bati erantzuten dio, islatutako helbidea, berriz, itzulketaren bidezko bide bati buruzko erantzuna da. Biak nahasteak agerian uzteari buruzko ondorio seguruak sortzen ditu, frogek sostengatzen ez dituztenak.
Bi gailu, bi interfaze multzo
Bideratzailean oinarritutako konfigurazioan tunela bideratzailean amaitzen da eta LAN bezeroak trafiko arrunta bidaltzen dio bere ate lehenetsiari. Bezeroaren interfaze zerrenda laburra izaten da: helbide pribatu bat, agian beste bat beste sare baterako, eta begizta. Arriskua ez da horietako bat tunel helbidea izatea; arriskua da eskaera zuk aukeratu ez zenuen bide batetik irtetea.
Galdetu bezeroari helmuga jakin batek zein bide hartuko lukeen, zein interfaze dauden galdetu beharrean. Erantzunak ate bat eta nukleoak erabiliko lukeen iturburu helbidea izendatzen ditu, eta hori jada helbide inbentario edozein baino informatiboagoa da.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsDokumentazio barrutiak proba helmuga onak dira, inoiz ez baitira benetako zerbitzu batean ebazten. Alderatu bezeroak dioena bideratzaileak dioenarekin, eta hartu bat ez datozen edozein froga gisa politikan oinarritutako bideratzeak, tunel zatituaren arau batek edo bigarren bide lehenetsi batek kontuan hartu ez duzun zerbait egiten duela.
Binding erantzunak zer esan dezakeen
RFC 8489 arauak Binding eskaera eta erantzuna definitzen ditu, non zerbitzariak eskaera horretarako behatu zuen iturburu garraio helbidea jakinarazten duen. Une bateko bosteko bati buruzko adierazpena da, ez bezeroaren interfazeen errolda. Beraz, interesgarria den guztia bezeroaren eta behaketa puntuaren artean gertatzen da.
Hutsune hori bideratzeak eta itzulketak betetzen dute. Irteerako trafikoari iturburu NAT egiten dion bideratzaileak bezeroaren iturburu pribatua ordezkatzen du bere helbidearekin irteera interfazean. Interfaze hori tunela bada, islatzaileak tunel helbidea ikusten du. Paketea tunelaren kanpoan geratu bada, islatzaileak WAN itzulketak sortu duena ikusten du. Bezero bera, islatzaile bera, erantzun desberdina.
Antzekoak diruditen hiru kasu, eta ez direnak
Ezagutza erabilgarria ez da publikoaren eta pribatuaren artekoa, baizik eta zein betearazte puntuk landu zuen paketea. Landu kasuak bideratzailearen taulak irekita, nabigatzaile bakar batek hirurak sor ditzakeelako idatzi zenuela ahaztu zenuen arau baten arabera.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Bigarren kasuak soilik hausten du trafiko jakin bat inoiz zuzenean ez ateratzeko baldintza, eta lehenengoak eta hirugarrenak soilik agertzen dute tunel aldeko identifikatzaile bat. Hiru errenkadetatik batek ere ez du hornitzaile zehatz baten portaerari buruzko aldarrikapenik: islatzaile pribatu bat iristeko modukoa den ala ez bideratzetik, beste muturreko baimendutako IP helbideetatik eta bi muturretako suebaki politikatik baitago.
Hornitzaile berean kontua izateak ez du horietako ezer frogatzen. Gogoratzekoa da, halaber, bideratutako eskaera batek bezeroaren LAN iturburua gorde dezakeela ezerk itzultzen ez badu, beraz iturburu eremua topologia diagramatik suposatu beharrean jarraitu behar da.
Biltzea ez da hautatzea
WebRTCk probatzeko hautagai helbideak biltzen ditu, eta diagnostiko zerrenda batean ageri den hautagai batek baliteke inoiz multimedia ez garraiatzea. Zerrenda «hau da beste muturrekoak ikasi zuena» gisa irakurtzeak gehiegi balioesten ditu frogak. Hautatutako bikotea da sesioa benetan garraiatu zuena, eta beste eremu batean dago.
HTTPS irteera egiaztatzaile batek beste galdera bati erantzuten dio: web zerbitzari batek eskaera horretarako ikusi zuen iturburu helbidea. Egiaztapen gurutzatu erabilgarria da, hain zuzen, UDP islatzaile batek ez bezalako protokoloa eta askotan beste helmuga bat erabiltzen dituelako, eta bien arteko desadostasunak bideratze arau batera eramaten du normalean, ez akats batera.
Erabaki politika, eta gero irakurri erantzuna
Idatzi asmoa probatu aurretik: zein trafikok erabili behar duen tunela, zein atera daitekeen zuzenean, zein helbide familia dauden irismenean eta zer gertatu behar den tunela behera dagoenean. Oinarri hori gabe behaketa guztiak anbiguoak dira, ezin duelako bereizi ihes bat nahita baimendu zenuen bide batetik.
Ondoren galdetu galdera bat aldiko. Helmuga honek zein bide hartzen du. Islatzaile honek zein helbide jakinarazten du. Sesioak zein hautagai bikote hautatu zuen. Eutsi erantzunak politikaren ondoan eta eman data, firmware eguneraketa batek jokabide lehenetsia isilean alda baitezake iazko ondorioa baliogabetuz.
Bideratzailea betearazte puntu sendoa da oraindik, ikusten baitu bezero batek bere burua berrikonfiguratu gabe saihestu ezin duen trafikoa. Ez da promesa aplikazio protokolo bakoitzeko eremu bakoitzak ezer agertzen ez duenik, eta ez du ordezkatzen baimendu nahi zenituen bideak idaztea.