Môže jedno rozhranie WAN obsluhovať VPN medzi lokalitami aj vzdialený prístup?

Jedna verejná adresa môže súčasne obsluhovať tunel pobočky a fond roamingových používateľov. Nemôže však obsluhovať jedno spoločné pravidlo prijatia. Partner pobočky a roamingový používateľ sa líšia tým, kým sa vyhlasujú, ako sa tento dôkaz overuje, aké adresy dostávajú a ktoré prefixy im smú odpovedať. Keď začnete vonkajšiu adresu brať ako dopravný detail a nie ako identitu, návrh sa výrazne zjednoduší.

Rýchly test zdravého rozumu: skúste napísať oba záznamy prijatia, skôr než sa dotknete routera. Ak jedna podmienka párovania musí pokryť obe, politika je už nejednoznačná a prvý príznak bude vyzerať ako porucha smerovania alebo firewallu, hoci v skutočnosti ide o poruchu identity.

Dva záznamy pred akoukoľvek konfiguráciou

Záznam pobočky je krátky a stabilný. Uvádza adresu partnera alebo názov certifikátu, vopred zdieľaný kľúč alebo trustpoint certifikátu, chránené podsiete na oboch stranách, rozhranie tunela a statickú trasu, ktorá posiela premávku k pobočke do tohto tunela. Každé pole sa týka jedného známeho partnera a pevnej množiny prefixov.

Záznam roamingu je širší a osobnejší. Uvádza protokol a port klienta, ako sa používateľ alebo zariadenie autentifikuje, fond adries prideľovaný pri pripojení, zdroje, ku ktorým tento fond smie dosiahnuť, prefixy rozdeleného tunela, servery DNS tlačené ku klientovi a akýkoľvek druhý faktor. Každé pole odpovedá na otázku o neznámom počte používateľov, a nie o jednej bráne.

Práve tento rozdiel v podrobnosti je celý dôvod, prečo sa obe roly rozchádzajú. Profil pobočky môže bezpečne dôverovať jednému kľúču, pretože kľúč patrí jednému zariadeniu na jednom mieste. Profil roamingu, ktorý dôveruje jednému skupinovému kľúču pre všetkých, ničí zodpovednosť na používateľa, a to sa zvyčajne zistí neskôr, pri analýze incidentu a nie pri zavádzaní.

Kde sa rozchádzajú párovanie partnerov a autentifikácia

Na IOS XE nesie profil IKEv2 parametre, o ktorých sa nedá vyjednávať, a podmienky používané na výber partnera. To znamená, že strana pobočky aj strana roamingu potrebujú každá vlastný profil, aj keď končia na tom istom rozhraní a aj keď zdieľajú jednu kryptografickú PKI. Cisco dokumentuje roly profilu, autentifikácie a párovania vo svojej príručke na konfiguráciu IKEv2 pre IOS XE 17.

Profil pobočky zvyčajne páruje úzku identitu: vzdialenú adresu, FQDN alebo subjekt certifikátu. Niečo ako match identity remote address 198.51.100.10 255.255.255.255 pripne jedného partnera a authentication remote pre-share s kľúčom uloženým pre každé miesto stačí. Držte párovanie čo najkonkrétnejšie, ako inventár partnerov dovolí, pretože prekrývajúci sa zástupný znak vyššie v poradí výberu môže stiahnuť premávku pobočky do nesprávneho profilu.

Profil roamingu nemôže pripnúť adresu, preto páruje skupinu, key-id alebo pole certifikátu a potom skutočnú kontrolu používateľa odovzdá AAA alebo autorizačnej politike pripojenej k profilu. Toto rozdelenie je dôležité: autentifikácia partnera odpovedá, či klient smie postaviť tunel, a autorizácia na používateľa odpovedá, ktorý fond a ktoré zdroje dostane. Použitie kľúča pobočky ako univerzálneho prihlásenia zahadzuje druhú odpoveď.

Preposielanie a preklad potrebujú rovnaké rozdelenie

Prijatie a dostupnosť sú oddelené problémy. Úspešná výmena IKE a IPsec dokazuje, že strany sa zhodujú na kľúčoch; nevytvára trasu k fondu, ktorý klient dostal. Fondy vzdialeného prístupu preto potrebujú návratovú cestu: buď statickú trasu na rozhranie tunela, alebo smerovací protokol, ktorý vkladá zhrnutie fondu. Prefixy pobočky zvyčajne prichádzajú tým istým smerovacím procesom, ktorý obsluhuje zvyšok lokality.

Preklad je miesto, kde sa obe roly najčastejšie zrážajú. Premávka medzi lokalitami, ktorá si musí zachovať svoje privátne adresy, potrebuje výnimku z NAT obmedzenú na tieto dva prefixy, v oboch smeroch. Roamingoví klienti zvyčajne potrebujú výnimku aj pre premávku v tuneli, ale ich premávka do internetu buď obchádza tunel rozdeleným tunelom, alebo vychádza v koncentrátore po NAT. Vynímať všetko, čo prichádza z tunela, je klasická chyba, pretože to berie preklad aj premávke, ktorá ho naozaj potrebuje.

Držte pravidlá výnimky rovnako úzke ako pravidlá prijatia. Ak sa zhrnutie fondu a prefix pobočky prekryjú, návratová cesta sa stane nejednoznačnou dávno predtým, než sa zahodí čo i len jeden paket, a príznak sa prejaví ako lokalita, ktorá občas stratí podsieť, a nie ako čistá porucha tunela.

Preberacie prípady, ktoré odhalia skríženú politiku

Postavte štyri prípady a spusťte ich v poradí. Hostiteľ v pobočke dosiahne zdroj len pre pobočku. Roamingový klient dosiahne ten istý zdroj cez adresu zo svojho fondu. Roamingový klient skúša prefix pobočky, ktorý by sa nemal dotknúť. Partner pobočky sa pokúša získať adresu z fondu vzdialeného prístupu. Posledné dva prípady chytajú zdieľaný profil, pretože v bežnom monitorovaní zlyhávajú ticho.

Potom potvrďte dátovú rovinu, a nie konfiguráciu. show crypto ikev2 sa a show crypto ipsec sa povedia, ktorý profil a ktoré selektory niesli každý tok, zatiaľ čo show ip nat translations a počítadlá tunela ukážu, či návratová cesta a výnimka skutočne sedeli. Trasovanie alebo zachytávanie paketov na rozhraní tunela uzatvára slučku.

Zapíšte pozorovanú identitu, adresu z fondu a zvolenú politiku vedľa každého výsledku. Beh je hotový, keď každý prípad zodpovedá presne jednému záznamu a žiadny prípad nepotrebuje dočasnú výnimku, aby prešiel.