Bevezetés

A Virtual Connect egy további kiegészítő lehetőség a felhőkapcsolathoz dedikált példányhoz Webex-hívásokhoz (dedikált példány). A Virtual Connect lehetővé teszi az ügyfelek számára, hogy biztonságosan kiterjesszék magánhálózatukat az interneten keresztül pont-pont IP VPN-alagutak használatával. Ez a csatlakozási lehetőség biztosítja a magánhálózati kapcsolat gyors létrehozását a meglévő Ügyfél-előfeltételi berendezések (CPE) és az internetkapcsolat használatával.

A Cisco redundáns IP VPN-alagutakat és a szükséges internet-hozzáférést a Cisco dedikált példány adatközponti régiójában (régióiban) üzemelteti, kezeli és biztosítja, ahol a szolgáltatásra szükség van. Hasonlóképpen, a rendszergazda felelős a megfelelő CPE- és internetszolgáltatásokért, amelyek a Virtual Connect létrehozásához szükségesek.

Egy adott dedikált példányrégió minden egyes virtuális csatlakozási rendelése két, IPSec-titkosítással védett útválasztási beágyazási (GRE) alagutat (GRE over IPSec) tartalmazna, egyet-egyet a Cisco minden egyes adatközpontjához a kiválasztott régióban.

A Virtual Connect sávszélesség-korlátja alagútonként 250 Mbps, és kisebb üzemelő példányok esetén ajánlott. Mivel két pont-pont VPN-alagutat használnak, a felhőbe irányuló összes forgalomnak át kell mennie az ügyfél fejállomásán, a CPE-n, ezért előfordulhat, hogy nem megfelelő, ha sok távoli hely van. Az egyéb alternatív társviszony-létesítési lehetőségekért lásd: Cloud Connectivity.

Mielőtt beküldené a virtuális kapcsolatra vonatkozó társítási kérést, győződjön meg arról, hogy a dedikált példány szolgáltatás aktiválva van az adott régióban.

Előfeltételek

A Virtuális csatlakozás létrehozásának előfeltételei a következők:

  • Az ügyfél biztosítja

    • Internetkapcsolat elegendő rendelkezésre álló sávszélességgel az üzembe helyezés támogatásához

    • Két IPSec-alagút nyilvános IP-címe(i)

    • Ügyféloldali GRE szállítási IP-címek a két GRE alagúthoz

  • Partner és ügyfél

    • Együttműködés a sávszélesség-követelmények értékeléséhez

    • Győződjön meg arról, hogy a hálózati eszközök támogatják a Border Gateway Protocol (BGP) útválasztást és a GRE OVER IPSec alagút kialakítását

  • Partner vagy ügyfél biztosítja

    • Hálózati csapat a helyek közötti VPN-alagút technológiák ismeretével

    • Hálózati csapat, amely ismeri a BGP-t, az eBGP-t és az általános útválasztási elveket

  • Cisco

    • A Cisco privát automatikus rendszerszámokat (ASN) és átmeneti IP-címzést rendelt a GRE-alagút interfészeihez

    • A Cisco nyilvános, de nem internetes átirányítható C osztályú (/24) hálózatot rendelt a dedikált példányfelhő-címzéshez

Ha egy ügyfélnek csak 1 CPE-eszköze van, akkor az egyes régiókban a Cisco adatközpontjai (DC1 és DC2) felé vezető 2 alagút az adott CPE-eszközről származik. Az ügyfélnek 2 CPE-eszközre is lehetősége van, majd minden CPE-eszköznek 1 alagúthoz kell csatlakoznia, csak a Cisco adatközpontjai (DC1 és DC2) felé minden régióban. További redundancia érhető el, ha minden egyes alagutat külön fizikai helyen/helyen fejezünk be az Ügyfél infrastruktúráján belül.

Műszaki adatok

Telepítési modell

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 1. ábra egy példát mutat be a Virtual Connect üzembe helyezési modelljére a 2-koncentrátor beállításhoz az ügyféloldalon.

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.

Az alagútonkénti sávszélesség 250 Mbps-ra van korlátozva.

