ASA hairpin: sortida a internet o tram de VPN entre seus?

Dos usuaris d’accés remot darrere del mateix ASA poden enviar trànsit per la mateixa interfície externa i rebre un tracte completament diferent. Un va cap a un lloc web públic, així que el paquet necessita traducció d’origen i una ruta d’internet. L’altre va cap a un servidor darrere d’un túnel entre seus que també acaba en aquesta interfície, així que el paquet necessita identitat, un selector de túnel que coincideixi i un camí de tornada cap al pool de clients. El permís per a la mateixa interfície és una condició prèvia per a tots dos i una solució per a cap.

Dos trams, una interfície

Decidiu quin tram esteu construint abans d’escriure una regla NAT, perquè les regles no són intercanviables. El tram A és de client a internet: l’adreça del pool entra, l’adreça pública traduïda surt i torna per la mateixa interfície. El tram B és de client a un prefix privat a l’altre costat d’un altre peer IPsec: l’adreça del pool es conserva, es torna a xifrar i es lliura a un peer que ha de saber com respondre al pool.

El que tots dos necessiten primer és el permís per a la mateixa interfície. Sense això, l’ASA es nega a reenviar un paquet per la interfície per la qual ha arribat, i la fallada sembla un problema d’encaminament en lloc d’un problema de política:

same-security-traffic permit intra-interface

Aquesta única línia autoritza un esquema de reenviament, tal com descriu la referència de NAT de l’ASA per a camins per la mateixa interfície. No afegeix cap ruta de client, no autoritza cap recurs, no tradueix cap adreça ni negocia cap selector IPsec, així que espereu afegir-hi tres o quatre coses més i no llegiu la seva acceptació com un progrés.

Tram A: el client vol internet

Per a una sortida a internet, l’adreça del pool ha de deixar de ser privada abans que el paquet surti de l’equip. En un disseny PAT corrent, la regla tradueix el pool a l’adreça de la interfície externa, i l’estat de tornada restaura el flux cap al 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

Després confirmeu que el client ha demanat realment a l’ASA que porti aquest trànsit. Una exclusió del túnel dividit envia la destinació pública per la connexió pròpia del telèfon, que no arriba mai a l’ASA, i cap regla NAT arregla un paquet que no s’ha enviat mai. Compareu la llista de túnel dividit de la política de grup amb la destinació que proveu.

La resta del tram és corrent: una ruta per defecte o específica utilitzable des de la interfície externa, una política d’accés que permeti el flux i DNS gestionat segons la política de resolutor que hàgiu triat. Afegiu route-lookup aquí pel mateix motiu que més avall, ja que la interfície d’entrada i la de sortida són idèntiques.

Tram B: el client vol un lloc privat

Aquest tram falla en més llocs, així que escriviu-lo en ordre. Primer la ruta del client: el prefix de destinació ha de ser a la llista de túnel dividit, o el client no el posarà al túnel. Segon el selector de túnel: l’ACL de criptografia entre seus ha de cobrir l’adreça del pool cap al prefix remot, no només la LAN local cap al prefix remot. Tercer la identitat, perquè l’adreça del pool no es tradueixi al PAT d’internet pel camí.

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

El costat remot és la part que la gent oblida provar. El peer necessita una ruta de tornada al pool i un selector que l’inclogui, i la seva pròpia política ha de permetre les adreces d’origen que veurà. Si el lloc s’utilitza amb una visió traduïda, és un disseny vàlid, però llavors tots dos peers, tots dos selectors i totes dues taules d’encaminament han de coincidir en les adreces traduïdes.

Reviseu també l’ordre de les regles. Una regla PAT àmplia per sobre de la regla d’identitat traduirà l’intercanvi privat abans que la regla d’identitat s’avaluï, i el símptoma és un túnel de lloc sense SA coincident en lloc d’un error de NAT.

La prova que us diu quin tram heu construït

Utilitzeu l’avaluació de camí de l’ASA en lloc de llegir la configuració i esperar que funcioni. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed mostra la decisió de NAT, la ruta i el resultat de l’ACL per a un flux; repetiu-ho amb una destinació privada. Si la fase NAT reescriu un flux de privat a privat, heu construït el tram A per a un paquet que necessitava el tram B.

Dues ordres més tanquen el forat. show nat detail imprimeix l’ordre de regles que ha seguit packet-tracer, i show crypto ipsec sa mostra si existeix un selector per a la parella que espereu. Un SA que falta és un problema de configuració del selector o del peer, no una cosa que la regla NAT pugui reparar.

Verifiqueu cada tram amb el trànsit que serveix

Accepteu el tram A amb una petició pública corrent del client i el tram B amb una petició a un recurs privat que existeixi realment. Després repetiu cadascun amb un recurs denegat, perquè «permès» i «autoritzat per la política d’accés» no són la mateixa evidència, i un ping originat al concentrador no exercita cap dels dos camins del client.

Manteniu els dos registres de prova separats al tiquet: adreça d’origen, destinació, regla NAT que ha coincidit i resultat. Quan el proper informe digui «la VPN està trencada», aquesta parella us diu en un minut quin tram ha regredit, i la resposta sol ser una ruta o un selector en lloc de la línia de la mateixa interfície que tothom sospita primer.