Úvod

Virtual Connect je další možnost doplňku pro připojení cloudu k vyhrazené instanci pro volání Webex (vyhrazená instance). Služba Virtual Connect umožňuje zákazníkům bezpečně rozšířit privátní síť přes internet pomocí tunelů VPN typu point-to-point IP. Tato možnost připojení poskytuje rychlé navázání připojení k privátní síti pomocí stávajícího zařízení CPE (Customer Premise Equipment) a připojení k internetu.

Společnost Cisco hostuje, spravuje a zajišťuje redundantní tunely IP VPN a požadovaný přístup k Internetu v oblastech datacentra vyhrazené instance společnosti Cisco, kde je služba vyžadována. Podobně je administrátor zodpovědný za odpovídající CPE a internetové služby, které jsou vyžadovány pro zřízení Virtual Connect.

Každá objednávka virtuálního připojení v konkrétní oblasti vyhrazené instance by zahrnovala dva tunely GRE (Generic Routing Encapsulation) chráněné šifrováním IPSec (GRE over IPSec), jeden do každého datacentra společnosti Cisco ve vybrané oblasti.

Virtual Connect má limit šířky pásma 250 Mb/s na tunel a doporučuje se pro menší nasazení. Vzhledem k tomu, že se používají dva tunely VPN typu point-to-point, veškerý provoz do cloudu musí projít zákaznickým headendem CPE, a proto nemusí být vhodný tam, kde je mnoho vzdálených míst. Další alternativní možnosti partnerského vztahu najdete v tématu připojení ke cloudu.

Než odešlete požadavek na peering pro Virtual Connect, ujistěte se, že je v dané oblasti aktivována služba Dedicated Instance.

Požadavky

Mezi předpoklady pro vytvoření služby Virtual Connect patří:

  • Zákazník poskytuje

    • Připojení k Internetu s dostatečnou dostupnou šířkou pásma pro podporu nasazení

    • Veřejné IP adresy pro dva tunely IPSec

    • IP adresy GRE pro přenos na straně zákazníka pro dva tunely GRE

  • Partner a zákazník

    • Spolupráce při vyhodnocování požadavků na šířku pásma

    • Zajistěte, aby síťová zařízení podporovala směrování protokolu BGP (Border Gateway Protocol) a návrh tunelového propojení GRE přes IPSec

  • Partner nebo zákazník poskytuje

    • Síťový tým se znalostí technologií VPN tunelů typu site-to-site

    • Síťový tým se znalostí BGP, eBGP a obecných principů směrování

  • Cisco

    • Společnost Cisco přiřadila rozhraní tunelového propojení GRE privátní čísla automatických systémů (ASN) a přechodné adresování IP

    • Společnost Cisco přiřadila veřejnou, ale ne internetovou směrovatelnou síť třídy C (/24) pro adresování dedicated Instance Cloud

Pokud má zákazník pouze 1 zařízení CPE, budou 2 tunely směrem k datovým centrům společnosti Cisco (DC1 a DC2) v každé oblasti z tohoto zařízení CPE. Zákazník má také možnost pro 2 zařízení CPE, pak by se každé zařízení CPE mělo připojit k 1 tunelu pouze směrem k datovým centrům společnosti Cisco (DC1 a DC2) v každé oblasti. Další redundance lze dosáhnout ukončením každého tunelu v samostatné fyzické lokalitě/umístění v rámci infrastruktury zákazníka.

Technické údaje

Model nasazení

Virtual Connect používá dvouvrstvou architekturu předávacího objektu, kde směrovací a řídicí roviny GRE jsou poskytovány jedním zařízením a řídicí rovina protokolu IPSec je poskytována jiným zařízením.

Po dokončení připojení Virtual Connect budou vytvořeny dva tunely GRE přes IPSec mezi podnikovou sítí zákazníka a vyhrazenou instancí datových center Cisco. Jedno pro každé redundantní datové centrum v rámci příslušné oblasti. Další síťové prvky potřebné pro partnerský vztah vyměňuje partner nebo zákazník společnosti Cisco prostřednictvím aktivačního formuláře Control Hub Virtual Connect.

Níže uvedený obrázek ukazuje příklad modelu nasazení virtuálního připojení pro variantu se 2 koncentrátory na straně zákazníka.

Virtual Connect - VPN je návrh rozbočovače, kde jsou lokality rozbočovače zákazníka připojeny k DC1 a DC2 datových center vyhrazené instance v rámci konkrétní oblasti.

