ASA hairpin: internetutgång eller site-till-site-VPN-ben?

Klientpoolen kan gå mot internet eller in i en site-VPN. Bestäm vilket ben du behöver innan du skriver NAT och kontrollera sedan rutt, selector och returväg.

Två fjärråtkomstsanvändare bakom samma ASA kan skicka trafik ut genom samma externa gränssnitt och få helt olika behandling. Den ene ska till en offentlig webbplats, så paketet behöver källtranslering och en internetrutt. Den andre ska till en server bakom en site-till-site-tunnel som också terminerar på det gränssnittet, så paketet behöver identitet, en matchande tunnel-selector och en returväg till klientpoolen. Tillstånd för samma gränssnitt är en förutsättning för båda och en lösning för ingen av dem.

Två ben, ett gränssnitt

Bestäm vilket ben du bygger innan du skriver en NAT-regel, eftersom reglerna inte är utbytbara. Ben A är klient till internet: pooladress in, översatt offentlig adress ut, tillbaka genom samma gränssnitt. Ben B är klient till ett privat prefix på andra sidan av en annan IPsec-peer: pooladressen bevaras, krypteras om och levereras till en peer som måste veta hur den svarar poolen.

Det båda behöver först är tillståndet för samma gränssnitt. Utan det vägrar ASA:n att vidarebefordra ett paket ut genom gränssnittet det kom in på, och felet ser ut som ett routningsproblem i stället för ett policyproblem:

same-security-traffic permit intra-interface

Den enda raden tillåter ett vidarebefordringsarrangemang, som ASA:s NAT-referens beskriver för vägar genom samma gränssnitt. Den lägger inte till en klientrutt, auktoriserar inte en resurs, översätter inte en adress och förhandlar inte en IPsec-selector, så räkna med att lägga till tre eller fyra saker till efter den och läs inte dess acceptans som framsteg.

Ben A: klienten vill ut på internet

För en internetutgång måste pooladressen sluta vara privat innan paketet lämnar enheten. I en vanlig PAT-design översätter regeln poolen till det externa gränssnittets adress, och returtillståndet återställer klientflödet:

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äfta sedan att klienten verkligen bad ASA:n att bära den trafiken. En split-tunnel-uteslutning skickar den offentliga destinationen över telefonens egen anslutning, som aldrig når ASA:n, och ingen NAT-regel reparerar ett paket som aldrig skickades. Jämför grupppolicyens split-tunnellista med destinationen du testar.

Resten av benet är vanligt: en användbar standard- eller specifik rutt ut genom det externa gränssnittet, en åtkomstpolicy som tillåter flödet, och DNS hanterad enligt den resolverpolicy du valde. Lägg till route-lookup här av samma skäl som nedan, eftersom in- och utgränssnittet är identiska.

Ben B: klienten vill till en privat plats

Det här benet misslyckas på fler ställen, så skriv det i ordning. Först klientrutten: destinationsprefixet måste finnas i split-tunnellistan, annars placerar klienten det inte i tunneln. Sedan tunnel-selectorn: site-till-site-krypto-ACL:en måste täcka pooladress till fjärrprefix, inte bara det lokala LAN:et till fjärrprefixet. Till sist identitet, så att pooladressen inte översätts till internet-PAT på vägen.

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

Fjärrsidan är den del folk glömmer att testa. Peeren behöver en rutt tillbaka till poolen och en selector som inkluderar den, och dess egen policy måste tillåta källadresserna den kommer att se. Om platsen i stället används genom en översatt vy är det en giltig design, men då måste båda peerarna, båda selectorerna och båda routingtabellerna vara överens om de översatta adresserna.

Kontrollera även regelordningen. En bred PAT-regel ovanför identitetsregeln översätter det privata utbytet innan identitetsregeln ens utvärderas, och symptomet är en sitetunnel utan matchande SA i stället för ett NAT-fel.

Testet som säger vilket ben du har byggt

Använd ASA:ns egen vägutvärdering i stället för att läsa konfigurationen och hoppas. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed visar NAT-beslutet, rutten och ACL-resultatet för ett flöde; upprepa det med en privat destination. Om NAT-fasen skriver om ett privat-till-privat-flöde har du byggt ben A för ett paket som behövde ben B.

Två kommandon till stänger gapet. show nat detail skriver ut regelordningen som packet-tracer följde, och show crypto ipsec sa visar om det finns en selector för paret du förväntar dig. En saknad SA är en selector- eller peer-konfigurationsfråga, inte något NAT-regeln kan reparera.

Verifiera varje ben med den trafik det betjänar

Acceptera ben A med en vanlig offentlig begäran från klienten, och ben B med en begäran till en privat resurs som faktiskt finns. Upprepa sedan varje med en nekad resurs, eftersom ”tillåten” och ”godkänd av åtkomstpolicyn” inte är samma bevis, och en ping som utgår från navet övar ingen av klientvägarna.

Håll de två testposterna åtskilda i ärendet: källadress, destination, den NAT-regel som matchade, och resultat. När nästa rapport säger ”VPN:et är trasigt” säger det paret dig inom en minut vilket ben som har regredierat, och svaret är oftast en rutt eller en selector i stället för raden med samma gränssnitt som alla misstänker först.

Relaterade artiklar