A Virtual Connect kétrétegű fejállomás-architektúrát használ, ahol az útválasztási és GRE-vezérlősíkokat az egyik eszköz biztosítja, az IPSec vezérlősíkot pedig egy másik biztosítja.

A Virtuális csatlakozás kapcsolat befejezése után két GRE OVER IPSec alagút jön létre az Ügyfél vállalati hálózata és a Dedikált példány Cisco adatközpontjai között. Egy-egy az egyes redundáns adatközpontokhoz az adott régión belül. A társviszony-létesítéshez szükséges további hálózati elemeket a partner vagy az ügyfél kicseréli a Cisco-ra a Control Hub Virtual Connect aktiválási űrlapon keresztül.

Az alábbi ábra a virtuális csatlakozás telepítési modelljét mutatja be a 2 koncentrátoros opcióhoz az ügyfél oldalon.

Virtuális csatlakozás – A VPN egy hub-kialakítás, ahol az ügyfél központi telephelyei egy adott régión belüli dedikált példány adatközpontjainak DC1-hez és DC2-höz kapcsolódnak.

A jobb redundancia érdekében két hub-hely ajánlott, de a két alagúttal rendelkező One Hub-hely szintén támogatott üzembe helyezési modell.

A Partnerektől elvárás, hogy szorosan együttműködjenek az Ügyfelekkel, biztosítva a legoptimálisabb útvonal kiválasztását a Virtual Connect szolgáltatási régió számára.

Az alábbi ábra a dedikált példány felhőkapcsolati társviszony-létesítési régióit mutatja.

A Virtuális csatlakozás útválasztása bővítmény külső BGP (eBGP) használatával van megvalósítva a dedikált példány és a Customer Premise Equipment (CPE) között. A Cisco egy régión belüli minden egyes redundáns tartományvezérlőhöz meghirdeti a megfelelő hálózatot az Ügyfél CPE-jének, és a CPE-nek meg kell hirdetnie a Cisco alapértelmezett útvonalát.

• A Cisco karbantartja és hozzárendeli

  • Alagút interfész IP-címzés (átmeneti kapcsolat az útválasztáshoz) A Cisco hozzárendeli a kijelölt megosztott címtérből (nem nyilvánosan átirányítható)

  • Alagútszállítási desitinációs cím (Cisco oldala)

  • Privát autonóm rendszerszámok (ASNs) az ügyfél BGP útválasztási konfigurációjához

    • A Cisco a kijelölt magánhasználati tartományból rendeli hozzá a feladatokat: 64512-től 65534-ig

• A dedikált példány és a CPE közötti útvonalak cseréjére használt eBGP

  • A Cisco a hozzárendelt /24 hálózatot 2/25-re osztja az adott régió minden egyes DC-jéhez

  • A Virtual Connectben minden /25 hálózatot a Cisco visszahív CPE-re a megfelelő pont-pont VPN alagutakon keresztül (átmeneti kapcsolat)

  • A CPE-t a megfelelő eBGP-szomszédokkal kell konfigurálni. Ha egy CPE-t használ, akkor két eBGP-szomszédot használunk, amelyek közül az egyik minden távoli alagútra mutat. Ha két CPE-t használ, akkor minden CPE-nek lesz egy eBGP-szomszédja, amely a CPE egyetlen távoli alagútjához pásztáz.

  • Az egyes GRE-alagutak Cisco-oldala (alagút interfész IP-cím) a BGP-szomszédként van konfigurálva a CPE-n

  • A CPE-nek meg kell hirdetnie egy alapértelmezett útvonalat az egyes alagutak felett

  • A CPE szükség szerint újra elosztható a tanult útvonalak újraelosztására a cutomer vállalati hálózatán belül.

• Nem hibakapcsolati feltétel esetén egyetlen CPE két aktív/aktív alagúttal rendelkezik. Két CPE-csomópont esetében minden CPE egy aktív alagúttal rendelkezik, és mindkét CPE-csomópontnak aktívnak és átmenő forgalomnak kell lennie. Nem meghibásodási forgatókönyv esetén a forgalomnak két alagútra kell oszlania, amelyek a megfelelő /25-ös célhelyre mennek, ha az egyik alagút leesik, a fennmaradó alagút mindkettő forgalmát képes szállítani. Ilyen hiba esetén, ha a /25 hálózat nem működik, akkor a /24 hálózat lesz biztonsági mentési útvonalként használva. A Cisco a belső WAN-ján keresztül küldi az ügyfélforgalmat a dc felé, amely megszakította a kapcsolatot.