Pro lepší redundanci se doporučují dvě centrální lokality, ale jedna centrální lokalita se dvěma tunely je také podporovaným modelem nasazení.

Šířka pásma na tunel je omezena na 250 Mb/s. Aby bylo zajištěno efektivní přepnutí na záložní systém, nesmí kombinovaný provoz přes obě tunely překročit 250 Mb/s, protože v případě selhání bude veškerý provoz směrován přes jeden tunel.

Vzdálená pracoviště zákazníka ve stejné oblasti by se musela připojit zpět k lokalitám centra přes síť WAN zákazníka a za toto připojení není odpovědná společnost Cisco.

Od partnerů se očekává úzká spolupráce se zákazníky a zajištění výběru nejoptimálnější cesty pro oblast služeb Virtual Connect.

Níže uvedený obrázek znázorňuje peeringové oblasti pro cloudové připojení vyhrazené instance.

Virtuální propojovací oblasti

Směrování

Směrování pro doplněk Virtual Connect je implementováno pomocí externího protokolu BGP (eBGP) mezi vyhrazenou instancí a zařízením CPE (Customer Premise Equipment). Společnost Cisco bude inzerovat svou příslušnou síť pro každý redundantní řadič domény v rámci oblasti CPE zákazníka a CPE je povinna inzerovat výchozí trasu do společnosti Cisco.

  • Společnost Cisco udržuje a přiřazuje

    • Ip adresování tunelového rozhraní (přechodná linka pro směrování) Cisco přiřazuje z určeného sdíleného adresního prostoru (neveřejně směrovatelného)

    • Adresa pro popisování tunelového přenosu (strana Cisco)

    • Čísla privátních autonomních systémů (ASN) pro konfiguraci směrování protokolu BGP zákazníka

      • Společnost Cisco přiřazuje z určeného rozsahu soukromého použití: 64512 až 65534

  • eBGP používaný k výměně tras mezi vyhrazenou instancí a CPE

    • Cisco rozdělí přiřazenou síť /24 na 2 /25 pro každý řadič domény v příslušné oblasti

    • Ve službě Virtual Connect je každá síť /25 inzerována zpět do CPE společností Cisco prostřednictvím příslušných tunelů VPN typu point-to-point (přechodná linka)

    • CPE musí být nakonfigurován s příslušnými sousedy eBGP. Pokud používáte jeden CPE, použijí se dva sousedé eBGP, z nichž jeden ukazuje na každý vzdálený tunel. Pokud používáte dva CPE, pak každý CPE bude mít jednoho souseda eBGP, který se připojí k jedinému vzdálenému tunelu pro CPE.

    • Cisco strana každého tunelu GRE (IP rozhraní tunelového propojení) je nakonfigurována jako soused protokolu BGP na CPE

    • CPE je vyžadováno k inzerci výchozí trasy přes každý z tunelů

    • CPE je zodpovědná za redistribuci naučených tras v rámci podnikové sítě cutomeru podle potřeby.

  • V případě selhání linky bez selhání bude mít jeden CPE dva aktivní/aktivní tunely. Pro dva uzly CPE bude mít každý CPE jeden aktivní tunel a oba uzly CPE by měly být aktivní a předávající provoz. Ve scénáři bez selhání musí být provoz rozdělen do dvou tunelů směřujících do správných cílů /25, pokud jeden z tunelů klesne, zbývající tunel může přenášet provoz pro oba. V takovém scénáři selhání, když je síť /25 mimo provoz, pak se síť /24 použije jako záložní trasa. Cisco bude posílat zákaznický provoz prostřednictvím své interní wan směrem k řadiči domény, který ztratil připojení.

Tok provozu virtuálního připojení

Plynulost dopravy, když jsou oba tunely v provozu

Vyhrazená instance – virtuální připojení

Tento obrázek znázorňuje architekturu sítě Virtual Connect a podrobně popisuje tok provozu, když jsou v provozu primární i sekundární tunely.

Představuje aktivní model konektivity, který umožňuje zákazníkovi přístup k aplikacím sjednocené komunikace hostovaným v datových centrech společnosti Cisco a využívá duální... GRE/IPSEC tunely přes internet s BGP pro výměnu tras.

