Virtual Connect uporablja dvostopenjsko arhitekturo glavne postaje, kjer usmerjanje in GRE krmilne ravnine zagotavlja ena naprava, krmilno ravnino IPSec pa druga.

Po zaključku povezljivosti Virtual Connect bosta ustvarjena dva tunela GRE preko IPSec med poslovnim omrežjem stranke in podatkovnimi centri Cisco. Ena za vsako odvečno podatkovno središče v ustrezni regiji. Dodatne omrežne elemente, potrebne za peering, partner ali stranka zamenja s Ciscom prek obrazca za aktivacijo Control Hub Virtual Connect.

Slika 1 prikazuje primer modela uvajanja navidezne povezave za možnost 2 koncentratorja na strani stranke.

Virtual Connect - VPN je zasnova vozlišča, kjer so spletna mesta središča stranke povezana z DC1 in DC2 podatkovnih centrov namenske instance v določeni regiji.

Za boljšo redundanco sta priporočeni dve mesti vozlišča, vendar je podprt model uvajanja tudi eno središče z dvema predoroma.

Pasovna širina na predor je omejena na 250 Mbps.

Strankina oddaljena mesta v isti regiji bi se morala povezati nazaj s spletnimi mesti vozlišča prek strankinega omrežja WAN in Cisco ni odgovoren za to povezljivost.

Od partnerjev se pričakuje, da bodo tesno sodelovali s strankami in zagotovili izbiro najbolj optimalne poti za regijo storitve »Virtual Connect«.

Slika 2 prikazuje območja peering povezljivosti v oblaku namenskega primerka.

Dodatek Usmerjanje za navidezno povezavo se izvaja z zunanjim BGP (eBGP) med namenskim primerkom in opremo CPE (Customer Premise Equipment). Cisco bo oglaševal svoje omrežje za vsako odvečno enosmerno omrežje v regiji do strankinega CPE, CPE pa mora oglaševati privzeto pot do Cisca.

• Cisco vzdržuje in dodeljuje

  • Naslavljanje IP vmesnika tunela (prehodna povezava za usmerjanje) Cisco dodeli iz določenega naslovnega prostora v skupni rabi (ki ni javno usmerljivo)

  • Naslov za odstranitev prometa v predoru (Ciscova stran)

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

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

• eBGP se uporablja za izmenjavo poti med namenskim primerkom in CPE

  • Cisco bo dodeljeno omrežje /24 razdelil na 2/25 za vsak DC v ustrezni regiji

  • V navidezni povezavi Cisco vsako omrežje /25 oglašuje nazaj CPE prek ustreznih tunelov VPN od točke do točke (prehodna povezava)

  • CPE mora biti konfiguriran z ustreznimi sosednjimi eBGP. Če uporabljate en CPE, bosta uporabljena dva soseda eBGP, ena kaže na vsak oddaljeni tunel. Če uporabljate dva CPE, bo vsak CPE imel enega soseda eBGP, ki se bo pridružil enemu oddaljenemu tunelu za CPE.

  • Cisco stran vsakega predora GRE (IP vmesnika tunela) je konfigurirana kot soseda BGP na CPE

  • CPE je potreben za oglaševanje privzete poti v vsakem od predorov

  • CPE je odgovoren za prerazporeditev, kot je potrebno, naučenih poti znotraj podjetniškega omrežja uporabnika.

• V pogoju brez okvare povezave bo en CPE imel dva aktivna/aktivna tunela. Za dve vozlišči CPE bo vsak CPE imel en aktivni tunel in obe vozlišči CPE morata biti aktivni in prehajati promet. V scenariju brez okvare se mora promet razdeliti na dva predora, ki gredo do pravilnih /25 ciljev, če se eden od predorov pokvari, lahko preostali predor prenese promet za oba. V takšnem scenariju napake, ko omrežje /25 ne deluje, se omrežje /24 uporabi kot varnostna pot. Cisco bo poslal promet strank prek svojega notranjega omrežja WAN proti DC, ki je izgubil povezljivost.

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

