- Etusivu
- /
- Artikkeli
Dedikoitu instanssi – virtuaalinen yhteys
Virtual Connect on lisäosa pilviyhteydelle Webex Calling Dedicated Instanceen. Virtual Connectin avulla asiakkaat voivat laajentaa yksityisverkkoaan turvallisesti internetin yli käyttämällä point-to-point IP VPN -tunneleita. Tässä käsitellään Virtual Connectin tilaamista, aktivoimista ja konfigurointia.
Johdanto
Virtual Connect on lisäosa pilviyhteydelle Webex-puheluiden erilliseen instanssiin (Dedicated Instance). Virtual Connectin avulla asiakkaat voivat laajentaa yksityisverkkoaan turvallisesti internetin yli käyttämällä point-to-point IP VPN -tunneleita. Tämä yhteysvaihtoehto tarjoaa nopean yksityisen verkkoyhteyden muodostamisen käyttämällä olemassa olevia asiakkaan laitteita (CPE) ja internetyhteyttä.
Cisco isännöi, hallinnoi ja varmistaa redundantteja IP VPN -tunneleita ja tarvittavan internetyhteyden Ciscon Dedicated Instance -tietokeskusalueella/-alueilla, joilla palvelua tarvitaan. Vastaavasti järjestelmänvalvoja on vastuussa vastaavista CPE- ja internetpalveluistaan, joita tarvitaan Virtual Connectin muodostamiseen.
Jokainen Virtual Connect -tilaus tietyllä Dedicated Instance -alueella sisältäisi kaksi IPSec-salauksella (GRE IPSecin kautta) suojattua yleistä reitityskapselointitunnelia (GRE), yhden kumpaankin Ciscon konesaliin valitulla alueella.
Virtual Connectin kaistanleveysraja on 250 Mbps tunnelia kohden, ja sitä suositellaan pienemmille käyttöönottoille. Koska käytössä on kaksi point-to-point VPN-tunnelia, kaiken pilveen menevän liikenteen on kuljettava asiakkaan päätelaitteen CPE:n kautta, joten se ei välttämättä sovellu paikkoihin, joissa on paljon etäsijainteja. Muita vertaisyhteysvaihtoehtoja on kohdassa Pilviyhteydet.
Ennen kuin lähetät vertaisyhteyspyynnön Virtual Connectille, varmista, että Dedicated Instance -palvelu on aktivoitu kyseisellä alueella.
Edellytykset
Virtuaalisen yhteyden muodostamisen edellytyksiä ovat:
-
Asiakas toimittaa
-
Internet-yhteys, jolla on riittävästi kaistanleveyttä käyttöönoton tukemiseksi
-
Julkinen IP-osoite/-osoitteet kahdelle IPSec-tunnelille
-
Asiakkaan puolen GRE-kuljetus-IP-osoitteet kahdelle GRE-tunnelille
-
-
Kumppani ja asiakas
-
Arvioikaa yhdessä kaistanleveysvaatimuksia
-
Varmista, että verkkolaitteet tukevat Border Gateway Protocol (BGP) -reititystä ja GRE IPSec-tunnelin kautta tapahtuvaa käyttöä
-
-
Kumppani tai asiakas tarjoaa
-
Verkkotiimi, jolla on tietoa sivustojen välisistä VPN-tunnelitekniikoista
-
Verkkotiimi, jolla on tietoa BGP:stä, eBGP:stä ja yleisistä reititysperiaatteista
-
-
Cisco
-
Cisco antoi GRE-tunneliliitännöille yksityiset autonomiset järjestelmänumerot (ASN) ja ohimenevät IP-osoitteet
-
Cisco on määrittänyt julkisen, mutta ei internet-reititettävän C-luokan (/24) verkko Dedicated Instance Cloud -osoitteille
-
Jos asiakkaalla on vain yksi CPE-laite, kaksi tunnelia Ciscon datakeskuksiin (DC1 ja DC2) kullakin alueella kulkevat kyseisestä CPE-laitteesta. Asiakkaalla on myös mahdollisuus kahteen CPE-laitteeseen, jolloin jokaisen CPE-laitteen tulisi muodostaa yhteys vain yhteen tunneliin Ciscon datakeskuksiin (DC1 ja DC2) kullakin alueella. Lisäredundanssia voidaan saavuttaa päättämällä jokainen tunneli erilliseen fyysiseen site/location asiakkaan infrastruktuurin sisällä.
Tekniset tiedot
Käyttöönottomalli
Virtual Connect käyttää kaksikerroksista päätelaitearkkitehtuuria, jossa reititys- ja GRE-ohjaustasot tarjoaa yksi laite ja IPSec-ohjaustaso toinen.
Kun Virtual Connect -yhteydet on muodostettu, asiakkaan yritysverkon ja Dedicated Instance Ciscon datakeskusten välille luodaan kaksi GRE IPSec-tunnelia. Yksi jokaiseen redundanttiseen datakeskukseen kyseisen alueen sisällä. Kumppani tai asiakas vaihtaa vertaisyhteyden edellyttämät lisäverkkoelementit Ciscolle Control Hub Virtual Connect -aktivointilomakkeen kautta.
Alla oleva kuva näyttää esimerkin virtuaalisen yhteyden käyttöönottomallista asiakkaan puolella, kun käytössä on kaksi keskitintä.

