Virtual Connect utilizează o arhitectură de tip headend cu două niveluri, în care planurile de rutare și control GRE sunt furnizate de un dispozitiv, iar planul de control IPSec este furnizat de altul.

La finalizarea conexiunii Virtual Connect, vor fi create două tuneluri GRE prin IPSec între rețeaua de întreprindere a Clientului și centrele de date Cisco pentru Instanță Dedicată. Câte unul pentru fiecare centru de date redundant din regiunea respectivă. Elementele de rețea suplimentare necesare pentru peering sunt schimbate de partener sau client către Cisco prin intermediul formularului de activare Control Hub Virtual Connect.

Figura de mai jos prezintă un exemplu de model de implementare Virtual Connect pentru opțiunea cu 2 concentratoare pe partea clientului.

Virtual Connect - VPN este un design Hub, în care Site-urile Hub ale Clientului sunt conectate la DC1 și DC2 ale centrelor de date ale Instanței Dedicate dintr-o anumită regiune.

Două site-uri Hub sunt recomandate pentru o mai bună redundanță, dar site-ul One Hub cu două tuneluri este, de asemenea, un model de implementare acceptat.

Partenerii sunt așteptați să colaboreze îndeaproape cu Clienții, asigurându-se că este aleasă cea mai optimă cale pentru regiunea de servicii Virtual Connect.

Figura de mai jos prezintă regiunile de peering pentru conectivitatea în cloud a Instanțelor Dedicate.

Suplimentul de rutare pentru Virtual Connect este implementat folosind BGP extern (eBGP) între Instanța Dedicată și Echipamentul Clientului (CPE). Cisco își va face publicitate rețelei respective pentru fiecare DC redundant dintr-o regiune către CPE-ul Clientului, iar CPE-ul trebuie să facă publicitate unei rute implicite către Cisco.

• Cisco întreține și atribuie

  • Adresarea IP a interfeței de tunel (legătură tranzitorie pentru rutare) Cisco alocă dintr-un spațiu de adresă partajat desemnat (nedirecționabil public)

  • Adresa de destinație a transportului în tunel (partea Cisco)

  • Numere private de sistem autonom (ASN) pentru configurația de rutare BGP a clientului

    • Cisco atribuie din intervalul de utilizare privat desemnat: 64512 până la 65534

• eBGP folosit pentru a schimba rute între Instanța Dedicată și CPE

  • Cisco va împărți rețeaua /24 alocată în 2/25 câte una pentru fiecare DC din regiunea respectivă

  • În Virtual Connect, fiecare rețea /25 este anunțată înapoi către CPE de către Cisco prin tunelurile VPN punct la punct respective (legătură tranzitorie)

  • CPE trebuie configurat cu vecinii eBGP corespunzători. Dacă se utilizează un CPE, vor fi folosiți doi vecini eBGP, unul indicând fiecare tunel la distanță. Dacă utilizați două CPE, atunci fiecare CPE va avea un vecin eBGP care se adresează unui singur tunel la distanță pentru CPE.

  • Partea Cisco a fiecărui tunel GRE (IP interfață de tunel) este configurată ca vecin BGP pe CPE

  • CPE este necesar pentru a face publicitate unei rute implicite peste fiecare dintre tuneluri

  • CPE este responsabil pentru redistribuirea, după cum este necesar, a rutelor învățate în cadrul rețelei de întreprindere a clientului.

• În condiția de eroare a legăturii fără eșec, un singur CPE va avea două tuneluri active/active. Pentru două noduri CPE, fiecare CPE va avea un tunel activ și ambele noduri CPE ar trebui să fie active și să treacă trafic. În scenariul de non-eșec, traficul trebuie să fie împărțit în două tuneluri care merg către destinațiile corecte /25, dacă unul dintre tuneluri scade, tunelul rămas poate transporta traficul pentru ambele. Într-un astfel de scenariu de eșec, când rețeaua /25 este oprită, atunci rețeaua /24 este utilizată ca rută de rezervă. Cisco va trimite traficul clienților prin WAN-ul său intern către DC care și-a pierdut conectivitatea.

