ASA hairpin: internetuitgang of site-naar-site-VPN-poot?

Twee remote-access-gebruikers achter dezelfde ASA kunnen verkeer via dezelfde buiteninterface versturen en volstrekt verschillend worden behandeld. De ene gaat naar een openbare website, dus het pakket heeft brontranslatie en een internetroute nodig. De andere gaat naar een server achter een site-naar-site-tunnel die ook op die interface eindigt, dus het pakket heeft identiteit, een passende tunnel-selector en een retourpad naar de clientpool nodig. Toestemming voor dezelfde interface is een voorwaarde voor beide en een oplossing voor geen van beide.

Twee poten, één interface

Bepaal welke poot u bouwt voordat u een NAT-regel typt, want de regels zijn niet uitwisselbaar. Poot A is client naar internet: pooladres erin, vertaald openbaar adres eruit, terug via dezelfde interface. Poot B is client naar een privéprefix aan de overkant van een andere IPsec-peer: het pooladres blijft behouden, wordt opnieuw versleuteld en afgeleverd bij een peer die moet weten hoe hij de pool beantwoordt.

Wat beide eerst nodig hebben, is de toestemming voor dezelfde interface. Zonder die weigert de ASA een pakket door te sturen via de interface waarop het aankwam, en de fout ziet eruit als een routeringsprobleem in plaats van een beleidsprobleem:

same-security-traffic permit intra-interface

Die ene regel staat een doorstuuropstelling toe, zoals de ASA NAT-referentie die voor paden via dezelfde interface beschrijft. Hij voegt geen clientroute toe, autoriseert geen resource, vertaalt geen adres en onderhandelt geen IPsec-selector, dus verwacht daarna nog drie of vier dingen toe te voegen en lees de acceptatie ervan niet als vooruitgang.

Poot A: de client wil internet

Voor een internetuitgang moet het pooladres ophouden privé te zijn voordat het pakket het apparaat verlaat. In een gewoon PAT-ontwerp vertaalt de regel de pool naar het adres van de buiteninterface, en de retourstatus herstelt de stroom richting de client:

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

Bevestig daarna dat de client de ASA daadwerkelijk heeft gevraagd dat verkeer te dragen. Een split-tunnel-uitsluiting stuurt de openbare bestemming over de eigen verbinding van de telefoon, die de ASA nooit bereikt, en geen enkele NAT-regel repareert een pakket dat nooit is verzonden. Vergelijk de split-tunnellijst van het groepsbeleid met de bestemming die u test.

De rest van de poot is gewoon: een bruikbare standaard- of specifieke route uit de buiteninterface, een toegangsbeleid dat de stroom toestaat, en DNS afgehandeld volgens het resolverbeleid dat u koos. Voeg route-lookup hier toe om dezelfde reden als hieronder, omdat de in- en uitgangsinterface identiek zijn.

Poot B: de client wil een privésite

Deze poot faalt op meer plaatsen, dus schrijf hem in volgorde. Eerst de clientroute: de bestemmingsprefix moet in de split-tunnellijst staan, anders plaatst de client hem niet in de tunnel. Dan de tunnel-selector: de site-naar-site-crypto-ACL moet pooladres tot externe prefix dekken, niet alleen het lokale LAN tot de externe prefix. Ten slotte identiteit, zodat het pooladres onderweg niet naar de internet-PAT wordt vertaald.

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

De verre kant is het deel dat mensen vergeten te testen. De peer heeft een route terug naar de pool nodig en een selector die die bevat, en zijn eigen beleid moet de bronadressen toestaan die hij zal zien. Als de site in plaats daarvan via een vertaalde weergave wordt gebruikt, is dat een geldig ontwerp, maar dan moeten beide peers, beide selectors en beide routingtabellen het over de vertaalde adressen eens zijn.

Controleer ook de regelvolgorde. Een brede PAT-regel boven de identiteitsregel vertaalt de privé-uitwisseling voordat de identiteitsregel ooit wordt geëvalueerd, en het symptoom is een sitetunnel zonder passende SA in plaats van een NAT-fout.

De test die u vertelt welke poot u hebt gebouwd

Gebruik de eigen pad-evaluatie van de ASA in plaats van de configuratie te lezen en te hopen. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed toont de NAT-beslissing, de route en het ACL-resultaat voor één stroom; herhaal het met een privébestemming. Als de NAT-fase een privé-naar-privé-stroom herschrijft, hebt u poot A gebouwd voor een pakket dat poot B nodig had.

Twee commando’s meer dichten de kloof. show nat detail drukt de regelvolgorde af die packet-tracer volgde, en show crypto ipsec sa toont of er een selector bestaat voor het paar dat u verwacht. Een ontbrekende SA is een selector- of peer-configuratiekwestie, niet iets wat de NAT-regel kan repareren.

Verifieer elke poot met het verkeer dat hij bedient

Accepteer poot A met een gewoon openbaar verzoek van de client, en poot B met een verzoek naar een privébron die echt bestaat. Herhaal daarna elk met een geweigerde bron, want ‘toegestaan’ en ‘goedgekeurd door het toegangsbeleid’ zijn niet hetzelfde bewijs, en een ping die bij de hub ontstaat, oefent geen van beide clientpaden.

Houd de twee testrecords gescheiden in het ticket: bronadres, bestemming, de NAT-regel die overeenkwam, en resultaat. Als het volgende rapport zegt ‘de VPN is stuk’, vertelt dat paar u binnen een minuut welke poot is achteruitgegaan, en het antwoord is meestal een route of een selector in plaats van de regel met dezelfde interface die iedereen als eerste verdenkt.