Virtual Connect - VPN on Hub-ratkaisu, jossa asiakkaan Hub-sivustot on yhdistetty tietyn alueen Dedicated Instancen datakeskusten DC1- ja DC2-verkkoihin.
Kahden Hub-sivuston käyttöä suositellaan paremman redundanssin saavuttamiseksi, mutta myös yksi Hub-sivusto kahdella tunnelilla on tuettu käyttöönottomalli.
Tunnelin kaistanleveys on rajoitettu 250 Mbps:iin. Tehokkaan vikasietoisuuden varmistamiseksi tunnelien yhteenlaskettu liikenne ei saa ylittää 250 Mbps, koska kaikki liikenne reititetään yhden tunnelin kautta vikatilanteessa.
Asiakkaan samalla alueella sijaitsevien etäkohteiden on yhdistettävä takaisin Hub-kohteeseen/kohteihin asiakkaan WAN-verkon kautta, eikä Cisco ole vastuussa tästä yhteydestä.
Kumppaneiden odotetaan tekevän tiivistä yhteistyötä asiakkaiden kanssa varmistaakseen, että Virtual Connect -palvelualueelle valitaan optimaalisin polku.
Alla oleva kuva näyttää Dedicated Instance -pilviyhteyden vertaisverkon alueet.

Reititys
Virtual Connect -lisäosan reititys toteutetaan ulkoisen BGP:n (eBGP) avulla Dedicated Instancen ja Customer Premise Equipmentin (CPE) välillä. Cisco mainostaa asiakkaan CPE:lle kunkin alueen redundanttisen toimialueen ohjaimen verkkoaan, ja CPE:n on mainostettava Ciscolle oletusreitti.
-
Cisco ylläpitää ja määrittää
-
Tunneliliitännän IP-osoitteenmääritys (ohimenevä linkki reititystä varten) Cisco määrittää osoitteen nimetystä jaetusta osoiteavaruudesta (ei julkisesti reititettävissä)
-
Tunnelikuljetuksen määränpääosoite (Ciscon puolella)
-
Asiakkaan BGP-reitityskonfiguraation yksityiset autonomiset järjestelmänumerot (ASN)
-
Cisco määrittää yksityiskäyttöön tarkoitetusta alueesta: 64512–65534
-
-
-
eBGP:tä käytetään reittien vaihtamiseen Dedicated Instancen ja CPE:n välillä
-
Cisco jakaa määrätyn /24 verkko kahteen /25 yksi jokaiselle alueen DC:lle
-
Virtual Connectissa jokainen /25 Cisco mainostaa verkkoa takaisin CPE:lle vastaavien point-to-point VPN-tunnelien (transient link) kautta
-
CPE on konfiguroitava asianmukaisten eBGP-naapureiden kanssa. Jos käytetään yhtä CPE:tä, käytetään kahta eBGP-naapuria, yksi osoittaen kumpaankin etätunneliin. Jos käytetään kahta CPE:tä, kummallakin CPE:llä on yksi eBGP-naapuri, joka ohjaa CPE:n yksittäiseen etätunneliin.
-
Kunkin GRE-tunnelin (tunneliliitännän IP-osoite) Ciscon puoli on konfiguroitu BGP-naapuriksi CPE:ssä.
-
CPE:n on mainostettava oletusreittiä kunkin tunnelin yli.
-
CPE vastaa opittujen reittien uudelleenjakelusta asiakkaan yritysverkossa tarpeen mukaan.
-
-
Vikaantumattoman linkin vikatilanteessa yhdellä CPE:llä on kaksi active/active tunnelit. Kahdella CPE-solmulla kummallakin on yksi aktiivinen tunneli ja molempien CPE-solmujen tulisi olla aktiivisia ja välittää liikennettä. Vikaantumattomassa skenaariossa liikenteen on jaettava kahteen tunneliin, jotka johtavat oikeaan suuntaan. /25 määränpäät, jos toinen tunneleista sortuu, jäljelle jäävä tunneli voi kuljettaa molempien liikennettä. Tällaisessa vikatilanteessa, kun /25 verkko on alhaalla, niin silloin /24 verkkoa käytetään varareittinä. Cisco lähettää asiakasliikenteen sisäisen WAN-verkkonsa kautta sille toimialueen ohjaimelle, jonka yhteys on katkennut.
Virtuaalisen yhteyden liikennevirta
Liikennevirta, kun molemmat tunnelit ovat auki

