Uvod

Virtual Connect je dodatna možnost za povezljivost z oblakom z namensko instanco za klicanje Webex (namenska instanca). Virtual Connect strankam omogoča varno razširitev zasebnega omrežja prek interneta z uporabo tunelov IP VPN od točke do točke. Ta možnost povezljivosti omogoča hitro vzpostavitev povezave z zasebnim omrežjem z uporabo obstoječe opreme na lokaciji stranke (CPE) in internetne povezljivosti.

Cisco gosti, upravlja in zagotavlja redundantne tunele IP VPN in potreben dostop do interneta v območju(-ih) podatkovnih centrov namenskih primerkov Cisco, kjer je storitev potrebna. Podobno je skrbnik odgovoren za ustrezno CPE in internetne storitve, ki so potrebne za vzpostavitev virtualne povezave.

Vsako naročilo Virtual Connect v določeni regiji namenske instance bi vključevalo dva tunela z generično usmerjevalno enkapsulacijo (GRE), zaščitena s šifriranjem IPSec (GRE prek IPSec), enega do vsakega podatkovnega centra Cisco v izbrani regiji.

Virtual Connect ima omejitev pasovne širine 250 Mbps na tunel in je priporočljiv za manjše uvedbe. Ker se uporabljata dva VPN tunela od točke do točke, mora ves promet v oblak potekati skozi strankino glavno postajo CPE, zato morda ni primeren tam, kjer je veliko oddaljenih lokacij. Za druge alternativne možnosti peeringa glejte Povezljivost v oblaku.

Preden oddate zahtevo za peering za Virtual Connect, se prepričajte, da je storitev Dedicated Instance aktivirana v zadevni regiji.

Predpogoji

Predpogoji za vzpostavitev virtualne povezave vključujejo:

  • Stranka zagotavlja

    • Internetna povezava z zadostno razpoložljivo pasovno širino za podporo uvajanja

    • Javni IP-naslov(i) za dva IPSec tunela

    • IP-naslovi GRE transporta na strani stranke za dva GRE tunela

  • Partner in stranka

    • Sodelujte pri ocenjevanju zahtev glede pasovne širine

    • Zagotovite, da omrežne naprave podpirajo usmerjanje protokola BGP (Border Gateway Protocol) in zasnovo tunela GRE prek IPSec.

  • Partner ali stranka zagotavlja

    • Omrežna ekipa z znanjem o tehnologijah VPN tunelov od lokacije do lokacije

    • Omrežna ekipa z znanjem BGP, eBGP in splošnih načel usmerjanja

  • Cisco

    • Cisco je dodelil zasebne avtonomne sistemske številke (ASN) in prehodno naslavljanje IP za vmesnike predorov GRE

    • Cisco je dodelil javni, vendar ne internetni usmerjevalnik razreda C (/24) omrežje za naslavljanje namenskih instanc v oblaku

Če ima stranka samo eno napravo CPE, bosta dva tunela do podatkovnih centrov Cisco (DC1 in DC2) v vsaki regiji potekala iz te naprave CPE. Stranka ima tudi možnost za 2 napravi CPE, pri čemer se mora vsaka naprava CPE povezati samo z enim tunelom proti Ciscovim podatkovnim centrom (DC1 in DC2) v vsaki regiji. Dodatno redundanco je mogoče doseči z zaključkom vsakega tunela v ločenem fizičnem site/location znotraj infrastrukture stranke.

Tehnične podrobnosti

Model uvajanja

Virtual Connect uporablja dvoslojno arhitekturo glavne postaje, kjer ena naprava zagotavlja usmerjevalno in GRE nadzorno ravnino, druga pa nadzorno ravnino IPSec.

Po dokončanju povezljivosti Virtual Connect bosta med poslovnim omrežjem stranke in podatkovnimi centri namenske instance Cisco ustvarjena dva tunela GRE over IPSec. Enega za vsak redundantni podatkovni center znotraj posamezne regije. Dodatne omrežne elemente, potrebne za peering, partner ali stranka izmenja s Ciscom prek aktivacijskega obrazca za Control Hub Virtual Connect.

Spodnja slika prikazuje primer modela uvajanja virtualne povezave za možnost z dvema koncentratorjema na strani stranke.

Virtual Connect – VPN je zasnova vozlišča, kjer so vozlišča strank povezana s podatkovnimi centri DC1 in DC2 namenske instance znotraj določene regije.

