Функція Virtual Connect допомагає безпечно розширювати приватну мережу через Інтернет за допомогою IP VPN-тунелів «точка-точка».
Вступ
Virtual Connect - це додаткова опція для хмарного підключення до виділеного екземпляра для викликів Webex (Dedicated Instance). Virtual Connect дозволяє клієнтам безпечно розширювати свою приватну мережу через Інтернет, використовуючи тунелі IP VPN типу точка-точка. Цей варіант підключення забезпечує швидке встановлення з 'єднання з приватною мережею за допомогою існуючого обладнання приміщення клієнта (CPE) та підключення до Інтернету.
Cisco розміщує, керує та забезпечує резервні тунелі IP VPN та необхідний доступ до Інтернету в регіоні(ах) центрів обробки даних виділеного екземпляра Cisco, де потрібна послуга. Аналогічно, Адміністратор несе відповідальність за відповідні послуги CPE та Інтернету, які необхідні для встановлення віртуального з 'єднання.
Кожне замовлення Virtual Connect у певній області виділеного екземпляра включатиме два загальних тунелі інкапсуляції маршрутизації (GRE), захищених шифруванням IPSec (GRE over IPSec), по одному для кожного центру обробки даних Cisco у вибраному регіоні.
Virtual Connect має обмеження пропускної здатності 250 Мбіт/с на тунель і рекомендується для невеликих розгортань. Оскільки використовуються два VPN-тунелі «точка-точка», весь трафік в хмару повинен проходити через головну частину клієнта CPE, і тому він може не підходити там, де є багато віддалених сайтів. Інші альтернативні варіанти пірингу див. у розділі Підключення до хмари.
Передумови
Передумови для встановлення Virtual Connect включають:
Замовник надає
Підключення до Інтернету з достатньою доступною пропускною здатністю для підтримки розгортання
Публічні IP-адреси для двох тунелів IPSec
Транспортні IP-адреси GRE на стороні клієнта для двох тунелів GRE
Партнер і клієнт
Працюйте разом, щоб оцінити вимоги до пропускної здатності
Переконайтеся, що мережеві пристрої підтримують маршрутизацію протоколу прикордонного шлюзу (BGP) та дизайн тунелю GRE over IPSec
Партнер або клієнт надає
Мережева команда зі знанням технологій VPN-тунелю site-to-site
Мережева команда зі знанням BGP, eBGP та загальних принципів маршрутизації
Cisco
Cisco призначила приватні автоматичні системні номери (Asn) та перехідну IP-адресу для інтерфейсів тунелю GRE
Cisco призначила загальнодоступну, але не маршрутизовану мережу класу C (/24) для адреси Dedicated Instance Cloud
 |
Якщо у клієнта є лише 1 пристрій CPE, то 2 тунелі до центрів обробки даних Cisco (DC1 І DC2) в кожному регіоні будуть з цього пристрою CPE. Замовник також має опцію для 2 пристроїв CPE, тоді кожен пристрій CPE повинен підключатися до 1 тунелю тільки до центрів обробки даних Cisco (DC1 і DC2) у кожному регіоні. Додаткове резервування може бути досягнуто шляхом припинення кожного тунелю на окремому фізичному майданчику/місці в інфраструктурі Замовника. |
Технічні деталі
Модель розгортання
Virtual Connect використовує дворівневу головну архітектуру, де площини маршрутизації та управління GRE забезпечуються одним пристроєм, а площина управління IPSec забезпечується іншим.
Після завершення підключення Virtual Connect між корпоративною мережею Замовника та центрами обробки даних Cisco Dedicated Instance буде створено два тунелі GRE over IPSec. По одному для кожного резервного центру обробки даних у відповідному регіоні. Додаткові мережеві елементи, необхідні для пірингу, обмінюються Партнером або Клієнтом з Cisco через форму активації віртуального підключення Control Hub.
На малюнку 1 показаний приклад моделі розгортання Virtual Connect для опції 2-концентратора на стороні клієнта.
Virtual Connect - VPN - це конструкція концентратора, де сайти концентратора Клієнта підключаються до DC1 та DC2 центрів обробки даних Dedicated Instance у певному регіоні.
Для кращого резервування рекомендуються два сайти концентратора, але сайт One Hub з двома тунелями також є підтримуваною моделлю розгортання.
|
Пропускна здатність одного тунелю обмежена 250 Мбіт/с. |
 |
