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

To fjernkoplingsbrukarar bak same ASA kan senda trafikk ut av same eksterne grensesnitt og få heilt ulik handsaming. Den eine skal til eit offentleg nettstad, så pakken treng kjeldeomsetjing og ei internett-rute. Den andre skal til ein tenar bak ein site-til-site-tunnel som også terminerer på det grensesnittet, så pakken treng identitet, ein samsvarande tunnel-selector og ein returveg til klientpulen. Løyve for same grensesnitt er ein føresetnad for begge og ei løysing for ingen av dei.

To bein, eitt grensesnitt

Avgjer kva bein du byggjer før du skriv ei NAT-regel, fordi reglane ikkje er utskiftbare. Bein A er klient til internett: puljeadresse inn, omsett offentleg adresse ut, tilbake gjennom same grensesnitt. Bein B er klient til eit privat prefiks på den andre sida av ein annan IPsec-peer: puljeadressa blir halden, kryptert på nytt og levert til ein peer som må vita korleis han svarar puljen.

Det begge treng først, er løyvet for same grensesnitt. Utan det nektar ASA-en å senda vidare ein pakke ut av grensesnittet han kom inn på, og feilen ser ut som eit ruteproblem i staden for eit policyproblem:

same-security-traffic permit intra-interface

Den eine linja tillèt eit vidaresendingsarrangement, slik ASA NAT-referansen skildrar for vegar gjennom same grensesnitt. Ho legg ikkje til ei klientrute, autoriserer ikkje ein ressurs, omset ikkje ei adresse og forhandlar ikkje ein IPsec-selector, så vent å leggja til tre eller fire ting meir etter henne, og les ikkje godkjenninga som framgang.

Bein A: klienten vil på internett

For ein internettutgang må puljeadressa slutta å vera privat før pakken forlèt eininga. I eit vanleg PAT-design omset regelen puljen til adressa til det eksterne grensesnittet, og returtilstanden gjenopprettar 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

Stadfest deretter at klienten faktisk bad ASA-en bera den trafikken. Ei split-tunnel-utelating sender den offentlege destinasjonen over telefonens eiga tilkopling, som aldri når ASA-en, og inga NAT-regel reparerer ein pakke som aldri vart send. Samanlikn split-tunnel-lista til gruppepolicyen med destinasjonen du testar.

Resten av beinet er vanleg: ei brukbar standard- eller spesifikk rute ut av det eksterne grensesnittet, ein tilgangspolicy som tillèt flyten, og DNS handsama etter resolverpolicyen du valde. Legg til route-lookup her av same grunn som nedanfor, sidan inngangs- og utgangsgrensesnittet er identiske.

Bein B: klienten vil til eit privat område

Dette beinet feilar fleire stader, så skriv det i rekkjefølgje. Først klientruta: destinasjonsprefikset må stå på split-tunnel-lista, elles plasserer ikkje klienten det i tunnelen. Deretter tunnel-selectoren: site-til-site-krypto-ACL-en må dekkja puljeadresse til fjernprefiks, ikkje berre det lokale LAN-et til fjernprefikset. Til slutt identitet, slik at puljeadressa ikkje blir omsett til internett-PAT undervegs.

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

Fjernsida er den delen folk gløymer å testa. Peeren treng ei rute tilbake til puljen og ein selector som inkluderer henne, og sin eigen policy må tillata kjeldeadressene han vil sjå. Viss området i staden blir brukt gjennom ein omsett vising, er det eit gyldig design, men då må begge peerane, begge selectorane og begge rutetabellane vera samde om dei omsette adressene.

Kontroller også reglerekkjefølgja. Ei brei PAT-regel over identitetsregelen vil omsetja den private utvekslinga før identitetsregelen i det heile blir vurdert, og symptomet er ein site-tunnel utan samsvarande SA i staden for ein NAT-feil.

Testen som fortel deg kva bein du har bygt

Bruk ASA-en si eiga stivurdering i staden for å lesa konfigurasjonen og håpa. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed viser NAT-avgjerda, ruta og ACL-resultatet for ein flyt; gjer det om att med ein privat destinasjon. Viss NAT-fasen skriv om ein privat-til-privat-flyt, har du bygt bein A for ein pakke som trong bein B.

To kommandoar til tettar gapet. show nat detail skriv ut reglerekkjefølgja som packet-tracer følgde, og show crypto ipsec sa viser om det finst ein selector for paret du ventar. Ein manglande SA er eit selector- eller peer-konfigurasjonsproblem, ikkje noko NAT-regelen kan reparera.

Stadfest kvart bein med trafikken det tener

Godta bein A med ein vanleg offentleg førespurnad frå klienten, og godta bein B med ein førespurnad til ein privat ressurs som faktisk finst. Gjer deretter kvar om att med ein avvist ressurs, fordi «tillate» og «godkjent av tilgangspolicyen» ikkje er same prov, og ein ping som kjem frå huben, øver ikkje på nokon av klientvegane.

Hald dei to testpostane skilde i saka: kjeldeadresse, destinasjon, NAT-regelen som samsvara, og resultat. Når neste rapport seier «VPN-et er øydelagt», fortel det paret deg innan eit minutt kva bein som har regrediert, og svaret er vanlegvis ei rute eller ein selector i staden for linja med same grensesnitt som alle mistenkjer først.