ASA hairpin: internetútgong of site-nei-site-VPN-skank?

De klantpool kin nei it internet of yn in site-VPN fuortgean. Beslis hokker skank jo nedich hawwe foardat jo NAT skriuwe, en kontrolearje dan rûte, selektor en antwurdpaad.

Twa remote-access-brûkers efter deselde ASA kinne ferkear út deselde bûtenste interface stjoere en folslein oars behannele wurde. De iene giet nei in iepenbiere website, dus it pakket hat boarnetranslaasje en in internetrûte nedich. De oare giet nei in tsjinner efter in site-nei-site-tunnel dy’t ek op dy interface einiget, dus it pakket hat identiteit, in bypassende tunnelselektor en in werompaad nei de klantpool nedich. Tastimming foar deselde interface is in betingst foar beide en in oplossing foar gjinien.

Twa skonken, ien interface

Beslis hokker skank jo bouwe foardat jo in NAT-regel yntype, want de regels binne net útwikselber. Skank A is klant nei internet: pooladres yn, oersetten iepenbier adres út, werom troch deselde interface. Skank B is klant nei in privaat prefix oan de oare kant fan in oare IPsec-peer: it pooladres bliuwt bewarre, wurdt opnij fersifere en oan in peer levere dy’t witte moat hoe’t er de pool beantwurdzje moat.

Wat beide earst nedich hawwe, is de tastimming foar deselde interface. Sûnder dy wegeret de ASA om in pakket út ’e interface te stjoeren dêr’t it op oankaam, en de flater liket in rûteprobleem ynstee fan in beliedsprobleem:

same-security-traffic permit intra-interface

Dy iene rigel machtiget in troerstjoerregeling, sa’t de ASA-NAT-referinsje it foar paden troch deselde interface beskreau. It foeget gjin klantrûte ta, machtiget gjin boarne, oerset gjin adres en ûnderhannelet gjin IPsec-selektor, dus ferwachtsje dêrnei noch trije of fjouwer dingen ta te foegjen en lês de akseptaasje derfan net as foarútgong.

Skank A: de klant wol it internet

Foar in internetútgong moat it pooladres ophâlde privaat te wêzen foardat it pakket it apparaat ferlit. Yn in gewoan PAT-ûntwerp oerset de regel de pool nei it adres fan ’e bûtenste interface, en de weromsteat herstelt de klantrjochte stream:

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

Befêstigje dan dat de klant de ASA echt frege hat dat ferkear te dragen. In split-tunnel-útsluting stjoert de iepenbiere bestimming oer de eigen ferbining fan ’e telefoan, dy’t de ASA nea berikt, en gjin NAT-regel reparearret in pakket dat nea stjoerd is. Ferlykje de split-tunnel-list fan it groepsbelied mei de bestimming dy’t jo testen.

De rest fan ’e skank is gewoan: in brûkbere standert- of spesifike rûte út ’e bûtenste interface, in tagongsbelied dat de stream tastiet, en DNS behannele neffens it resolverbelied dat jo keazen hawwe. Foegje route-lookup hjir ta om deselde reden as hjirûnder, om’t de yngongs- en útgangsinterface identyk binne.

Skank B: de klant wol in privaat site

Dizze skank mislearret op mear plakken, dus skriuw it yn folchoarder. Earst de klantrûte: it bestimmingsprefix moat yn ’e split-tunnel-list stean, oars set de klant it net yn ’e tunnel. Twadde de tunnelselektor: de site-nei-site-krypto-ACL moat pooladres nei fiere prefix dekke, net allinnich it lokale LAN nei it fiere prefix. Tredde identiteit, sadat it pooladres ûnderweis net yn it internet-PAT oerset wurdt.

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

De fiere kant is it part dat minsken ferjitte te testen. De peer hat in rûte werom nei de pool nedich en in selektor dy’t dy omfettet, en syn eigen belied moat de boarneadressen tastean dy’t er sjen sil. As it site ynstee fia in oersetten byld brûkt wurdt, is dat in jildich ûntwerp, mar dan moatte beide peers, beide selektors en beide rûtetabellen it oer de oersetten adressen iens wêze.

Kontrolearje ek de regelfolchoarder. In brede PAT-regel boppe de identiteitsregel oerset de private útwikseling foardat de identiteitsregel ea evaluearre wurdt, en it symptoom is in sitetunnel sûnder bypassende SA ynstee fan in NAT-flater.

De test dy’t jo seit hokker skank jo boud hawwe

Brûk de eigen paadevaluaasje fan ’e ASA ynstee fan de konfiguraasje te lêzen en te hoopjen. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed toant it NAT-beslút, de rûte en it ACL-resultaat foar ien stream; werhelje it mei in private bestimming. As de NAT-faze in privaat-nei-privaat-stream weromskriuwt, hawwe jo skank A boud foar in pakket dat skank B nedich hie.

Twa opdrachten mear slute de kloof. show nat detail printsje de regelfolchoarder dy’t packet-tracer folge, en show crypto ipsec sa toant oft der in selektor bestiet foar it pear dat jo ferwachtsje. In ûntbrekkende SA is in selektor- of peer-konfiguraasjeprobleem, net iets dat de NAT-regel reparearje kin.

Ferifiearje elke skank mei it ferkear dat it tsjinnet

Akseptearje skank A mei in gewoan iepenbier fersyk fan ’e klant, en akseptearje skank B mei in fersyk nei in privaat boarne dy’t echt bestiet. Werhelje dan elk mei in wegere boarne, want “tastien” en “goedkard troch it tagongsbelied” binne net itselde bewiis, en in ping dy’t by de hub ûntstiet oefenet gjin fan beide klantpaden.

Hâld de twa testrecords apart yn it ticket: boarneadres, bestimming, de NAT-regel dy’t oerienkaam, en resultaat. As it folgjende rapport seit “de VPN is stikken”, fertelt dat pear jo binnen in minút hokker skank efterútgien is, en it antwurd is meastentiids in rûte of in selektor ynstee fan ’e rigel fan deselde interface dy’t elkenien earst fertinkt.

Relatearre artikelen