Za boljšo redundanco sta priporočljivi dve lokaciji Hub, vendar je podprt model uvajanja tudi ena lokacija Hub z dvema predoroma.

Pasovna širina na tunel je omejena na 250 Mbps. Za zagotovitev učinkovitega preklopa na drugo omrežje skupni promet v obeh predorih ne sme presegati 250 Mbps, saj bo v primeru okvare ves promet usmerjen skozi en predor.

Strankina oddaljena mesta znotraj iste regije bi se morala povezati nazaj z mesti Hub prek strankinega omrežja WAN in Cisco ni odgovoren za to povezljivost.

Od partnerjev se pričakuje tesno sodelovanje s strankami in zagotavljanje, da je za regijo storitve Virtual Connect izbrana najoptimalnejša pot.

Spodnja slika prikazuje območja peeringa za povezljivost namenskih instanc v oblaku.

Virtualna povezovalna območja

Usmerjanje

Usmerjanje za dodatek Virtual Connect je implementirano z uporabo zunanjega BGP (eBGP) med namensko instanco in opremo na lokaciji stranke (CPE). Cisco bo za vsak redundantni krmilnik domene znotraj regije oglaševal svoje omrežje strankini CPE, CPE pa mora Ciscu oglaševati privzeto pot.

  • Cisco vzdržuje in dodeljuje

    • Naslavljanje IP-ja tunelskega vmesnika (prehodna povezava za usmerjanje), ki ga Cisco dodeli iz določenega skupnega naslovnega prostora (ki ni javno usmerljiv)

    • Naslov cilja za prevoz skozi predor (stran Cisco)

    • Zasebne avtonomne sistemske številke (ASN) za konfiguracijo usmerjanja BGP strank

      • Cisco dodeli iz določenega obsega zasebne uporabe: 64512 do 65534

  • eBGP se uporablja za izmenjavo poti med namensko instanco in CPE

    • Cisco bo razdelil dodeljene /24 omrežje v 2 /25 enega za vsak krmilnik domene v ustrezni regiji

    • V Virtual Connectu vsak /25 Cisco omrežje oglašuje nazaj do CPE prek ustreznih VPN tunelov od točke do točke (prehodna povezava).

    • CPE mora biti konfiguriran z ustreznimi sosedi eBGP. Če uporabljate eno CPE, bosta uporabljena dva soseda eBGP, eden bo kazal na vsak oddaljeni tunel. Če uporabljate dve CPE-ji, bo imel vsak CPE enega soseda eBGP, ki bo usmerjen na en sam oddaljeni tunel za CPE.

    • Ciscova stran vsakega GRE tunela (IP vmesnika tunela) je konfigurirana kot BGP sosed na CPE.

    • CPE mora oglaševati privzeto pot čez vsak predor.

    • CPE je odgovoren za prerazporeditev naučenih poti znotraj poslovnega omrežja stranke po potrebi.

  • V primeru okvare povezave brez okvare bo imela ena CPE dva active/active predori. Pri dveh vozliščih CPE bo imelo vsako vozlišče CPE en aktiven tunel, obe vozlišči CPE pa morata biti aktivni in prepuščati promet. V scenariju brez okvare se mora promet razdeliti v dva predora, ki vodita v pravilno smer. /25 destinacije, če se eden od predorov poruši, lahko preostali predor prenaša promet za oba. V takšnem scenariju neuspeha, ko /25 omrežje ne deluje, potem /24 Omrežje se uporablja kot rezervna pot. Cisco bo promet strank poslal prek svoje notranje WAN povezave proti krmilniku podatkov, ki je izgubil povezljivost.

Pretok prometa navidezne povezave

Prometni tok, ko sta oba predora odprta

Namenski primerek - virtualna povezava

Ta slika prikazuje arhitekturo omrežja Virtual Connect in podrobno prikazuje pretok prometa, ko sta v uporabi tako primarni kot sekundarni predor.

Predstavlja model aktivne povezljivosti, s katerim stranka dostopa do aplikacij za uničeno komunikacijo, ki gostujejo v Ciscovih podatkovnih centrih, in pri tem izkorišča dvojno GRE/IPSEC tuneli prek interneta z BGP za izmenjavo poti.

