Cisco ASA-ko tunel bidezko bide lehenetsia: noiz aplikatzen den benetan

Urrutiko sarbideko erabiltzaile batek ezin du ASAren atzeko ezerera iritsi, zerbitzari berak barneko LANetik ping-ari erantzuten dion bitartean. Tunela altxatzen da, bezeroak pool-etik helbide bat jasotzen du, eta paketeak oraindik interneteko bide lehenetsitik irteten du edo desagertu egiten da. Eredu horrek normalean esan nahi du deszifratutako trafikoak ez zuela bere bidea aurkitu eta bide lehenetsi arruntera erori zela. Konponbidea ez da NAT arau bat gehiago; tunel bidezko bide lehenetsia da.

Hasi sintomarekin, ez konfigurazioarekin

Begiratu paketea nora doan, nora joango zela espero zenuenaren ordez. Kanpoko interfazean egindako harrapaketa batek saio huts baten zehar pakete deszifratua ISPren atebiderantz erakusten du pool-eko helbidea oraindik ukitu gabe, edo ez du ezer erakusten bilaketa huts egin duelako. Edozein kasutan tunela ez da arazoa.

Tunela osasuntsu agertzen da show vpn-sessiondb-en, eta horregatik jarraitzen dute pertsonek IKE arazten.

Hau ACL jaitsiera batetik bereizten duena norabidea da. ACL jaitsiera erregistratu eta zenbatzen da, eta falta den bide batek bat datorren sarrerarik gabeko bilaketa hutsegitea sortzen du. Exekutatu show route bezeroaren helmugarako eta irakurri zer hautatu zuen ASA-k benetan, bide lehenetsi bat hautatu zen eta zein barne.

Nola desberdintzen den tunel bidezko bilaketa

Ciscoren ASA 9.23 bideratze estatikoaren gida dokumentuak bide lehenetsi bereizi bat jasotzen du bide estatiko edo ikasirik ez duen VPN trafiko deszifratuarentzat. tunneled gako-hitzak bide hori markatzen du, beraz pakete deszifratu bat hurrengo jauzi desberdin batera eror daiteke ASA-k bere garraiorako erabiltzen duenetik. Bide zehatzagoek irabazten jarraitzen dute, eta horregatik bezero batek 10.0.0.0/8-ra irits daiteke barneko atebidearen bidez eta beste guztia galdu.

Diseinu minimo batek bi bide lehenetsi mantentzen ditu hurrengo jauzi desberdinekin. Batek ASA-ren beraren trafikoa darama, eta besteak bide hoberik ez duen trafiko deszifratua. Bi hurrengo jauziek oraindik iristeko modukoak izan behar dute haiek konektatzen dituzun interfazetik.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Bi bide lehenetsiek hurrengo jauzi berbera adierazten badute, gako-hitzak ez du ezer aldatzen eta sintomak ez du mugituko.

Funtzionatuko duen ala ez erabakitzen duten murrizketak

Gida berak tunel bidezko bide lehenetsi bakarra baimentzen du eta ECMP ez dela onartzen adierazten du, beraz ezin duzu bide hori karga-banatu. Gainera, bideen jarraipenari, atzera-bidearen egiaztapenari eta ikuskapen zein kudeaketa fluxu batzuei buruzko murrizketak zerrendatzen ditu. Irakurri horiek instalatutako bertsioaren arabera funtzioaren inguruan diseinatu aurretik. Horiek alde batera uzten dituen diseinu batek leku zehatz batean huts egiten du normalean, ez leku guztietan, eta horregatik sintomak tartekakoa dirudi.

Atzera-bidearen egiaztapena da diseinu asimetrikoetan hozka egiten duena. Erantzuna ASA-k espero duen interfaze desberdin batetik iritsiko balitz, paketea baztertu egiten da bideratzeak garrantzirik izan aurretik. Konpondu topologia edo itzulera-bidea, egiaztapena desaktibatu beharrean hurrengo jauzi bat behartzeko.

Bideen jarraipena tranpa bereizia da: jarraitutako objektuak normalean bide lehenetsi arrunta zaintzen du, ez tunel bidezkoa.

Zer ez duen egiten gako-hitzak

Ez du ASA-k IKE eraikitzeko erabiltzen duen iturburu-helbidea hautatzen. Tunelaren kanpoko muturrak plataformaren interfaze eta iturburu hautaketa propioa jarraitzen du, eta tunel bidezko bide lehenetsiak ez du parte hartzen erabaki horretan. Hura aldatzeak ez du konponduko helbide okerretik datorren phase 1 bat.

Ez du hurrengo jauzia proxy bihurtzen ere. Helmugak HTTP CONNECT trukaketa espero badu, IP pakete gordinak proxy ostalari batera bidaltzeak ez dizu ematen haiek bideratzen ez dituen ostalari bat besterik. Konfiguratu bezeroak onartzen duen proxy mekanismoa horren ordez.

Eta ez du beherako bidalketarik sortzen. Erakusten duzun atebideak oraindik VPN pool-era itzultzeko bide bat behar du, eta iturburuaren itzulpena diseinuak eskatzen duen lekuan.

Egiaztatu bidea hasieratik amaierara

Bidea ezarri ondoren, egiaztatu lau gauza ordenan: show route pool-ak behar duen helmuga baterako, harrapaketa hurrengo jauzi berrirako interfazean, harrapaketa atebidean bertan, eta itzulera-bidea atebide horretatik pool-eko helbidera. Lehen biek ASA-k bidea hautatu zuela frogatzen dute, eta azken biek norbait han erantzuten ari dela.

Atebideak erantzuten badu baina bezeroak inoiz ez badu erantzunik ikusten, begiratu iturburuaren itzulpena eta erantzun-bidea bideratze-taula berriro ukitu aurretik.

Idatzi balioztatu zenuen bertsioa, murrizketen zerrenda bertsioaren araberakoa baita eta tren batean funtzionatzen duen diseinuak beste batean bide desberdina behar dezakeelako. Ohar hori konfigurazio-zatiak baino gehiago bizi da.