Az Ügyfél ugyanazon régión belüli távoli webhelyeinek vissza kell kapcsolódniuk a Hub-telephely(ek)hez az Ügyfél WAN-ján keresztül, és nem a Cisco felelőssége ez a kapcsolat.

A partnerektől elvárjuk, hogy szorosan együttműködjenek az ügyfelekkel, biztosítva, hogy a "Virtual Connect" szolgáltatási régióhoz a legoptimálisabb útvonalat válasszák.

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

Hívástovábbítás

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.

Csatlakozási folyamat

Az alábbi magas szintű lépések azt ismertetik, hogyan hozhat létre kapcsolatot a virtuális Csatlakozás dedikált példányhoz.
1

Rendelés leadása a Cisco CCW-ben

2

Virtuális csatlakozás aktiválása a Control Hubból

3

A Cisco hálózati konfigurációt végez

4

Az ügyfél elvégzi a hálózati konfigurációt

1. lépés: CCW megrendelés

A Virtual Connect a CCW dedikált példányának bővítménye.

1

Keresse meg a CCW rendelési webhelyet, majd kattintson a Bejelentkezés gombra a webhelyre való bejelentkezéshez:

https://apps.cisco.com/Commerce/guest.
2

Becslés létrehozása.

3

Adja hozzá az "A-FLEX-3" termékváltozatot.

4

Válassza a Beállítások szerkesztése lehetőséget.

5

A megjelenő előfizetés lapon válassza a Beállítások és bővítmények lehetőséget.

6

A További bővítmények alatt jelölje be a "Virtuális csatlakozás dedikált példányhoz" melletti jelölőnégyzetet. Az SKU neve "A-FLEX-DI-VC".

7

Adja meg azoknak a régióknak a mennyiségét és számát, amelyekben virtuális csatlakozás szükséges.

A Virtuális csatlakozás mennyisége nem haladhatja meg a dedikált példányhoz vásárolt régiók teljes számát. Emellett régiónként csak egy Virtuális csatlakozás rendelés engedélyezett.
8

Ha elégedett a választásokkal, kattintson az Ellenőrzés és mentés gombra az oldal jobb felső részén.

9

Kattintson a Mentés és folytatás gombra a megrendelés véglegesítéséhez. A véglegesített rendelés most a rendelési rácsban van.

2. lépés: Virtuális csatlakozás aktiválása a Control Hubban

1

Jelentkezzen be a Control Hubba https://admin.webex.com/login.

2

A Szolgáltatások szakaszban keresse meg a Dedikált instacnce hívása > > a Felhőkapcsolat lehetőséget.

3

A Virtual Connect kártyán a megvásárolt Virtual Connect mennyiség szerepel. A rendszergazda mostantól az Aktiválás gombra kattintva kezdeményezheti a Virtual Connect aktiválását.

Az aktiválási folyamatot csak az "Ügyfél teljes rendszergazdája" szerepkörrel rendelkező rendszergazdák aktiválhatják. Míg az "Ügyfél csak olvasható rendszergazda" szerepkörrel rendelkező rendszergazda csak megtekintheti az állapotot.
4

Az Aktiválás gombra kattintva megjelenik a Virtuális csatlakozás aktiválása űrlap, hogy a rendszergazda megadja a Virtuális csatlakozás technikai adatait, amelyek a Cisco oldalán lévő társviszony-konfigurációkhoz szükségesek.

Az űrlap statikus információkat is biztosít a Cisco oldalán, a kiválasztott régió alapján. Ezek az információk hasznosak lesznek az ügyfél-rendszergazdák számára, hogy az oldalukon konfigurálják a CPE-t a kapcsolat létrehozásához.

  1. GRE-alagútátvitel IP-címe: Az ügyfélnek meg kell adnia az ügyfél oldalsó Tunnel Transport IP-címeit, és a Cisco dinamikusan kiosztja az IP-címeket az aktiválás befejezése után. Az érdekes forgalomra vonatkozó IPSec ACL-nek lehetővé kell tennie a helyi tunnel transport IP/32 protokollt a távoli alagút-átviteli IP/32-re. Az ACL-nek csak a GRE IP protokollt kell megadnia.

    Az ügyfél által megadott IP-cím lehet privát vagy nyilvános.

  2. IPSec-társak: Az ügyfélnek meg kell adnia az IPSec-alagút forrás IP-címeit, és a Cisco kiosztja az IPSec-cél IP-címet. Szükség esetén a belső IPSEC-alagútcímek nyilvános címre történő NAT-fordítása is támogatott.

    Az ügyfél által megadott IP-címnek nyilvánosnak kell lennie.

    Az aktiválási képernyőn megadott összes többi statikus információ a Cisco oldalsó biztonsági és titkosítási szabványait követi. Ez a statikus konfiguráció nem testreszabható vagy módosítható. A Cisco oldalán lévő statikus konfigurációkkal kapcsolatos további segítségért az ügyfélnek fel kell vennie a kapcsolatot a TAC-val.