Definicije:

  • Prostor stranke:
    • To predstavlja omrežje stranke na lokaciji, kjer se nahajajo uporabniki in njihove naprave (npr. IP-telefoni, računalniki z odjemalci UC).
    • Promet, ki izvira od tukaj, mora doseči aplikacije za uničeno komunikacijo, ki gostujejo v Ciscovih podatkovnih centrih.
  • Podatkovni centri namenske instance Cisco Webex Calling (namenska instanca) (WxC-DI DC-A in WxC-DI DC-B):
    • To so Ciscovi podatkovni centri, ki gostijo aplikacije za uničeno komunikacijo.
    • DC-A in DC-B sta geografsko ločena, kar zagotavlja redundanco.
    • Vsak podatkovni center ima svojo podomrežo za aplikacije uničene komunikacije:
      • DC-A subnet:X.X.X.0/25
      • DC-B subnet:X.X.X.128/25
  • GRE/IPsec Predori (predor 1 in predor 2):
    • To so varne, šifrirane povezave med prostori stranke in podatkovnim centrom Cisco prek javnega interneta.
    • GRE (generična enkapsulacija usmerjanja): Ta protokol se uporablja za enkapsulacijo različnih protokolov omrežne plasti znotraj virtualnih povezav od točke do točke. Omogoča delovanje usmerjevalnih protokolov, kot je BGP, prek tunela.
    • IPsec (varnost internetnega protokola): Ta paket protokolov zagotavlja kriptografske varnostne storitve (avtentikacija, integriteta, zaupnost) za IP-komunikacije. Šifrira promet, enkapsuliran z GRE, kar zagotavlja varen prenos podatkov prek interneta.
  • Protokol mejnega prehoda (BGP):
    • BGP je usmerjevalni protokol, ki se uporablja za izmenjavo usmerjevalnih informacij med prostori stranke in podatkovnimi centri Cisco.

Kot je prikazano na zgornjem diagramu, morajo naprave, nameščene v prostorih strank, vzpostaviti dve GRE/IPSEC predori.

Spodaj uporabljene konvencije poimenovanja z XX / YY, DC-A DC-B so generični za vse regije, kjer je na voljo namenska instanca. Te vrednosti bodo edinstvene za vsako regijo in dejanske vrednosti za vsako regijo. Specifične vrednosti so podane med aktivacijo virtualne povezave.

Na strani Cisco bodo tuneli IPSec in GRE zaključeni na različnih napravah. Stranka mora torej ustrezno konfigurirati ciljne IP-naslove IPSec in GRE na napravah. Stranke lahko uporabljajo isti IP za GRE in IPSEC, če je to podprto na njihovih napravah. Glejte zgornji diagram. Vrednosti, povezane z IP-jem, so podane med aktivacijo virtualne povezave na portalu.

  • Predor 1: Poveže prostore stranke z "namenskim centrom DC-A" (podatkovnim centrom A) prek interneta. Ta predor uporablja BGP AS:64XX1 na strani stranke in BGP AS:64XX2 na strani namenskega primerka DC-A. Konfiguracije virov tunelov IPSEC in GRE so razdeljene na podrobnosti, ki jih zagotovi stranka, in podrobnosti, ki jih zagotovi Cisco.
  • Predor 2: Poveže prostore stranke z "namenskim centrom DC-B" (podatkovnim centrom B) prek interneta. Ta predor uporablja BGP AS:64YY1 na strani stranke in BGP AS:64YY2 na strani namenskega primerka DC-B. Tako kot pri tunelu 1 si tudi konfiguracije virov tunelov IPSEC in GRE delita stranka in Cisco.

V BGP-ju AS:64XX in BGP AS:64YY, XX in YY sta specifična za določeno regijo.

Ko GRE/IPSEC Ko so tuneli vzpostavljeni do podatkovnih centrov Webex Calling Dedicated Instance (A in B), bi morala stranka prejeti naslednje poti, ki jih Cisco oglašuje prek ustreznih sej BGP.

  • Za DC-A: Poti, ki jih oglašuje Cisco, bodo X.X.X.0/25 in X.X.x.0/24. Neobvezno, če je IaaS zahtevan in konfiguriran za poti strank Y.Y.Y.0/25 in Y.Y.Y.0/24 bo oglaševal Cisco.
  • Za DC-B: Poti, ki jih oglašuje Cisco, bodo X.X.X.128/25 in X.X.x.0/24. Neobvezno, če je IaaS zahtevan in konfiguriran za poti strank Y.Y.Y.128/25 in Y.Y.Y.0/24 bo oglaševal Cisco.
  • Stranka mora oglaševati 0.0.0./0 pot do Cisca skozi obe povezavi (tuneli)
  • Stranka mora slediti najdaljši predponi (/25) poti za pošiljanje prometa do Cisca skozi ustrezne tunele, ko sta oba tunela vzpostavljena.
  • Cisco bo promet vračal skozi iste predore, da bo promet ostal simetričen.

