Опцията Virtual Connect помага за сигурно разширяване на частната им мрежа през интернет, използвайки IP VPN тунели от точка до точка.
Въведение
Виртуалното свързване е добавка опция за свързване в облак към специален екземпляр за Webex Calling (посветен екземпляр). Virtual Connect позволява на клиентите да разширят сигурно своята частна мрежа през интернет, използвайки IP VPN тунели от точка до точка. Тази опция за свързване осигурява бързо установяване на частна мрежова връзка чрез използване на съществуващото клиентско оборудване (CPE) и интернет свързаност.
Cisco хоства, управлява и осигурява излишни IP VPN тунели и необходимия достъп до Интернет в регион(ите) на центъра за данни на Cisco Dedicated Instance, където се изисква услугата. По същия начин, администраторът е отговорен за съответните им CPE и интернет услуги, които са необходими за установяване на Virtual Connect.
Всяка поръчка за виртуално свързване в определен регион на Специализиран инстанция ще включва два тунела за капсулиране на генерично маршрутизиране (GRE), защитени с IPSec криптиране (GRE над IPSec), по един към всеки център за данни на Cisco в избрания регион.
Virtual Connect има ограничение на честотната лента от 250 Mbps на тунел и се препоръчва за по-малки разгръщания. Тъй като се използват два VPN тунела от точка до точка, целият трафик към облака трябва да премине през CPE на клиентската глава и следователно може да не е подходящ, където има много отдалечени сайтове. За други алтернативни опции за пиринг вж Облачна свързаност .
Предварителни изисквания
Предпоставките за установяване на Virtual Connect включват:
Клиентът предоставя
Интернет връзка с достатъчно налична честотна лента, за да поддържа внедряването
Публичен IP адрес(и) за два IPSec тунела
GRE транспортни IP адреси от страна на клиента за двата GRE тунела
Партньор и Клиент
Работете заедно, за да оцените изискванията за честотна лента
Уверете се, че мрежово устройство(а) поддържат маршрутизиране по протокола на граничния шлюз (BGP) и дизайн на тунел GRE над IPSec
Партньорът или Клиентът предоставя
Мрежов екип с познания за VPN тунелни технологии от място до място
Мрежов екип с познания по BGP, eBGP и общи принципи за маршрутизиране
Cisco
Присвоени на Cisco частни автономни системни номера (ASN) и преходно IP адресиране за GRE тунелни интерфейси
Присвоена на Cisco публична, но не и интернет маршрутизирана мрежа от клас C (/24) за адресиране в облак за Специализирани инстанции
 |
Ако клиентът има само 1 CPE устройство, тогава 2-та тунела към центровете за данни на Cisco (DC1 и DC2) във всеки регион ще бъдат от това CPE устройство. Клиентът също има опция за 2 CPE устройства, след което всяко CPE устройство трябва да се свърже към 1 тунел само към центровете за данни на Cisco (DC1 и DC2) във всеки регион. Допълнително резервиране може да бъде постигнато чрез прекратяване на всеки тунел в отделен физически обект/местоположение в инфраструктурата на Клиента. |
Технически данни
Модел на разполагане
Virtual Connect използва двустепенна архитектура на главата, където равнините на маршрутизиране и GRE се осигуряват от едно устройство, а IPSec контролната равнина се осигурява от друго.
При завършване на Виртуална връзка свързаност, ще бъдат създадени два тунела GRE през IPSec между корпоративната мрежа на Клиента и центровете за данни на Cisco за специален екземпляр. По един за всеки излишен център за данни в рамките на съответния регион. Допълнителните мрежови елементи, необходими за пиринга, се обменят от Партньорът или Клиентът към Cisco чрез формуляра за активиране на Control Hub Virtual Connect.
Фигура 1 показва пример за модел за разгръщане на Virtual Connect за опцията с 2 концентратора от страна на клиента.
Виртуално свързване – VPN е дизайн на хъб, при който хъб сайтовете на клиента са свързани към DC1 и DC2 на центровете за данни на Специализиран инстанция в рамките на определен регион.
Два сайта на Hub се препоръчват за по-добро резервиране, но един сайт Hub с два тунела също е поддържан модел за разгръщане.
|
Пропускателната способност на тунел е ограничена до 250 Mbps. |
 |