5

Kattintson az Aktiválás gombra, miután az összes kötelező mező ki lett töltve.

6

Miután kitöltötte a Virtuális csatlakozás aktiválási űrlapját egy partikluáris régióhoz, az ügyfél exportálhatja az aktiválási űrlapot a Control Hubból, a Hívás > dedikált példányból > Felhőkapcsolat lapot, majd kattintson a Beállítások exportálása elemre.

Biztonsági okokból a hitelesítés és a BGP-jelszó nem lesz elérhető az Exportált dokumentumban, de a rendszergazda megtekintheti ezt a Control Hubban, ha a Control Hub, Hívás > Dedikált példány > Felhőkapcsolat lapon található Beállítások megtekintése lehetőségre kattint.

3. lépés: A Cisco hálózati konfigurációt végez

1

A Virtuális csatlakozás aktiválási űrlapjának kitöltése után az állapot aktiválási folyamatban lévőre frissül a dedikált példány hívása > > Cloud Connectivity Virtual Connect kártya hívásában.

2

A Cisco 5 munkanapon belül elvégzi a szükséges konfigurációkat a Cisco oldalsó eszközén. Sikeres befejezés esetén az állapot "Aktiválva" lesz az adott régióhoz a Control Hubban.

4. lépés: Az ügyfél elvégzi a hálózati konfigurációt

Az állapot "Aktiválva" állapotra változik, hogy értesítse az Ügyféladminisztrátorirt arról, hogy az IP VPN-kapcsolat konfigurációinak Cisco oldala az Ügyfél által megadott bemenetek alapján be van fejezve. Az ügyfél rendszergazdájának azonban be kell fejeznie a konfigurációk oldalát a CTE-ken, és tesztelnie kell a virtuális csatlakozás alagút online kapcsolati útvonalait. A konfigurálás vagy a csatlakozás során felmerülő problémák esetén az ügyfél segítségért fordulhat a Cisco TAC-hoz.

Hibaelhárítás

IPsec első fázisa (IKEv2 tárgyalás) hibaelhárítás és érvényesítés

Az IPsec alagúttárgyalás két fázisból áll, az IKEv2 fázisból és az IPsec fázisból. Ha az IKEv2 fázis tárgyalás nem fejeződik be, akkor nincs második IPsec fázis elindítása. Először kiadja a "show crypto ikev2 sa" parancsot (a Cisco eszközön) vagy hasonló parancsot a harmadik féltől származó eszközön, hogy ellenőrizze, aktív-e az IKEv2 munkamenet. Ha az IKEv2 alkalom nem aktív, a lehetséges okok 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 nincs konfigurálva.

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

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

  • A tűzfal blokkolja az IKEv2 UDP csomagokat.

Először ellenőrizze az IPsec-naplókat, hogy vannak-e olyan üzenetek, amelyek az IKEv2-alagúttárgyalások menetét mutatják. A naplók jelezhetik, ha probléma van az IKEv2-tárgyalással. A naplóüzenetek hiánya azt is jelezheti, hogy az IKEv2 munkamenet nincs aktiválva.

Néhány gyakori hiba az IKEv2-tárgyalással kapcsolatban:

  • A CPE oldalon az IKEv2 beállításai nem egyeznek a Cisco oldalával, ellenőrizze újra az említett beállításokat:

    • Ellenőrizze, hogy az IKE 2-es verzió van-e.

    • Ellenőrizze, hogy a Titkosítási és hitelesítési paraméterek egyeznek-e a várható titkosítással a Dedikált példány oldalán.

      Amikor a "GCM" rejtjel használatban van, 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őrizze a Diffie Hellman modulus csoportot.

    • Ellenőrizze a pszeudo-random funkció beállításait.

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

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

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

