- Головна
- /
- Стаття
Дякуємо за відгук.
Виділений екземпляр - віртуальне підключення
У цій статті
Надіслати відгук?Віртуальне підключення — це додаткова опція для хмарного підключення до виділеного екземпляра Webex Calling. Virtual Connect дозволяє клієнтам безпечно розширювати свою приватну мережу через Інтернет за допомогою тунелів IP VPN від точки до точки. Тут ми обговорюємо замовлення, активацію та налаштування для Virtual Connect.
Вступ
Virtual Connect - це додаткова опція для підключення до хмари до виділеного екземпляра для Webex Calling (виділеного екземпляра). Virtual Connect дозволяє клієнтам безпечно розширювати свою приватну мережу через Інтернет за допомогою тунелів IP VPN від точки до точки. Ця опція підключення забезпечує швидке встановлення підключення до приватної мережі за допомогою існуючого обладнання для клієнтів (CPE) та підключення до Інтернету.
Cisco розміщує, керує та забезпечує надлишкові тунелі IP VPN та необхідний доступ до Інтернету в регіоні (регіонах) центру обробки даних Cisco, де потрібна послуга. Аналогічно, Адміністратор несе відповідальність за відповідні CPE та Інтернет-послуги, які необхідні для встановлення Virtual Connect.
Кожне замовлення віртуального підключення в певному регіоні виділеного екземпляра включатиме два загальних тунелі інкапсуляції маршрутизації (GRE), захищені шифруванням IPsec (GRE через IPsec), по одному до кожного центру обробки даних Cisco у вибраному регіоні.
Virtual Connect має обмеження пропускної здатності 250 Мбіт/с на тунель і рекомендується для невеликих розгортань. Оскільки використовуються два VPN-тунелі «точка-точка», весь трафік у хмару повинен проходити через головну адресу клієнта CPE, і тому він може не підійти там, де багато віддалених сайтів. Інші альтернативні варіанти пірінгу див. у розділі «Х марне підключення».
Перш ніж надсилати запит на пірінг для віртуального підключення, переконайтеся, що служба виділеного екземпляра активована у відповідному регіоні.
передумови
Передумови для встановлення Virtual Connect включають:
-
Клієнт надає
-
Підключення до Інтернету з достатньою доступною пропускною здатністю для підтримки розгортання
-
Загальнодоступна IP-адреса (и) для двох тунелів IPsec
-
На стороні клієнта GRE транспортують IP-адреси для двох тунелів GRE
-
-
Партнер і Клієнт
-
Працюйте разом, щоб оцінити вимоги до пропускної здатності
-
Переконайтеся, що мережеві пристрої підтримують маршрутизацію протоколу прикордонного шлюзу (BGP) та проектування тунелю GRE через IPsec
-
-
Партнер або Клієнт надає
-
Мережева команда з знаннями технології тунельних VPN від сайту до сайту
-
Мережева команда зі знаннями BGP, EBGP та загальних принципів маршрутизації
-
-
Cisco
-
Cisco призначила приватні автономні системні номери (ASN) та перехідну IP-адресацію для інтерфейсів тунелю GRE
-
Cisco призначила загальнодоступну, але не маршрутизовану мережу класу C (/24) для адресації виділених екземплярів у хмарі
-
Якщо клієнт має лише один пристрій CPE, то 2 тунелі до центрів обробки даних Cisco (DC1 та DC2) у кожному регіоні будуть з цього пристрою CPE. Клієнт також має можливість для двох пристроїв CPE, тоді кожен пристрій CPE повинен підключатися до 1 тунелю лише до центрів обробки даних Cisco (DC1 та DC2) у кожному регіоні. Додаткове резервування може бути досягнуто шляхом завершення кожного тунелю в окремому фізичному майданчику/місці в межах інфраструктури Замовника.
Технічні деталі
Модель розгортання
Virtual Connect використовує дворівневу архітектуру головного пристрою, де маршрутизація та площини управління GRE забезпечуються одним пристроєм, а площина управління IPsec забезпечу ється іншим.
Після завершення підключення Virtual Connect між корпоративною мережею Замовника та цен трами обробки даних Cisco з виді леними екземплярами будуть створені два тунелі GRE через IPsec. Один до кожного резервного центру обробки даних у відповідному регіоні. Додаткові мережеві елементи, необхідні для пірінгу, обмінюються Пар тнером або Клієнтом на Cisco через форму активації Control Hub Virtual Connect.
На малюнку нижче показано приклад моделі розгортання віртуального підключення для опції 2-концентратора на стороні клієнта.
Virtual Connect - це дизайн хаба, де сайти хаба клієнта підключаються до DC1 та DC2 центрів обробки даних виділених екземплярів у певному регіоні.
Рекомендуються два сайти хаба для кращого резервування, але один сайт хаба з двома тунелями також є підтримуваною моделлю розгортання.
Пропускна здатність на тунель обмежена 250 Мбіт/с. Для забезпечення ефективного відмови об'ємний трафі к через обидва тунелі не повинен перевищувати 250 Мбіт/с, оскільки весь трафі к буде спрямовуватися через один тунель у разі несправності.
Віддаленим сайтам Клієнта в тому ж регіоні потрібно буде знову підключитися до сайтів Х аба через WAN Клієнта, і компанія Cisco не несе відповідальності за таке підключення.
Очікується, що партнери будуть тісно співпрацювати з Клієнтами, забезпечуючи вибір найбільш оптимального шляху для регіону обслуговування Virtual Connect.
На малюнку нижче показані регіони пірінгу для хмарного підключення виділених екземплярів.
Маршрутизація
Маршрутизація для доповнення 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 до постійного струму, який втратив зв'язок.
Віртуальний зв'язок потоку трафіку
Транспортний потік, коли обидва тунелі підняті
Це зображення ілюструє архітектуру мережі Virtual Connect, деталізуючи по тік трафіку, коли працюють як первинний, так і вторинний тунелі.
Він являє собою модель активного підключення для клієнта для доступу до додатків UC, розміщених у центрах обробки даних Cisco, використовуючи подвійні тунелі GRE/IPSEC через Інтернет з BGP для обміну маршрутами.
Визначення:
- Приміщення замов ника:
- Це являє собою локальну мережу клієнта, де знаходяться користувачі та їхні пристрої (наприклад, IP-телефони, комп'ютери з клієнтами UC).
- Трафік, що по ходить звідси, повинен надходити до програм UC, розміщених у центрах обробки даних Cisco.
- Cisco Webex CallingВиділені екземпляри (виділені екземпляри) центри обробки даних (WXC-Di DC-
A та WXC-Di DC-B):
- Це центри обробки даних Cisco, на яких розміщуються додатки UC.
- DC-A і DC-B географічно відрізняються, забезпечуючи резервування.
- Кожен центр обробки даних має свою підмережу для додатків UC:
- Підмережа DC-A: X.X.X.0/25
- Підмережа DC-B: X.X.X.128/25
- Тунелі GRE/IPsec (тунель 1 та тунель 2):
- Це безпечні, зашифровані зв'язки між приміщен ням клієнта та центром обробки даних Cisco через загальнодоступний Інтернет.
- GRE (Generic Routing Encapsulation): Цей протокол використовується для інкапсуляції різних протоколів мережевого рівня всередині віртуальних посилань «точка-точка». Це дозволяє протоколам маршрутизації, таким як BGP, працювати над тунелем.
- IPsec (Internet Protocol Security): Цей набір протоколів забезпечує послуги криптографічної безпеки (аутентифікація, цілісність, конфіденційність) для IP- комунікацій. Він шифрує GRE-інкапсульований трафік, забезпечуючи безпечну передачу даних через Інтернет.
- Прото@@ кол прикордонного шлюзу (BGP):
- BGP - це протокол маршрутизації, який використовується для обміну інформацією про маршрутизацію між приміщенням клієнта та цен трами обробки даних Cisco.
Як показано на наведеній вище схемі, пристрої, розгорнуті в приміщеннях замовника, повинні встановити два тунелі GRE/IPSEC.
Конвенції іменування, використані нижче для XX/YY, DC-A DC-B, є загальними для всіх регіонів, де пропонується виділений екземпляр. Ці значення будуть унікальними для кожного регіону та фактичними значеннями для кожного регіону. Конкретні значення надаються під час активації віртуального з'єднання.
На стороні Cisco тунелі IPsec та GRE будуть припинені на різних пристроях. Таким чином, клієнт повинен переконатися, що налаштував IP-адреси призначення IPsec та GRE призначення на пристроях відповідно. Клієнти можуть використовувати один і той же IP для GRE та IPSEC, якщо він підтримується на їхніх пристроях. Зверніться до схеми вище. Значення, пов'язані з IP, надаються під час активації віртуального з'єднання на порталі.
- Тунель 1: Підключає приміщення клієнта до «Виділеного екземпляра DC-A» (Центр обробки даних A) через Інтернет. Цей тунель використовує BGP AS: 64XX1 на стороні клієнта та BGP AS: 64XX2 на стороні виділеного екземпляра DC-A. Конфігурації джерела тунелю IPSEC та GRE розділені між деталями, наданими клієнтом, та наданими Cisco.
- Тунель 2: Підключає приміщення клієнта до «Виділеного екземпляра DC-B» (Центр обробки даних B) через Інтернет. Цей тунель використовує BGP AS: 64YY1 на стороні клієнта та BGP AS: 64YY2 на стороні виділеного екземпляра DC-B. Як і тунель 1, конфігурації джерела тунелю IPSEC та GRE спільні між замовником та Cisco.
У BGP AS: 64XX та BGP AS: 64YY, XX та YY є специфічними для певного регіону.
Після встановлення тунелів GRE/IPSEC до центрів обробки даних Webex Calling виділених екземплярів (A та B) клієнт повинен отримати наступні маршрути, рекламовані від Cisco протягом відповідних сеансів BGP.
- Для DC-A: Маршрути, рекламовані від Cisco, будуть X.X.0/25 та X.X.0/24. За бажанням, якщо IaaS запитується та налаштовується для маршрутів клієнтів, Y.Y.0/25 та Y.Y.0/24 буде рекламуватися від Cisco.
- Для DC-B: Маршрути, рекламовані від Cisco, будуть X.X.128/25 та X.X.0/24. За бажанням, якщо IaaS запитується та налаштовується для маршрутів клієнтів, Y.Y.128/25 та Y.Y.0/24 буде рекламуватися від Cisco.
- Клієнт повинен рекламувати маршрут 0.0.0./0 до Cisco через обидва з'єднання (тунелі)
- Клієнт повинен дотримуватися найдовших маршрутів префікса (/25), щоб надсилати трафік до Cisco через відповідні тунелі, коли обидва тунелі працюють.
- Cisco поверне трафік через ті ж тунелі, щоб зберегти симетричний трафік.
Потік трафіку:
- Трафік, призначений для «DC-A UC Apps» (X.X.0/25) з приміщення клієнта, протікає через тунель 1.
- Трафік, призначений для «DC-B UC Apps» (X.X.128/25) з приміщення клієнта, протікає через тунель 2.
Сценарій невдачі: транспортний потік, коли один з тунелів не працює
Як показано на наведеній вище схемі, коли тунель до DC-A йде вниз, bgp, встановлений через тунель до DC-A, спуститься вниз.
Вплив на BGP: Коли тунель 1 спускається, сеанс BGP через цей тунель також знизиться . Отже, DC-A більше не зможе рекламувати свої маршрути (зокрема X. X.0/25) замовнику через цей шлях. Отже, маршрутизатор клієнта виявить шлях недосяжним.
Тепер, оскільки Тунель 1 не працює, маршрутизатор клієнта в приміщенні клієнта автоматично видаляє маршрути, вивчені через Тунель 1, зі своєї таблиці маршрутизації або позначатиме їх як недосяжні.
- Трафік, призначений для мережі додатків UC (X.X.0/24) або підмережі DC-A (X.X.0/25), потім буде перенаправлений через робочий тунель до DC-B, який продовжує рекламувати X.X.0/24, що включає мережу X.X.0/25.
- Подібна поведінка буде спостерігатися, якщо тунель до DC-B не працює, а тунель до DC-A все ще вгору.
Процес підключення
| 1 | |
| 2 | |
| 3 | |
| 4 |
Крок 1: Замовлення CCW
Virtual Connect - це доповнення для виділеного екземпляра в CCW.
| 1 |
Перейдіть на сайт замовлення CCW, а потім натисніть Увійти, щоб увійти на сайт: |
| 2 |
Створити оцінку. |
| 3 |
Додати артикул «A-FLEX-3". |
| 4 |
Виберіть Параметри редагування. |
| 5 |
На вкладці підписки виберіть Параметри та доповнення. |
| 6 |
У розділі Додаткові доповнення встановіть прапорець біля пункту «Віртуальне підключення для виділеного екземпляра». Назва артикулу - «A-FLEX-DI-VC». |
| 7 |
Введіть кількість і кількість регіонів, в яких потрібно Virtual Connect. Кількість віртуального підключення не повинна перевищувати загальну кількість регіонів, придбаних для виділеного екземпляра. Крім того, для кожного регіону дозволено лише одне замовлення Virtual Connect. |
| 8 |
Коли ви задоволені вибором, натисніть Перевірити та зберегти у верхній правій частині сторінки. |
| 9 |
Натисніть Зберегти та продовжити, щоб завершити замовлення. Ваше остаточне замовлення тепер відображається в сітці замовлень. |
Крок 2: Активація віртуального підключення в Контрольному центрі
| 1 |
Увійдіть у Контрольний центр https://admin.webex.com/login. |
| 2 |
У розділі Служби перей діть до Дзвінки > Ви ділені інсталяції > Підключення до хмари. |
| 3 |
У картці Virtual Connect вказано кількість придбаного Virtual Connect. Адміністратор тепер може натиснути на Активувати, щоб ініціювати активацію Virtual Connect. 
Процес активації може бути запущений тільки Адміністраторами з роллю «Повний адміністратор клієнта». Тоді як адміністратор з роллю «Адміністратор клієнта лише для читання» може переглядати лише статус. |
| 4 |
Після натискання кнопки Ак тивувати відображається форма Активувати вірту альне підключення, щоб адміністратор надав технічні деталі Virtual Connect, необхідні для конфігурацій піering на стороні Cisco. Форма також надає статичну інформацію на стороні Cisco на основі вибраного регіону. Ця інформація буде корисною для адміністраторів клієнтів, щоб налаштувати CPE на своєму боці для встановлення підключення. |
| 5 |
Натисніть кнопку Активувати після заповнення всіх обов'язкових полів. |
| 6 |
Після заповнення форми активації віртуального підключення для певного регіону, клієнт може експортувати форму активації з Control Hub, Виклик > Виділений екземпляр > вкладка Хмарне підключення та натиснути на Експорт налаштувань. 
З міркувань безпеки аутентифікація та пароль BGP не будуть доступні в експортованому документі, але адміністратор може переглянути їх у Контрольному центрі, натиснувши Пара метри перегляду в Контрольному центрі, Виклик > Виділений екземпляр > вкладка Підключення до хмари. |
Крок 3: Cisco виконує конфігурацію мережі
| 1 |
Після заповнення форми активації віртуального підключення статус буде оновлено до пункту Активація триває у розділі Ви клики > Ви ділений екземпляр > Картка віртуального підключення до хмари. |
| 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-адресою кінцевої точки тунелю IPsec виділеного екземпляра.
-
Параметри сеансу IKEv2 не збігаються між стороною виділеного екземпляра та стороною клієнта.
-
Брандмауер блокує пакети UDP IKEv2.
Спочатку перевірте журнали IPsec на наявність будь-яких повідомлень, які показують хід узгодження тунелю IKEv2. Журнали можуть вказувати, де є проблема з переговорами IKEv2. Відсутність журнальних повідомлень також може свідчити про те, що сеанс IKEv2 не активується.
Деякі поширені помилки під час переговорів IKEv2:
-
Налаштування IKEv2 на стороні CPE не збігаються зі стороною Cisco, перевірте згадані налаштування:
-
Перевірте, чи версія IKE є версією 2.
-
Переконайтеся, що параметри шифрування та автентифікації відповідають очікуваному шифруванню на стороні виділеного екземпляра.
Коли використовується шифр «GCM», протокол GCM обробляє аутентифікацію та встановлює параметр аутентифікації на NULL.
-
Перевірте налаштування терміну служби.
-
Перевірте групу модулів Діффі Хеллмана.
-
Перевірте налаштування псевдовипадкової функції.
-
-
Список доступу для криптокарти не встановлено на:
-
Дозвіл GRE (локальний_тунель_транспорт_ip) 255.255.255.255 (віддалений_тунель_транспорт_ip) 255.255.255.255" (або еквівалентна команда)
Список доступу повинен бути спеціально для протоколу «GRE» і протокол «IP» працювати не буде.
-
Якщо повідомлення журналу не показують жодної активності переговорів для фази IKEv2, то може знадобитися захоплення пакетів.
Сторона виділеного екземпляра не завжди може розпочати обмін IKEv2 і іноді може очікувати, що сторона CPE клієнта буде ініціатором.
Перевірте конфігурацію на стороні CPE на наявність наступних передумов для ініціації сеансу IKEv2:
-
Перевірте наявність списку криптодоступу IPsec для трафіку GRE (протокол 50) від IP-адреси транспорту тунелю CPE до IP-адреси транспортування тунелю виділеного екземпляра.
-
Переконайтеся, що інтерфейс тунелю GRE увімкнено для збереження GRE, якщо обладнання не підтримує GRE keepalives, Cisco отримує сповіщення, оскільки GRE keepalives буде ввімкнено на стороні виділеного екземпляра за замовчуванням.
-
Переконайтеся, що BGP увімкнено та налаштовано з сусідньою адресою IP-адреси тунелю виділеного екземпляра.
При правильному налаштуванні починається тунель IPsec і переговори IKEv2 першої фази:
-
GRE зберігається від інтерфейсу тунелю GRE на стороні CPE до інтерфейсу тунелю GRE на стороні виділеного екземпляра.
-
Сеанс TCP сусіда BGP від сусіда BGP на стороні CPE до сусіда BGP на стороні виділеного екземпляра.
-
Пінг від IP-адреси тунелю бічного CPE до IP-адреси тунелю на стороні виділеного екземпляра.
Ping не може бути тунельним транспортним IP до IP тунельного транспорту, це повинен бути тунельний IP до тунельного IP.
Якщо трасування пакетів потрібне для трафіку IKEv2, встановіть фільтр для UDP і порту 500 (якщо в середині кінцевих точок IPsec немає пристрою NAT) або порт 4500 (коли пристрій NAT вставлено посередині кінцевих точок IPsec).
Переконайтеся, що пакети UDP IKEv2 з портом 500 або 4500 надсилаються та приймаються на IP-адресу DI IPsec та з неї.
Центр обробки даних виділеного екземпляра не завжди може запускати перший пакет IKEv2. Вимога полягає в тому, щоб пристрій CPE міг ініціювати перший пакет IKEv2 на стороні виділеного екземпляра.
Якщо локальний брандмауер дозволяє це, то також спробуйте зробити пінг на віддалену адресу IPsec. Якщо пінг не пройшов успішно з локальної адреси на віддалену адресу IPsec, виконайте маршрут трасування, щоб допомогти, і визначте, куди скинуто пакет.
Деякі брандмауери та інтернет-обладнання можуть не дозволяти відстежувати маршрут.
Виправлення неполадок та перевірка другої фази IPsec (узгодження IPsec)
Переконайтеся, що перша фаза IPsec (тобто асоціація безпеки IKEv2) активна, перш ніж усунути несправності другої фази IPsec. Виконайте команду «показати криптовалюту ikev2 sa» або еквівалентну команду, щоб перевірити сеанс IKEv2. У виході переконайтеся, що сеанс IKEv2 працював більше декількох секунд і що він не відскакує. Час безперебійної роботи сеансу відображається як «Активний час» сеансу або еквівалент у виході.
Після того, як сеанс IKEv2 підтвердиться як активний, перевірте сеанс IPsec. Як і в сеансі IKEv2, виконайте команду «показати криптовалюту ipsec sa» або еквівалентну команду для перевірки сеансу IPsec. І сеанс IKEv2, і сеанс IPsec повинні бути активними, перш ніж буде встановлено тунель GRE. Якщо сеанс IPsec не відображається як активний, перевірте журнали IPsec на наявність повідомлень про помилки або помилки узгодження.
Деякі з найбільш поширених проблем, з якими можна зіткнутися під час переговорів щодо IPsec, є:
Налаштування на стороні CPE не збігаються зі стороною Виділеного екземпляра, перевірте параметри знову:
-
Переконайтеся, що параметри шифрування та автентифікації відповідають параметрам на стороні Виділеного екземпляра.
-
Перевірте налаштування Perfect Forward Secrets та відповідність налаштувань на стороні виділеного екземпляра.
-
Перевірте налаштування терміну служби.
-
Переконайтеся, що IPsec налаштовано в тунельному режимі.
-
Перевірте вихідні та цільові адреси IPsec.
Пошук та перевірка інтерфейсу тунелю
Коли сеанси IPsec і IKEv2 перевіряються як активні, пакети в тунелі GRE Keepalive здатні протікати між кінцевими точками виділеного екземпляра та тунелю CPE. Якщо інтерфейс тунелю не відображає статус, деякі поширені проблеми:
-
VRF транспортного інтерфейсу тунелю не відповідає VRF інтерфейсу зворотного циклу (якщо на інтерфейсі тунелю використовується конфігурація VRF).
Якщо конфігурація VRF не використовується в інтерфейсі тунелю, цю перевірку можна ігнорувати.
-
Keepalives не ввімкнено на інтерфейсі бічного тунелю CPE
Якщо Keepalives не підтримуються на обладнанні CPE, Cisco має бути повідомлено, щоб також вимкнено типові Keepalives на стороні виділеного екземпляра.
Якщо підтримуються keepalives, перевірте, чи увімкнено keepalives.
-
Маска або IP-адреса інтерфейсу тунелю неправильна і не відповідає очікуваним значенням виділеного екземпляра.
-
Адреса транспортування тунелю джерела або призначення невірна і не відповідає очікуваним значенням виділеного екземпляра.
-
Брандмауер блокує пакети GRE, надіслані в тунель IPsec або отримані з тунелю IPsec (тунель GRE транспортується через тунель IPsec)
Пінг-тест повинен перевірити, чи інтерфейс локального тунелю працює, а зв'язок хороший до інтерфейсу віддаленого тунелю. Виконайте перевірку пінгу від IP тунелю (а не транспортного IP) до віддаленого тунельного IP.
Список криптодоступу для тунелю IPsec, який несе трафік тунелю GRE, дозволяє перетинати лише пакети GRE. В результаті пінги не працюватимуть від IP тунельного транспорту до IP віддаленого тунельного транспорту.
Перевірка ping призводить до пакету GRE, який генерується з вихідного тунельного транспортного IP до IP транспорту тунелю призначення, тоді як корисне навантаження пакета GRE (внутрішня IP) буде вихідним та цільовим IP тунелю.
Якщо тестування ping не пройшло успішно, а попередні елементи перевірені, то може знадобитися захоплення пакетів, щоб переконатися, що ping icmp призводить до пакету GRE, який потім інкапсулюється в пакет IPsec, а потім надсилається з вихідної адреси IPsec на адресу IPsec призначення. Лічильники на інтерфейсі тунелю GRE та лічильники сеансів IPsec також можуть допомогти показати. якщо пакети надсилання та прийому збільшуються.
Окрім пінг-трафіку, захоплення також повинно показувати пакети keepalive GRE навіть під час простою трафіку. Нарешті, якщо BGP налаштовано, пакети BGP keepalive також повинні надсилатися як пакети GRE, інкапсульовані в пакети IPSEC, а також через VPN.
Виправлення неполадок та перевірка BGP
Сеанси BGP
BGP необхідний як протокол маршрутизації через тунель VPN IPsec. Місцевий сусід BGP повинен встановити сеанс EBGP з сусідом BGP виділеного екземпляра. IP-адреси сусідів EBGP такі ж, як і локальні та віддалені тунельні IP-адреси. Спочатку переконайтеся, що сеанс BGP завершено, а потім переконайтеся, що правильні маршрути надходять від виділеного екземпляра, а правильний маршрут за замовчуванням надіслано до виділеного екземпляра.
Якщо тунель GRE працює, переконайтеся, що пінг успішний між локальним та віддаленим IP-адресою тунелю GRE. Якщо пінг пройшов успішно, але сеанс BGP не наближається, перевірте журнал BGP на наявність помилок встановлення BGP.
Деякі з найбільш поширених питань переговорів BGP:
-
Номер віддаленого АС не відповідає номеру AS, налаштованому на стороні виділеного екземпляра, повторно перевірте конфігурацію сусіднього AS.
-
Локальний номер AS не відповідає тому, що очікує сторона виділеного екземпляра. Переконайтеся, що локальний номер AS відповідає очікуваним параметрам виділеного екземпляра.
-
Брандмауер блокує пакети 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.
Важливо, що, коли обидва тунелі активні, цей тунель центру обробки даних А не використовується для передачі трафіку в центр обробки даних 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 just-mss 1350" або еквівалентну команду, а також «tunnel path\ u0002mtu-discovery» або еквівалентну команду на стороні клієнта, щоб допомогти з динамічним налаштуванням MTU трафіку через тунель VPN.
