ASA hairpin: výstup do internetu, nebo větev VPN mezi lokalitami?

Pula klientů může odcházet do internetu nebo do lokální VPN. Rozhodněte, kterou větev potřebujete, ještě než napíšete NAT, a pak zkontrolujte trasu, selektor a zpětnou cestu.

Dva uživatelé vzdáleného přístupu za stejným ASA mohou posílat provoz ze stejného vnějšího rozhraní a dostat úplně jiné zacházení. Jeden jde na veřejný web, takže paket potřebuje překlad zdroje a internetovou trasu. Druhý jde na server za tunelem mezi lokalitami, který také končí na tomto rozhraní, takže paket potřebuje identitu, odpovídající selektor tunelu a zpětnou cestu do klientské puly. Povolení pro stejné rozhraní je předpokladem pro obojí a řešením pro ani jedno.

Dvě větve, jedno rozhraní

Rozhodněte, kterou větev stavíte, než napíšete pravidlo NAT, protože pravidla nejsou zaměnitelná. Větev A je klient do internetu: adresa z puly dovnitř, přeložená veřejná adresa ven, zpět stejným rozhraním. Větev B je klient k privátnímu prefixu na druhé straně jiného IPsec peeru: adresa z puly zůstává zachována, znovu se šifruje a doručí peeru, který musí vědět, jak pule odpovědět.

Co obě nejdřív potřebují, je povolení pro stejné rozhraní. Bez něj ASA odmítne přeposlat paket z rozhraní, na kterém přišel, a selhání vypadá jako problém směrování, ne jako problém politiky:

same-security-traffic permit intra-interface

Tento jediný řádek povoluje schéma přeposílání, jak popisuje reference NAT pro ASA pro cesty stejným rozhraním. Nepřidává trasu klienta, neautorizuje prostředek, nepřekládá adresu ani nevyjednává selektor IPsec, takže po něm čekejte přidání dalších tří nebo čtyř věcí a nečtěte jeho přijetí jako pokrok.

Větev A: klient chce internet

Pro výstup do internetu musí adresa z puly přestat být privátní, než paket opustí zařízení. V běžném návrhu PAT pravidlo překládá pulu na adresu vnějšího rozhraní a zpětný stav obnovuje tok směrem ke klientovi:

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

Pak potvrďte, že klient skutečně požádal ASA, aby tento provoz nesl. Vyloučení z rozděleného tunelu posílá veřejné cíle přes vlastní připojení telefonu, které se k ASA vůbec nedostane, a žádné pravidlo NAT neopraví paket, který nebyl nikdy odeslán. Porovnejte seznam rozděleného tunelu skupinové politiky s cílem, který testujete.

Zbytek větve je běžný: použitelná výchozí nebo konkrétní trasa z vnějšího rozhraní, přístupová politika, která tok povoluje, a DNS řešené podle zvolené politiky resolveru. Přidejte route-lookup zde ze stejného důvodu jako níže, protože vstupní a výstupní rozhraní jsou totožná.

Větev B: klient chce privátní lokalitu

Tato větev selhává na více místech, takže ji pište popořadě. Nejprve trasa klienta: cílový prefix musí být v seznamu rozděleného tunelu, jinak jej klient do tunelu neumístí. Za druhé selektor tunelu: krypto ACL mezi lokalitami musí pokrývat adresu puly k vzdálenému prefixu, ne jen místní LAN ke vzdálenému prefixu. Za třetí identita, aby se adresa puly cestou nepřeložila do internetového PAT.

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

Vzdálená strana je část, kterou lidé zapomínají testovat. Peer potřebuje trasu zpět do puly a selektor, který ji zahrnuje, a jeho vlastní politika musí povolit zdrojové adresy, které uvidí. Pokud se lokalita používá přes přeložený pohled, je to platný návrh, ale pak se oba peery, oba selektory a obě směrovací tabulky musí shodnout na přeložených adresách.

Zkontrolujte také pořadí pravidel. Široké pravidlo PAT nad pravidlem identity přeloží privátní výměnu dřív, než se pravidlo identity vůbec vyhodnotí, a příznakem je tunel lokality bez odpovídajícího SA, nikoli chyba NAT.

Test, který vám řekne, kterou větev jste postavili

Použijte vlastní vyhodnocení cesty na ASA místo čtení konfigurace a doufání. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed ukazuje rozhodnutí NAT, trasu a výsledek ACL pro jeden tok; zopakujte to s privátním cílem. Pokud fáze NAT přepisuje tok z privátního do privátního, postavili jste větev A pro paket, který potřeboval větev B.

Další dva příkazy mezeru uzavřou. show nat detail vypíše pořadí pravidel, které packet-tracer sledoval, a show crypto ipsec sa ukáže, zda pro očekávanou dvojici existuje selektor. Chybějící SA je věc konfigurace selektoru nebo peeru, ne něco, co pravidlo NAT opraví.

Ověřte každou větev provozem, kterému slouží

Přijměte větev A běžným veřejným požadavkem klienta a větev B požadavkem na privátní prostředek, který skutečně existuje. Pak každou zopakujte se zamítnutým prostředkem, protože „povoleno“ a „schváleno přístupovou politikou“ nejsou stejný důkaz, a ping vzniklý v hubu necvičí ani jednu klientskou cestu.

Držte oba záznamy testů v tiketu oddělené: zdrojová adresa, cíl, pravidlo NAT, které se shodovalo, a výsledek. Když příští zpráva řekne „VPN je rozbitá“, tato dvojice vám během minuty řekne, která větev se zhoršila, a odpovědí je obvykle trasa nebo selektor, ne řádek stejného rozhraní, který všichni podezřívají jako první.

Související články