Virtual Connect používá dvouúrovňovou architekturu headend, kde směrovací a řídicí rovina GRE je poskytována jedním zařízením a řídicí rovina IPSEC je poskytována jiným.

Po dokončení konektivity Virtual Connect budou vytvořeny dva tunely GRE přes IPSEC mezi podnikovou sítí Zákazníka a datovými centry Cisco vyhrazené instance. Jedno na každé redundantní datové centrum v rámci příslušné Oblasti. Další síťové prvky potřebné pro peeringu si partner nebo zákazník vyměňují se společností Cisco prostřednictvím aktivačního formuláře virtuálního připojení Control Hub.

Obrázek 1 ukazuje příklad modelu nasazení virtuálního připojení pro možnost 2-koncentrátoru na straně zákazníka.

Virtual Connect - VPN je design centra, kde jsou weby Customer’s Hub připojeny k DC1 a DC2 datových center vyhrazené instance v určité oblasti.

Pro lepší redundanci se doporučují dvě stránky rozbočovače, ale Jeden rozbočovač se dvěma tunely je také podporovaný model nasazení.

Šířka pásma na tunel je omezena na 250 Mb/s.

Vzdálené weby zákazníka v rámci stejné oblasti by se musely připojit zpět k webům centra přes síť WAN zákazníka a za toto připojení neodpovídá společnost Cisco.

Očekává se, že partneři budou úzce spolupracovat se Zákazníky a zajistí, aby byla zvolena optimální cesta pro oblast služeb „Virtual Connect“.

Obrázek 2 znázorňuje peeringové oblasti cloudové konektivity vyhrazené instance.

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

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

  • Adresování IP rozhraní tunelu (přechodný odkaz pro směrování) Společnost Cisco přiřadí z určeného sdíleného prostoru adres (neveřejného směrovatelného)

  • Adresa desitinace tunelové dopravy (strana společnosti Cisco)

  • Soukromá autonomní systémová čísla (ASNS) pro konfiguraci směrování BGP zákazníka

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

• ebgp používaný pro výměnu tras mezi vyhrazenou instancí a CPE

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

  • Ve virtuálním připojení je každá síť /25 společností Cisco inzerována zpět do CPE prostřednictvím příslušných dvoubodových tunelů VPN (přechodný odkaz)

  • CPE musí být nakonfigurován s příslušnými sousedy eBGP. Pokud používáte jeden CPE, budou použity dva eBGP sousedy, 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ý bude bušit k jedinému vzdálenému tunelu pro CPE.

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

  • CPE je povinna inzerovat výchozí trasu přes každý z tunelů

  • CPE je odpovědný za redistribuci, podle potřeby, naučené trasy v rámci podnikové sítě cutomer.

• Při neporušeném stavu spojení 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 projíždějící provoz. V případě nezávadného scénáře musí být provoz rozdělen do dvou tunelů směřujících do správných/25 destinací, pokud jeden z tunelů pojede dolů, zbývající tunel může nést provoz pro oba. V takovém případě, když je síť /25 dole, pak se síť /24 použije jako záložní trasa. Společnost Cisco pošle zákaznický provoz prostřednictvím interní sítě WAN do distribučního centra, které ztratilo připojení.

Jednání o tunelu IPSEC zahrnuje dvě fáze, fázi IKEv2 a fázi IPSEC. Pokud vyjednávání fáze IKEv2 není dokončeno, pak není zahájena druhá fáze IPSEC. Nejprve zadejte příkaz "show crypto ikev2 sa" (na zařízení Cisco) nebo podobný příkaz na zařízení třetí strany, abyste ověřili, zda je relace IKEV2 aktivní. Pokud relace IKEv2 není aktivní, potenciální důvody mohou být:

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

• Seznam přístupu k tunelu IPSEC je špatně nakonfigurován.

• Mezi zákazníkem a IP tunelového koncového bodu IPSEC vyhrazené instance není připojení.

• Parametry relace IKEv2 neodpovídají straně vyhrazené instance a straně zákazníka.

• Firewall blokuje IKEv2 UDP pakety.

Nejprve si v protokolech IPSEC prohlédněte všechny zprávy, které ukazují průběh vyjednávání tunelu IKEv2. Protokoly mohou naznačovat, kde je problém s jednáním IKEv2. Nedostatek protokolovacích zpráv může také naznačovat, že relace IKEV2 není aktivována.

Některé běžné chyby při vyjednávání IKEv2 jsou:

• Nastavení pro IKEv2 na straně CPE neodpovídají straně Cisco, znovu zkontrolujte 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.

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

  • Ověřte nastavení životnosti.

  • Ověřte skupinu modulů Diffie Hellman.

  • Ověřte nastavení pseudo náhodné funkce.

• Seznam přístupu pro mapu šifrování není nastaven na:

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

    Seznam přístupu musí být určen konkrétně pro protokol GRE a protokol IP nebude fungovat.

Pokud zprávy protokolu nezobrazují žádnou vyjednávací aktivitu pro fázi IKEv2, může být zapotřebí zachycení paketů.

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 strany CPE pro následující předpoklady pro zahájení relace IKEv2: Zkontrolujte seznam přístupu k šifrování IPSEC pro provoz GRE (protokol 50) z IP tunelového přenosu CPE do IP tunelového přenosu vyhrazené instance. Ujistěte se, že rozhraní tunelu GRE je povoleno pro keepalives GRE, pokud zařízení nepodporuje keepalives GRE, pak je společnost Cisco upozorněna, protože keepalives GRE budou ve výchozím nastavení povoleny na straně vyhrazené instance. Ujistěte se, že je protokol BGP povolen a nakonfigurován s adresou souseda adresy IP tunelu vyhrazené instance.