Az IPsec alagút-egyeztetés két fázisból áll: az IKEv2 fázisból és az IPsec fázisból. Ha az IKEv2 fázis egyeztetése nem fejeződik be, akkor nem indul el a második IPsec fázis. Először add ki a „show crypto ikev2 sa” parancsot (Cisco eszközön) vagy hasonló parancsot egy harmadik féltől származó eszközön annak ellenőrzéséhez, hogy az IKEv2 munkamenet aktív-e. Ha az IKEv2 munkamenet nem aktív, annak a lehetséges okai a következők lehetnek:

• Az érdekes forgalom nem indítja el az IPsec alagutat.

• Az IPsec alagút hozzáférési listája helytelenül van konfigurálva.

• Nincs kapcsolat az ügyfél és a dedikált példány IPsec alagút végpontjának IP-címe között.

• Az IKEv2 munkamenet paraméterei nem egyeznek a dedikált példány és az ügyféloldal között.

• Egy tűzfal blokkolja az IKEv2 UDP csomagokat.

Először is, ellenőrizze az IPsec naplókat, hogy vannak-e olyan üzenetek, amelyek az IKEv2 alagút-egyeztetés előrehaladását mutatják. A naplók jelezhetik, hogy hol van probléma az IKEv2 egyeztetéssel. A naplózási üzenetek hiánya azt is jelezheti, hogy az IKEv2 munkamenet nincs aktiválva.

Néhány gyakori hiba az IKEv2 egyeztetés során:

• A CPE oldalon az IKEv2 beállításai nem egyeznek meg a Cisco oldalon találhatóakkal, ellenőrizze újra az említett beállításokat:

  • Ellenőrizd, hogy az IKE verziója 2-es-e.

  • Ellenőrizze, hogy a titkosítási és hitelesítési paraméterek megegyeznek-e a dedikált példány oldalán várt titkosítással.

    Amikor a „GCM” titkosítást használják, a GCM protokoll kezeli a hitelesítést, és a hitelesítési paramétert NULL értékre állítja.

  • Ellenőrizze az élettartam beállítását.

  • Ellenőrizd a Diffie-Hellman moduluscsoportot.

  • Ellenőrizze a pszeudo-véletlenszerű függvény beállításait.

• A kriptotérkép hozzáférési listája nincs beállítva a következőre:

  • GRE engedélyezése (local_tunnel_transport_ip) 255.255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (vagy azzal egyenértékű parancs)

    A hozzáférési listának kifejezetten a "GRE" protokollhoz kell tartoznia, és az "IP" protokoll nem fog működni.

Ha a naplóüzenetek nem mutatnak semmilyen tárgyalási tevékenységet az IKEv2 fázisban, akkor csomagrögzítésre lehet szükség.

Megfelelő konfigurálás esetén a következőképpen kezdődik az IPsec alagút és az IKEv2 egyeztetés első fázisa:

• GRE keepalive-ok a CPE oldali GRE alagút interfésztől a dedikált példány oldali GRE alagút interfészig.

• BGP szomszédos TCP munkamenet a CPE oldali BGP szomszédtól a dedikált példány oldali BGP szomszédig.

• Pingelje a CPE oldali alagút IP-címéről a dedikált példány oldali alagút IP-címére.

  A ping nem lehet alagút IP-címe alagút IP-címtől, annak alagút IP-címnek kell lennie.

Ha csomagkövetésre van szükség az IKEv2 forgalomhoz, állítsa be a szűrőt UDP-re és vagy az 500-as portra (ha nincs NAT-eszköz az IPsec végpontok között), vagy a 4500-as portra (ha egy NAT-eszköz van beszúrva az IPsec végpontok közé).

Ellenőrizze, hogy az 500-as vagy 4500-as porttal rendelkező IKEv2 UDP csomagok küldése és fogadása a DI IPsec IP-címről megtörténik-e.

Az IPsec második fázisának hibaelhárítása előtt ellenőrizze, hogy az IPsec első fázisa (azaz az IKEv2 biztonsági társítás) aktív-e. Hajtson végre egy „show crypto ikev2 sa” vagy azzal egyenértékű parancsot az IKEv2 munkamenet ellenőrzéséhez. A kimenetben ellenőrizze, hogy az IKEv2 munkamenet már néhány másodpercnél régebben aktív-e, és hogy nem pattogó-e. A munkamenet üzemideje a kimenetben a munkamenet „Aktív ideje” vagy azzal egyenértékű értékként jelenik meg.

Miután az IKEv2 munkamenet ellenőrizve van, vizsgálja meg az IPsec munkamenetet. Az IKEv2 munkamenethez hasonlóan futtassa a „show crypto ipsec sa” vagy azzal egyenértékű parancsot az IPsec munkamenet ellenőrzéséhez. A GRE alagút létrehozása előtt mind az IKEv2, mind az IPsec munkamenetnek aktívnak kell lennie. Ha az IPsec-munkamenet nem jelenik meg aktívként, ellenőrizze az IPsec-naplókat hibaüzenetek vagy egyeztetési hibák után.

