Een interne dienst publiceren over een ASA-site-naar-site-VPN
Vijf geordende controles om een interne dienst via een ASA-site-naar-site-VPN beschikbaar te maken: beschermd bereik, bronmodel, vertaling, poortbereik, retourpad.
Een dienst publiceren die achter een site-naar-site-VPN leeft, is één taak met vijf faalpunten, en ze falen in een vaste volgorde. De tunnel komt omhoog, de vertaling klopt, de vestiging antwoordt, en het antwoord komt via hetzelfde pad terug. Wanneer een van die punten fout is, toont de browser hetzelfde: een verbinding die blijft hangen of wordt gereset. Werk de lijst van boven naar beneden af en stop bij de eerste controle die faalt.
Controle 1: de tunnel beschermt het bronadres
Begin met een tunnel die al verkeer doorlaat, en bevestig dan dat het adres dat je wilt publiceren binnen het beschermde bereik ligt. Op een ASA komt dat bereik uit de crypto-ACL of uit de routes van een VTI, en het moet het echte adres van de bron dekken, niet het subnet dat de vestiging voor beheer gebruikt. Een selector die de bron mist, levert een tunnel die staat en een stroom die er nooit in komt.
Bevestig dat met de tunneltellers en de routetabel voordat je de vertaling aanraakt. Als de bron vanaf de hub niet via de tunnel bereikbaar is, kan niets later in deze lijst dat repareren.
Stop hier als het beschermde bereik en het bronadres niet overeenkomen.
Controle 2: bepaal welke bron de vestiging ziet
De vestiging ziet ofwel het oorspronkelijke clientadres ofwel een vertaald adres, en die keuze bepaalt het retourpad. Het clientadres bewaren leest schoner in de logs van de bron, maar dan moet de vestiging antwoorden voor openbare clients via de tunnel terugsturen; een gewone internet-standaardroute stuurt ze de andere kant op en de verbinding sterft in één richting. De bron vertalen naar een adres dat de vestiging al via de tunnel routeert, haalt die eis weg.
Vertaling verandert ook wat de bron kan loggen en waarop op bron gebaseerde regels kunnen matchen. Als de applicatie de mens achter een verzoek moet kennen, hoort dat in een geauthenticeerde reverse proxy, niet in een NAT-beslissing.
Controle 3: schrijf de vertaling tegen de echte interfaces
Een ASA evalueert vertaalregels in volgorde en meldt welke heeft gematcht, dus het interfacepaar in de regel is niet cosmetisch. Een regel die voor een pad van buiten naar binnen is geschreven, matcht niet met een stroom waarvan de ingress en egress afwijken van wat je aannam.
Het pad dat je bouwt heeft vier delen, en alle vier moeten kloppen:
| Leg | Source | Destination |
|---|---|---|
| Request from the internet | 198.51.100.25 | 203.0.113.20:443 |
| After destination translation | 198.51.100.25 | 10.60.20.10:443 |
| After source translation toward the tunnel | 10.10.250.10 | 10.60.20.10:443 |
| Branch reply | 10.60.20.10 | 10.10.250.10 |
| Restored reply to the client | 203.0.113.20 | 198.51.100.25 |
Behandel de bereiken in die tabel als plaatsaanduidingen. Wat telt, is dat de tuple na vertaling een adres is dat de vestiging via de tunnel accepteert, en dat de omgekeerde mapping in de NAT-status bestaat zodat het antwoord op de uitweg wordt hersteld.
Controle 4: beperk de toegangsregel tot de gepubliceerde poort
Publiceer de poort, niet de host. Een regel die de bron op elke dienst toestaat, maakt van één gepubliceerde applicatie een pad naar alles wat de bron draait, inclusief de beheerinterface die je bewust buiten het internet hield. Sta de gepubliceerde poort toe van de vertaalde bron naar de bron, en laat beheerdiensten op hun alleen-VPN-pad.
Controleer tegelijk de regelvolgorde. Een brede toestemming boven je specifieke regel maakt de specifieke regel onzichtbaar.
Controle 5: volg één verzoek en het antwoord
Begin niet met een browser, want een browser verbergt welk deel faalde. Volg de stroom op de hub en lees het resultaat voordat je iets verandert.
packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2lDe trace noemt de vertaling die matchte, de toegangsregel die de stroom toestond of weigerde, en of het pakket de tunnel in werd gerouteerd. Als hij toont dat de stroom een interface verlaat die je niet verwachtte, is het interfacepaar in de NAT-regel fout. Als hij een weigering toont, is de regelvolgorde fout. Als hij de tunnel bereikt maar de bron nooit antwoordt, is het retourpad van de vestiging het probleem.
Stuur daarna één echt verzoek van buiten en bevestig dat het antwoord via dezelfde tunnel terugkomt. Leg de gepubliceerde ingang, de vertaling, het beschermde adrespaar en de retourroute vast als het publicatierecord.