Při správné konfiguraci začíná tunel IPSEC a první fáze vyjednávání IKEv2:

• GRE keepalives z CPE bočního tunelového rozhraní GRE na straně vyhrazené instance.

• Relace TCP souseda protokolu BGP ze souseda protokolu BGP na straně CPE souseda protokolu BGP na straně vyhrazené instance.

• Ping z adresy IP bočního tunelu CPE na adresu IP bočního tunelu vyhrazené instance.

  Ping nemůže být tunelový transport IP na tunelový transport IP, musí to být tunel IP na tunel IP.

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

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

Datové centrum vyhrazené instance nemusí vždy spustit první paket IKEV2. Požadavek je, aby zařízení CPE bylo schopno iniciovat první paket IKEV2 směrem ke straně vyhrazené instance. Pokud to místní firewall umožňuje, zkuste také příkaz ping na vzdálenou adresu IPSEC. Pokud příkaz ping neproběhne z místní adresy na vzdálenou IPSEC, proveďte trasování, abyste pomohli, a určete, kde je paket upuštěn. Některé brány firewall a internetové vybavení nemusí umožňovat sledování trasy.

Před řešením potíží s druhou fází IPSEC ověřte, zda je aktivní první fáze IPSEC (tj. bezpečnostní asociace IKEv2). Proveďte "show crypto ikev2 sa" nebo ekvivalentní příkaz k ověření relace IKEV2. Ve výstupu ověřte, že relace IKEv2 byla na více než několik sekund a že není skákání. Doba provozuschopnosti relace se zobrazí ve výstupu jako „aktivní čas“ relace nebo ekvivalent.

Jakmile je relace IKEv2 ověřena jako aktivní, Vyšetřte relaci IPSEC. Stejně jako u relace IKEv2, proveďte "show crypto ipsec sa" nebo ekvivalentní příkaz k ověření relace IPSEC. Před vytvořením tunelu GRE musí být aktivní relace IKEV2 i relace IPSEC. Pokud se relace IPSEC nezobrazí jako aktivní, zkontrolujte v protokolech IPSEC chybové zprávy nebo chyby při vyjednávání.

Některé z nejčastějších problémů, se kterými se mohou během jednání IPSEC setkat, jsou:

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

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

• Ověřte nastavení Perfect Forward Secrecy a shodu nastavení na straně vyhrazené instance.

• Ověřte nastavení životnosti.

• Ověřte, zda je protokol IPSEC nakonfigurován v tunelovém režimu.

• Ověřte zdrojové a cílové adresy IPSEC.

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

• Transportní VRF tunelového rozhraní neodpovídá VRF rozhraní loopback (pokud je v tunelovém rozhraní použita konfigurace VRF).

  Pokud není konfigurace VRF v tunelovém rozhraní použita, může být tato kontrola ignorována.

• Keepalives nejsou povoleny na rozhraní bočního tunelu CPE

  Pokud keepalives nejsou podporovány na zařízení CPE, musí být upozorněna společnost Cisco, aby byly zakázány také výchozí keepalives na straně vyhrazené instance. Pokud jsou keepalives podporovány, ověřte, zda jsou keepalives povoleny.

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

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

• Firewall blokuje GRE pakety odesílané do tunelu IPSEC nebo přijaté z tunelu IPSEC (tunel GRE je přenášen přes tunel IPSEC)

Test ping by měl ověřit, zda je místní rozhraní tunelu funkční a zda je dobré připojení ke vzdálenému rozhraní tunelu. Proveďte kontrolu ping z IP tunelu (ne transportní IP) do vzdálené IP tunelu.

Seznam přístupu k šifrování pro tunel IPSEC, který nese tunelový provoz GRE, umožňuje křížení pouze paketů GRE. V důsledku toho nebudou pingy fungovat od IP tunelového přenosu do IP vzdáleného tunelového přenosu.

Výsledkem kontroly ping je GRE paket, který je generován ze zdrojové IP tunelové transportní IP do cílové IP tunelové transportní IP, zatímco payload GRE paketu (vnitřní IP) bude IP zdrojové a cílové tunelové IP.

Pokud test ping není úspěšný a předchozí položky jsou ověřeny, pak může být vyžadován záznam paketu, aby bylo zajištěno, že icmp ping vede k GRE paketu, který je pak zapouzdřen do paketu IPSEC a poté 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. pokud se zvyšují odesílání a příjem paketů.

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

Na straně vyhrazené instance jsou povoleny dvě funkce pro dynamickou úpravu MTU pro velké velikosti paketů. Tunel GRE přidává do paketů IP, které procházejí relací VPN, další záhlaví. Tunel IPSEC přidá další záhlaví nad GRE záhlaví a dále sníží největší MTU povolenou nad tunelem.

Tunel GRE upravuje funkci MSS a cesta tunelu GRE ve funkci zjišťování MTU je povolena na straně vyhrazené instance. Nakonfigurujte "ip tcp adjust-mss 1350" nebo ekvivalentní příkaz, stejně jako "tunel path\u0002mtu-discovery" nebo ekvivalentní příkaz na straně zákazníka, aby pomohl s dynamickým nastavením MTU provozu tunelem VPN.