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

To fjernadgangsbrugere bag samme ASA kan sende trafik ud af samme udvendige interface og få helt forskellig behandling. Den ene skal til et offentligt websted, så pakken har brug for kildetranslation og en internetrute. Den anden skal til en server bag en site-til-site-tunnel, der også terminerer på det interface, så pakken har brug for identitet, en matchende tunnel-selector og en returvej til klientpuljen. Tilladelse til samme interface er en forudsætning for begge og en løsning for ingen af dem.

To ben, ét interface

Beslut, hvilket ben du bygger, før du skriver en NAT-regel, for reglerne kan ikke udskiftes. Ben A er klient til internet: puljeadresse ind, oversat offentlig adresse ud, tilbage gennem samme interface. Ben B er klient til et privat præfiks på den anden side af en anden IPsec-peer: puljeadressen bevares, genkrypteres og leveres til en peer, der skal vide, hvordan den svarer puljen.

Det, begge har brug for først, er tilladelsen til samme interface. Uden den nægter ASA’en at videresende en pakke ud af det interface, den ankom på, og fejlen ser ud som et routingproblem i stedet for et politikproblem:

same-security-traffic permit intra-interface

Den ene linje tillader et videresendelsesarrangement, som ASA NAT-referencen beskriver for veje gennem samme interface. Den tilføjer ingen klientrute, autoriserer ingen ressource, oversætter ingen adresse og forhandler ingen IPsec-selector, så forvent at tilføje tre eller fire ting mere efter den, og læs ikke dens accept som fremskridt.

Ben A: klienten vil på internettet

For en internetudgang skal puljeadressen holde op med at være privat, før pakken forlader enheden. I et almindeligt PAT-design oversætter reglen puljen til det udvendige interfaces adresse, og returtilstanden genskaber klientflowet:

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

Bekræft derefter, at klienten faktisk bad ASA’en om at bære den trafik. En split-tunnel-udelukkelse sender den offentlige destination over telefonens egen forbindelse, som aldrig når ASA’en, og ingen NAT-regel reparerer en pakke, der aldrig blev sendt. Sammenlign gruppepolitikkens split-tunnel-liste med den destination, du tester.

Resten af benet er almindeligt: en brugbar standard- eller specifik rute ud af det udvendige interface, en adgangspolitik, der tillader flowet, og DNS håndteret efter den resolverpolitik, du valgte. Tilføj route-lookup her af samme grund som nedenfor, da indgangs- og udgangsinterface er identiske.

Ben B: klienten vil til et privat site

Dette ben fejler flere steder, så skriv det i rækkefølge. Først klientruten: destinationspræfikset skal stå på split-tunnel-listen, ellers placerer klienten det ikke i tunnelen. Dernæst tunnel-selectoren: site-til-site-krypto-ACL’en skal dække puljeadresse til fjernpræfiks, ikke kun det lokale LAN til fjernpræfikset. Til sidst identitet, så puljeadressen ikke oversættes til internet-PAT undervejs.

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

Den fjerne side er den del, folk glemmer at teste. Peeren har brug for en rute tilbage til puljen og en selector, der inkluderer den, og dens egen politik skal tillade de kildeadresser, den vil se. Hvis stedet i stedet bruges gennem en oversat visning, er det et gyldigt design, men så skal begge peers, begge selectors og begge routingtabeller være enige om de oversatte adresser.

Kontroller også regelrækkefølgen. En bred PAT-regel over identitetsreglen oversætter den private udveksling, før identitetsreglen overhovedet evalueres, og symptomet er en site-tunnel uden matchende SA i stedet for en NAT-fejl.

Testen, der fortæller dig, hvilket ben du har bygget

Brug ASA’ens egen sti-evaluering i stedet for at læse konfigurationen og håbe. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed viser NAT-beslutningen, ruten og ACL-resultatet for et flow; gentag det med en privat destination. Hvis NAT-fasen omskriver et privat-til-privat-flow, har du bygget ben A til en pakke, der havde brug for ben B.

To kommandoer mere lukker hullet. show nat detail udskriver den regelrækkefølge, som packet-tracer fulgte, og show crypto ipsec sa viser, om der findes en selector for det par, du forventer. En manglende SA er et selector- eller peer-konfigurationsproblem, ikke noget NAT-reglen kan reparere.

Verificér hvert ben med den trafik, det betjener

Accepter ben A med en almindelig offentlig anmodning fra klienten, og accepter ben B med en anmodning til en privat ressource, der faktisk findes. Gentag derefter hver med en afvist ressource, fordi »tilladt« og »godkendt af adgangspolitikken« ikke er samme bevis, og en ping, der stammer fra hubben, udøver ingen af klientvejene.

Hold de to testposter adskilt i sagen: kildeadresse, destination, den NAT-regel der matchede, og resultat. Når den næste rapport siger »VPN’et er i stykker«, fortæller det par dig inden for et minut, hvilket ben der er regredieret, og svaret er som regel en rute eller en selector i stedet for linjen med samme interface, som alle mistænker først.