• Zanimiv promet ne sproži tunela IPsec.

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

• Med stranko in IP končne točke tunela IPsec namenskega primerka ni povezave.

• Parametri seje IKEv2 se ne ujemajo med namenskim primerkom in stranko.

• Požarni zid blokira pakete UDP IKEv2.

Najprej preverite, ali so v dnevnikih IPsec sporočila, ki prikazujejo napredek pogajanj o tunelu IKEv2. V dnevnikih je lahko navedeno, kje je prišlo do težave s pogajanji IKEv2. Pomanjkanje sporočil o pisanju dnevnika lahko tudi pomeni, da seja IKEv2 ni aktivirana.

Nekatere pogoste napake pri pogajanjih IKEv2 so:

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

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

  • Preverite, ali se parametra šifriranja in preverjanja pristnosti ujemata s pričakovanim šifriranjem na strani namenskega primerka.

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

  • Preverite nastavitev življenjske dobe.

  • Preverite skupino modulov Diffie Hellman.

  • Preverite nastavitve funkcije Pseudo Random.

• Seznam dostopa za kripto zemljevid ni nastavljen na:

  • Dovoli 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« in protokol »IP« ne bo deloval.

Če dnevniška sporočila ne prikazujejo nobene pogajalske dejavnosti za fazo IKEv2, bo morda potreben zajem paketov.

Namenska stran primerka morda ne bo vedno začela izmenjave IKEv2 in lahko včasih pričakuje, da bo strankina stran CPE pobudnik. Preverite konfiguracijo CPE za naslednje zahteve za začetek seje IKEv2: Preverite seznam dostopa do kriptovalut IPsec za promet GRE (protokol 50) od IP-ja za prenos predora CPE do IP prenosa predora namenske instance. Prepričajte se, da je vmesnik predora GRE omogočen za vzdrževanje GRE, če oprema ne podpira vzdrževanja GRE, je Cisco obveščen, ker bodo zadrževalci GRE privzeto omogočeni na strani namenskega primerka. Prepričajte se, da je protokol BGP omogočen in konfiguriran s sosednjim naslovom IP tunela namenskega primerka.

Če je pravilno konfiguriran, se začne tunel IPsec in pogajanja v prvi fazi IKEv2:

• GRE ohranja 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 namenskega primerka.

• Ping z naslova IP stranskega predora CPE na naslov IP stranskega predora namenskega primerka.

  Ping ne more biti IP prenosa predora do IP prenosa predora, mora biti IP predora do IP predora.

Če je za promet IKEv2 potrebno sledenje paketom, nastavite filter za UDP in vrata 500 (ko nobena naprava NAT ni na sredini končnih točk IPsec) ali vrata 4500 (ko je naprava NAT vstavljena na sredino končnih točk IPsec).

Preverite, ali so paketi IKEv2 UDP z vrati 500 ali 4500 poslani in prejeti na naslov IP DI IPsec in z njega.

Podatkovno središče namenskega primerka morda ne bo vedno začelo s prvim paketom IKEv2. Zahteva je, da je naprava CPE sposobna sprožiti prvi paket IKEv2 proti strani namenskega primerka. Če lokalni požarni zid to dovoljuje, poskusite tudi pingati na oddaljeni naslov IPsec. Če ping ni uspešen z lokalnega na oddaljeni naslov IPsec, izvedite pot sledenja za pomoč in določite, kje je paket spuščen. Nekateri požarni zidovi in internetna oprema morda ne omogočajo sledenja.

Preverite, ali je prva faza IPsec (to je varnostna povezava IKEv2) aktivna, preden odpravite težave z drugo fazo IPsec. Izvedite »pokaži kripto ikev2 sa« ali enakovreden ukaz, da preverite sejo IKEv2. V izhodu preverite, ali je seja IKEv2 vzpostavljena več kot nekaj sekund in ali se ne odbija. Čas delovanja seje je prikazan kot »Aktivni čas« seje ali enakovreden izhodu.