Tämä kuva havainnollistaa Virtual Connect -verkon arkkitehtuuria ja esittää liikennevirran, kun sekä ensisijaiset että toissijaiset tunnelit ovat toiminnassa.
Se edustaa aktiivista yhteysmallia, jonka avulla asiakas voi käyttää Ciscon datakeskuksissa isännöityjä UC-sovelluksia hyödyntäen kahta eri ominaisuutta. GRE/IPSEC tunneleita internetin yli BGP:n avulla reittien vaihtoa varten.
Määritelmät:
- Asiakkaan lähtökohta:
- Tämä edustaa asiakkaan omaa verkkoa, jossa käyttäjät ja heidän laitteensa (esim. IP-puhelimet, UC-asiakasohjelmia käyttävät tietokoneet) sijaitsevat.
- Täältä lähtevän liikenteen on saavutettava Ciscon datakeskuksissa isännöidyt UC-sovellukset.
- Cisco Webex -puheluiden dedikoidun instanssin (dedikoitu instanssi) datakeskukset (WxC-DI DC-A ja WxC-DI DC-B):
- Nämä ovat Ciscon datakeskuksia, joissa UC-sovellukset sijaitsevat.
- DC-A ja DC-B ovat maantieteellisesti erillisiä, mikä tarjoaa redundanssia.
- Jokaisella datakeskuksella on oma aliverkkonsa UC-sovelluksille:
- DC-A subnet:X.X.X.0/25
- DC-B subnet:X.X.X.128/25
- GRE/IPsec Tunnelit (tunneli 1 ja tunneli 2):
- Nämä ovat suojattuja, salattuja yhteyksiä asiakkaan tilojen ja Ciscon datakeskuksen välillä julkisen internetin kautta.
- GRE (yleisen reitityksen kapselointi): Tätä protokollaa käytetään kapseloimaan erilaisia verkkokerrosprotokollia virtuaalisten pisteestä pisteeseen -linkkien sisään. Se sallii reititysprotokollien, kuten BGP:n, toiminnan tunnelin yli.
- IPsec (Internet-protokollan suojaus): Tämä protokollapaketti tarjoaa kryptografisia tietoturvapalveluita (todennus, eheys, luottamuksellisuus) IP-viestinnälle. Se salaa GRE-kapseloidun liikenteen varmistaen turvallisen tiedonsiirron internetin kautta.
- Rajayhdyskäytäväprotokolla (BGP):
- BGP on reititysprotokolla, jota käytetään reititystietojen vaihtamiseen asiakkaan tilojen ja Ciscon datakeskustenvälillä.
Kuten yllä olevasta kaaviosta käy ilmi, asiakkaan tiloissa käyttöönotettujen laitteiden on luotava kaksi GRE/IPSEC tunnelit.
Alla käytetyt nimeämiskäytännöt XX:n kanssa / YY, DC-A ja DC-B ovat yleisiä kaikille alueille, joilla Dedicated Instance -palvelua tarjotaan. Nämä arvot ovat yksilöllisiä kullekin alueelle ja kunkin alueen todelliset arvot. Tarkat arvot annetaan virtuaaliyhteyden aktivoinnin yhteydessä.
Ciscon puolella IPSec- ja GRE-tunnelit päätetään eri laitteilla. Asiakkaan on siis varmistettava, että IPSec- ja GRE-kohde-IP-osoitteet määritetään laitteissa vastaavasti. Asiakkaat voivat käyttää samaa IP-osoitetta GRE:lle ja IPSEC:lle, jos heidän laitteensa tukevat sitä. Katso yllä olevaa kaaviota. IP-osoitteeseen liittyvät arvot annetaan portaalin virtuaaliyhteyden aktivoinnin yhteydessä.
- Tunneli 1: Yhdistää asiakkaan toimitilan internetin kautta "Dedicated Instance DC-A:han" (datakeskus A). Tämä tunneli käyttää BGP:tä AS:64XX1 asiakkaan puolella ja BGP:llä AS:64XX2 Dedicated Instance DC-A:n puolella. IPSEC- ja GRE-tunnelilähdekonfiguraatiot on jaettu asiakkaan toimittamiin ja Ciscon toimittamiin tietoihin.
- Tunneli 2: Yhdistää asiakkaan toimitilan internetin kautta "Dedicated Instance DC-B:hen" (Data Center B). Tämä tunneli käyttää BGP:tä AS:64YY1 asiakkaan puolella ja BGP:llä AS:64YY2 Dedicated Instance DC-B:n puolella. Kuten tunnelissa 1, IPSEC- ja GRE-tunnelien lähdekonfiguraatiot jaetaan asiakkaan ja Ciscon kesken.
BGP:ssä AS:64XX ja BGP AS:64YY, XX ja YY ovat spesifisiä tietylle alueelle.
Kun GRE/IPSEC Kun tunnelit on muodostettu Webex Calling Dedicated Instance -tietokeskuksiin (A ja B), asiakkaan tulisi saada seuraavat Ciscon mainostamat reitit vastaavien BGP-istuntojen kautta.
- DC-A:lle: Ciscon mainostamat reitit ovat X.X.X.0/25 ja X.X.x.0/24. Valinnainen, jos IaaS-palvelua pyydetään ja se konfiguroidaan asiakasreiteille Y.Y.Y.0/25 ja Y.Y.Y.0/24 mainostetaan Ciscolta.
- DC-B:lle: Ciscon mainostamat reitit ovat X.X.X.128/25 ja X.X.x.0/24. Valinnainen, jos IaaS-palvelua pyydetään ja se konfiguroidaan asiakasreiteille Y.Y.Y.128/25 ja Y.Y.Y.0/24 mainostetaan Ciscolta.
- Asiakkaan on mainostettava 0.0.0./0 reitti Ciscolle molempien yhteyksien (tunnelien) kautta
- Asiakkaan on noudatettava pisintä etuliitettä (/25) reittejä liikenteen lähettämiseksi Ciscolle kyseisten tunnelien kautta, kun molemmat tunnelit ovat toiminnassa.
- Cisco palauttaa liikenteen samojen tunnelien kautta pitääkseen liikenteen symmetrisena.
Liikennevirta:
- Liikenne, jonka kohde on "DC-A UC Apps" (X.X.X.0/25) asiakastiloista virtaa tunnelin 1 kautta.
- Liikenne, jonka kohde on "DC-B UC Apps" (X.X.X.128/25) asiakastiloista virtaa tunnelin 2 kautta.
Vikasietoisuusskenaario : liikennevirta, kun yksi tunneleista on alas laskettu

