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í.

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.

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í.

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.

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í.

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.

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.

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.

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.