Отдалечените сайтове на Клиента в рамките на същия регион ще трябва да се свържат обратно към сайта(ите) на центъра през WAN на Клиента и Cisco не носи отговорност за тази свързаност. |
Очаква се партньорите да работят в тясно сътрудничество с клиентите, като гарантират, че е избран най-оптималният път за региона на обслужване „Virtual Connect“.
Фигура 2 показва пиринговите региони за свързаност в облак за специален екземпляр.
Маршрутизиране
добавка за маршрутизиране за Virtual Connect се реализира с помощта на външен BGP (eBGP) между Специализирано инстанция и оборудването на клиента (CPE). Cisco ще рекламира своята съответна мрежа за всеки излишен DC в рамките на региона на CPE на клиента и CPE трябва да обяви маршрут по подразбиране до Cisco.
Cisco поддържа и възлага
IP адресиране на тунелен интерфейс (преходна връзка за маршрутизиране) Cisco присвоява от определено споделено адресно пространство (непублично маршрутизирано)
Адрес на местоназначение за тунелен транспорт (от страната на Cisco)
Частни автономни системни номера (ASN) за конфигурация на клиентска BGP маршрутизация
Cisco присвоява от определения обхват за частна употреба: 64512 до 65534
eBGP се използва за обмен на маршрути между Специализиран инстанция и CPE
Cisco ще раздели назначената /24 мрежа на 2/25 за всеки DC в съответния регион
Във Virtual Connect всяка /25 мрежа се рекламира обратно към CPE от Cisco през съответните VPN тунели от точка до точка (преходна връзка)
CPE трябва да бъде конфигуриран със съответните съседи на eBGP. Ако се използва един CPE, ще се използват два съседа на eBGP, като единият сочи към всеки отдалечен тунел. Ако използвате два CPE, тогава всеки CPE ще има един съсед eBGP, насочващ към единичния отдалечен тунел за CPE.
Cisco страната на всеки GRE тунел ( IP на тунелен интерфейс) е конфигурирана като BGP съсед на CPE
CPE се изисква за рекламиране на маршрут по подразбиране над всеки от тунелите
CPE е отговорен за преразпределянето, ако е необходимо, на научените маршрути в рамките на корпоративната мрежа на клиента.
При условие за отказ на връзката без повреда, един CPE ще има два активни/активни тунела. За два CPE възела, всеки CPE ще има един активен тунел и двата CPE възела трябва да са активни и преминаващи трафик. При сценарий без отказ трафикът трябва да се раздели на два тунела, които отиват до правилните /25 дестинации, ако един от тунелите падне, оставащият тунел може да пренесе трафика и за двата. При такъв сценарий на неуспех, когато мрежата /25 не работи, тогава мрежата /24 се използва като резервен маршрут. Cisco ще изпраща клиентски трафик през своя вътрешен WAN към DC, който загуби връзка.
Процес на свързване
| 1 | |
| 2 | |
| 3 | |
| 4 |
Стъпка 1: Разпореждане CCW
Virtual Connect е добавка за специален екземпляр в CCW.
| 1 | Отидете до сайта за поръчки CCW и след това щракнете върху Вход, за да влезете в сайта: |
||
| 2 | Създаване на оценка. |
||
| 3 | Добавете "A-FLEX-3" SKU. |
||
| 4 | Изберете Опции за редактиране. |
||
| 5 | В раздела за абонамент, който се показва, Изберете Опции и Добавки. |
||
| 6 | Под Допълнителни добавки поставете поле за отметка до „Virtual Connect for Dedicated Instance“. Името на SKU е "A-FLEX-DI-VC". |
||
| 7 | Въведете количеството и броя на регионите, в които се изисква Virtual Connect.
|
||
| 8 | Когато сте доволни от избора си, щракнете върху Потвърди и Запази в горната дясна част на страницата. |
||
| 9 | Щракнете върху Запиши и продължи, за да финализирате поръчката си. Вашата финализирана поръчка вече се показва в мрежата за поръчки. |
Стъпка 2: Активиране на Virtual Connect в Control Hub
| 1 | Влезте в Control Hubhttps://admin.webex.com/login . |
||||||||
| 2 | В Услуги раздел, отидете до Обаждане > Специален екземпляр > Свързване в облак . |
||||||||
| 3 | В картата Virtual Connect е посочено закупеното количество Virtual Connect. Сега администраторът може да щракне върху Активирайте за да стартирате активирането на Virtual Connect. 
|
||||||||
| 4 | При щракване върху Активирайте бутон, Активирайте Virtual Connect се показва формуляр за администратора, за да предостави технически подробности за Virtual Connect, необходими за конфигурациите за пиринг от страна на Cisco.
|
||||||||
| 5 | Кликнете върху Активирайте бутон, след като всички задължителни полета са попълнени. |
||||||||
| 6 | След като формулярът за активиране на виртуално свързване е попълнен за конкретен регион, клиентът може да експортира формуляра за активиране от Control Hub, Calling > Dedicated Instance > Cloud Connectivity и щракнете върху Export settings. 
|
Стъпка 3: Cisco извършва мрежова конфигурация
| 1 | След като формулярът за активиране на Virtual Connect бъде попълнен, състоянието ще бъде актуализирано на Активирането е в ход в Обаждане > Специализиран екземпляр > карта за виртуална връзка с облак. |
| 2 | Cisco ще завърши необходимите конфигурации на страничното оборудване на Cisco вътре 5 работни дни . При успешно завършване състоянието ще бъде актуализирано на „Активирано“ за този конкретен регион в Control Hub. |
Стъпка 4: Клиентът извършва мрежова конфигурация
Състоянието се променя на „Активирано“, за да уведоми администратора на Клиента, че конфигурацията на Cisco за IP VPN свързаността е завършена въз основа на въведените данни, предоставени от Клиента. Но се очаква администраторът на клиента да завърши своята част от конфигурациите на CPE и да тества маршрутите за свързване, за да може тунелът Virtual Connect да бъде онлайн. В случай на проблеми по време на конфигуриране или свързване, клиентът може да се обърне към Cisco TAC за съдействие. |
Отстраняване на неизправности
IPsec първа фаза (IKEv2 преговори) Отстраняване на неизправности и валидиране
Договарянето на IPsec тунел включва две фази, фаза IKEv2 и фаза IPsec. Ако договарянето на фазата IKEv2 не завърши, тогава няма иницииране на втора фаза на IPsec. Първо, издайте командата "show crypto ikev2 sa" (на оборудване на Cisco ) или подобна команда на оборудването на трета страна, за да проверите дали сесията IKEv2 е активна. Ако сесията IKEv2 не е активна, потенциалните причини могат да бъдат:
Интересният трафик не задейства IPsec тунела.
Списъкът за списък за достъп до тунел IPsec е неправилно конфигуриран.
Няма свързаност между клиента и IPsec на крайната точка на тунела на специален IP.
Параметрите на сесията на IKEv2 не съвпадат между страната на Специализирания модел и страната на клиента.
Защитна стена блокира IKEv2 UDP пакетите.
Първо проверете регистрационните файлове на IPsec за съобщения, които показват напредъка на договарянето на IKEv2 тунел. Регистрите могат да показват къде има проблем с договарянето на IKEv2. Липсата на съобщения за регистриране може също да означава, че IKEv2 сесията не се активира.
Настройките за IKEv2 от страната на CPE не съвпадат със страната на Cisco , проверете отново споменатите настройки:
Проверете дали версията на IKE е версия 2.
Проверете дали параметрите за шифроване и удостоверяване съвпадат с очакваното криптиране от страна на Специализирания екземпляр.
Когато се използва шифърът "GCM", протоколът GCM обработва удостоверяването и задава параметъра за удостоверяване на NULL.
Проверете настройката за продължителност на живота.
Проверете модулната група на Diffie Hellman.
Проверете настройките на псевдослучайната функция.
списък за достъп за крипто картата не е настроен на:
Разрешете GRE (local_tunnel_transport_ip ) 255.255.255.255 (remote_tunnel_transport_ip ) 255.255.255.255" (или еквивалентна команда)
Списъкът за списък за достъп трябва да е специално за протокола "GRE" и протоколът "IP" няма да работи.
Ако регистрационните съобщения не показват никаква активност на договаряне за фазата IKEv2, тогава може да е необходимо прихващане на пакети .
|
Страната на специализирания модел може не винаги да започне IKEv2 обмен и понякога може да очаква CPE страната на клиента да бъде инициатор. Проверете конфигурацията от страна на CPE за следните предпоставки за иницииране на IKEv2 сесия:
|
Когато е конфигурирано правилно, следното започва IPsec тунела и договарянето на IKEv2 от първата фаза:
GRE поддържа активност от GRE тунелния интерфейс от страната на CPE към интерфейса на GRE тунела от страна на специален инстанция.
BGP съсед TCP сесия от съседната BGP страна на CPE към съседната BGP страна на Специализиран инстанция.
Изпратете пинг от IP адреса на тунелния страничен CPE към IP адрес IP адрес на тунелния страничен екземпляр.
Ping не може да бъде IP от тунелен транспорт към тунелен IP, той трябва да бъде IP от тунел.
Ако е необходимо проследяване на пакети за трафика на IKEv2, задайте филтъра за UDP и порт 500 (когато няма NAT устройство в средата на крайните точки на IPsec) или порт 4500 (когато NAT устройство е вмъкнато в средата на IPsec крайни точки).
Проверете дали IKEv2 UDP пакети с порт 500 или 4500 се изпращат и получават до и от DI IPsec IP адрес.
|
Центърът за данни със специален екземпляр не винаги може да започне първия IKEv2 пакет. Изискването е CPE устройството да може да инициира първия IKEv2 пакет към страната на Специализирания екземпляр. Ако локалната защитна стена го позволява, опитайте и пинг до отдалечения IPsec адрес. Ако пингът не е успешен от локален към отдалечен IPsec адрес, извършете маршрут за проследяване, за да помогнете и определете къде е изпуснат пакетът. Някои защитни стени и интернет оборудване може да не позволяват проследяване на маршрут. |
Втора фаза на IPsec (договаряне на IPsec) Отстраняване на неизправности и валидиране
Проверете дали първата фаза на IPsec (тоест асоциацията за сигурност IKEv2) е активна, преди да отстраните неизправности във втората фаза на IPsec. Изпълнете „show crypto ikev2 sa“ или еквивалентна команда, за да проверите сесията на IKEv2. В изхода проверете дали сесията IKEv2 е била активна за повече от няколко секунди и че не отскача. Времето на работа на сесията се показва като "Активно време" на сесията или еквивалентно на изхода.
След като сесията на IKEv2 се потвърди, че е активна, проучете сесията на IPsec. Както при сесията IKEv2, изпълнете „show crypto ipsec sa“ или еквивалентна команда, за да проверите IPsec сесията. И сесията IKEv2, и сесията IPsec трябва да са активни, преди да се установи тунелът GRE. Ако сесията на IPsec не се показва като активна, проверете регистрационните файлове на IPsec за съобщения за грешки или грешки при договаряне.
Някои от по-често срещаните проблеми, които могат да се срещнат по време на преговорите за IPsec, са:
Настройките от страната на CPE не съвпадат със страната за специален екземпляр, проверете отново настройките:
Уверете се, че параметрите за шифроване и удостоверяване съвпадат с настройките от страната на Специализиран екземпляр.
Проверете настройките за перфектна препращана секретност и дали настройките за съвпадение от страната на Специализирания екземпляр.
Проверете настройките за целия живот.
Проверете дали IPsec е конфигуриран в тунелен режим.
Проверете IPsec адресите на източника и местоназначението.
Отстраняване и валидиране на неизправности в интерфейса на тунела
Когато IPsec и IKEv2 сесиите са проверени като активирани и активни, пакетите за поддържане на активност на тунела GRE могат да преминават между крайните точки на Специализирания екземпляр и CPE тунела. Ако интерфейсът на тунела не показва състояние, някои често срещани проблеми са:
Транспортният VRF на тунелния интерфейс не съвпада с VRF на интерфейса за обратна връзка (ако VRF конфигурацията се използва на интерфейса на тунела).
Ако VRF конфигурацията не се използва на интерфейса на тунела, тази проверка може да бъде игнорирана.
Keepalives не са разрешени в интерфейса на страничния тунел на CPE
Ако поддържането на активността не се поддържа от CPE оборудването, тогава Cisco трябва да бъде уведомен, така че поддържащите активности по подразбиране от страна на Специализирания екземпляр също да бъдат деактивирани.
Ако поддържането на активността се поддържа, проверете дали поддържането на активността е активирано.
Маската или IP адрес на интерфейса на тунела не е правилен и не съответства на очакваните стойности за специален екземпляр.
Транспортният адрес на тунела на източник или местоназначение не е правилен и не съответства на очакваните стойности за специален екземпляр.
Защитна стена блокира изпращането на GRE пакети в тунела IPsec или получени от тунела IPsec (тунелът GRE се транспортира през тунела IPsec)
Пинг тестът трябва да потвърди, че интерфейсът на локалния тунел е активиран и връзката е добра с интерфейса за отдалечен тунел. Извършете проверката на ping от тунелния IP (не транспортния IP) до отдалечения IP на тунела.
|
Списъкът за крипто списък за достъп за тунела IPsec, който пренася трафика на GRE тунела, позволява преминаването само на GRE пакети. В резултат на това пинговете няма да работят от тунелен транспортен IP към отдалечен тунелен транспортен IP. |
Проверката на ping води до GRE пакет, който се генерира от изходния тунел за транспортен IP до IP транспортния тунел на дестинацията, докато полезният товар на GRE пакета (вътрешният IP) ще бъде IP адресът на тунела на източника и дестинацията.
Ако ping тестът не е успешен и предходните елементи са проверени, тогава може да се изисква прихващане на пакети , за да се гарантира, че icmp ping води до GRE пакет, който след това се капсулира в IPsec пакет и след това се изпраща от изходния IPsec адрес до IPsec адреса на местоназначението. Броячите на интерфейса на тунела GRE и броячите на IPsec сесиите също могат да помогнат за показването. ако пакетите за изпращане и получаване се увеличават.
В допълнение към ping трафика, прихващането трябва да показва и поддържащи активност GRE пакети дори по време на неактивен трафик. И накрая, ако BGP е конфигуриран, BGP пакетите за поддържане на активността също трябва да се изпращат като GRE пакети, капсулирани в IPSEC пакети, както и през VPN.
Отстраняване и валидиране на BGP проблеми
BGP сесии
BGP се изисква като протокол за маршрутизиране през VPN IPsec тунела. Локалният BGP съсед трябва да установи eBGP сесия с BGP съседа на Специализиран инстанция. IP адресите на съседите на eBGP са същите като IP адресите на локалния и отдалечения тунел. Първо се уверете, че BGP сесията е стартирана и след това се уверете, че правилните маршрути се получават от Специализирания екземпляр и правилният маршрут по подразбиране се изпраща до Специализирания екземпляр.
Ако GRE тунелът е отворен, проверете дали ping е успешен между локалния и отдалечения IP тунел GRE. Ако пингът е успешен, но BGP сесията не се появява, тогава проучете BGP дневника за грешки при установяване на BGP.
Някои от по-често срещаните проблеми при договаряне на BGP са:
Номерът на отдалечения AS не съвпада с AS номера, който е конфигуриран от страната на Специализиран екземпляр, проверете отново конфигурацията на съседния AS.
Локалният номер на AS не съвпада с това, което страната на Dedictaed Instance очаква, проверете дали местният AS номер съответства на очакваните параметри на Dedicated Instance.
Защитна стена блокира BGP TCP пакети, капсулирани в GRE пакети, да бъдат изпратени в тунела IPsec или да бъдат получени от тунела IPSEC
IP отдалеченият съсед на BGP не съвпада с IP отдалечения GRE тунел.
BGP обмен на маршрути
След като BGP сесията бъде проверена и за двата тунела, уверете се, че правилните маршрути се изпращат и получават от страната на Специализирания екземпляр.
Решението за специализирани инстанции за VPN очаква да бъдат установени два тунела от страна на клиента/партньора. Първият тунел сочи към Центъра за данни A Специализиран екземпляр, а вторият тунел сочи към Центъра за данни B за Специализиран екземпляр. И двата тунела трябва да са в активно състояние и решението изисква активно/активно разгръщане. Всеки център за данни за специален екземпляр ще рекламира своя локален /25 маршрут, както и /24 резервен маршрут. Когато проверявате входящите BGP маршрути от Специализиран екземпляр, уверете се, че BGP сесията, свързана с тунела, сочещ към Центъра за данни A за Специализиран екземпляр, получава локален маршрут на Центъра за данни A /25, както и резервния маршрут /24. В допълнение, уверете се, че тунелът, сочещ към център за данни B за Специализиран екземпляр, получава локален маршрут на центъра за данни B /25 за Специализиран екземпляр, както и маршрута за архивиране /24. Имайте предвид, че маршрутът за архивиране /24 ще бъде същият маршрут, обявен от център за данни A за Специализиран екземпляр и център за данни B за Специален екземпляр.
Резервирането се предоставя на център за данни със специален екземпляр, ако интерфейсът на тунела към този център за данни се повреди. Ако свързаността към център за данни A на специален екземпляр се загуби, тогава трафикът ще бъде препратен от център за данни B на специален екземпляр към център за данни A. В този сценарий тунелът към център за данни B ще използва маршрута на центъра за данни B /25 за изпращане на трафик към център за данни B и тунела към център за данни B ще използва резервния /24 маршрут за изпращане на трафик към център за данни A през център за данни B.
Важно е, когато и двата тунела са активни, тунелът на център за данни A да не се използва за изпращане на трафик към център за данни B и обратно. В този сценарий, ако трафикът се изпраща към център за данни A с дестинация на център за данни B, център за данни A ще препрати трафика към център за данни B и след това център за данни B ще се опита да изпрати трафик обратно към източника през тунела на центъра за данни B. Това ще доведе до неоптимално маршрутизиране и може също да наруши защитните стени, преминаващи през трафика. Следователно е важно и двата тунела да са в активна/активна конфигурация по време на нормална работа.
Маршрутът 0.0.0.0/0 трябва да бъде рекламиран от страната на клиента към страната на центъра за данни със специален екземпляр. По-конкретни маршрути няма да бъдат приети от страна на Специализирания инстанция. Уверете се, че маршрутът 0.0.0.0/0 се рекламира както от тунела А на Центъра за данни за Специализиран екземпляр, така и от Тунела на Центъра за данни B за Специализиран екземпляр.
MTU конфигурация
В страната за специален екземпляр са активирани две функции за динамично регулиране на MTU за големи размери на пакети. GRE тунелът добавя още заглавки към IP пакетите, преминаващи през VPN сесията. Тунелът IPsec добавя допълнителните заглавки върху заглавките GRE, което допълнително ще намали най-големия разрешен MTU през тунела.
Тунелът GRE настройва функцията MSS, а пътят на тунела GRE в функцията за откриване на MTU е активиран от страната на Специализирания екземпляр. Конфигурирайте "ip tcp adjust-mss 1350" или еквивалентна команда, както и "tunnel path\u0002mtu-discovery" или еквивалентна команда от страна на клиента, за да помогнете при динамичното регулиране на MTU на трафика през VPN тунела.