Definice:

  • Prostory zákazníka:
    • Toto představuje síť zákazníka v místě instalace, kde se nacházejí uživatelé a jejich zařízení (např. IP telefony, počítače s klienty sjednocené komunikace).
    • Provoz odtud pocházející musí dosáhnout aplikací sjednocené komunikace hostovaných v datových centrech společnosti Cisco.
  • Datová centra Cisco Webex Calling Dedicated Instance (Dedicated Instance) (WxC-DI DC-A a WxC-DI DC-B):
    • Toto jsou datová centra společnosti Cisco, která hostují aplikace sjednocené komunikace.
    • DC-A a DC-B jsou geograficky odlišné, což zajišťuje redundanci.
    • Každé datové centrum má svou vlastní podsíť pro aplikace sjednocené komunikace:
      • DC-A subnet:X.X.X.0/25
      • DC-B subnet:X.X.X.128/25
  • GRE/IPsec Tunely (Tunel 1 a Tunel 2):
    • Jedná se o bezpečná, šifrovaná spojení mezi zákaznickým prostorem a datovým centrem Cisco přes veřejný internet.
    • GRE (Generické zapouzdření směrování): Tento protokol se používá k zapouzdření různých protokolů síťové vrstvy uvnitř virtuálních spojení typu point-to-point. Umožňuje provoz směrovacích protokolů, jako je BGP, přes tunel.
    • IPsec (zabezpečení internetového protokolu): Tato sada protokolů poskytuje kryptografické bezpečnostní služby (autentizace, integrita, důvěrnost) pro IP komunikaci. Šifruje provoz zapouzdřený pomocí GRE, čímž zajišťuje bezpečný přenos dat přes internet.
  • Protokol hraniční brány (BGP):
    • BGP je směrovací protokol používaný k výměně směrovacích informací mezi zákaznickou lokalitou a datovými centry Cisco.

Jak je znázorněno na výše uvedeném diagramu, zařízení nasazená v prostorách zákazníka musí navázat dvě GRE/IPSEC tunely.

Níže uvedené konvence pojmenování s XX / YY, DC-A DC-B jsou obecné pro všechny regiony, kde je nabízena vyhrazená instance. Tyto hodnoty budou pro každý region jedinečné a skutečné hodnoty pro každý region. Konkrétní hodnoty jsou poskytovány během aktivace virtuálního připojení.

Na straně Cisco budou tunely IPSec a GRE ukončeny na různých zařízeních. Zákazník se tedy musí ujistit, že na zařízeních odpovídajícím způsobem nakonfiguruje cílové IP adresy IPSec a GRE. Zákazníci mohou používat stejnou IP adresu pro GRE a IPSEC, pokud je to na jejich zařízeních podporováno. Viz výše uvedený diagram. Hodnoty související s IP adresou jsou poskytovány během aktivace virtuálního připojení na portálu.

  • Tunel 1: Připojuje prostory zákazníka k „vyhrazené instanci DC-A“ (datové centrum A) přes internet. Tento tunel používá BGP AS:64XX1 na straně zákazníka a BGP AS:64XX2 na straně vyhrazené instance DC-A. Konfigurace zdrojů tunelů IPSEC a GRE jsou rozděleny mezi podrobnosti poskytnuté zákazníkem a podrobnosti poskytnuté společností Cisco.
  • Tunel 2: Připojuje prostory zákazníka k „dedikované instanci DC-B“ (datovému centru B) přes internet. Tento tunel používá BGP AS:64YY1 na straně zákazníka a BGP AS:64YY2 na straně vyhrazené instance DC-B. Stejně jako u tunelu 1 jsou konfigurace zdrojů tunelů IPSEC a GRE sdíleny mezi zákazníkem a společností Cisco.

V protokolu BGP AS:64XX a BGP AS:64YY, XX a YY jsou specifické pro konkrétní region.

Jakmile GRE/IPSEC Pokud jsou tunely zřízeny do datových center vyhrazených instancí Webex Calling (A a B), měl by zákazník obdržet následující trasy inzerované společností Cisco prostřednictvím odpovídajících relací BGP.

  • Pro DC-A: Trasy inzerované společností Cisco budou X.X.X.0/25 a X.X.x.0/24. Volitelně, pokud je IaaS vyžádána a nakonfigurována pro zákaznické trasy Y.Y.Y.0/25 a Y.Y.Y.0/24 bude inzerováno společností Cisco.
  • Pro DC-B: Trasy inzerované společností Cisco budou X.X.X.128/25 a X.X.x.0/24. Volitelně, pokud je IaaS vyžádána a nakonfigurována pro zákaznické trasy Y.Y.Y.128/25 a Y.Y.Y.0/24 bude inzerováno společností Cisco.
  • Zákazník potřebuje inzerovat 0.0.0./0 cesta k Ciscu přes obě připojení (tunely)
  • Zákazník musí dodržovat nejdelší prefix (/25) trasy pro odesílání provozu do Cisco přes příslušné tunely, když jsou oba tunely v provozu.
  • Společnost Cisco bude vracet provoz přes stejné tunely, aby zachovala symetrii provozu.