Віддалені об 'єкти Замовника в тому ж регіоні повинні бути підключені до об' єкта(ів) концентратора через WAN Замовника, і Cisco не несе відповідальності за це підключення. |
Очікується, що партнери будуть тісно співпрацювати з Клієнтами, забезпечуючи вибір найбільш оптимального шляху для регіону обслуговування «Віртуальне з ’єднання».
На малюнку 2 показані пирингові області підключення до виділеного екземпляра хмарного сховища.
Маршрутизація
Маршрутизація для додатку Virtual Connect реалізується за допомогою зовнішнього BGP (eBGP) між виділеним екземпляром та обладнанням приміщення клієнта (CPE). Cisco буде рекламувати свою відповідну мережу для кожного резервного постійного струму в межах регіону до CPE Замовника, і CPE повинен рекламувати маршрут за замовчуванням до Cisco.
Cisco підтримує та призначає
IP-адресація тунельного інтерфейсу (перехідна лінія для маршрутизації) Cisco призначає з призначеного спільного адресного простору (не публічно маршрутизується)
Адреса призначення тунельного транспорту (сторона Cisco)
Приватні автономні системні номери (Asn) для конфігурації маршрутизації BGP замовника
Cisco призначає з призначеного діапазону приватного використання: від 64512 до 65534
eBGP використовується для обміну маршрутами між виділеним екземпляром та CPE
Cisco розділить призначену /24 мережу на 2 /25 по одному для кожного постійного струму у відповідному регіоні
У 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, а потім натисніть Login (Увійти), щоб увійти на сайт: |
||
| 2. | Створити оцінку. |
||
| 3. | Додайте артикул "A-FLEX-3". |
||
| 4. | Виберіть Редагувати параметри. |
||
| 5. | На вкладці підписки, яка з 'явиться, виберіть Параметри та додатки. |
||
| 6 | У розділі Додаткові додатки встановіть прапорець поруч із пунктом "Віртуальне з 'єднання для виділеного екземпляра". Назва артикулу - "A-FLEX-DI-VC". |
||
| 7 | Введіть кількість і кількість регіонів, в яких потрібне віртуальне з 'єднання.
|
||
| 8 | Коли ви будете задоволені своїм вибором, натисніть Перевірити та Зберегти у верхній правій частині сторінки. |
||
| 9 | Натисніть Зберегти та продовжити, щоб завершити замовлення. Ваше остаточне замовлення тепер відображається в сітці замовлень. |
Крок 2. Активація Virtual Connect в Control Hub
| 1. | Увійдіть в Control Hubhttps://admin.webex.com/login. |
||||||||
| 2. | У розділі "Послуги" перейдіть до розділу "Виклики" > "Виділені інсталяції" > "Підключення до хмари". |
||||||||
| 3. | На картці Virtual Connect вказано придбану кількість Virtual Connect. Тепер адміністратор може натиснути кнопку Активувати, щоб ініціювати активацію Virtual Connect. 
|
||||||||
| 4. | Після натискання кнопки Активувати відображається форма Активувати віртуальне з 'єднання, щоб адміністратор міг надати технічні відомості щодо віртуального з' єднання, необхідні для конфігурацій пірингу на стороні Cisco.
|
||||||||
| 5. | Натисніть кнопку Активувати після заповнення всіх обов 'язкових полів. |
||||||||
| 6 | Після заповнення форми активації віртуального з 'єднання для регіону частинок клієнт може експортувати форму активації з Центру керування, зателефонувавши > Виділений екземпляр > вкладка Підключення до хмари та натиснувши Налаштування експорту. 
|
Крок 3: Cisco виконує налаштування мережі
| 1. | Після заповнення форми активації Virtual Connect статус буде оновлено до Activation In-Progress у розділі Calling > Dedicated Instance > Cloud Connectivity Virtual Connect card. |
| 2. | Компанія Cisco виконає необхідні конфігурації бічного обладнання Cisco протягом 5 робочих днів. Після успішного завершення статус буде оновлено до «Активовано» для цього конкретного регіону в Центрі керування. |
Крок 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.
Між клієнтом і кінцевою точкою IP тунелю Dedicated Instance IPsec немає з 'єднання.
Параметри сеансу IKEv2 не збігаються між стороною виділеного екземпляра та стороною клієнта.
Брандмауер блокує пакети IKEv2 UDP.
По-перше, перевірте журнали IPsec на наявність будь-яких повідомлень, які показують хід переговорів про тунель IKEv2. Журнали можуть вказувати, де є проблема з переговорами IKEv2. Відсутність повідомлень журналювання також може вказувати на те, що сеанс IKEv2 не активується.
Налаштування для IKEv2 на стороні CPE не збігаються зі стороною Cisco, ще раз перевірте зазначені налаштування:
Переконайтеся, що ВЕРСІЯ IKE є версією 2.
Переконайтеся, що параметри шифрування та автентифікації відповідають очікуваному шифруванню на стороні виділеного екземпляра.
Коли використовується шифр "GCM", протокол GCM обробляє автентифікацію і встановлює параметр автентифікації на NULL.
Перевірте налаштування терміну служби.
Перевірте групу модулів Диффі Хеллмана.
Перевірте налаштування псевдовипадкової функції.
Список доступу для криптографічної карти не налаштований на:
Дозвіл 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 на стороні виділеного екземпляра.
Сесія TCP сусіда BGP від сторони CPE сусіда BGP до сторони виділеного екземпляра сусіда BGP.
Пінг з IP-адреси бічного тунелю CPE на IP-адресу виділеного екземпляра бічного тунелю.
Ping не може бути IP тунельного транспорту до IP тунельного транспорту, він повинен бути IP тунельного транспорту до IP тунельного транспорту.
Якщо трасування пакетів необхідне для трафіку IKEv2, встановіть фільтр для UDP і або порту 500 (коли жоден NAT-пристрій не знаходиться посередині кінцевих точок IPsec), або порту 4500 (коли NAT-пристрій вставляється посередині кінцевих точок IPsec).
Переконайтеся, що UDP-пакети IKEv2 з портом 500 або 4500 відправляються та отримуються на IP-адресу DI IPsec та з неї.
|
Виділений центр обробки даних екземплярів не завжди може розпочати перший пакет 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 не збігаються зі стороною Dedicated Instance (Виділений екземпляр), перевірте ще раз налаштування:
Переконайтеся, що параметри шифрування та автентифікації збігаються з параметрами на стороні виділеного екземпляра.
Перевірте налаштування Perfect Forward Secrecy та відповідність налаштувань на стороні Dedicated Instance (Виділений екземпляр).
Перевірте налаштування терміну служби.
Переконайтеся, що IPsec налаштовано в тунельному режимі.
Перевірте адреси IPsec джерела та призначення.
Усунення несправностей та перевірка інтерфейсу тунелю
Коли сеанси IPsec і IKEv2 перевіряються як вгору і активні, GRE-тунель зберігає живі пакети, здатні протікати між виділеним екземпляром і кінцевими точками тунелю CPE. Якщо інтерфейс тунелю не відображається, деякі поширені проблеми:
Транспортний VRF інтерфейсу тунелю не відповідає VRF інтерфейсу петлі (якщо на інтерфейсі тунелю використовується конфігурація VRF).
Якщо конфігурація VRF не використовується в інтерфейсі тунелю, цю перевірку можна проігнорувати.
Keepalives не ввімкнено на інтерфейсі бокового тунелю CPE
Якщо утримання не підтримується на обладнанні CPE, необхідно повідомити Cisco, щоб утримання за замовчуванням на стороні виділеного екземпляра також було вимкнено.
Якщо підтримуються Keepalives, перевірте, чи увімкнено Keepalives.
Маска або IP-адреса інтерфейсу тунелю неправильна і не відповідає очікуваним значенням виділеного екземпляра.
Адреса транспортування тунелю джерела або призначення неправильна і не відповідає очікуваним значенням виділеного екземпляра.
Брандмауер блокує GRE-пакети з відправлених в тунель IPsec або отриманих з тунелю IPsec (тунель GRE транспортується через тунель IPsec)
Тест ping повинен перевірити, чи локальний інтерфейс тунелю ввімкнений, а з 'єднання з віддаленим інтерфейсом тунелю є хорошим. Виконайте перевірку 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 також можуть допомогти показати, чи збільшуються пакети відправки та отримання.
На додаток до пінг-трафіку, захоплення також повинно показувати збереження пакетів GRE навіть під час простою трафіку. Нарешті, якщо налаштовано BGP, пакети BGP Keepalive також повинні надсилатися як пакети 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 для обох тунелів переконайтеся, що правильні маршрути надсилаються та отримуються зі сторони виділеного екземпляра.
Рішення Dedicated Instance 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 повинен бути прорекламований від сторони клієнта до сторони центру обробки даних Dedicated Instance. Більш конкретні маршрути не будуть прийняті на стороні виділеного екземпляра. Переконайтеся, що маршрут 0.0.0.0/0 рекламується як з тунелю A Центру обробки даних виділеного екземпляра, так і з тунелю B Центру обробки даних виділеного екземпляра.
Конфігурація MTU
На стороні виділеного екземпляра увімкнено дві функції для динамічного налаштування MTU для великих розмірів пакетів. Тунель GRE додає більше заголовків до IP-пакетів, що проходять через сеанс VPN. Тунель IPsec додає додаткові заголовки поверх заголовків GRE, що ще більше зменшить найбільший MTU, дозволений над тунелем.
Тунель GRE налаштовує функцію MSS, а шлях тунелю GRE у функції виявлення MTU ввімкнено на стороні виділеного екземпляра. Налаштуйте "ip tcp adjust-mss 1350" або еквівалентну команду, а також "шлях тунелю\ u0002mtu-discovery" або еквівалентну команду на стороні клієнта, щоб допомогти з динамічним налаштуванням MTU трафіку через тунель VPN.
