Může jedno rozhraní WAN obsloužit VPN mezi lokalitami a vzdálený přístup?

Jedna veřejná adresa může současně obsluhovat tunel pobočky a fond roamingových uživatelů. Nemůže ale obsloužit jedno sdílené pravidlo přijetí. Protějšek pobočky a roamingový uživatel se liší v tom, kým se prokazují, jak se tento důkaz ověřuje, jaké adresy dostávají a které prefixy jim smějí odpovídat. Jakmile začnete vnější adresu brát jako dopravní detail a ne jako identitu, návrh se výrazně zjednoduší.

Rychlý test střízlivosti: zkuste napsat oba záznamy přijetí, než se dotknete routeru. Pokud má jedna podmínka párování pokrýt oba, je politika už teď nejednoznačná a první příznak bude vypadat jako porucha směrování nebo firewallu, i když jde ve skutečnosti o poruchu identity.

Dva záznamy před jakoukoli konfigurací

Záznam pobočky je krátký a stabilní. Uvádí adresu protějšku nebo jméno certifikátu, předsdílený klíč nebo trustpoint certifikátu, chráněné podsítě na obou stranách, rozhraní tunelu a statickou trasu, která posílá provoz směrem k pobočce do tohoto tunelu. Každé pole se týká jednoho známého protějšku a pevné sady prefixů.

Záznam roamingového přístupu je širší a osobnější. Uvádí protokol a port klienta, jak se uživatel nebo zařízení autentizuje, fond adres přidělovaný při připojení, prostředky, na které tento fond smí dosáhnout, prefixy rozděleného tunelu, DNS servery předávané klientovi a případný druhý faktor. Každé pole odpovídá na otázku o neznámém počtu uživatelů, ne o jedné bráně.

Právě tento rozdíl v podrobnosti je celý důvod, proč se obě role rozcházejí. Profil pobočky může bezpečně věřit jednomu klíči, protože klíč patří jednomu zařízení na jednom místě. Profil roamingu, který věří jednomu skupinovému klíči pro všechny, boří odpovědnost po jednotlivých uživatelích, což se obvykle zjistí později, při analýze incidentu a ne při zavádění.

Kde se rozchází párování protějšku a autentizace

Na IOS XE nese profil IKEv2 parametry, o kterých nelze vyjednávat, a podmínky používané k výběru protějšku. To znamená, že strana pobočky i strana roamingu potřebují každá vlastní profil, i když končí na stejném rozhraní a i když sdílejí jednu kryptografickou PKI. Cisco popisuje role profilu, autentizace a párování ve své příručce pro konfiguraci IKEv2 na IOS XE 17.

Profil pobočky obvykle páruje úzkou identitu: vzdálenou adresu, FQDN nebo subjekt certifikátu. Něco jako match identity remote address 198.51.100.10 255.255.255.255 připne jeden protějšek a authentication remote pre-share s klíčem uloženým pro každé místo stačí. Držte párování co nejkonkrétnější, jak inventář protějšků dovolí, protože překrývající se zástupný znak výše v pořadí výběru může stáhnout provoz pobočky do špatného profilu.

Profil roamingu nemůže připnout adresu, takže páruje skupinu, key-id nebo pole certifikátu a skutečnou kontrolu uživatele pak předá AAA nebo autorizační politice připojené k profilu. Na tomto rozdělení záleží: autentizace protějšku odpovídá na to, zda klient smí postavit tunel, a autorizace po uživateli odpovídá na to, který fond a které prostředky dostane. Použití klíče pobočky jako univerzálního přihlášení zahazuje druhou odpověď.

Předávání a překlad potřebují stejné rozdělení

Přijetí a dosažitelnost jsou oddělené problémy. Úspěšná výměna IKE a IPsec dokazuje, že strany souhlasí s klíči; nevytváří trasu k fondu, který klient dostal. Fondy vzdáleného přístupu proto potřebují zpětnou cestu, buď statickou trasu na rozhraní tunelu, nebo směrovací protokol, který vloží souhrn fondu. Prefixy pobočky obvykle přicházejí stejným směrovacím procesem, který obsluhuje zbytek lokality.

Překlad je místo, kde se obě role nejčastěji srážejí. Provoz mezi lokalitami, který si musí ponechat své privátní adresy, potřebuje výjimku z NAT omezenou na tyto dva prefixy, v obou směrech. Roamingoví klienti obvykle potřebují výjimku i pro provoz v tunelu, ale jejich provoz do internetu buď tunel obchází rozděleným tunelem, nebo vychází na koncentrátoru po NAT. Vynětí všeho, co přichází z tunelu, je klasická chyba, protože zároveň bere překlad provozu, který ho opravdu potřebuje.

Držte pravidla výjimky stejně úzká jako pravidla přijetí. Pokud se souhrn fondu a prefix pobočky překryjí, zpětná cesta je nejednoznačná dávno předtím, než se zahodí jediný paket, a příznak se projeví jako lokalita, která občas ztratí podsíť, a ne jako čistá porucha tunelu.

Přejímací případy, které odhalí kříženou politiku

Postavte čtyři případy a spusťte je v pořadí. Host v pobočce dosáhne na prostředek jen pro pobočku. Roamingový klient dosáhne na stejný prostředek přes adresu ze svého fondu. Roamingový klient zkouší prefix pobočky, kterého se nemá dotýkat. Protějšek pobočky se snaží získat adresu z fondu vzdáleného přístupu. Poslední dva případy chytají sdílený profil, protože v běžném monitoringu selhávají tiše.

Pak potvrďte datovou rovinu, ne konfiguraci. show crypto ikev2 sa a show crypto ipsec sa řeknou, který profil a které selektory nesly každý tok, zatímco show ip nat translations a počítadla tunelu ukážou, zda zpětná cesta a výjimka skutečně sedly. Trasování nebo snímání paketů na rozhraní tunelu uzavře smyčku.

Zapište pozorovanou identitu, adresu z fondu a zvolenou politiku vedle každého výsledku. Běh je hotový, když každý případ odpovídá právě jednomu záznamu a žádný případ nepotřebuje k průchodu dočasnou výjimku.