Tok dopravy:

  • Provoz směřující pro „DC-A UC Apps“ (X.X.X.0/25) z prostor zákazníka protéká tunelem 1.
  • Provoz směřující pro „DC-B UC Apps“ (X.X.X.128/25) z prostor zákazníka protéká tunelem 2.

Scénář přepnutí při selhání : plynulosti dopravy, když je jeden z tunelů neprůjezdný

Vyhrazená instance – virtuální připojení

Jak je znázorněno na výše uvedeném diagramu, když je tunel do DC-A nefunkční, přeruší se i BGP navázaný tunelem do DC-A.

Dopad na protokol BGP: Když dojde k výpadku tunelu 1, dojde také k výpadku relace BGP přes tento tunel. V důsledku toho již nebude DC-A moci inzerovat své trasy (konkrétně X.X.X.0/25) k zákazníkovi touto cestou. Zákaznický router proto detekuje cestu jako nedostupnou.

Protože je tunel 1 nefunkční, zákaznický router v prostorách zákazníka automaticky odstraní trasy zjištěné přes tunel 1 ze své směrovací tabulky nebo je označí jako nedostupné.

  • Provoz směřující do sítě UC App Network (X.X.X.0/24) nebo podsíť DC-A (X.X.X.0/25) bude poté přesměrován pracovním tunelem směrem k DC-B, který bude i nadále inzerovat X.X.X.0/24 což zahrnuje X.X.X.0/25 síť.
  • Podobné chování bude pozorováno, pokud je tunel do DC-B nefunkční, zatímco tunel do DC-A je stále v provozu.

Proces připojení

Následující kroky vysoké úrovně popisují, jak vytvořit připojení pomocí virtuálního připojení pro vyhrazenou instanci.
1

Zadat objednávku v Cisco CCW

2

Aktivace služby Virtual Connect z Control Hubu

3

Cisco provádí konfiguraci sítě

4

Zákazník provádí konfiguraci sítě

Krok 1: Objednávka CCW

Virtual Connect je doplněk pro Dedicated Instance v CCW.

1

Přejděte na objednávkový web CCW a kliknutím na tlačítko Přihlásit se přihlaste k webu:

2

Vytvořit odhad.

3

Přidejte SKU "A-FLEX-3".

4

Vyberte Možnosti úprav.

5

Na kartě předplatného, která se zobrazí, vyberte Možnosti a Doplňky.

6

V části Další doplňky zaškrtněte políčko vedle položky "Virtual Connect for Dedicated Instance". Název SKU je "A-FLEX-DI-VC".

7

Zadejte množství a počet oblastí, ve kterých je služba Virtual Connect vyžadována.

Množství Služby Virtual Connect by nemělo překročit celkový počet oblastí zakoupených pro vyhrazenou instanci. V každé oblasti je také povolena pouze jedna objednávka služby Virtual Connect.
8

Až budete s výběrem spokojeni, klikněte na Ověřit a uložit v pravé horní části stránky.

9

Kliknutím na tlačítko Uložit a pokračovat dokončete objednávku. Vaše dokončená objednávka se nyní nachází v mřížce objednávek.

Krok 2: Aktivace Virtual Connect v Control Hubu

1

Přihlaste se k Centru řízení https://admin.webex.com/login.

2

V části Služby přejděte na Volání > Vyhrazené připojení instacnce > cloudu.

3

Na kartě Virtual Connect je uvedeno zakoupené množství Virtual Connect. Správce nyní může kliknutím na tlačítko Aktivovat zahájit aktivaci Virtual Connect.

Proces aktivace mohou aktivovat pouze správci s rolí "Úplný správce zákazníka". Zatímco správce s rolí "Správce jen pro čtení zákazníka" může zobrazit pouze stav.
4

Po kliknutí na tlačítko Aktivovat se zobrazí formulář Aktivovat virtual Connect , ve kterém správce poskytne technické podrobnosti o virtual Connect vyžadované pro konfigurace partnerského vztahu na straně společnosti Cisco.

