Tunneled standardrute på Cisco ASA: når ho faktisk gjeld

Ein eksternbrukar når ingenting forbi ASA-en medan den same tenaren svarar på ping frå det interne LAN-et. Tunnelen kjem opp, klienten får ei adresse frå poolen, og pakken går likevel ut gjennom standardruta til nettet eller forsvinn. Dette mønsteret tyder vanlegvis på at den dekrypterte trafikken ikkje fann ei eiga rute og fall gjennom til den vanlege standardruta. Rettinga er ikkje ei ny NAT-regel; ho er den tunneled standardruta.

Start med symptomet, ikkje konfigurasjonen

Sjå kvar pakken går i staden for kvar du venta at han skulle gå. Eit opptak på den ytre grensesnittet under ei mislukka økt viser den dekrypterte pakken på veg mot ISP-porten med pooladressa framleis intakt, eller viser ingenting fordi oppslaget feila. Uansett er ikkje tunnelen problemet.

Tunnelen ser sunn ut i show vpn-sessiondb, og det er nettopp derfor folk held fram med å feilsøkje IKE.

Det som skil dette frå eit ACL-slepp er retninga. Eit ACL-slepp blir logga og telde, medan ei manglande rute gir ein oppslagsfeil utan samsvarande oppføring. Køyr show route for målet til klienten og les kva ASA-en faktisk valde, inkludert om ei standardrute vart vald og kva for ei.

Korleis tunneled-oppslaget skil seg

Ciscos rettleiar for statisk ruting på ASA 9.23 dokumenterer ei eiga standardrute for dekryptert VPN-trafikk som ikkje har noka statisk eller lærd rute. Nøkkelordet tunneled markerer den ruta, slik at ein dekryptert pakke kan falle tilbake til eit anna neste hopp enn det ASA-en brukar for eigen transport. Meir spesifikke ruter vinn framleis, og derfor kan ein klient nå 10.0.0.0/8 via den interne porten og miste alt anna.

Eit minimalt oppsett held to standardruter med ulike neste hopp. Den eine ber eigen trafikk til ASA-en, den andre ber dekryptert trafikk som ikkje har noka betre rute. Begge neste hoppa må framleis vere tilgjengelege frå grensesnittet du knyter dei til.

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

Viss begge standardrutene peikar på same neste hopp, endrar nøkkelordet ingenting og symptomet flyttar seg ikkje.

Avgrensningane som avgjer om det verkar

Den same rettleiaren tillèt berre éi tunneled standardrute og slår fast at ECMP ikkje er støtta for ho, så du kan ikkje lastbalansere den vegen. Han listar òg avgrensingar knytte til rutesporing, verifisering av returveg og enkelte inspeksjons- og administrasjonsflytar. Les dei opp mot utgåva du har installert før du designar rundt funksjonen. Eit design som ignorerer dei, feilar vanlegvis på éin bestemt stad i staden for overalt, og derfor verkar symptomet periodisk.

Verifisering av returveg er den som bit i asymmetriske design. Viss svaret skulle kome inn gjennom eit anna grensesnitt enn ASA-en ventar, blir pakken droppa før rutinga betyr noko. Rett opp topologien eller returvegen i staden for å slå av verifiseringa for å tvinge fram eit neste hopp.

Rutesporing er ei eiga felle: det spora objektet vaktar vanlegvis den vanlege standardruta, ikkje den tunneled.

Kva nøkkelordet ikkje gjer

Det vel ikkje kjeldeadressa ASA-en brukar for å byggje IKE. Det ytre tunnelendepunktet følgjer plattformas eige val av grensesnitt og kjelde, og den tunneled standardruta har ingen del i den avgjerda. Å endre ho reparerer ikkje ein phase 1 som har kjelde i feil adresse.

Det gjer heller ikkje neste hopp om til ein proxy. Viss målet ventar ei HTTP CONNECT-utveksling, gir det deg berre ein vert som ikkje rutar dei å sende rå IP-pakkar til ein proxyvert. Konfigurer heller proxy-mekanismen klienten støttar.

Og det lagar ikkje vidare videresending. Porten du peikar på treng framleis ei rute tilbake til VPN-poolen, pluss kjeldeomsetjing der designet krev det.

Stadfest vegen frå ende til ende

Når ruta er på plass, sjekk fire ting i rekkjefølgje: show route for eit mål poolen treng, eit opptak på grensesnittet mot det nye neste hoppet, eit opptak på sjølve porten, og ein returveg frå den porten til pooladressa. Dei to første beviser at ASA-en valde vegen, og dei to siste beviser at nokon svarar på han.

Viss porten svarar men klienten aldri ser eit svar, sjå på kjeldeomsetjinga og returruta før du rører rutetabellen igjen.

Noter kva utgåve du stadfesta på, fordi avgrensningslista er versjonsspesifikk og eit design som verkar på éi toglinje kan trenge ein annan veg på ei anna. Den notata lever lenger enn konfigurasjonsutdraget.