Pretok prometa:

  • Promet, namenjen za »DC-A UC Apps« (X.X.X.0/25) iz prostorov stranke teče skozi predor 1.
  • Promet, namenjen za »DC-B UC Apps« (X.X.X.128/25) iz prostorov stranke teče skozi predor 2.

Scenarij preklopa ob okvari : prometni tok, ko je eden od predorov zaprt

Namenski primerek - virtualna povezava

Kot je prikazano na zgornjem diagramu, ko je tunel do DC-A nedosegljiv, se bo prekinil tudi bgp, vzpostavljen skozi tunel do DC-A.

Vpliv na BGP: Ko predor 1 prekine delovanje, se prekine tudi seja BGP prek tega predora. Posledično DC-A ne bo več mogel oglaševati svojih poti (zlasti X.X.X.0/25) do stranke po tej poti. Zato bo usmerjevalnik stranke zaznal pot kot nedosegljivo.

Ker je predor 1 izklopljen, bo usmerjevalnik stranke na lokaciji stranke samodejno odstranil poti, pridobljene prek predora 1, iz svoje usmerjevalne tabele ali pa jih označil kot nedosegljive.

  • Promet, namenjen omrežju aplikacij UC (X.X.X.0/24) ali podomrežje DC-A (X.X.X.0/25) bo nato preusmerjen skozi delovni predor proti postaji DC-B, ki še naprej oglašuje X.X.X.0/24 ki vključuje X.X.X.0/25 omrežje.
  • Podobno vedenje bo opaženo, če je predor do DC-B nedosegljiv, medtem ko je predor do DC-A še vedno vzpostavljen.

Postopek povezljivosti

Naslednji koraki na visoki ravni opisujejo, kako vzpostaviti povezljivost z virtualno povezavo za namensko instanco.
1

Oddajte naročilo v Cisco CCW

2

Aktivirajte Virtual Connect iz Control Huba

3

Cisco izvaja konfiguracijo omrežja

4

Stranka izvede konfiguracijo omrežja

1. korak: Naročilo proti časovnemu zamiku

Virtual Connect je dodatek za namensko instanco v CCW.

1

Pojdite na spletno mesto za naročanje CCW in nato kliknite Prijava, da se prijavite na spletno mesto:

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

Ustvari oceno.

3

Dodajte kodo artikla »A-FLEX-3«.

4

Izberite Možnosti urejanja.

5

Na zavihku naročnine, ki se prikaže, izberite Možnosti in dodatke.

6

V razdelku Dodatni dodatki izberite potrditveno polje poleg možnosti »Virtual Connect for Dedicated Instance«. Ime SKU je "A-FLEX-DI-VC".

7

Vnesite količino in število regij, v katerih je potrebna Virtual Connect.

Količina Virtual Connect ne sme presegati skupnega števila regij, kupljenih za namensko instanco. Prav tako je dovoljeno samo eno naročilo Virtual Connect na regijo.
8

Ko ste zadovoljni z izbiro, kliknite Preveri in shrani v zgornjem desnem kotu strani.

9

Kliknite Shrani in nadaljuj, da dokončate naročilo. Vaše dokončano naročilo se zdaj prikaže v tabeli naročil.

2. korak: Aktivacija Virtual Connect v Control Hubu

1

Prijavite se v Control Hub https://admin.webex.com/login.

2

V razdelku Storitve poiščite Klicanje > Namenska instanca > Povezljivost z oblakom.

3

Na kartici Virtual Connect je navedena kupljena količina Virtual Connect. Skrbnik lahko zdaj klikne na Aktiviraj, da začne aktivacijo Virtual Connect.

Postopek aktivacije lahko sprožijo samo skrbniki z vlogo »Stranka s polnimi pravicami skrbnika«. Medtem ko si lahko skrbnik z vlogo »Skrbnik stranke samo za branje« stanje samo ogleda.
4

Ko kliknete gumb Aktiviraj, se prikaže obrazec Aktiviraj virtualno povezavo, kjer lahko skrbnik vnese tehnične podrobnosti o virtualni povezavi, potrebne za konfiguracije peeringa na strani Cisco.