Ha a naplóüzenetek nem mutatnak semmilyen egyeztetési tevékenységet az IKEv2 fázishoz, akkor szükség lehet egy csomaggyűjtésre.

A dedikált példány oldala nem mindig kezdi meg az IKEv2 cserét, és néha arra számíthat, hogy az ügyfél CPE-oldala lesz a kezdeményező.

Ellenőrizze a CPE-oldal konfigurációját az IKEv2-munkamenet indításához a következő előfeltételekhez:

  • Keressen egy IPsec kriptográfiai hozzáférési listát a GRE forgalomhoz (50. protokoll) a CPE alagútátviteli IP-ről a Dedikált példány alagútátviteli IP-re.

  • Győződjön meg arról, hogy a GRE alagútinterfész engedélyezve van a GRE életben tartása érdekében, ha a berendezés nem támogatja a GRE életben tartását, akkor a Cisco értesítést kap, mivel a GRE életben tartása alapértelmezés szerint engedélyezve lesz a Dedikált példány oldalán.

  • Győződjön meg arról, hogy a BGP engedélyezve van és konfigurálva van a dedikált példány alagútjának IP-címével.

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

  • A GRE életben marad a CPE oldal GRE alagútinterfészéről a dedikált példány oldalának GRE alagútinterfészére.

  • BGP-szomszéd TCP-munkamenet a CPE-oldali BGP-szomszéd és a dedikált példány oldali BGP-szomszéd között.

  • A CPE-oldalalagút IP-címéből a dedikált példány oldalalagút IP-címébe ping.

    A ping nem lehet alagútátvitel IP-alagútátvitel IP-alagútátvitel, hanem IP-alagútátvitel IP-alagútátvitel.

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

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

Előfordulhat, hogy a dedikált példány adatközpontja nem mindig kezdi meg az első IKEv2 csomagot. A követelmény az, hogy a CPE eszköz képes legyen elindítani az első IKEv2 csomagot a dedikált példány oldala felé.

Ha a helyi tűzfal megengedi, próbáljon pingelni a távoli IPsec-címre is. Ha a pingelés sikertelen a helyről a távoli IPsec-címre, akkor egy nyomkövetési útvonalat kell végeznie, hogy segítsen meghatározni, hol dobja a csomagot.

Előfordulhat, hogy egyes tűzfalak és internetberendezések nem teszik lehetővé a nyomkövetési útvonalat.

IPsec második fázis (IPsec tárgyalás) hibaelhárítás és érvényesítés

Ellenőrizze, hogy az IPsec első fázisa (azaz az IKEv2 biztonsági társítás) aktív-e az IPsec második fázisa hibaelhárítása előtt. Az IKEv2 munkamenet ellenőrzéséhez hajtson végre egy "crypto ikev2 sa" vagy azzal egyenértékű parancsot. A kimenetben ellenőrizze, hogy az IKEv2-munkamenet néhány másodpercnél hosszabb ideig tartott-e, és nem pattan-e. A munkamenet üzemideje a kimenetben "Aktív idő" munkamenetként vagy azzal egyenértékűként jelenik meg.

Miután az IKEv2 munkamenet aktív és aktív, Vizsgálja meg az IPsec munkamenetet. Az IKEv2 munkamenethez hasonlóan az IPsec munkamenet ellenőrzéséhez hajtson végre egy "crypto ipsec sa" vagy azzal egyenértékű parancsot. Mind az IKEv2 munkamenetnek, mind az IPsec munkamenetnek aktívnak kell lennie a GRE-alagút létrehozása előtt. Ha az IPsec-munkamenet nem jelenik meg aktívként, ellenőrizze az IPsec-naplókat, hogy vannak-e hibaüzenetek vagy tárgyalási hibák.

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

A CPE-oldal beállításai nem egyeznek a Dedikált példány oldalával, ellenőrizze újra a beállításokat:

  • Ellenőrizze, hogy a Titkosítási és hitelesítési paraméterek egyeznek-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 titoktartási beállításokat, és hogy azok egyeznek-e a Dedikált példány oldalán.

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

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

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

