Tunneled default route sa Cisco ASA: kailan talaga ito nalalapat

Ang user ng remote access ay walang naaabot sa kabila ng ASA habang ang parehong server ay sumasagot sa mga ping mula sa panloob na LAN. Bumangon ang tunnel, nakakuha ang client ng address mula sa pool, at lumalabas pa rin ang packet sa internet default o nawawala. Ang ganitong pattern ay karaniwang nangangahulugan na ang decrypted na traffic ay walang nahanap na sariling ruta at nahulog sa ordinaryong default. Ang pag-aayos ay hindi isa pang panuntunan ng NAT; ito ay ang tunneled default.

Magsimula sa sintomas, hindi sa config

Tingnan kung saan pumupunta ang packet, hindi kung saan mo inaasahan itong pumunta. Ang capture sa panlabas na interface habang may nabigong session ay nagpapakita ng decrypted na packet na patungo sa gateway ng ISP habang buo pa ang address ng pool, o wala talagang ipinapakita dahil nabigo ang paghahanap. Sa alinmang paraan, hindi ang tunnel ang problema.

Mukhang malusog ang tunnel sa show vpn-sessiondb, at iyon mismo ang dahilan kung bakit patuloy pa rin sa pag-debug ng IKE ang mga tao.

Ang naghihiwalay dito sa pagtatapon ng ACL ay ang direksyon. Ang pagtatapon ng ACL ay naka-log at binibilang, samantalang ang nawawalang ruta ay nagdudulot ng kabiguan sa paghahanap na walang katugmang entry. Patakbuhin ang show route para sa destinasyon ng client at basahin kung ano talaga ang pinili ng ASA, kabilang kung may napiling default at alin.

Paano naiiba ang tunneled na paghahanap

Ang gabay ng Cisco sa static routing sa ASA 9.23 ay nagdodokumento ng hiwalay na default para sa decrypted na VPN traffic na walang static o natutunang ruta. Minamarkahan ng tunneled keyword ang rutang iyon, kaya ang decrypted na packet ay maaaring mahulog sa ibang susunod na hop kaysa sa ginagamit ng ASA para sa sarili nitong transport. Nananalo pa rin ang mas tiyak na ruta, kaya nakakaabot ang client sa 10.0.0.0/8 sa pamamagitan ng panloob na gateway at nawawala ang lahat ng iba pa.

Ang pinakamaliit na layout ay nagpapanatili ng dalawang default na may magkaibang susunod na hop. Ang isa ay nagdadala ng sariling traffic ng ASA, ang isa ay nagdadala ng decrypted na traffic na walang mas magandang ruta. Dapat pa ring maabot ang dalawang susunod na hop mula sa interface na kinakabitan mo sa kanila.

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

Kung ang dalawang default ay tumuturo sa parehong susunod na hop, walang binabago ang keyword at hindi gagalaw ang sintomas.

Ang mga paghihigpit na nagpapasya kung gagana ito

Ang parehong gabay ay pinapayagan lamang ang isang tunneled default at sinasabing hindi sinusuportahan ang ECMP para dito, kaya hindi mo maaaring hatiin ang load sa rutang iyon. Naglilista rin ito ng mga paghihigpit tungkol sa pagsubaybay ng ruta, pagpapatunay ng reverse path, at ilang daloy ng inspeksyon at pamamahala. Basahin ang mga ito laban sa naka-install na release bago magdisenyo sa paligid ng feature. Ang disenyong hindi pinapansin ang mga ito ay karaniwang nabibigo sa isang partikular na lugar sa halip na sa lahat ng dako, at kaya mukhang pabago-bago ang sintomas.

Ang pagpapatunay ng reverse path ang kumakagat sa mga asymmetric na disenyo. Kung ang tugon ay darating sa ibang interface kaysa sa inaasahan ng ASA, itinatapon ang packet bago pa maging mahalaga ang routing. Ayusin ang topology o ang pabalik na ruta sa halip na patayin ang pagpapatunay para pilitin ang isang susunod na hop.

Ang pagsubaybay ng ruta ay hiwalay na bitag: ang sinusubaybayang object ay karaniwang nagbabantay sa ordinaryong default, hindi sa tunneled.

Ano ang hindi ginagawa ng keyword

Hindi nito pinipili ang source address na ginagamit ng ASA para bumuo ng IKE. Ang panlabas na dulo ng tunnel ay sumusunod sa sariling pagpili ng interface at source ng platform, at wala ang tunneled default sa desisyong iyon. Ang pagbabago nito ay hindi mag-aayos ng phase 1 na nagmumula sa maling address.

Hindi rin nito ginagawang proxy ang susunod na hop. Kung ang destinasyon ay umaasa sa palitan ng HTTP CONNECT, ang pagpapadala ng hilaw na IP packet sa proxy host ay nagbibigay lamang ng host na hindi nagro-ruta sa mga ito. I-configure sa halip ang mekanismong proxy na sinusuportahan ng client.

At hindi ito lumilikha ng downstream forwarding. Ang gateway na tinutukoy mo ay kailangan pa rin ng rutang pabalik sa VPN pool, kasama ang source translation kung saan ito hinihingi ng disenyo.

I-verify ang landas mula simula hanggang dulo

Kapag nakalagay na ang ruta, suriin ang apat na bagay nang sunod-sunod: show route para sa destinasyong kailangan ng pool, capture sa interface patungo sa bagong susunod na hop, capture sa gateway mismo, at pabalik na landas mula sa gateway na iyon patungo sa address ng pool. Ang unang dalawa ay nagpapatunay na pinili ng ASA ang landas, at ang huling dalawa ay nagpapatunay na may sumasagot doon.

Kung sumasagot ang gateway pero hindi kailanman nakikita ng client ang tugon, tingnan ang source translation at ang pabalik na ruta bago muling hawakan ang talahanayan ng ruta.

Itala ang release na ginamitan mo ng validation, dahil ang listahan ng paghihigpit ay partikular sa bersyon at ang disenyong gumagana sa isang train ay maaaring mangailangan ng ibang landas sa iba. Ang talaang iyon ay mas matagal kaysa sa snippet ng config.