Obrazec vsebuje tudi statične informacije na strani Cisca, glede na izbrano regijo. Te informacije bodo koristne za skrbnike strank pri konfiguriranju CPE na njihovi strani za vzpostavitev povezljivosti.

  1. IP-naslov za prenos tunela GRE: Stranka mora navesti svoje IP-naslove za tunelski transport, Cisco pa jih bo dinamično dodelil po zaključku aktivacije. IPSec ACL za zanimiv promet bi moral omogočati lokalni tunelski transport IP/32 do oddaljenega tunelskega prometa IP/32. ACL mora določati tudi samo protokol GRE IP.

    IP-naslov, ki ga posreduje stranka, je lahko zaseben ali javen.

  2. Vrstniki IPSec: Stranka mora navesti izvorne IP-naslove IPSec tunela, Cisco pa dodeli ciljni IP-naslov IPSec. Po potrebi je podprta tudi izvedba NAT prevajanja notranjega naslova tunela IPSEC v javni naslov.

    IP-naslov, ki ga navede stranka, mora biti javen.

    Vse druge statične informacije, navedene na aktivacijskem zaslonu, so upoštevane v skladu s Ciscovimi varnostnimi in šifrirnimi standardi. Te statične konfiguracije ni mogoče prilagoditi ali spremeniti. Za nadaljnjo pomoč glede statičnih konfiguracij na strani Cisca se mora stranka obrniti na TAC.
5

Ko izpolnite vsa obvezna polja, kliknite gumb Aktiviraj.

6

Ko je obrazec za aktivacijo Virtual Connect za določeno regijo izpolnjen, ga lahko stranka izvozi iz Control Huba, tako da kliče > Namenski primerek > zavihek Povezljivost v oblaku in kliknite Izvozi nastavitve.

Zaradi varnostnih razlogov preverjanje pristnosti in geslo BGP ne bosta na voljo v izvoženem dokumentu, vendar si ju lahko skrbnik ogleda v Control Hubu s klikom na Ogled nastavitev v razdelku Control Hub, Klicanje > Namenski primerek > Zavihek Povezljivost v oblaku.

3. korak: Cisco izvaja konfiguracijo omrežja

1

Ko je obrazec za aktivacijo Virtual Connect izpolnjen, se bo stanje v razdelku Klic posodobilo na Aktivacija v teku > Namenski primerek > Kartica za virtualno povezavo v oblaku.

2

Cisco bo zahtevane konfiguracije na Ciscovi stranski opremi dokončal v 5 delovnih dneh. Po uspešnem zaključku se bo stanje za to določeno regijo v Control Hubu posodobilo na »Aktivirano«.

4. korak: Stranka izvede konfiguracijo omrežja

Stanje se spremeni v »Aktivirano«, da se skrbnik stranke obvesti, da so bile konfiguracije za povezljivost IP VPN na strani Cisca dokončane na podlagi vnosov, ki jih je posredovala stranka. Vendar pa se od skrbnika stranke pričakuje, da dokonča svojo stran konfiguracij na CPE-jih in preizkusi poti povezljivosti, da bo predor Virtual Connect vzpostavljen. V primeru kakršnih koli težav med konfiguracijo ali povezljivostjo se lahko stranka za pomoč obrne na Cisco TAC.

Odpravljanje težav

Odpravljanje težav in preverjanje veljavnosti prve faze IPsec (pogajanja IKEv2)

Pogajanja o tunelu IPsec vključujejo dve fazi, fazo IKEv2 in fazo IPsec. Če se pogajanja o fazi IKEv2 ne zaključijo, se druga faza IPsec ne začne. Najprej izdajte ukaz »show crypto ikev2 sa« (na opremi Cisco) ali podoben ukaz na opremi tretje osebe, da preverite, ali je seja IKEv2 aktivna. Če seja IKEv2 ni aktivna, so možni razlogi lahko naslednji:

  • Zanimiv promet ne sproži tunela IPsec.

  • Seznam dostopa do tunela IPsec je napačno konfiguriran.

  • Med stranko in končno IP-točko tunela IPsec namenske instance ni povezave.

  • Parametri seje IKEv2 se ne ujemajo med namensko instanco in stranjo stranke.

  • Požarni zid blokira pakete IKEv2 UDP.

Najprej preverite dnevnike IPsec za morebitna sporočila, ki kažejo napredek pogajanj o tunelu IKEv2. Dnevniki lahko kažejo, kje je težava s pogajanji IKEv2. Pomanjkanje sporočil dnevnika lahko kaže tudi na to, da seja IKEv2 ni aktivirana.

