ASA hairpin: internettutgang eller site-til-site-VPN-ben?

To fjernkoblingsbrukere bak samme ASA kan sende trafikk ut av samme eksterne grensesnitt og få helt forskjellig behandling. Den ene skal til et offentlig nettsted, så pakken trenger kildetranslasjon og en internett-rute. Den andre skal til en server bak en site-til-site-tunnel som også terminerer på det grensesnittet, så pakken trenger identitet, en samsvarende tunnel-selector og en returvei til klientpulen. Tillatelse for samme grensesnitt er en forutsetning for begge og en løsning for ingen av dem.

To ben, ett grensesnitt

Bestem hvilket ben du bygger før du skriver en NAT-regel, fordi reglene ikke er utskiftbare. Ben A er klient til internett: puljeadresse inn, oversatt offentlig adresse ut, tilbake gjennom samme grensesnitt. Ben B er klient til et privat prefiks på den andre siden av en annen IPsec-peer: puljeadressen bevares, krypteres på nytt og leveres til en peer som må vite hvordan den svarer puljen.

Det begge trenger først, er tillatelsen for samme grensesnitt. Uten den nekter ASA-en å videresende en pakke ut av grensesnittet den kom inn på, og feilen ser ut som et ruteproblem i stedet for et policyproblem:

same-security-traffic permit intra-interface

Den ene linjen tillater et videresendingsarrangement, slik ASA NAT-referansen beskriver for veier gjennom samme grensesnitt. Den legger ikke til en klientrute, autoriserer ikke en ressurs, oversetter ikke en adresse og forhandler ikke en IPsec-selector, så forvent å legge til tre eller fire ting mer etter den, og ikke les godkjenningen som fremgang.

Ben A: klienten vil på internett

For en internettutgang må puljeadressen slutte å være privat før pakken forlater enheten. I et vanlig PAT-design oversetter regelen puljen til det eksterne grensesnittets adresse, og returtilstanden gjenoppretter klientflyten:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

Bekreft deretter at klienten faktisk ba ASA-en om å bære den trafikken. En split-tunnel-utelatelse sender den offentlige destinasjonen over telefonens egen forbindelse, som aldri når ASA-en, og ingen NAT-regel reparerer en pakke som aldri ble sendt. Sammenlign gruppepolicyens split-tunnel-liste med destinasjonen du tester.

Resten av benet er vanlig: en brukbar standard- eller spesifikk rute ut av det eksterne grensesnittet, en tilgangspolicy som tillater flyten, og DNS håndtert etter resolverpolicyen du valgte. Legg til route-lookup her av samme grunn som nedenfor, siden inngangs- og utgangsgrensesnittet er identiske.

Ben B: klienten vil til et privat område

Dette benet feiler flere steder, så skriv det i rekkefølge. Først klientruten: destinasjonsprefikset må stå på split-tunnel-listen, ellers plasserer ikke klienten det i tunnelen. Deretter tunnel-selectoren: site-til-site-krypto-ACL-en må dekke puljeadresse til fjernprefiks, ikke bare det lokale LAN-et til fjernprefikset. Til slutt identitet, slik at puljeadressen ikke oversettes til internett-PAT underveis.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

Fjernsiden er den delen folk glemmer å teste. Peeren trenger en rute tilbake til puljen og en selector som inkluderer den, og dens egen policy må tillate kildeadressene den vil se. Hvis området i stedet brukes gjennom en oversatt visning, er det et gyldig design, men da må begge peerne, begge selectorene og begge rutetabellene være enige om de oversatte adressene.

Kontroller også reglerekkefølgen. En bred PAT-regel over identitetsregelen vil oversette den private utvekslingen før identitetsregelen i det hele tatt vurderes, og symptomet er en site-tunnel uten samsvarende SA i stedet for en NAT-feil.

Testen som forteller deg hvilket ben du har bygget

Bruk ASA-ens egen stivurdering i stedet for å lese konfigurasjonen og håpe. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed viser NAT-beslutningen, ruten og ACL-resultatet for én flyt; gjenta det med en privat destinasjon. Hvis NAT-fasen skriver om en privat-til-privat-flyt, har du bygget ben A for en pakke som trengte ben B.

To kommandoer til lukker gapet. show nat detail skriver ut reglerekkefølgen som packet-tracer fulgte, og show crypto ipsec sa viser om det finnes en selector for paret du forventer. En manglende SA er et selector- eller peer-konfigurasjonsproblem, ikke noe NAT-regelen kan reparere.

Verifiser hvert ben med trafikken det betjener

Godta ben A med en vanlig offentlig forespørsel fra klienten, og godta ben B med en forespørsel til en privat ressurs som faktisk finnes. Gjenta deretter hver med en avvist ressurs, fordi «tillatt» og «godkjent av tilgangspolicyen» ikke er samme bevis, og en ping som kommer fra huben, øver ikke på noen av klientveiene.

Hold de to testpostene atskilt i saken: kildeadresse, destinasjon, NAT-regelen som samsvarte, og resultat. Når neste rapport sier «VPN-et er ødelagt», forteller det paret deg innen et minutt hvilket ben som har regrediert, og svaret er vanligvis en rute eller en selector i stedet for linjen med samme grensesnitt som alle mistenker først.