Cisco ASA tunneled standardrute: hvornår den faktisk gælder

En fjernadgangsbruger kan ikke nå noget bag ASA'en, mens den samme server svarer på ping fra det interne LAN. Tunnelen kommer op, klienten får en adresse fra poolen, og pakken forlader stadig via internetstandardruten eller forsvinder. Det mønster betyder normalt, at den dekrypterede trafik ikke fandt sin egen rute og faldt igennem til den almindelige standardrute. Rettelsen er ikke endnu en NAT-regel; det er den tunnelede standardrute.

Start med symptomet, ikke konfigurationen

Se, hvor pakken går hen, i stedet for hvor du forventede, den ville gå. En optagelse på det ydre interface under en mislykket session viser den dekrypterede pakke på vej mod ISP-gatewayen med pooladressen stadig intakt, eller viser ingenting, fordi opslaget mislykkedes. Uanset hvad er tunnelen ikke problemet.

Tunnelen ser sund ud i show vpn-sessiondb, og det er netop derfor, folk bliver ved med at fejlfinde IKE.

Det, der adskiller dette fra et ACL-drop, er retningen. Et ACL-drop logges og tælles, mens en manglende rute giver et mislykket opslag uden en matchende post. Kør show route for klientens destination og læs, hvad ASA'en faktisk valgte, herunder om en standardrute blev valgt, og hvilken.

Sådan adskiller det tunnelede opslag sig

Ciscos vejledning i statisk routing til ASA 9.23 dokumenterer en særskilt standardrute til dekrypteret VPN-trafik, der ikke har nogen statisk eller lært rute. Nøgleordet tunneled markerer den rute, så en dekrypteret pakke kan falde tilbage til et andet næste hop end det, ASA'en bruger til sin egen transport. Mere specifikke ruter vinder stadig, og derfor kan en klient nå 10.0.0.0/8 gennem den interne gateway og miste alt andet.

Et minimalt layout holder to standardruter med forskellige næste hop. Den ene bærer ASA'ens egen trafik, og den anden bærer dekrypteret trafik, der ikke har en bedre rute. Begge næste hop skal stadig kunne nås fra det interface, du knytter 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 standardruter peger på det samme næste hop, ændrer nøgleordet intet, og symptomet flytter sig ikke.

Begrænsningerne, der afgør, om det virker

Den samme vejledning tillader kun én tunneled standardrute og angiver, at ECMP ikke understøttes for den, så du kan ikke belastningsfordele den vej. Den opregner også begrænsninger vedrørende rutesporing, omvendt sti-kontrol og nogle inspektions- og styringsflows. Læs dem op mod din installerede version, før du designer omkring funktionen. Et design, der ignorerer dem, fejler normalt på ét bestemt sted i stedet for overalt, og derfor virker symptomet periodisk.

Kontrol af omvendt sti er den, der bider i asymmetriske designs. Hvis svaret ville ankomme via et andet interface, end ASA'en forventer, droppes pakken, før routing overhovedet bliver relevant. Ret topologien eller returvejen i stedet for at slå kontrollen fra for at tvinge et næste hop.

Rutesporing er en særskilt fælde: det sporede objekt beskytter normalt den almindelige standardrute, ikke den tunnelede.

Hvad nøgleordet ikke gør

Det vælger ikke den kildeaddresse, ASA'en bruger til at bygge IKE. Tunnelens ydre endepunkt følger platformens eget valg af interface og kilde, og den tunnelede standardrute har ingen andel i den beslutning. At ændre den reparerer ikke en phase 1, der stammer fra den forkerte adresse.

Det gør heller ikke det næste hop til en proxy. Hvis destinationen forventer en HTTP CONNECT-udveksling, giver det dig kun en vært, der ikke router dem, at sende rå IP-pakker til en proxy-vært. Konfigurer i stedet den proxy-mekanisme, klienten understøtter.

Og det skaber ikke videresendelse nedstrøms. Den gateway, du peger på, har stadig brug for en rute tilbage til VPN-poolen plus kildeoversættelse, hvor designet kræver det.

Verificér stien ende til ende

Når ruten er på plads, så tjek fire ting i rækkefølge: show route for en destination, poolen har brug for, en optagelse på interfacet mod det nye næste hop, en optagelse på selve gatewayen og en returvej fra den gateway til pooladressen. De første to beviser, at ASA'en valgte stien, og de sidste to beviser, at nogen svarer på den.

Hvis gatewayen svarer, men klienten aldrig ser et svar, så se på kildeoversættelsen og returruten, før du rører routingtabellen igen.

Notér den version, du validerede på, fordi begrænsningslisten er versionsspecifik, og et design, der virker på en toglinje, kan kræve en anden sti på en anden. Den note lever længere end konfigurationsuddraget.