Formulář také poskytuje statické informace na straně společnosti Cisco na základě vybrané oblasti. Tyto informace budou užitečné pro správce zákazníků při konfiguraci CPE na jejich straně pro navázání připojení.
  1. IP adresa tunelového transportu GRE: Zákazník je povinen poskytnout ADRESy IP adresy tunnel transportu na straně zákazníka a společnost Cisco dynamicky přidělí ADRESY IP po dokončení aktivace. Seznam IPSec ACL pro zajímavý provoz by měl umožnit místní přenos tunelu IP/32 na vzdálený přenos tunelu IP/32. Seznam ACL by měl také specifikovat pouze protokol GRE IP.

    IP adresa poskytnutá zákazníkem může být soukromá nebo veřejná.
  2. Protějšky IPSec: Zákazník je povinen zadat zdrojové adresy IP tunelu IPSec a společnost Cisco přidělí cílovou adresu IPSec. V případě potřeby je také podporováno provedení překladu interní adresy tunelového propojení IPSEC na veřejnou adresu.

    IP adresa poskytnutá zákazníkem by měla být veřejná.

    Všechny ostatní statické informace uvedené na aktivační obrazovce jsou dodržovány bezpečnostní a šifrovací standardy společnosti Cisco. Tato statická konfigurace není přizpůsobitelná ani upravitelná. Pro jakoukoli další pomoc týkající se statických konfigurací na straně společnosti Cisco by se zákazník musel obrátit na TAC.
5

Po vyplnění všech povinných polí klikněte na tlačítko Aktivovat .

6

Po vyplnění formuláře Aktivace služby Virtual Connect pro oblast particluar může zákazník exportovat aktivační formulář z Control Hubu, volání > vyhrazenou instanci > kartu Připojení ke cloudu a kliknout na nastavení exportu.

Z bezpečnostních důvodů nebudou ověřování a heslo BGP k dispozici v exportovaném dokumentu, ale administrátor si je může prohlédnout v Control Hub kliknutím na Zobrazit nastavení v části Control Hub, Volání > Vyhrazená instance > Karta Připojení ke cloudu.

Krok 3: Cisco provádí konfiguraci sítě

1

Po dokončení formuláře Aktivace služby Virtual Connect se stav aktualizuje na Probíhá aktivace při volání > vyhrazené instance > karta Virtual Connect připojení ke cloudu.

2

Společnost Cisco dokončí požadované konfigurace na svých zařízeních do 5 pracovních dnů. Po úspěšném dokončení bude stav aktualizován na "Aktivováno" pro danou oblast v Centru řízení.

Krok 4: Zákazník provádí konfiguraci sítě

Stav se změní na "Aktivováno", aby byl správce zákazníka upozorněn, že konfigurace společnosti Cisco pro připojení IP VPN byla dokončena na základě vstupů poskytnutých zákazníkem. Očekává se však, že správce zákazníka dokončí svou stranu konfigurací na CPE a otestuje trasy připojení pro tunel Virtual Connect, aby byl online. V případě jakýchkoli problémů, kterým se zákazník potýká v době konfigurace nebo připojení, se může obrátit na Cisco TAC s žádostí o pomoc.

Řešení problémů

Řešení problémů a ověření první fáze IPsec (vyjednávání IKEv2)

Vyjednávání tunelu IPsec zahrnuje dvě fáze, fázi IKEv2 a fázi IPsec. Pokud se vyjednávání fáze IKEv2 nedokončí, nedojde k zahájení druhé fáze IPsec. Nejprve zadejte příkaz „show crypto ikev2 sa“ (na zařízeních Cisco) nebo podobný příkaz na zařízeních třetí strany, abyste ověřili, zda je relace IKEv2 aktivní. Pokud relace IKEv2 není aktivní, možné důvody by mohly být:

  • Zajímavý provoz nespouští tunel IPsec.

  • Přístupový seznam tunelu IPsec je nesprávně nakonfigurován.

  • Mezi zákazníkem a koncovou IP adresou tunelu IPsec pro vyhrazenou instanci neexistuje žádné připojení.

  • Parametry relace IKEv2 se neshodují mezi stranou vyhrazené instance a stranou zákazníka.

  • Firewall blokuje pakety IKEv2 UDP.

Nejprve zkontrolujte protokoly IPsec, zda neobsahují zprávy, které ukazují průběh vyjednávání tunelu IKEv2. Protokoly mohou naznačovat, kde je problém s vyjednáváním IKEv2. Absence zpráv z protokolování může také znamenat, že relace IKEv2 není aktivována.

