Gunez guneko VPNak norabide bakarrean funtzionatzen du: bi hutsegite desberdin
Inoiz itzultzen ez den erantzuna eta ukatu zuten konexioa hutsegite desberdinak dira. Konparatu politika, bideratzea eta zerbitzariak benetan ikusten duen iturburu-helbidea.
A guneak B lortzen du, B ezin da A-ra iritsi, eta tunela ondo ikusten da bi norabideetan. Tunelari heldu aurretik, erabaki zein hutsegite duzun benetan. B-n hasi eta ukatzen den konexio berri batek eta A-n hasitako konexioari inoiz iristen ez zaion erantzun batek antzeko kexak eta guztiz desberdinak diren diagnostikoak sortzen ditu. Bata bidean politikaren edo ibilbidearen arazoa da; bestea jada baimenduta zegoen trafikoaren itzulera-bidearen edo egoeraren arazoa.
Bereizketak erabakitzen du zein komandok merezi duen exekutatzeak.
Itxura bereko bi hutsegite
Lehen kasuan, B-ren ostalariak SYN bat bidaltzen dio A-ri, eta ez da ezer itzultzen. Bigarrenean, A-ren ostalariak saio bat arrakastaz irekitzen du eta erantzuna itzultzeko bidean desagertzen da. Bi erabiltzaileek lotura norabide bakarrekoa dela diote, eta biek desagertu zen pakete bat deskribatzen dute, beraz deskribapenak berak ezin ditu bereizi.
Galdetu zein aldek hasi zuen huts egin zuen saiakera. Gertaera bakar horrek kausa posibleen erdia kentzen du.
Ondoren egiaztatu testak ostalari eta zerbitzu berak erabili zituela hasieratik amaierara. Alde batetik ping batek eta bestetik fitxategi partekatu baten konexioak bi gauza desberdin probatzen dituzte, eta atearen diagnostiko batek erabiltzaileen trafikorik inork erabiltzen ez duen tunel-helbidea aukera dezake.
Lehen kasua: itzulera-bidea falta da
Beste ate lehenetsi baten bidez erantzuten duen urruneko zerbitzari batek eskaera jaso eta erantzuna beste nonbait bidera dezake. Egoera jarraitzen duten suebakiek erantzun asimetrikoa baztertzen dute orduan, ez baitator bat ezarritako fluxu batekin, eta hori inoiz funtzionatu ez zuen norabide baten antza du zehazki. Itzulpenak beste bertsio bat gehitzen du: helmugak itzulitako iturburu bat ikusten du eta hari erantzuten dio, beraz jatorrizko helbiderako idatzitako arauak ez du inoiz bat egiten.
Egiaztatu helmugak itzulpenaren ondoren benetan ikusten duen helbidea, eta helbide horren itzulera-ibilbidea, jatorrizko azpisarearena izan beharrean.
Bigarren kasua: politikak ez zuen inoiz baimendu
Aurkako kasua itxuraz baino errazagoa eta ohikoagoa da: bulego batek zerbitzu zentral bat kontsumitu behar du eta ez du inoiz zentrora konexiorik hasi behar. Asimetria hori sarbide-erabaki nahita hartua da, eta tunelak diseinatu bezala funtzionatzen du. Irakurri sarbide-politika tunelaren edozein ezarpen aldatu aurretik. Dokumentuak, ez paketeen kapturak, adierazten du zein norabide zen asmoa. Kapturak gertatu zena erakuts dezake soilik, ez zer zegoen baimenduta.
Benetan beharrezkoa bada bi norabideetan hastea, gehitu zerbitzu zehatzaren baimena plataformaren arau-multzo onartuaren bidez. Aplikazio bat konpontzeko azpisare guztiak elkarrekiko fidagarri egiteak baldintza estua baimen zabal bihurtzen du, eta truke hori gutxitan berrikusten da geroago.
Konparatu aurretik eta ondoren ostalari beretan
Begiratu saiakera beraren bi muturrak, ez bi saiakera bereizi. Hartu kaptura hasi den ostalariaren atean eta helmugan, eta gero konparatu zer sartu zen, zer irten zen eta zer helbide ikusi zuen urruneko aldeak.
tcpdump -ni any host 10.20.30.40 and port 445 conntrack -L | grep 10.20.30.40 ip route get 10.20.30.40 swanctl --list-sas
Helmugako kapturak eskaera ustekabeko iturburu-helbide batekin erakusten badu, erantzuna itzulpenean edo bideratzean dago, ez tunelaren segurtasun-politikan. Helmugak eskaerarik erakusten ez badu, paketeak ez zuen inoiz bide babestua zeharkatu.
Zuzentze baten ondoren, errepikatu test berdina ostalari beretik eta egiaztatu erlazionatu gabeko sarbidea oraindik ukatuta dagoela. Tunelaren “established” egoerak ez du bi ondorioetako bat ere bere horretan sostengatzen.