Kuten yllä olevassa kaaviossa näkyy, kun DC-A:han menevä tunneli on alaspäin, tunnelin kautta DC-A:han muodostettu taustapeili kulkee alaspäin.
Vaikutus BGP:hen : Kun tunneli 1 kaatuu, myös kyseisen tunnelin BGP-istunto kaatuu. Näin ollen DC-A ei voi enää mainostaa reittejään (erityisesti X.X.X.0/25) asiakkaalle tätä reittiä pitkin. Näin ollen asiakasreititin tunnistaa polun tavoittamattomaksi.
Koska tunneli 1 on nyt alhaalla, asiakkaan tiloissa oleva asiakasreititin poistaa automaattisesti tunnelin 1 kautta opitut reitit reititystaulukostaan tai merkitsee ne tavoittamattomiksi.
- UC-sovellusverkkoon suunnattu liikenne (X.X.X.0/24) tai DC-A-aliverkko (X.X.X.0/25) ohjataan sitten työtunnelin kautta kohti DC-B:tä, joka jatkaa mainostamista X.X.X.0/24 joka sisältää X.X.X.0/25 verkko.
- Samanlainen toiminta havaitaan, jos tunneli DC-B:hen on alhaalla, kun taas tunneli DC-A:han on edelleen toiminnassa.
Yhteysprosessi
1 | |
2 | |
3 | |
4 |
Vaihe 1: CCW-määräys
Virtual Connect on CCW:n Dedicated Instancen lisäosa.
1 |
Siirry CCW-tilaussivustolle ja kirjaudu sisään napsauttamalla Kirjaudu sisään: |
2 |
Luo arvio. |
3 |
Lisää tuotenumero "A-FLEX-3". |
4 |
Valitse Muokkaa asetuksia. |
5 |
Valitse näkyviin tulevasta tilausvälilehdestä Asetukset ja Lisäosat. |
6 |
Valitse Lisälisäosat-kohdasta valintaruutu "Virtual Connect for Dedicated Instance" -kohdan vieressä. Tuotenumeron nimi on "A-FLEX-DI-VC". |
7 |
Syötä niiden alueiden määrä ja lukumäärä, joilla Virtual Connect -ominaisuutta tarvitaan. Virtual Connect -tilausten määrä ei saa ylittää Dedicated Instance -tilaukseen ostettujen alueiden kokonaismäärää. Lisäksi vain yksi Virtual Connect -tilaus on sallittu aluetta kohden. |
8 |
Kun olet tyytyväinen valintoihisi, napsauta Vahvista ja tallenna sivun oikeassa yläkulmassa. |
9 |
Viimeistele tilauksesi napsauttamalla Tallenna ja jatka. Lopullinen tilauksesi näkyy nyt tilausruudukossa. |
Vaihe 2: Virtuaalisen yhteyden aktivointi Control Hubissa
1 |
Kirjaudu sisään Control Hubiin https://admin.webex.com/login. |
2 |
Siirry Palvelut -osiossa kohtaan Soittaminen > Dedikoitu instanssi > Pilviyhteydet. |
3 |
Virtual Connect -kortissa näkyy ostettujen Virtual Connect -tuotteiden määrä. Ylläpitäjä voi nyt aloittaa Virtual Connectin aktivoinnin napsauttamalla Aktivoi -painiketta. ![]() Aktivointiprosessin voivat käynnistää vain järjestelmänvalvojat, joilla on asiakkaan täysi järjestelmänvalvojan rooli. Kun taas järjestelmänvalvoja, jolla on asiakkaan vain lukuoikeudet omaava rooli, voi vain tarkastella tilaa. |
4 |
Kun napsautetaan Aktivoi -painiketta, näkyviin tulee Aktivoi Virtuaalinen yhteys -lomake, johon järjestelmänvalvoja voi antaa Ciscon vertaisverkon kokoonpanoihin tarvittavat Virtuaalinen yhteys -tekniset tiedot. Lomake tarjoaa myös staattista tietoa Ciscon puolelta valitun alueen perusteella. Näistä tiedoista on hyötyä asiakkaiden järjestelmänvalvojille heidän puolellaan olevan CPE:n määrittämisessä yhteyden muodostamiseksi. |
5 |
Napsauta Aktivoi -painiketta, kun kaikki pakolliset kentät on täytetty. |
6 |
Kun Virtual Connect -aktivointilomake on täytetty tietylle alueelle, asiakas voi viedä aktivointilomakkeen Control Hubista soittamalla > Dedikoitu instanssi > Pilviyhteydet-välilehti ja napsauta Vie asetukset -painiketta. ![]() Turvallisuussyistä todennus ja BGP-salasana eivät ole käytettävissä viedyssä asiakirjassa, mutta järjestelmänvalvoja voi tarkastella niitä Control Hubissa napsauttamalla Näytä asetukset kohdassa Control Hub, Soittaminen. > Dedikoitu instanssi > Pilviyhteydet-välilehti |
Vaihe 3: Cisco suorittaa verkon konfiguroinnin
1 |
Kun Virtual Connect -aktivointilomake on täytetty, sen tilaksi päivittyy Aktivointi käynnissä kohdassa Puhelut > Dedikoitu instanssi > Pilviyhteyden virtuaalinen yhteyskortti. |
2 |
Cisco suorittaa tarvittavat määritykset Ciscon sivulaitteissa 5 arkipäivän kuluessa. Onnistuneen valmistumisen jälkeen kyseisen alueen tilaksi päivittyy Control Hubissa ”Aktivoitu”. |
Vaihe 4: Asiakas suorittaa verkon konfiguroinnin
Tilaksi muutetaan "Aktivoitu", mikä ilmoittaa asiakkaan ylläpitäjälle, että Ciscon IP VPN -yhteyden konfiguraatiot on suoritettu loppuun asiakkaan antamien tietojen perusteella. Asiakaspääkäyttäjän odotetaan kuitenkin viimeistelevän oman puolensa CPE-määritysten tekemisen ja testaavan yhteysreitit, jotta Virtual Connect -tunneli on online-tilassa. Jos konfiguroinnin tai yhteyden muodostamisen aikana ilmenee ongelmia, asiakas voi ottaa yhteyttä Cisco TAC:iin saadaksesi apua. |
Vianmääritys
IPsec-protokollan ensimmäisen vaiheen (IKEv2-neuvottelu) vianmääritys ja validointi
IPsec-tunnelineuvotteluun kuuluu kaksi vaihetta: IKEv2-vaihe ja IPsec-vaihe. Jos IKEv2-vaiheen neuvottelu ei valmistu, toista IPsec-vaihetta ei aloiteta. Tarkista ensin, onko IKEv2-istunto aktiivinen, antamalla komento "show crypto ikev2 sa" (Ciscon laitteella) tai vastaava komento kolmannen osapuolen laitteella. Jos IKEv2-istunto ei ole aktiivinen, mahdolliset syyt voivat olla:
-
Mielenkiintoinen liikenne ei laukaise IPsec-tunnelia.
-
IPsec-tunnelin käyttöoikeusluettelo on määritetty väärin.
-
Asiakkaan ja Dedicated Instance IPsec -tunnelin päätepisteen IP-osoitteen välillä ei ole yhteyttä.
-
IKEv2-istunnon parametrit eivät vastaa dedikoidun instanssin puolen ja asiakkaan puolen välillä.
-
Palomuuri estää IKEv2 UDP -paketit.
Tarkista ensin IPsec-lokeista viestit, jotka osoittavat IKEv2-tunnelineuvottelun edistymisen. Lokit saattavat viitata IKEv2-neuvottelun ongelmiin. Lokikirjausviestien puute voi myös viitata siihen, että IKEv2-istuntoa ei aktivoida.
Joitakin yleisiä virheitä IKEv2-neuvottelussa ovat:
-
CPE-puolen IKEv2-asetukset eivät vastaa Ciscon puolen asetuksia, tarkista mainitut asetukset uudelleen:
-
Tarkista, että IKE-versio on versio 2.
-
Varmista, että salaus- ja todennusparametrit vastaavat odotettua salausta erillisen instanssin puolella.
Kun "GCM"-salaus on käytössä, GCM-protokolla käsittelee todennuksen ja asettaa todennusparametrin arvoksi NULL.
-
Tarkista käyttöiän asetus.
-
Tarkista Diffie-Hellmanin moduuliryhmä.
-
Tarkista pseudosatunnaisfunktion asetukset.
-
-
Kryptokartan käyttöoikeusluetteloa ei ole asetettu arvoon:
-
Salli GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (tai vastaava komento)
Käyttöoikeusluettelon on oltava erityisesti "GRE"-protokollaa varten, muuten "IP"-protokolla ei toimi.
-
Jos lokitiedot eivät osoita IKEv2-vaiheen neuvottelutoimintaa, pakettien sieppaus saattaa olla tarpeen.
Dedikoidun instanssin puoli ei aina aloita IKEv2-vaihtoa ja saattaa joskus odottaa asiakkaan CPE-puolen olevan aloittaja.
Tarkista CPE-puolen määrityksistä seuraavat IKEv2-istunnon aloittamisen edellytykset:
-
Tarkista IPsec-kryptoprotokollan käyttöoikeusluettelo GRE-liikenteelle (protokolla 50) CPE-tunnelisiirto-IP-osoitteesta Dedicated Instance -tunnelisiirto-IP-osoitteeseen.
-
Varmista, että GRE-tunneliliitäntä on otettu käyttöön GRE-keepalive-tallennuksille. Jos laite ei tue GRE-keepalive-tallennuksia, Ciscolle ilmoitetaan siitä, koska GRE-keepalive-tallennukset ovat oletusarvoisesti käytössä Dedicated Instancen puolella.
-
Varmista, että BGP on käytössä ja määritetty Dedicated Instance -tunnelin IP-osoitteen naapuriosoitteella.
Kun konfigurointi on tehty oikein, IPsec-tunneli ja ensimmäisen vaiheen IKEv2-neuvottelu alkavat seuraavasti:
-
GRE-keepalive-tiedostot CPE-puolen GRE-tunnelirajapinnasta Dedicated Instancen puolen GRE-tunnelirajapintaan.
-
BGP-naapurin TCP-istunto CPE-puolen BGP-naapurilta Dedicated Instancen puolen BGP-naapurille.
-
Lähetä ping-kutsu CPE:n puoleisen tunnelin IP-osoitteesta Dedicated Instancen puoleisen tunnelin IP-osoitteeseen.
Ping ei voi olla tunnelisiirto-IP-osoite tunnelisiirto-IP-osoitteesta tunnelisiirto-IP-osoitteeseen, sen on oltava tunnelisiirto-IP-osoite.
Jos IKEv2-liikenteelle tarvitaan pakettien jäljitys, aseta suodatin UDP:lle ja joko portille 500 (kun IPsec-päätepisteiden keskellä ei ole NAT-laitetta) tai portille 4500 (kun NAT-laite on asetettu IPsec-päätepisteiden keskelle).
Varmista, että portin 500 tai 4500 IKEv2 UDP -paketit lähetetään ja vastaanotetaan DI IPsec IP -osoitteesta.
Dedikoidun instanssin datakeskus ei aina aloita ensimmäistä IKEv2-pakettia. Vaatimuksena on, että CPE-laite pystyy aloittamaan ensimmäisen IKEv2-paketin Dedicated Instance -puolelle.
Jos paikallinen palomuuri sallii sen, yritä myös lähettää ping-komento etä-IPsec-osoitteeseen. Jos ping-kutsu paikallisesta IPsec-osoitteesta etäosoitteeseen ei onnistu, jäljitä reitti ja selvitä, mihin paketti pudotetaan.
Jotkin palomuurit ja internet-laitteet eivät välttämättä salli reitin jäljitystä.
IPsecin toisen vaiheen (IPsec-neuvottelu) vianmääritys ja validointi
Varmista, että IPsecin ensimmäinen vaihe (eli IKEv2-suojausassosiaatio) on aktiivinen ennen IPsecin toisen vaiheen vianmääritystä. Suorita komento "show crypto ikev2 sa" tai vastaava tarkistaaksesi IKEv2-istunnon. Tarkista tulosteesta, että IKEv2-istunto on ollut käynnissä yli muutaman sekunnin ja että se ei pomppi. Istunnon käyttöaika näkyy tulosteessa istunnon "aktiivisena aikana" tai vastaavana.
Kun IKEv2-istunto on vahvistettu aktiiviseksi, tutki IPsec-istuntoa. Kuten IKEv2-istunnon kanssa, suorita "show crypto ipsec sa" tai vastaava komento IPsec-istunnon varmistamiseksi. Sekä IKEv2-istunnon että IPsec-istunnon on oltava aktiivisia ennen GRE-tunnelin muodostamista. Jos IPsec-istunto ei näy aktiivisena, tarkista IPsec-lokeista virheilmoitukset tai neuvotteluvirheet.
Joitakin yleisimpiä ongelmia, joita IPsec-neuvottelujen aikana voidaan kohdata, ovat:
CPE-puolen asetukset eivät vastaa Dedicated Instance -puolen asetuksia. Tarkista asetukset uudelleen:
-
Varmista, että salaus- ja todennusparametrit vastaavat Dedicated Instance -puolen asetuksia.
-
Varmista, että Perfect Forward Secrecy -asetukset vastaavat Dedicated Instance -puolen asetuksia.
-
Tarkista käyttöikäasetukset.
-
Varmista, että IPsec on määritetty tunnelitilassa.
-
Tarkista lähde- ja kohde-IPsec-osoitteet.
Tunnelirajapinnan vianmääritys ja validointi
Kun IPsec- ja IKEv2-istuntojen on vahvistettu olevan aktiivisia, GRE-tunnelin keepalive-paketit voivat kulkea Dedicated Instancen ja CPE-tunnelin päätepisteiden välillä. Jos tunnelirajapinnan tila ei näy, joitakin yleisiä ongelmia ovat:
-
Tunnelirajapinnan siirto-VRF ei vastaa loopback-rajapinnan VRF:ää (jos VRF-konfiguraatiota käytetään tunnelirajapinnassa).
Jos VRF-konfiguraatiota ei käytetä tunnelirajapinnassa, tämä tarkistus voidaan jättää huomiotta.
-
Keepalive-toiminnot eivät ole käytössä CPE-puolen tunnelirajapinnassa.
Jos CPE-laitteet eivät tue keepalive-toimintoja, Ciscolle on ilmoitettava siitä, jotta myös Dedicated Instancen puolella olevat oletusarvoiset keepalive-toiminnot poistetaan käytöstä.
Jos keepalive-toimintoja tuetaan, varmista, että ne ovat käytössä.
-
Tunneliliitännän maski tai IP-osoite on virheellinen eikä vastaa Dedicated Instancen odotettuja arvoja.
-
Lähde- tai kohdetunnelin siirto-osoite on virheellinen eikä vastaa Dedicated Instancen odotettuja arvoja.
-
Palomuuri estää GRE-pakettien lähettämisen IPsec-tunneliin tai vastaanottamisen IPsec-tunnelista (GRE-tunneli kuljetetaan IPsec-tunnelin kautta).
Ping-testin pitäisi varmistaa, että paikallinen tunneliliitäntä on toiminnassa ja että yhteys etätunneliliitäntään on hyvä. Suorita ping-tarkistus tunnelin IP-osoitteesta (ei siirto-IP-osoitteesta) etätunnelin IP-osoitteeseen.
GRE-tunneliliikennettä kuljettavan IPsec-tunnelin kryptokäyttöoikeusluettelo sallii vain GRE-pakettien läpäisyn. Tämän seurauksena pingit eivät toimi tunnelisiirron IP-osoitteesta etätunnelisiirron IP-osoitteeseen.
Ping-tarkistus tuottaa GRE-paketin, joka generoidaan lähdetunnelin siirto-IP-osoitteesta kohdetunnelin siirto-IP-osoitteeseen, kun taas GRE-paketin (sisäisen IP-osoitteen) hyötykuorma on lähde- ja kohdetunnelin IP-osoitteet.
Jos ping-testi ei onnistu ja edellä mainitut kohdat on varmistettu, paketin sieppaus voi olla tarpeen sen varmistamiseksi, että ICMP-ping tuottaa GRE-paketin, joka sitten kapseloidaan IPsec-pakettiin ja lähetetään lähde-IPsec-osoitteesta kohde-IPsec-osoitteeseen. GRE-tunnelirajapinnan laskurit ja IPsec-istuntolaskurit voivat myös auttaa näyttämään, kasvavatko lähetettyjen ja vastaanotettavien pakettien määrät.
Ping-liikenteen lisäksi sieppauksen pitäisi näyttää myös keepalive GRE -paketit myös lepotilassa olevan liikenteen aikana. Lopuksi, jos BGP on konfiguroitu, BGP keepalive -paketit tulisi lähettää myös GRE-paketteina IPSEC-paketteihin kapseloituina VPN:n kautta.
BGP-vianmääritys ja validointi
BGP-istunnot
BGP vaaditaan reititysprotokollana VPN IPsec -tunnelin yli. Paikallisen BGP-naapurin tulisi muodostaa eBGP-istunto Dedicated Instance BGP -naapurin kanssa. eBGP-naapurin IP-osoitteet ovat samat kuin paikallisen ja etätunnelin IP-osoitteet. Varmista ensin, että BGP-istunto on käynnissä, ja tarkista sitten, että Dedicated Instancelta vastaanotetaan oikeat reitit ja että Dedicated Instancelle lähetetään oikea oletusreitti.
Jos GRE-tunneli on toiminnassa, varmista, että ping-komento paikallisen ja etä-GRE-tunnelin IP-osoitteen välillä onnistuu. Jos ping onnistuu, mutta BGP-istunto ei käynnisty, tutki BGP-loki BGP:n perustamisvirheiden varalta.
Joitakin yleisimpiä BGP-neuvotteluongelmia ovat:
-
Etä-AS-numero ei vastaa erillisen instanssin puolella määritettyä AS-numeroa. Tarkista naapuri-AS-kokoonpano uudelleen.
-
Paikallinen AS-numero ei vastaa dedikoidun instanssin puolen odottamia tietoja. Varmista, että paikallinen AS-numero vastaa odotettuja dedikoidun instanssin parametreja.
-
Palomuuri estää GRE-paketteihin kapseloitujen BGP TCP -pakettien lähettämisen IPsec-tunneliin tai vastaanottamisen IPSEC-tunnelista.
-
Etä-BGP-naapurin IP-osoite ei vastaa etä-GRE-tunnelin IP-osoitetta.
BGP-reitinvaihto
Kun BGP-istunto on vahvistettu molemmille tunneleille, varmista, että Dedicated Instancen puolella lähetetään ja vastaanotetaan oikeita reittejä.
Dedicated Instance VPN -ratkaisu odottaa kahden tunnelin muodostamista customer/partner puolella. Ensimmäinen tunneli osoittaa Dedicated Instance -tietokeskukseen A ja toinen tunneli osoittaa Dedicated Instance -tietokeskukseen B. Molempien tunnelien on oltava aktiivisessa tilassa ja ratkaisu vaatii active/active käyttöönotto. Jokainen Dedicated Instance -tietokeskus mainostaa paikallista /25 reitti sekä /24 varareitti. Kun tarkistat Dedicated Instancesta saapuvia BGP-reittejä, varmista, että Dedicated Instancen konesaliin A osoittavaan tunneliin liittyvä BGP-istunto vastaanottaa Dedicated Instancen konesalin A. /25 paikallisreitti sekä /24 varareitti. Varmista lisäksi, että Dedicated Instance -tietokeskukseen B osoittava tunneli vastaanottaa Dedicated Instance -tietokeskuksen B. /25 paikallisreitti sekä /24 varareitti. Huomaa, että /24 Varareitti on sama reitti, jota mainostetaan sekä Dedicated Instance -tietokeskuksesta A että Dedicated Instance -tietokeskuksesta B.
Dedicated Instance -tietokeskukselle tarjotaan redundanssia, jos tunneliliitäntä kyseiseen tietokeskukseen kaatuu. Jos yhteys Dedicated Instance -tietokeskukseen A katkeaa, liikenne ohjataan Dedicated Instance -tietokeskuksesta B tietokeskukseen A. Tässä skenaariossa tunneli tietokeskukseen B käyttää tietokeskusta B. /25 reitti liikenteen lähettämiseen datakeskukseen B ja tunneli datakeskukseen B käyttää varareittiä /24 reitti liikenteen lähettämiseksi datakeskukseen A datakeskuksen B kautta.
On tärkeää, että molempien tunnelien ollessa aktiivisia, datakeskus A:n tunnelia ei käytetä liikenteen lähettämiseen datakeskukseen B ja päinvastoin. Tässä skenaariossa, jos liikennettä lähetetään datakeskukseen A määränpäänä datakeskus B, datakeskus A välittää liikenteen datakeskukseen B ja sitten datakeskus B yrittää lähettää liikenteen takaisin lähteelle datakeskus B:n tunnelin kautta. Tämä johtaa epäoptimaaliseen reititykseen ja voi myös rikkoa palomuurien läpi kulkevaa liikennettä. Siksi on tärkeää, että molemmat tunnelit ovat kunnossa. active/active konfigurointi normaalin käytön aikana.
The 0.0.0.0/0 Reitti on mainostettava asiakkaan puolelta Dedicated Instancen datakeskuksen puolelle. Dedikoidun instanssin puoli ei hyväksy tarkempia reittejä. Varmista, että 0.0.0.0/0 Reittiä mainostetaan sekä Dedicated Instance -tietokeskuksen A tunnelista että Dedicated Instance -tietokeskuksen B tunnelista.
MTU-konfiguraatio
Dedikoidun instanssin puolella on kaksi ominaisuutta, jotka säätävät MTU:ta dynaamisesti suurille pakettikoille. GRE-tunneli lisää VPN-istunnon läpi kulkeviin IP-paketteihin otsikoita. IPsec-tunneli lisää ylimääräisiä otsikoita GRE-otsikoiden päälle, mikä pienentää entisestään tunnelin yli sallittua suurinta MTU:ta.
GRE-tunneli säätää MSS-ominaisuutta ja GRE-tunnelipolku MTU-etsintätoiminnossa on käytössä Dedicated Instancen puolella. Määritä komento "ip tcp adjust-mss 1350" tai vastaava sekä "tunnel path\u0002mtu-discovery" tai vastaava komento asiakkaan puolella VPN-tunnelin läpi kulkevan liikenteen MTU-arvon dynaamisen säätämisen helpottamiseksi.