Negocierea tunelului IPsec implică două faze, faza IKEv2 și faza IPsec. Dacă negocierea fazei IKEv2 nu se finalizează, atunci nu există inițierea unei a doua faze IPsec. Mai întâi, executați comanda „show crypto ikev2 sa” (pe echipamente Cisco) sau o comandă similară pe echipamente terțe pentru a verifica dacă sesiunea IKEv2 este activă. Dacă sesiunea IKEv2 nu este activă, motivele potențiale ar putea fi:

• Traficul interesant nu declanșează tunelul IPsec.

• Lista de acces la tunelul IPsec este configurată greșit.

• Nu există conectivitate între client și adresa IP a punctului final al tunelului IPsec al instanței dedicate.

• Parametrii sesiunii IKEv2 nu se potrivesc între partea de instanță dedicată și partea de client.

• Un firewall blochează pachetele UDP IKEv2.

Mai întâi, verificați jurnalele IPsec pentru orice mesaje care arată progresul negocierii tunelului IKEv2. Jurnalele pot indica unde există o problemă cu negocierea IKEv2. Lipsa mesajelor de înregistrare în jurnal poate indica, de asemenea, că sesiunea IKEv2 nu este activată.

Câteva erori frecvente în negocierea IKEv2 sunt:

• Setările pentru IKEv2 pe partea CPE nu corespund cu cele de pe partea Cisco, verificați din nou setările menționate:

  • Verificați dacă versiunea IKE este versiunea 2.

  • Verificați dacă parametrii de criptare și autentificare corespund cu criptarea așteptată pe partea instanței dedicate.

    Când cifrul „GCM” este utilizat, protocolul GCM gestionează autentificarea și setează parametrul de autentificare la NULL.

  • Verificați setarea duratei de viață.

  • Verificați grupul de modul Diffie-Hellman.

  • Verificați setările funcției pseudo-aleatoare.

• Lista de acces pentru harta criptografică nu este setată la:

  • Permite GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (sau comandă echivalentă)

    Lista de acces trebuie să fie specifică protocolului „GRE”, iar protocolul „IP” nu va funcționa.

Dacă mesajele din jurnal nu arată nicio activitate de negociere pentru faza IKEv2, atunci poate fi necesară o captură de pachete.

Când este configurat corect, tunelul IPsec și prima fază de negociere IKEv2 sunt inițiate prin următoarele:

• Permite menținerea activă a datelor GRE de la interfața tunelului GRE din partea CPE la interfața tunelului GRE din partea instanței dedicate.

• Sesiune TCP vecin BGP de la vecinul BGP din partea CPE către vecinul BGP din partea instanței dedicate.

• Ping de la adresa IP a tunelului din partea CPE la adresa IP a tunelului din partea instanței dedicate.

  Ping-ul nu poate fi IP-ul de transport de la tunel la IP-ul de transport de la tunel, ci trebuie să fie IP-ul de la tunel la IP-ul de la tunel.

Dacă este necesară o urmărire a pachetelor pentru traficul IKEv2, setați filtrul pentru UDP și fie portul 500 (când niciun dispozitiv NAT nu se află în mijlocul punctelor finale IPsec), fie portul 4500 (când un dispozitiv NAT este introdus în mijlocul punctelor finale IPsec).

Verificați dacă pachetele IKEv2 UDP cu portul 500 sau 4500 sunt trimise și primite către și de la adresa IP DI IPsec.

Verificați dacă prima fază IPsec (adică asocierea de securitate IKEv2) este activă înainte de a depana a doua fază IPsec. Executați o comandă „show crypto ikev2 sa” sau o comandă echivalentă pentru a verifica sesiunea IKEv2. În rezultat, verificați dacă sesiunea IKEv2 este activă mai mult de câteva secunde și că nu se retrage. Timpul de funcționare al sesiunii este afișat ca „Timp activ” al sesiunii sau echivalent în rezultat.

După ce sesiunea IKEv2 este verificată ca fiind pornită și activă, investigați sesiunea IPsec. Ca și în cazul sesiunii IKEv2, executați o comandă „show crypto ipsec sa” sau echivalentă pentru a verifica sesiunea IPsec. Atât sesiunea IKEv2, cât și sesiunea IPsec trebuie să fie active înainte de stabilirea tunelului GRE. Dacă sesiunea IPsec nu apare ca activă, verificați jurnalele IPsec pentru mesaje de eroare sau erori de negociere.