Alagútinterfész hibaelhárítás és hitelesítés

Amikor az IPsec és az IKEv2 munkamenetek fel- és aktívként vannak ellenőrizve, a GRE-alagút életben tartja azokat a csomagokat, amelyek képesek áramlani a dedikált példány és a CPE-alagút végpontjai között. Ha az alagútinterfész állapota nem jelenik meg, néhány gyakori probléma a következő:

  • Az alagútinterfész átviteli VRF nem egyezik a loopback interfész VRF-jével (ha VRF konfigurációt használ az alagútinterfészen).

    Ha a VRF konfigurációt nem használja az alagútinterfészen, akkor ezt a jelölést figyelmen kívül lehet hagyni.

  • Az életben tartás nem engedélyezett a CPE-oldalsó alagútinterfészen

    Ha a CPE-eszközök nem támogatják az életben tartást, akkor a Ciscót értesíteni kell, hogy az alapértelmezett életben tartást a Dedikált példány oldalán is letiltsák.

    Ha a megőrzési idő támogatott, ellenőrizze, hogy engedélyezve van-e a megőrzési idő.

  • Az alagútinterfész maszkja vagy IP-címe helytelen, és nem egyezik a várt dedikált példány értékeivel.

  • A forrás- vagy célalagút szállítási címe helytelen, és nem egyezik a várt dedikált példány értékeivel.

  • A tűzfal blokkolja az IPsec-alagútba küldött vagy az IPsec-alagútból fogadott GRE-csomagokat (a GRE-alagút az IPsec-alagúton keresztül kerül továbbításra)

A ping-tesztnek ellenőriznie kell, hogy a helyi alagútinterfész fel van-e állítva, és a kapcsolat jó a távoli alagútinterfészhez. Végezze el a ping ellenőrzést az alagút IP-jéről (nem a szállítási IP-ről) a távoli alagút IP-jére.

A GRE alagútforgalmat szállító IPsec-alagút kriptográfiai hozzáférési listája csak GRE-csomagok áthaladását teszi lehetővé. Ennek eredményeként a pöcök nem fognak működni alagútátviteli IP-ről távoli alagútátviteli IP-re.

A ping-ellenőrzés egy GRE csomagot eredményez, amely a forrás alagút szállítási IP-jéről a cél alagút szállítási IP-jére jön létre, míg a GRE csomag payload (a belső IP) lesz a forrás- és célalagút IP-je.

Ha a ping teszt sikertelen, és az előző elemeket ellenőrizték, akkor szükség lehet egy csomaggyűjtésre annak biztosítására, hogy az icmp ping GRE-csomagot eredményez, amelyet aztán egy IPsec csomagba ágyaznak, majd a forrás IPsec címről a cél IPsec címére küldik. 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 megmutatni. ha a küldési és fogadási csomagok száma növekszik.

A ping forgalom mellett a fogásnak még tétlen forgalom közben is életben kell tartania a GRE-csomagokat. Végül, ha a BGP be van állítva, a BGP életben maradó csomagokat IPSEC csomagokba ágyazott GRE csomagként, valamint a VPN-en keresztül is el kell küldeni.

BGP-hibaelhárítás és -ellenőrzés

BGP alkalmak

BGP szükséges útválasztási protokollként a VPN IPsec-alagútjában. A helyi BGP-szomszédnak eBGP-munkamenetet kell létrehoznia a dedikált példány BGP-szomszédjával. Az eBGP-vel szomszédos IP-címek megegyeznek a helyi és távoli alagút IP-címeivel. Először győződjön meg arról, hogy a BGP-munkamenet készen van, majd ellenőrizze, hogy a megfelelő útvonalak érkeznek-e a dedikált példányból, és a megfelelő alapértelmezett útvonal kerül-e elküldésre a dedikált példánynak.

Ha a GRE-alagút fel van állítva, ellenőrizze, hogy sikeres-e a pingelés a helyi és a távoli GRE-alagút IP-címe között. Ha a ping sikeres, de a BGP-munkamenet nem érkezik meg, akkor vizsgálja meg a BGP-naplót a BGP-beállítási hibák miatt.

