Tunneled standardrute på Cisco ASA: når den faktisk gjelder

En eksternbruker når ingenting forbi ASA-en mens den samme serveren svarer på ping fra det interne LAN-et. Tunnelen kommer opp, klienten får en adresse fra poolen, og pakken forlater likevel nettets standardrute eller forsvinner. Dette mønsteret betyr vanligvis at den dekrypterte trafikken ikke fant en egen rute og falt gjennom til den vanlige standardruten. Rettelsen er ikke en ny NAT-regel; den er den tunnelede standardruten.

Start med symptomet, ikke konfigurasjonen

Se hvor pakken går i stedet for hvor du forventet at den skulle gå. Et opptak på det ytre grensesnittet under en mislykket økt viser den dekrypterte pakken på vei mot ISP-porten med pooladressen fortsatt intakt, eller viser ingenting fordi oppslaget feilet. Uansett er ikke tunnelen problemet.

Tunnelen ser sunn ut i show vpn-sessiondb, og det er nettopp derfor folk fortsetter å feilsøke IKE.

Det som skiller dette fra et ACL-slipp er retningen. Et ACL-slipp logges og telles, mens en manglende rute gir et oppslagsfeil uten samsvarende oppføring. Kjør show route for klientens mål og les hva ASA-en faktisk valgte, inkludert om en standardrute ble valgt og hvilken.

Hvordan det tunnelede oppslaget skiller seg

Ciscos veiledning for statisk ruting på ASA 9.23 dokumenterer en egen standardrute for dekryptert VPN-trafikk som ikke har noen statisk eller lært rute. Nøkkelordet tunneled markerer den ruten, slik at en dekryptert pakke kan falle tilbake til et annet neste hopp enn det ASA-en bruker for egen transport. Mer spesifikke ruter vinner fortsatt, og derfor kan en klient nå 10.0.0.0/8 via den interne porten og miste alt annet.

En minimal oppsett holder to standardruter med ulike neste hopp. Den ene bærer ASA-ens egen trafikk, den andre bærer dekryptert trafikk som ikke har noen bedre rute. Begge neste hopp må fortsatt være tilgjengelige fra grensesnittet du kobler dem 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

Hvis begge standardrutene peker på samme neste hopp, endrer nøkkelordet ingenting og symptomet flytter seg ikke.

Begrensningene som avgjør om det virker

Den samme veiledningen tillater bare én tunneled standardrute og slår fast at ECMP ikke støttes for den, så du kan ikke lastebalansere den veien. Den lister også begrensninger knyttet til rutesporing, verifisering av returvei og enkelte inspeksjons- og administrasjonsflyter. Les dem opp mot utgivelsen du har installert før du designer rundt funksjonen. Et design som ignorerer dem, feiler vanligvis på ett bestemt sted i stedet for overalt, og derfor virker symptomet periodisk.

Verifisering av returvei er den som biter i asymmetriske design. Hvis svaret skulle komme inn gjennom et annet grensesnitt enn ASA-en forventer, blir pakken droppet før rutingen betyr noe. Fiks topologien eller returveien i stedet for å slå av verifiseringen for å tvinge fram et neste hopp.

Rutesporing er en egen felle: det sporede objektet vokter vanligvis den vanlige standardruten, ikke den tunnelede.

Hva nøkkelordet ikke gjør

Det velger ikke kildeadressen ASA-en bruker for å bygge IKE. Det ytre tunnelendepunktet følger plattformens eget valg av grensesnitt og kilde, og den tunnelede standardruten har ingen del i den avgjørelsen. Å endre den reparerer ikke en phase 1 som har kilde i feil adresse.

Det gjør heller ikke neste hopp om til en proxy. Hvis målet forventer en HTTP CONNECT-utveksling, gir det deg bare en vert som ikke ruter dem å sende rå IP-pakker til en proxyvert. Konfigurer heller proxy-mekanismen klienten støtter.

Og det lager ikke videre videresending. Porten du peker på trenger fortsatt en rute tilbake til VPN-poolen, pluss kildeoversettelse der designet krever det.

Verifiser veien fra ende til ende

Når ruten er på plass, sjekk fire ting i rekkefølge: show route for et mål poolen trenger, et opptak på grensesnittet mot det nye neste hoppet, et opptak på selve porten, og en returvei fra den porten til pooladressen. De to første beviser at ASA-en valgte veien, og de to siste beviser at noen svarer på den.

Hvis porten svarer men klienten aldri ser et svar, se på kildeoversettelsen og returruten før du rører rutetabellen igjen.

Noter hvilken utgivelse du verifiserte på, fordi begrensningslisten er versjonsspesifikk og et design som virker på én toglinje kan trenge en annen vei på en annen. Den noten lever lenger enn konfigurasjonsutdraget.