Mezi běžné chyby při vyjednávání IKEv2 patří:

  • Nastavení IKEv2 na straně CPE se neshoduje se stranou Cisco, zkontrolujte znovu uvedená nastavení:

    • Zkontrolujte, zda je verze IKE verze 2.

    • Ověřte, zda parametry šifrování a ověřování odpovídají očekávanému šifrování na straně vyhrazené instance.

      Pokud se používá šifra „GCM“, protokol GCM zpracovává ověřování a nastavuje parametr ověřování na hodnotu NULL.

    • Ověřte nastavení životnosti.

    • Ověřte Diffie-Hellmanovu grupu modulů.

    • Ověřte nastavení funkce Pseudo Random.

  • Přístupový seznam pro kryptomapu není nastaven na:

    • Povolení GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (nebo ekvivalentní příkaz)

      Přístupový seznam musí být určen výhradně pro protokol „GRE“ a protokol „IP“ nebude fungovat.

Pokud zprávy protokolu neukazují žádnou vyjednávací aktivitu pro fázi IKEv2, může být nutné zachytit pakety.

Strana vyhrazené instance nemusí vždy zahájit výměnu IKEv2 a někdy může očekávat, že iniciátorem bude strana CPE zákazníka.

Zkontrolujte konfiguraci na straně CPE, zda jsou splněny následující předpoklady pro zahájení relace IKEv2:

  • Zkontrolujte seznam přístupových práv IPsec pro kryptografický provoz GRE (protokol 50) z transportní IP adresy tunelu CPE do transportní IP adresy tunelu vyhrazené instance.

  • Ujistěte se, že je v tunelovém rozhraní GRE povoleno udržování synchronizace GRE. Pokud zařízení udržování synchronizace GRE nepodporuje, bude společnost Cisco upozorněna, protože udržování synchronizace GRE bude ve výchozím nastavení na straně vyhrazené instance povoleno.

  • Ujistěte se, že je protokol BGP povolen a nakonfigurován s adresou souseda IP adresy tunelu vyhrazené instance.

Po správné konfiguraci se spustí tunel IPsec a první fáze vyjednávání IKEv2:

  • Udržování aktivity GRE z rozhraní tunelu GRE na straně CPE do rozhraní tunelu GRE na straně vyhrazené instance.

  • BGP neighbor TCP relace od BGP neighbor na straně CPE k BGP neighbor na straně dedikované instance.

  • Odešlete příkaz ping z IP adresy tunelu na straně CPE na IP adresu tunelu na straně vyhrazené instance.

    Ping nemůže být IP adresa tunelu k transportní IP adrese tunelu, musí být IP adresa tunelu k IP adrese tunelu.

Pokud je pro provoz IKEv2 potřeba trasování paketů, nastavte filtr pro UDP a buď port 500 (pokud se uprostřed koncových bodů IPsec nenachází žádné zařízení NAT), nebo port 4500 (pokud je uprostřed koncových bodů IPsec vloženo zařízení NAT).

Ověřte, zda jsou pakety IKEv2 UDP s portem 500 nebo 4500 odesílány a přijímány na IP adresu DI IPsec a z ní.

Datové centrum vyhrazené instance nemusí vždy zahájit první paket IKEv2. Požadavek je, aby zařízení CPE bylo schopno iniciovat první paket IKEv2 směrem ke straně vyhrazené instance.

Pokud to lokální firewall umožňuje, zkuste také odeslat příkaz ping na vzdálenou IPsec adresu. Pokud příkaz ping z lokální na vzdálenou IPsec adresu neproběhne úspěšně, proveďte trasování trasy, abyste zjistili, kam byl paket zahozen.

Některé firewally a internetová zařízení nemusí trasování trasy umožňovat.

Řešení problémů a ověření druhé fáze IPsec (vyjednávání IPsec)

Před řešením problémů s druhou fází IPsec ověřte, zda je aktivní první fáze IPsec (tj. přidružení zabezpečení IKEv2). Pro ověření relace IKEv2 proveďte příkaz „show crypto ikev2 sa“ nebo ekvivalentní příkaz. Ve výstupu ověřte, zda je relace IKEv2 aktivní déle než několik sekund a zda se neruší. Doba provozuschopnosti relace se ve výstupu zobrazuje jako „doba aktivity“ relace nebo ekvivalent.

Jakmile se relace IKEv2 ověří jako aktivní, prozkoumejte relaci IPsec. Stejně jako u relace IKEv2 ověřte relaci IPsec pomocí příkazu „show crypto ipsec sa“ nebo ekvivalentního příkazu. Před navázáním tunelu GRE musí být aktivní relace IKEv2 i relace IPsec. Pokud se relace IPsec nezobrazuje jako aktivní, zkontrolujte protokoly IPsec, zda neobsahují chybové zprávy nebo chyby vyjednávání.

