Rruga e paracaktuar tunneled në Cisco ASA: kur zbatohet vërtet

Një përdorues i aksesit në distancë nuk arrin asgjë përtej ASA-s, ndërsa i njëjti server përgjigjet ndaj ping-ve nga LAN-i i brendshëm. Tuneli ngrihet, klienti merr një adresë nga pool-i, dhe pakoja prapë del nga rruga e paracaktuar e internetit ose zhduket. Ky model zakonisht do të thotë që trafiku i dekriptuar nuk gjeti rrugë të vetën dhe ra në rrugën e paracaktuar të zakonshme. Rregullimi nuk është një rregull tjetër NAT; rregullimi është rruga e paracaktuar tunneled.

Filloni me simptomën, jo me konfigurimin

Shikoni ku shkon pakoja, jo ku prisnit të shkonte. Një kapje në ndërfaqen e jashtme gjatë një sesioni të dështuar tregon pakon e dekriptuar duke u nisur drejt gateway-it të ISP-së me adresën e pool-it ende të paprekur, ose nuk tregon asgjë sepse kërkimi dështoi. Në të dyja rastet tuneli nuk është problemi.

Tuneli duket i shëndetshëm në show vpn-sessiondb, dhe pikërisht për këtë njerëzit vazhdojnë të debuginë IKE.

Ajo që e dallon këtë nga një hedhje ACL është drejtimi. Një hedhje ACL regjistrohet dhe numërohet, ndërsa një rrugë që mungon prodhon një dështim kërkimi pa asnjë zë përputhës. Ekzekutoni show route për destinacionin e klientit dhe lexoni çfarë zgjodhi vërtet ASA, duke përfshirë nëse u zgjodh një rrugë e paracaktuar dhe cila.

Si ndryshon kërkimi tunneled

Udhëzuesi i Cisco për routing statik në ASA 9.23 dokumenton një rrugë të paracaktuar të veçantë për trafikun VPN të dekriptuar që nuk ka rrugë statike ose të mësuar. Fjalëkyçi tunneled shënon atë rrugë, kështu që një pako e dekriptuar mund të bjerë në një hop tjetër pasues nga ai që ASA përdor për transportin e vet. Rrugët më specifike fitojnë prapë, dhe për këtë arsye një klient mund të arrijë 10.0.0.0/8 përmes gateway-it të brendshëm dhe të humbasë gjithçka tjetër.

Një plan minimal mban dy rrugë të paracaktuara me hop-e pasuese të ndryshme. Njëra mbart trafikun e vetë ASA-s, tjetra mbart trafikun e dekriptuar që nuk ka rrugë më të mirë. Të dy hop-et pasuese prapë duhet të jenë të arritshme nga ndërfaqja ku i lidhni.

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

Nëse të dyja rrugët e paracaktuara tregojnë të njëjtin hop pasues, fjalëkyçi nuk ndryshon asgjë dhe simptoma nuk do të lëvizë.

Kufizimet që vendosin nëse funksionon

I njëjti udhëzues lejon vetëm një rrugë të paracaktuar tunneled dhe thotë se ECMP nuk mbështetet për të, kështu që nuk mund të shpërndani ngarkesën në atë rrugë. Ai liston gjithashtu kufizime që lidhen me gjurmimin e rrugëve, verifikimin e rrugës së kthimit dhe disa flukse inspektimi dhe menaxhimi. Lexojini ato kundrejt versionit tuaj të instaluar përpara se të projektoni rreth këtij funksioni. Një projekt që i injoron ato zakonisht dështon në një vend të caktuar dhe jo kudo, dhe për këtë arsye simptoma duket e ndërprerë.

Verifikimi i rrugës së kthimit është ai që kafshon në projektet asimetrike. Nëse përgjigja do të vinte përmes një ndërfaqeje të ndryshme nga ajo që pret ASA, pakoja hidhet para se routing-u të ketë rëndësi. Rregulloni topologjinë ose rrugën e kthimit në vend që të çaktivizoni verifikimin për të imponuar një hop pasues.

Gjurmimi i rrugëve është një kurth i veçantë: objekti i gjurmuar zakonisht mbron rrugën e paracaktuar të zakonshme, jo atë tunneled.

Çfarë nuk bën fjalëkyçi

Ai nuk zgjedh adresën burimore që ASA përdor për të ndërtuar IKE. Pika e skajshme e jashtme e tunelit ndjek zgjedhjen e ndërfaqes dhe të burimit të vetë platformës, dhe rruga e paracaktuar tunneled nuk ka pjesë në atë vendim. Ndryshimi i saj nuk do të rregullojë një phase 1 që niset nga adresa e gabuar.

As nuk e shndërron hop-in pasues në proxy. Nëse destinacioni pret një shkëmbim HTTP CONNECT, dërgimi i pakove IP të papërpunuara te një host proxy ju jep vetëm një host që nuk po i ruton ato. Në vend të kësaj konfiguroni mekanizmin e proxy-t që klienti mbështet.

Dhe nuk krijon përcjellje në rrjedhën e poshtme. Gateway-it ku tregoni prapë i duhet një rrugë kthimi drejt pool-it të VPN, plus përkthim i burimit aty ku projekti e kërkon.

Verifikoni rrugën nga fillimi në fund

Pasi rruga të jetë vendosur, kontrolloni katër gjëra me radhë: show route për një destinacion që i duhet pool-it, një kapje në ndërfaqen drejt hop-it të ri pasues, një kapje në vetë gateway-in dhe një rrugë kthimi nga ai gateway te adresa e pool-it. Dy të parat vërtetojnë që ASA zgjodhi atë rrugë, dhe dy të fundit vërtetojnë që dikush përgjigjet në të.

Nëse gateway-i përgjigjet por klienti nuk sheh kurrë përgjigje, shikoni përkthimin e burimit dhe rrugën e kthimit përpara se të prekni përsëri tabelën e rrugëve.

Regjistroni versionin në të cilin verifikuat, sepse lista e kufizimeve varet nga versioni dhe një projekt që funksionon në një tren mund të ketë nevojë për një rrugë tjetër në një tjetër. Ai shënim jeton më gjatë se copëza e konfigurimit.