Ko je seja IKEv2 preverjena kot aktivna, raziščite sejo IPsec. Tako kot pri seji IKEv2 izvedite »pokaži kripto ipsec sa« ali enakovreden ukaz, da preverite sejo IPsec. Seja IKEv2 in seja IPsec morata biti aktivna, preden je tunel GRE vzpostavljen. Če seja IPsec ni prikazana kot aktivna, preverite, ali so v dnevnikih IPsec sporočila o napakah ali napake pri pogajanjih.

Nekatera najpogostejša vprašanja, s katerimi se lahko srečamo med pogajanji o IPsec, so:

Nastavitve na strani CPE se ne ujemajo s strani namenskega primerka, znova preverite nastavitve:

• Preverite, ali se parametra šifriranja in preverjanja pristnosti ujemata z nastavitvami na strani namenskega primerka.

• Preverite nastavitve popolne tajnosti posredovanja in nastavitve ujemanja na strani namenskega primerka.

• Preverite nastavitve življenjske dobe.

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

• Preverite izvorni in ciljni naslov IPsec.

Ko so seje IPsec in IKEv2 preverjene kot aktivne, lahko paketi tunela GRE tečejo med namenskim primerkom in končnimi točkami tunela CPE. Če se stanje vmesnika tunela ne prikaže, so nekatere pogoste težave:

• VRF prenosnega 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 tunela, lahko to preverjanje prezrete.

• Keepalives niso omogočeni na vmesniku stranskega predora CPE

  Če vzdrževanje ni podprto na opremi CPE, je treba o tem obvestiti Cisco, da se onemogočijo tudi privzete ohranitve na strani namenskega primerka. Če so keepalives podprti, preverite, ali so keepalives omogočeni.

• Maska ali naslov IP vmesnika tunela ni pravilen in se ne ujema s pričakovanimi vrednostmi namenskega primerka.

• Izvorni ali ciljni prenosni naslov predora 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 prejeti iz tunela IPsec (tunel GRE se prenaša prek tunela IPsec)

Test ping mora preveriti, ali je vmesnik lokalnega predora vzpostavljen in ali je povezljivost z oddaljenim vmesnikom tunela dobra. Izvedite preverjanje pinga od IP tunela (ne prenosnega IP-ja) do IP oddaljenega tunela.

Seznam kripto dostopa za predor IPsec, ki prenaša promet predora GRE, omogoča prečkanje samo paketov GRE. Posledično pingi ne bodo delovali od IP prenosa predora do IP oddaljenega prenosa predora.

Preverjanje pinga povzroči paket GRE, ki se ustvari iz izvornega prenosnega IP tunela do ciljnega transportnega IP predora, medtem ko bo koristni tovor paketa GRE (notranji IP) izvorni in ciljni IP predora.

Če test ping ni uspešen in so preverjeni prejšnji elementi, je morda potrebno zajemanje paketov, da se zagotovi, da je rezultat pinga icmp paket GRE, ki se nato inkapsulira v paket IPsec in nato pošlje iz izvornega naslova IPsec na ciljni naslov IPsec. Števci na vmesniku predora GRE in števci sej IPsec lahko prav tako pomagajo pri prikazu. če se paketi za pošiljanje in prejemanje povečujejo.

Poleg ping prometa bi moral zajem prikazati tudi keepalive GRE pakete tudi med mirovanjem prometa. Nazadnje, če je konfiguriran BGP, je treba pakete BGP keepalive poslati tudi kot pakete GRE, ki so inkapsulirani v paketih IPSEC tudi prek VPN.

Na strani namenskega primerka 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 dodaja dodatne glave na vrhu glav GRE, kar bo še dodatno zmanjšalo največji MTU, ki je dovoljen nad predorom.

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