Unele dintre cele mai frecvente probleme care pot fi întâlnite în timpul negocierilor IPsec sunt:

Setările de pe partea CPE nu corespund cu cele de pe partea Instanțelor Dedicate, verificați din nou setările:

• Verificați dacă parametrii de criptare și autentificare corespund setărilor de pe partea de instanță dedicată.

• Verificați setările Perfect Forward Secrecy și dacă setările corespund pe partea de Instanță Dedicată.

• Verificați setările pe durata de viață.

• Verificați dacă IPsec-ul a fost configurat în modul tunel.

• Verificați adresele IPsec sursă și destinație.

Când sesiunile IPsec și IKEv2 sunt verificate ca fiind active, pachetele keepalive din tunelul GRE pot circula între punctele finale ale tunelului Instanței Dedicate și CPE. Dacă interfața tunelului nu afișează starea, există câteva probleme frecvente:

• VRF-ul de transport al interfeței tunelului nu se potrivește cu VRF-ul interfeței loopback (dacă se utilizează configurația VRF pe interfața tunelului).

  Dacă configurația VRF nu este utilizată pe interfața tunelului, această verificare poate fi ignorată.

• Keepalive-urile nu sunt activate pe interfața tunelului lateral CPE

  Dacă funcțiile keepalive nu sunt acceptate pe echipamentul CPE, atunci Cisco trebuie notificat, astfel încât funcțiile keepalive implicite de pe partea Instanțelor Dedicate să fie și ele dezactivate.

  Dacă sunt acceptate keepalive-urile, verificați dacă sunt activate.

• Masca sau adresa IP a interfeței tunelului nu este corectă și nu corespunde valorilor așteptate pentru instanța dedicată.

• Adresa de transport a tunelului sursă sau destinație nu este corectă și nu corespunde valorilor așteptate pentru instanța dedicată.

• Un firewall blochează pachetele GRE trimise în tunelul IPsec sau primite din tunelul IPsec (tunelul GRE este transportat prin tunelul IPsec)

Un test ping ar trebui să verifice dacă interfața tunelului local este activă și dacă conectivitatea cu interfața tunelului la distanță este bună. Efectuați verificarea ping de la adresa IP a tunelului (nu de la adresa IP de transport) la adresa IP a tunelului la distanță.

Verificarea ping are ca rezultat un pachet GRE generat de la adresa IP de transport a tunelului sursă la adresa IP de transport a tunelului destinație, în timp ce sarcina utilă a pachetului GRE (adresa IP internă) va fi adresa IP a tunelului sursă și destinație.

Dacă testul ping nu are succes și elementele anterioare sunt verificate, atunci poate fi necesară o captură de pachet pentru a se asigura că ping-ul icmp are ca rezultat un pachet GRE care este apoi încapsulat într-un pachet IPsec și apoi trimis de la adresa IPsec sursă la adresa IPsec destinație. Contoarele de pe interfața tunelului GRE și contoarele de sesiune IPsec pot ajuta, de asemenea, la afișarea dacă pachetele de trimitere și recepție cresc.

Pe lângă traficul ping, captura ar trebui să afișeze și pachete GRE keepalive chiar și în timpul traficului inactiv. În cele din urmă, dacă este configurat BGP, pachetele BGP keepalive ar trebui trimise și ca pachete GRE încapsulate în pachete IPSEC prin VPN.

În partea de instanță dedicată, sunt activate două funcții pentru a ajusta dinamic MTU-ul pentru pachete de dimensiuni mari. Tunelul GRE adaugă mai multe anteturi pachetelor IP care trec prin sesiunea VPN. Tunelul IPsec care adaugă antete suplimentare peste antetele GRE va reduce și mai mult cel mai mare MTU permis prin tunel.

Tunelul GRE ajustează funcția MSS, iar calea tunelului GRE din funcția de descoperire MTU este activată pe partea Instanțelor Dedicate. Configurați comanda „ip tcp adjust-mss 1350” sau echivalentă, precum și comanda „tunnel” path\u0002mtu-discovery" sau o comandă echivalentă din partea clientului pentru a ajuta la ajustarea dinamică a MTU-ului traficului prin tunelul VPN.