Mezi častější problémy, které se mohou vyskytnout během vyjednávání IPsec, patří:

Nastavení na straně CPE neodpovídá nastavení na straně vyhrazené instance, zkontrolujte nastavení znovu:

  • Ověřte, zda parametry šifrování a ověřování odpovídají nastavení na straně vyhrazené instance.

  • Ověřte nastavení Perfect Forward Secrecy a to, že se shodují s nastavením na straně vyhrazené instance.

  • Ověřte nastavení životnosti.

  • Ověřte, zda byl IPsec nakonfigurován v tunelovém režimu.

  • Ověřte zdrojovou a cílovou IPsec adresu.

Řešení problémů a validace rozhraní tunelu

Jakmile jsou relace IPsec a IKEv2 ověřeny jako aktivní, pakety keepalive tunelu GRE mohou proudit mezi koncovými body vyhrazené instance a tunelu CPE. Pokud se stav rozhraní tunelu nezobrazuje, existují některé běžné problémy:

  • VRF přenosového rozhraní tunelu neodpovídá VRF rozhraní zpětné smyčky (pokud je na rozhraní tunelu použita konfigurace VRF).

    Pokud se na rozhraní tunelu nepoužívá konfigurace VRF, lze tuto kontrolu ignorovat.

  • Na rozhraní tunelu na straně CPE nejsou povoleny funkce keepalive.

    Pokud zařízení CPE nepodporuje funkce keepalive, je nutné informovat společnost Cisco, aby byly výchozí funkce keepalive na straně vyhrazené instance také deaktivovány.

    Pokud jsou podporovány funkce keepalive, ověřte, zda jsou povoleny.

  • Maska nebo IP adresa tunelového rozhraní není správná a neodpovídá očekávaným hodnotám vyhrazené instance.

  • Zdrojová nebo cílová adresa tunelového přenosu není správná a neodpovídá očekávaným hodnotám vyhrazené instance.

  • Firewall blokuje pakety GRE odesílané do tunelu IPsec nebo přijímané z tunelu IPsec (tunel GRE je přenášen přes tunel IPsec).

Test ping by měl ověřit, že je lokální tunelové rozhraní funkční a že je dobré připojení k rozhraní vzdáleného tunelového rozhraní. Proveďte kontrolu ping z IP adresy tunelu (ne transportní IP adresy) na vzdálenou IP adresu tunelu.

Seznam kryptografických přístupů pro tunel IPsec, kterým je přenášen provoz tunelu GRE, umožňuje průchod pouze paketů GRE. V důsledku toho nebudou příkazy ping fungovat z IP adresy tunelového transportu na vzdálenou IP adresu tunelového transportu.

Výsledkem kontroly ping je paket GRE, který je generován ze zdrojové IP adresy tunelového propojení do cílové IP adresy tunelového propojení, přičemž užitečná hmotnost paketu GRE (vnitřní IP adresa) bude zdrojová a cílová IP adresa tunelového propojení.

Pokud test ping neproběhne úspěšně a předchozí položky jsou ověřeny, může být nutné zachytit paket, aby se ověřilo, že výsledkem testu ICMP ping je paket GRE, který je následně zapouzdřen do paketu IPsec a odeslán ze zdrojové adresy IPsec na cílovou adresu IPsec. Čítače na rozhraní tunelu GRE a čítače relací IPsec mohou také pomoci zobrazit, zda se odesílané a přijímané pakety zvyšují.

Kromě provozu ping by měl zachycený provoz zobrazovat také keepalive GRE pakety, a to i během nečinného provozu. A konečně, pokud je nakonfigurován protokol BGP, měly by být pakety BGP keepalive odesílány také jako pakety GRE zapouzdřené v paketech IPSEC přes VPN.

Řešení problémů a validace BGP

BGP relace

BGP je vyžadován jako směrovací protokol přes tunel VPN IPsec. Lokální soused BGP by měl navázat relaci eBGP se sousedem BGP vyhrazené instance. IP adresy sousedů eBGP jsou stejné jako IP adresy lokálního a vzdáleného tunelu. Nejprve se ujistěte, že je relace BGP spuštěna, a poté ověřte, zda jsou z dedikované instance přijímány správné trasy a zda je do dedikované instance odesílána správná výchozí trasa.

