ASA VPN-hairpin: twee tunnels via één interface routeren

Het verkeer van een externe gebruiker kan dezelfde ASA-interface verlaten waarop het aankwam, maar hairpin-toestemming, tunnelbereik, NAT en ACL's zijn vier afzonderlijke beslissingen.

Een externe gebruiker verbindt met de ASA, vraagt om een host achter een vestiging, en de ASA stuurt dat verzoek naar buiten via precies de interface waarop de gebruiker binnenkwam. Niets daaraan vereist een tweede fysieke poort. Wat het wel vereist, zijn vier onafhankelijke beslissingen die mensen geneigd zijn tot één samen te voegen: toestemming om te hairpinnen, een tunnel die de juiste adressen beschermt, een NAT-beleid dat de bron behoudt die je hebt beloofd, en een toegangsbeleid dat de dienst autoriseert.

Eén pakket, twee tunnels

Volg de stroom en de volgorde van bewerkingen houdt op mysterieus te zijn. Het pakket komt binnen in de remote-access-tunnel, wordt ontsleuteld en wordt een gewoon IP-pakket met de clientpool als bron. De ASA routeert het vervolgens, vergelijkt het met de site-to-site crypto ACL, versleutelt het opnieuw en stuurt het via de buiteninterface richting de vestiging.

De adressen hieronder zijn illustratief, maar de vorm is belangrijk: de bron is de pool, niet het interne LAN van de ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Daaruit volgen twee dingen. De client heeft een route nodig voor het vestigingsprefix via zijn remote-access-verbinding, wat betekent dat de split-tunnel of de gepushte routelijst die moet bevatten. En de vestiging moet weten hoe ze verkeer terugstuur naar 10.77.0.20 of naar het adres dat jouw NAT-ontwerp heeft vervangen.

Hairpin-toestemming is globaal

Het commando waar mensen naar grijpen is same-security-traffic permit intra-interface. Het staat verkeer toe dezelfde interface binnen te komen en te verlaten, wat precies is wat dit pad nodig heeft. Het is ook een globale instelling: het inschakelen verandert het gedrag van andere stromen die toevallig twee keer dezelfde interface passeren.

Daarom hoort het in een wijzigingsrecord en niet in een debugsessie. Vraag wat er verder op het apparaat nu een pad via dezelfde interface kan nemen, en of iets daarvan dat zou moeten. Op een drukke rand met gastnetwerken of overlappende partnertunnels is het antwoord niet automatisch nee. Schrijf de reden naast de instelling, want de volgende engineer vindt het commando en niet het gesprek.

Beschermingsbereik en NAT zijn gescheiden

De site-to-site-tunnel beschermt wat zijn crypto ACL selecteert. Als die ACL het interne subnet van de ASA als bron noemt, is de remote-access-pool niet beschermd en wordt het pakket ofwel weggegooid ofwel in het openbaar verzonden, afhankelijk van het gedrag van het platform bij niet-overeenkomend verkeer. Voeg de pool toe aan de beschermde stroom wanneer het ontwerp pooladressen behoudt.

NAT beslist vervolgens of het pooladres overleeft. Identity NAT behoudt het, en de vestiging ziet 10.77.0.20 als bron. Vertaling verandert het contract: de vestiging stuurt verkeer nu terug naar het vertaalde adres, en haar eigen beleid moet dat accepteren. De regelvolgorde bepaalt of de crypto ACL vóór of na de vertaling overeenkomt, dus lees de effectieve stroom in plaats van aan te nemen welke wint.

Verwijder de algemene internet-PAT-regels niet om één transitgeval te laten werken. Een gerichte uitzondering of een bewuste identity-regel is makkelijker uit te leggen en terug te draaien dan een gat in het uitgaande beleid.

Versleuteling is geen autorisatie

Een werkende tunnel bewijst alleen dat twee peers het eens zijn over sleutels en selectors. Hij zegt niets over de vraag of deze gebruiker die dienst mag bereiken. Het VPN-filter of het groepsbeleid dat aan de remote-access-verbinding hangt, moet nog steeds de bestemming en poort van de vestiging toestaan, en de interface-ACL op het buitenpad geldt nog steeds.

Test het antwoord in beide richtingen. Een verbinding die slaagt terwijl een naburige dienst zou moeten falen, is informatiever dan één geslaagde ping, want ze toont dat het beleid selectief is en niet wijd open. Als de test die geweigerd zou moeten worden slaagt, is niet de tunnel schuldig, maar het beleid. Bewaar beide resultaten in het wijzigingsrecord zodat de volgende persoon weet welk gedrag bedoeld was.

Hairpin of een tweede interface

Hairpin-transit houdt het ontwerp klein en kost één globale instelling. Een aparte interface, of een routegebaseerde tunnel met een eigen virtuele interface, isoleert het transitpad en geeft je beleid per interface, tegen de prijs van adressering en nog een crypto map of profiel. Geen van beide is juister; ze falen anders.

Routegebaseerde ontwerpen zijn een andere ordening, geen selectievakje in dezelfde configuratie. Als je daarop overstapt, houdt de bovenstaande discussie over op beleid gebaseerde crypto ACL op te gelden en begint de routetabel het selectiewerk te doen.

Verifieer vanaf de echte client

Een probe die vanaf de ASA start, heeft een ander bronadres en zal het pad van pool naar vestiging niet doorlopen. Gebruik packet-tracer om de vijf-tuple te controleren, en open daarna een echte verbinding vanaf de werkelijke externe client, want de tracer simuleert en vervangt niet de eigen routing en het beleid van de client.

Na een geplande wijziging verbind je met een dienst die zou moeten werken, dan met een die geweigerd zou moeten worden, en bevestig daarna de terugroute van de vestiging. De de voorbeelden van Cisco voor VPN-hairpin-NAT houden intra-interface-toestemming, NAT en ACL's zichtbaar gescheiden, en dat is het mentale model dat het kopiëren waard is.

Gerelateerde artikelen