Nekatere pogoste napake pri pogajanjih IKEv2 so:

  • Nastavitve za IKEv2 na strani CPE se ne ujemajo s stranjo Cisco, ponovno preverite omenjene nastavitve:

    • Preverite, ali je različica IKE različica 2.

    • Preverite, ali se parametra šifriranja in preverjanja pristnosti ujemajo s pričakovanim šifriranjem na strani namenske instance.

      Ko je v uporabi šifra »GCM«, protokol GCM obravnava preverjanje pristnosti in nastavi parameter preverjanja pristnosti na NULL.

    • Preverite nastavitev življenjske dobe.

    • Preverite Diffie-Hellmanovo skupino modulov.

    • Preverite nastavitve funkcije Psevdo naključno.

  • Seznam dostopov za kripto zemljevid ni nastavljen na:

    • Dovoljenje GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (ali enakovreden ukaz)

      Seznam dostopov mora biti posebej za protokol »GRE«, protokol »IP« pa ne bo deloval.

Če dnevniška sporočila ne prikazujejo nobene pogajalske aktivnosti za fazo IKEv2, je morda potrebno zajem paketov.

Stran namenske instance morda ne bo vedno začela izmenjave IKEv2 in lahko včasih pričakuje, da bo pobudnik stran CPE stranke.

Preverite konfiguracijo strani CPE za naslednje predpogoje za začetek seje IKEv2:

  • Preverite seznam dostopa IPsec za kripto dostop za promet GRE (protokol 50) od transportnega IP-ja tunela CPE do transportnega IP-ja tunela namenske instance.

  • Prepričajte se, da je vmesnik tunela GRE omogočen za GRE keepalives. Če oprema ne podpira GRE keepalives, je Cisco obveščen, ker bodo GRE keepalives na strani namenske instance privzeto omogočeni.

  • Prepričajte se, da je BGP omogočen in konfiguriran z naslovom soseda IP-naslova tunela namenske instance.

Ko je pravilno konfiguriran, se začne tunel IPsec in prva faza pogajanj IKEv2:

  • Omogoča ohranjanje aktivnosti GRE od vmesnika predora GRE na strani CPE do vmesnika predora GRE na strani namenske instance.

  • Seja TCP soseda BGP od soseda BGP na strani CPE do soseda BGP na strani namenske instance.

  • Izvedite ukaz Ping z IP-naslova tunela na strani CPE na IP-naslov tunela na strani namenske instance.

    Ping ne more biti IP-naslov za transport med tuneli, ampak mora biti IP-naslov za transport med tuneli.

Če je za promet IKEv2 potrebna sled paketov, nastavite filter za UDP in vrata 500 (ko na sredini končnih točk IPsec ni naprave NAT) ali vrata 4500 (ko je na sredini končnih točk IPsec vstavljena naprava NAT).

Preverite, ali se paketi IKEv2 UDP z vrati 500 ali 4500 pošiljajo na in prejemajo na naslov IP DI IPsec.

Podatkovni center namenske instance morda ne bo vedno začel prvega paketa IKEv2. Zahteva je, da je naprava CPE sposobna sprožiti prvi paket IKEv2 proti strani namenske instance.

Če lokalni požarni zid to dovoljuje, poskusite tudi z ukazom ping na oddaljeni IPsec naslov. Če ping ni uspešen od lokalnega do oddaljenega IPsec naslova, izvedite sledenje poti, da ugotovite, kje je bil paket zaustavljen.

Nekateri požarni zidovi in internetna oprema morda ne dovoljujejo sledenja poti.

Odpravljanje težav in preverjanje veljavnosti druge faze IPsec (pogajanja IPsec)

Pred odpravljanjem težav z drugo fazo IPsec preverite, ali je prva faza IPsec (torej varnostna povezava IKEv2) aktivna. Za preverjanje seje IKEv2 izvedite ukaz »show crypto ikev2 sa« ali enakovreden ukaz. V izpisu preverite, ali je seja IKEv2 aktivna že več kot nekaj sekund in da se ne odbija. Čas delovanja seje se v izhodu prikaže kot »Aktivni čas« seje ali enakovredna vrednost.

Ko se seja IKEv2 potrdi kot vzpostavljena in aktivna, preiščite sejo IPsec. Kot pri seji IKEv2 izvedite ukaz »show crypto ipsec sa« ali enakovreden ukaz, da preverite sejo IPsec. Pred vzpostavitvijo tunela GRE morata biti aktivni tako seja IKEv2 kot seja IPsec. Če seja IPsec ne prikazuje kot aktivna, preverite dnevnike IPsec za sporočila o napakah ali napake pri pogajanjih.