Pokud je tunel GRE spuštěný, ověřte, zda byl úspěšný příkaz ping mezi lokální a vzdálenou IP adresou tunelu GRE. Pokud je ping úspěšný, ale relace BGP se nenavazuje, prozkoumejte protokol BGP, zda v něm nejsou chyby při navazování BGP.

Mezi nejčastější problémy s vyjednáváním BGP patří:

  • Číslo vzdáleného AS se neshoduje s číslem AS nakonfigurovaným na straně vyhrazené instance, znovu zkontrolujte konfiguraci sousedního AS.

  • Číslo lokálního AS neodpovídá očekávání strany vyhrazené instance. Ověřte, zda číslo lokálního AS odpovídá očekávaným parametrům vyhrazené instance.

  • Firewall blokuje odesílání paketů BGP TCP zapouzdřených v paketech GRE do tunelu IPsec nebo jejich příjem z tunelu IPSEC.

  • Vzdálená IP adresa souseda BGP neodpovídá vzdálené IP adrese tunelu GRE.

Výměna tras BGP

Jakmile je relace BGP ověřena pro oba tunely, ujistěte se, že ze strany vyhrazené instance jsou odesílány a přijímány správné trasy.

Řešení VPN pro vyhrazené instance očekává vytvoření dvou tunelů z customer/partner strana. První tunel směřuje do datového centra dedikované instance A a druhý tunel směřuje do datového centra dedikované instance B. Oba tunely musí být v aktivním stavu a řešení vyžaduje active/active nasazení. Každé datové centrum vyhrazené instance bude inzerovat své lokální /25 trasa, stejně jako /24 záložní trasa. Při kontrole příchozích tras BGP z vyhrazené instance se ujistěte, že relace BGP přidružená k tunelu směřujícímu do datového centra vyhrazené instance A přijímá data z datového centra vyhrazené instance A. /25 místní trasa, stejně jako /24 záložní trasa. Dále se ujistěte, že tunel směřující do datového centra dedikované instance B přijímá data z datového centra dedikované instance B. /25 místní trasa, stejně jako /24 záložní trasa. Všimněte si, že /24 Záložní trasa bude stejná trasa, která je inzerována z datového centra dedikované instance A a datového centra dedikované instance B.

Redundance je poskytována datovému centru vyhrazené instance, pokud dojde k výpadku tunelového rozhraní k tomuto datovému centru. Pokud dojde ke ztrátě připojení k datovému centru vyhrazené instance A, bude provoz přesměrován z datového centra vyhrazené instance B do datového centra A. V tomto scénáři bude tunel do datového centra B používat datové centrum B. /25 trasa pro odesílání provozu do datového centra B a tunel do datového centra B bude používat záložní /24 trasa pro odesílání provozu do datového centra A přes datové centrum B.

Je důležité, aby v případě, že jsou oba tunely aktivní, nebyl tunel z datového centra A používán k odesílání provozu do datového centra B a naopak. V tomto scénáři, pokud je provoz odeslán do datového centra A s cílem datového centra B, datové centrum A přepošle provoz do datového centra B a poté se datové centrum B pokusí odeslat provoz zpět ke zdroji přes tunel datového centra B. To povede k neoptimálnímu směrování a může to také narušit provoz procházející firewally. Proto je důležité, aby oba tunely byly v active/active konfigurace během běžného provozu.

Ten/Ta/To 0.0.0.0/0 Trasa musí být inzerována ze strany zákazníka na stranu datového centra vyhrazené instance. Konkrétnější trasy nebudou stranou vyhrazené instance akceptovány. Zajistěte, aby 0.0.0.0/0 Trasa je inzerována z tunelu datového centra A vyhrazené instance i z tunelu datového centra B vyhrazené instance.

Konfigurace MTU

Na straně vyhrazené instance jsou povoleny dvě funkce pro dynamickou úpravu MTU pro velké velikosti paketů. GRE tunel přidává k IP paketům protékajícím relací VPN další hlavičky. Tunel IPsec přidává další hlavičky nad hlavičky GRE, což dále sníží největší povolenou hodnotu MTU v tunelu.

Tunel GRE upravuje funkci MSS a cesta tunelu GRE ve funkci zjišťování MTU je povolena na straně vyhrazené instance. Nakonfigurujte příkaz „ip tcp adjust-mss 1350“ nebo ekvivalentní a také „tunnel path\u0002mtu-discovery" nebo ekvivalentní příkaz na straně zákazníka, který pomůže s dynamickým nastavením MTU provozu přes VPN tunel.