Az IPsec-tárgyalások során felmerülő leggyakoribb problémák a következők:

A CPE oldalon lévő beállítások nem egyeznek meg a dedikált példány oldalán lévőkkel, ellenőrizze újra a beállításokat:

• Ellenőrizze, hogy a titkosítási és hitelesítési paraméterek megegyeznek-e a dedikált példány oldalán található beállításokkal.

• Ellenőrizze a Tökéletes továbbítási titkosság beállításait, és hogy azok megegyeznek-e a dedikált példány oldalán található beállításokkal.

• Ellenőrizze az élettartamra vonatkozó beállításokat.

• Ellenőrizze, hogy az IPsec alagút módban van-e konfigurálva.

• Ellenőrizze a forrás- és cél IPsec-címeket.

Amikor az IPsec és az IKEv2 munkamenetek aktívnak bizonyulnak, a GRE alagút keepalive csomagjai áramolni tudnak a dedikált példány és a CPE alagút végpontjai között. Ha az alagút interfész állapota nem jelenik meg, néhány gyakori probléma a következő:

• Az alagút interfész szállítási VRF-je nem egyezik meg a loopback interfész VRF-jével (ha VRF konfigurációt használnak az alagút interfészen).

  Ha a VRF konfigurációt nem használják az alagút interfészen, ez az ellenőrzés figyelmen kívül hagyható.

• A keepalive-ok nincsenek engedélyezve a CPE oldali alagút interfészen.

  Ha a CPE berendezés nem támogatja a keepalive-okat, akkor értesíteni kell a Cisco-t, hogy a dedikált példány oldalán található alapértelmezett keepalive-ok is letiltásra kerüljenek.

  Ha a keepalive-ok támogatottak, ellenőrizze, hogy a keepalive-ok engedélyezve vannak-e.

• A bújtatási interfész maszkja vagy IP-címe helytelen, és nem egyezik meg a dedikált példány várt értékeivel.

• A forrás- vagy célalagút-átviteli cím helytelen, és nem egyezik a dedikált példány várható értékeivel.

• Egy tűzfal blokkolja a GRE csomagok IPsec alagútba küldését vagy onnan történő fogadását (a GRE alagút az IPsec alagúton keresztül továbbítódik).

Egy ping tesztnek ellenőriznie kell, hogy a helyi alagút interfész működik-e, és hogy a távoli alagút interfészhez jó-e a kapcsolat. Végezze el a ping ellenőrzést az alagút IP-címéről (ne a szállítási IP-címről) a távoli alagút IP-címére.

A ping ellenőrzés egy GRE csomagot eredményez, amely a forrás alagút szállítási IP-címétől a cél alagút szállítási IP-címéig generálódik, míg a GRE csomag hasznos terhelése (a belső IP-cím) a forrás és a cél alagút IP-címe lesz.

Ha a ping teszt sikertelen, és az előző tételek ellenőrzése megtörtént, akkor csomagrögzítésre lehet szükség annak biztosítására, hogy az ICMP ping egy GRE csomagot eredményezzen, amelyet aztán egy IPsec csomagba csomagolnak, majd a forrás IPsec címről a cél IPsec címre küldenek. A GRE alagút interfészén lévő számlálók és az IPsec munkamenet-számlálók szintén segíthetnek annak kimutatásában, hogy a küldött és fogadott csomagok száma növekszik-e.

A ping forgalom mellett a rögzítésnek a keepalive GRE csomagokat is meg kell mutatnia, még tétlen forgalom esetén is. Végül, ha a BGP konfigurálva van, a BGP keepalive csomagokat is GRE csomagokként, IPSEC csomagokba csomagolva kell elküldeni a VPN-en keresztül.

A dedikált példány oldalán két funkció engedélyezve van az MTU dinamikus beállításához nagy csomagméretek esetén. A GRE alagút további fejléceket ad a VPN-munkameneten áthaladó IP-csomagokhoz. Az IPsec alagút további fejléceket ad hozzá a GRE fejlécek tetejéhez, ami tovább csökkenti az alagúton megengedett legnagyobb MTU-t.

A GRE alagút beállítja az MSS funkciót, és a GRE alagút elérési útja az MTU felderítési funkciójában engedélyezve van a dedikált példány oldalán. Konfigurálja az „ip tcp adjust-mss 1350” vagy azzal egyenértékű parancsot, valamint a „tunnel” path\u0002mtu-discovery" vagy azzal egyenértékű parancs az ügyfél oldalon a VPN-alagúton keresztüli forgalom MTU-jának dinamikus beállításához.