Nekatere pogostejše težave, ki se lahko pojavijo med pogajanji IPsec, so:

Nastavitve na strani CPE se ne ujemajo z nastavitvami na strani namenske instance, ponovno preverite nastavitve:

  • Preverite, ali se parametra šifriranja in preverjanja pristnosti ujemajo z nastavitvami na strani namenske instance.

  • Preverite nastavitve Perfect Forward Secrecy in ali se ujemajo z nastavitvami na strani namenske instance.

  • Preverite nastavitve življenjske dobe.

  • Preverite, ali je IPsec konfiguriran v tunelskem načinu.

  • Preverite izvorni in ciljni IPsec naslov.

Odpravljanje težav in preverjanje veljavnosti vmesnika predora

Ko se seji IPsec in IKEv2 preverita kot vzpostavljeni in aktivni, lahko paketi keepalive tunela GRE tečejo med končnimi točkami namenskega primerka in tunela CPE. Če vmesnik predora ne prikazuje stanja, so nekatere pogoste težave:

  • VRF prenosa vmesnika predora se ne ujema z VRF vmesnika povratne zanke (če se na vmesniku predora uporablja konfiguracija VRF).

    Če konfiguracija VRF ni uporabljena na vmesniku predora, lahko to preverjanje prezremo.

  • Funkcije keepalive niso omogočene na vmesniku tunela na strani CPE.

    Če oprema CPE ne podpira funkcij keepalive, je treba o tem obvestiti Cisco, da se onemogočijo tudi privzete funkcije keepalive na strani namenske instance.

    Če so podprte funkcije keepalive, preverite, ali so omogočene.

  • Maska ali IP-naslov vmesnika predora ni pravilen in se ne ujema s pričakovanimi vrednostmi namenske instance.

  • Izvorni ali ciljni naslov za prenos tunela ni pravilen in se ne ujema s pričakovanimi vrednostmi namenskega primerka.

  • Požarni zid blokira pakete GRE, ki so poslani v tunel IPsec ali sprejeti iz tunela IPsec (tunel GRE se prenaša prek tunela IPsec).

Ping test bi moral preveriti, ali lokalni vmesnik predora deluje in ali je povezljivost z oddaljenim vmesnikom predora dobra. Izvedite preverjanje pinga od IP-naslova tunela (ne transportnega IP-naslova) do oddaljenega IP-naslova tunela.

Seznam kripto dostopa za tunel IPsec, ki prenaša promet tunela GRE, dovoljuje prehod samo paketov GRE. Posledično pingi ne bodo delovali od IP-naslova za transport tunela do oddaljenega IP-naslova za transport tunela.

Preverjanje pinga povzroči paket GRE, ki se generira od izvornega transportnega IP-ja tunela do ciljnega transportnega IP-ja tunela, medtem ko bo koristni delež paketa GRE (notranji IP) izvorni in ciljni IP-naslov tunela.

Če test ping ni uspešen in so zgornji elementi preverjeni, bo morda potrebno zajeti paket, da se zagotovi, da icmp ping ustvari paket GRE, ki se nato enkapsulira v paket IPsec in nato pošlje z izvornega naslova IPsec na ciljni naslov IPsec. Števci na vmesniku tunela GRE in števci sej IPsec lahko pomagajo tudi pri prikazu, ali se število poslanih in prejetih paketov povečuje.

Poleg prometa ping bi moral zajem prikazovati tudi pakete keepalive GRE, tudi med nedejavnim prometom. Če je konfiguriran BGP, je treba pakete BGP keepalive poslati tudi kot pakete GRE, enkapsulirane v pakete IPSEC, prek VPN-ja.

Odpravljanje težav in preverjanje BGP

Seje BGP

BGP je potreben kot usmerjevalni protokol prek tunela VPN IPsec. Lokalni sosed BGP mora vzpostaviti sejo eBGP s sosedom namenske instance BGP. IP-naslovi sosedov eBGP so enaki kot IP-naslovi lokalnega in oddaljenega tunela. Najprej se prepričajte, da je seja BGP vzpostavljena, nato pa preverite, ali se iz namenske instance prejemajo pravilne poti in ali se namenski instanci pošilja pravilna privzeta pot.

