Web zerbitzaria desagertu egiten da VPN bezeroa konektatzean
Eskaerak LANera iristen dira eta erantzunak tunelaren bidez irteten dira. Aukeratu baztertutako ibilbidea, politikaren araberako bideratzea edo itzulpena ostalariak egin behar duenaren arabera.
VPN bezeroa konektatzen den unean desagertzen den zerbitzua ez da normalean blokeatzen, interfaze okerretik erantzuten baitu. Eskaera sare-txartel fisikora iristen da, daemonak erantzun bat idazten du, eta bideratze-taulak erantzun hori tunelari ematen dio, tunelak lehenetsitako ibilbidea hartu baitu. Urruneko bezeroak ez du inoiz ireki duen konexio baten erantzunik ikusten, beraz itxaron egiten du eta gero denbora-muga bat jakinarazten du. Suhormaren erregelarik ez du parte hartzen segida horretan inon.
Sintoma: eskaerak barrura, erantzunak ate okerretik kanpora
Seinalea ostalarian beste guztia funtzionatzen duen bitartean huts egiten duen sarrera-konexioa da. Beste arrasto bat LANetik irisgarria baina internetetik ez den ostalaria da, edo tunela berriz konektatu arte funtzionatzen duena eta gero gelditzen dena. Kasu bakoitzean aurrerako noranzkoak ondo jokatu zuen eta atzerakoak ez, eta horrek bideratze-asimetria adierazten du, ez politika.
Egiaztatu erantzuna nora doan begiratuz, ez eskaera nola iristen den begiratuz.
Kapturatu aldi berean interfaze fisikoan eta tunel-gailuan. Eskaera interfaze fisikoan agertzen bada eta erantzuna tunelean, diagnostikoa amaituta dago. Inon agertzen ez den erantzunak zerbitzuak konexioa inoiz onartu ez zuela esan nahi du, eta hori arrazoi desberdineko ikerketa bereizia da.
Bi lehenetsitako ibilbide eta bideratze-erabaki bat
Lehenetsitako ibilbidea instalatzen duen bezeroak LANeko atebidearena baino metrika hobea duen bigarren sarrera bat gehitzen du. Zenbait bezerok erdi-mailako bi ibilbide instalatzen dituzte horren ordez, espazio bera zehatzago estaltzen dutenak eta bilaketak modu berean irabazten dituztenak. Bi tekniketako edozeinek irteerako pakete arruntei tunelaren interfazea aukeratzen uzten die.
Aukera hori helmugaren arabera bakarrik egiten da. Kernelak ez du galdetzen pakete bat nondik etorri den, politika-erregela batek hala agintzen ez badu. Beraz, bezeroaren helbide publikorako erantzuna tunelari ematen zaio, eta haren urruneko muturrak jabe ez den iturburu-helbidea duen pakete bat jasotzen du eta baztertu edo leku alferrikako batera birbidaltzen du. Linuxen, atzerako bidearen iragazketa zorrotzak jatorrizko eskaera bota dezake zure zerbitzuak ikusi aurretik ere, eta kanpotik berdin ikusten da. Bi sintomak sarrerako fluxu baten eta haren erantzunaren arteko lotura faltatik datoz.
Tunelak behar bezala jokatzen du uneoro. Lehenetsitako ibilbidea eramateko esan zioten eta hain zuzen ere hori egiten du.
Konpondu itzulera-bidea tunela hautsi gabe
Hiru konponketa-forma iraunkor daude, eta aukeraketa ostalariaren beraren trafikoaren zenbat tunelean barruan geratu behar duen araberakoa da. Zerbitzuaren helmuga edo ataka baztertzea aldaketarik txikiena da. Iturburuaren edo markaren araberako politika-bideratzea da zehatzena. Iturburu-itzulpena da zakarrena eta bi urte geroago azaltzeko errazena.
Aukeratu ostalariak egin behar duenaren arabera, ez aurkitutako lehenengo zatiaren arabera.
Helmuga bat baztertzea helbide publiko egonkorra duen zerbitzu baterako egokia da, eta daemona helbide fisikoari lotzea helbide guztiei lotu beharrean bazterketa hori seguruagoa egiten du. Iturburuaren arabera taula bat aukeratzen duen politika-erregelak ostalariaren beraren konexioak tunelean mantentzen ditu, zerbitzuaren erantzunak WAN atebidetik itzultzen dituen bitartean. Erantzunak WAN interfazean maskaratzeak bide berera iristen da zerbitzuaren erregistroetatik bezeroaren helbidea ezkutatzeko kostuarekin. Lehenetsitako ibilbidearen aldaketa berehalakoa diagnostikoa da eta ez konfigurazioa, bezeroak berriz konektatzean ibilbideak berridazten baititu.
ip rule show
ip route get 203.0.113.9 from 192.0.2.44Ostalariak atzean duen LAN baterako ere bideratzen duenean
Jauzi bat harago, asimetria bera itzultzen da zati mugikor gehiagorekin. Trafikoa internetetik iristen da bideratzailera, barne-gailu batera birbidaltzen da, eta gailu horren itzulera-bide bakarra tunela da, beraz erantzuna jatorrizko bezeroarengana iristen da hornitzailearen beraren helbidetik. Ondoren, konexioen jarraipenak hasiera ikusi ez zuen fluxu baten erantzuna aurkitzen du, eta baztertu egiten du. Bitartean, bezeroak ez du ezer ikusten.
Bi aldaketak konpontzen dute: helmugaren itzulpena sarrera-konexioa barne-gailura irits dadin, eta iturburuaren itzulpena gailu horren erantzuna bideratzailearenetik datorrela dirudien.
Bideratzaileen firmwarean ohiko adierazpena ataka-birbidaltzea WAN aldean iltzatzen duen politika-erregela da, bideratzailearen beraren trafikoak tunelean bidaiatzen duen bitartean. Iturburu-itzulpenik gabe, erantzun hori kanpoko bezeroari zuzenduta dago eta barne-gailuak ez du hartarako ibilbiderik. Probatu hiru gauza bereiz, arrazoi desberdinengatik huts egiten baitute: kanpotik iristen den konexioa, ostalariak berak hasten duena eta izen-bilaketa bat.