A leggyakoribb BGP-tárgyalási problémák a következők:

  • A távoli AS-szám nem egyezik a Dedikált példány oldalán konfigurált AS-számmal; ellenőrizze újra a szomszéd AS-konfigurációját.

  • A helyi AS-szám nem egyezik meg a dedikált példány oldalának elvárásaival. Ellenőrizze, hogy a helyi AS-szám egyezik-e a várt dedikált példány paramétereivel.

  • A tűzfal blokkolja a GRE-csomagokba ágyazott BGP TCP-csomagok küldését az IPsec-alagútba, illetve az IPSEC-alagútból való fogadását.

  • A távoli BGP-szomszéd IP-címe nem egyezik a távoli GRE-alagút IP-címével.

BGP-útvonalváltás

Miután a BGP-munkamenet mindkét alagútnál ellenőrizve van, győződjön meg arról, hogy a megfelelő útvonalak küldése és fogadása a dedikált példány oldaláról történik.

A dedikált példány VPN-megoldás két alagút létrehozását várja az ügyfél/partner oldalról. Az első alagút az „A” dedikált példány adatközpontjára, a második alagút pedig a „B” dedikált példány adatközpontjára mutat. Mindkét alagútnak aktív állapotban kell lennie, és a megoldáshoz aktív/aktív üzembe helyezésre van szükség. Minden dedikált példány adatközpont a helyi /25 útvonalat, valamint a /24 tartalék útvonalat hirdeti. A dedikált példányból bejövő BGP-útvonalak ellenőrzésekor győződjön meg arról, hogy az A dedikált példány adatközpontjára mutató alagúthoz társított BGP-munkamenet megkapja a dedikált példány adatközpontjának A /25 helyi útvonalát, valamint a /24 tartalék útvonalat. Ezenkívül győződjön meg arról, hogy a B dedikált példány adatközpontjára mutató alagút megkapja a Dedikált példány adatközpontjának B /25 helyi útvonalát, valamint a /24 tartalék útvonalat. Vegye figyelembe, hogy a /24 biztonsági mentési útvonal ugyanaz lesz, mint a dedikált példány adatközpontjából és a B dedikált példány adatközpontjából hirdetett útvonal.

A dedikált példány adatközpontja redundanciát kap, ha az adott adatközpont alagútinterfésze leáll. Ha a kapcsolat az A dedikált példány adatközpontjával megszakad, akkor a forgalmat a B dedikált példány adatközpontjából az A adatközpontba továbbítjuk. Ebben az esetben a B adatközpontba vezető alagút a B /25 útvonalat használja a forgalom küldéséhez a B adatközpontba, és a B adatközpontba vezető alagút a tartalék /24 útvonalat használja a forgalmat az A adatközpontba a B adatközponton keresztül.

Fontos, hogy amikor mindkét alagút aktív, az A-alagút nem használja a forgalmat a B adatközpontba, és fordítva. Ebben az esetben, ha a forgalmat az A adatközpontba küldik a B adatközpont célállomásával, az A adatközpont továbbítja a forgalmat a B adatközpontba, majd a B adatközpont megpróbálja visszaküldeni a forgalmat a forrásra a B adatközponton keresztül. Ez az optimálistól elmaradó útválasztást eredményez, és tönkreteheti a forgalmat a tűzfalakon keresztül. Ezért fontos, hogy a normál működés során mindkét alagút aktív/aktív konfigurációban legyen.

A 0.0.0.0/0 útvonalat az ügyfél oldaláról a dedikált példány adatközpont oldalára kell hirdetni. A dedikált példány oldala nem fogad el konkrétabb útvonalakat. Győződjön meg arról, hogy a 0.0.0.0/0 útvonal ki van hirdetve a dedikált példány adatközpontjának A alagútjából és a dedikált példány adatközpontjának B alagútjából.

MTU-konfiguráció

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

A GRE-alagút módosítja az MSS funkciót, és a GRE-alagút útvonala az MTU keresési funkció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 az „alagútútvonal\u0002mtu-discovery” vagy azzal egyenértékű parancsot az ügyféloldalon, hogy segítsen a forgalom MTU-jának dinamikus beállításában a VPN-alagúton keresztül.