Če je tunel GRE vzpostavljen, preverite, ali je bil ping uspešen med lokalnim in oddaljenim IP-naslovom tunela GRE. Če je ping uspešen, vendar seja BGP ne vzpostavi, preglejte dnevnik BGP za napake pri vzpostavljanju BGP.

Nekatere pogostejše težave s pogajanji BGP so:

  • Številka oddaljenega AS se ne ujema s številko AS, ki je konfigurirana na strani namenske instance, ponovno preverite konfiguracijo sosednjega AS.

  • Številka lokalnega AS se ne ujema s pričakovanji namenske instance. Preverite, ali se številka lokalnega AS ujema s pričakovanimi parametri namenske instance.

  • Požarni zid blokira pošiljanje paketov BGP TCP, enkapsuliranih v paketih GRE, v tunel IPsec ali prejemanje iz tunela IPSEC.

  • IP oddaljenega soseda BGP se ne ujema z IP oddaljenim tunelom GRE.

Izmenjava poti BGP

Ko je seja BGP preverjena za oba predora, se prepričajte, da se s strani namenske instance pošiljajo in prejemajo pravilne poti.

Rešitev namenske instance VPN pričakuje, da bosta iz customer/partner stran. Prvi tunel kaže na podatkovni center namenske instance A, drugi tunel pa na podatkovni center namenske instance B. Oba tunela morata biti v aktivnem stanju, rešitev pa zahteva active/active uvajanje. Vsak namenski podatkovni center bo oglaševal svoj lokalni /25 pot, kot tudi /24 rezervna pot. Pri preverjanju dohodnih poti BGP iz namenske instance se prepričajte, da seja BGP, povezana s tunelom, ki kaže na podatkovni center namenske instance A, prejme podatkovni center namenske instance A. /25 lokalna pot, kot tudi /24 rezervna pot. Poleg tega zagotovite, da tunel, ki kaže na podatkovni center namenske instance B, prejme podatkovni center namenske instance B. /25 lokalna pot, kot tudi /24 rezervna pot. Upoštevajte, da /24 Rezervna pot bo ista pot, ki je oglaševana iz podatkovnega centra namenske instance A in podatkovnega centra namenske instance B.

Redundanca se zagotovi namenskemu podatkovnemu centru, če tunelski vmesnik do tega podatkovnega centra ne deluje. Če se povezljivost s podatkovnim centrom namenske instance A prekine, se bo promet preusmeril iz podatkovnega centra namenske instance B v podatkovni center A. V tem primeru bo predor do podatkovnega centra B uporabljal podatkovni center B. /25 pot za pošiljanje prometa v podatkovni center B in tunel do podatkovnega centra B bo uporabljal rezervno kopijo /24 pot za pošiljanje prometa v podatkovni center A prek podatkovnega centra B.

Pomembno je, da se v primeru aktivne obeh predorov predor podatkovnega centra A ne uporablja za pošiljanje prometa v podatkovni center B in obratno. V tem primeru, če je promet poslan v podatkovni center A s ciljem podatkovnega centra B, bo podatkovni center A posredoval promet v podatkovni center B, nato pa bo podatkovni center B poskušal poslati promet nazaj k viru prek tunela podatkovnega centra B. To bo povzročilo neoptimalno usmerjanje in lahko tudi prekine promet, ki prečka požarne zidove. Zato je pomembno, da sta oba predora v active/active konfiguracijo med normalnim delovanjem.

The 0.0.0.0/0 Pot mora biti oglaševana s strani stranke do strani podatkovnega centra namenske instance. Namenska instanca ne bo sprejela bolj specifičnih poti. Zagotovite, da 0.0.0.0/0 Pot se oglašuje iz tunela namenskega podatkovnega centra A in tunela namenskega podatkovnega centra B.

Konfiguracija MTU-ja

Na strani namenske instance sta omogočeni dve funkciji za dinamično prilagajanje MTU za velike velikosti paketov. Predor GRE doda več glav paketom IP, ki tečejo skozi sejo VPN. Predor IPsec doda dodatne glave poleg glav GRE, kar bo še dodatno zmanjšalo največji dovoljeni MTU v predoru.

Predor GRE prilagodi funkcijo MSS, pot predora GRE v funkciji odkrivanja MTU pa je omogočena na strani namenske instance. Konfigurirajte ukaz »ip tcp adjust-mss 1350« ali enakovreden ukaz ter »tunnel path\u0002mtu-discovery" ali enakovreden ukaz na strani stranke za pomoč pri dinamičnem prilagajanju MTU prometa skozi VPN tunel.