Virtual Connect використовує дворівневу архітектуру головного пристрою, де площини маршрутизації та управління GRE забезпечуються одним пристроєм, а площина управління IPSec - іншим.

Після завершення підключення до Virtual Connect буде створено два тунелі GRE через IPSec між корпоративною мережею Клієнта та центрами обробки даних Cisco Dedicated Instance. По одному до кожного резервного центру даних у відповідному регіоні. Додаткові елементи мережі, необхідні для пірингу, обмінюються Партнером або Клієнтом з Cisco через форму активації Control Hub Virtual Connect.

На рисунку нижче показано приклад моделі розгортання віртуального підключення для варіанта з 2 концентраторами на стороні клієнта.

Virtual Connect - VPN - це дизайн концентратора, де сайти концентратора клієнта підключаються до DC1 і DC2 центрів обробки даних Dedicated Instance у певному регіоні.

Для кращого резервування рекомендується два вузли, але також підтримується модель розгортання One Hub з двома тунелями.

Очікується, що партнери тісно співпрацюватимуть із Клієнтами, забезпечуючи вибір найоптимальнішого шляху для регіону обслуговування 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 мережа рекламується Cisco CPE через відповідні тунелі VPN з точкою до точки (перехідний зв 'язок)

  • CPE повинен бути налаштований з відповідними сусідами eBGP. Якщо використовується один CPE, будуть використовуватися два сусіди eBGP, один з яких вказує на кожен віддалений тунель. Якщо використовується два CPE, то кожен CPE матиме одного сусіда eBGP, що понізує до єдиного віддаленого тунелю для CPE.

  • Сторона Cisco кожного тунелю GRE (IP інтерфейсу тунелю) налаштована як сусід BGP на CPE

  • CPE зобов 'язаний рекламувати маршрут за замовчуванням по кожному з тунелів

  • CPE відповідає за перерозподіл, за необхідності, вивчених маршрутів в межах мережі підприємства Cutomer.

• За умови невідмовності зв 'язку, один CPE буде мати два активних/активних тунелі. Для двох вузлів CPE кожен CPE матиме один активний тунель, і обидва вузли CPE повинні бути активними та передавати трафік. За сценарієм невідмовності, трафік повинен розділятися на два тунелі, що йдуть до правильних /25 пунктів призначення, якщо один з тунелів рухається вниз, решта тунелів може нести трафік для обох. За такого сценарію відмови, коли мережа/25 вимкнена, тоді мережа/24 використовується як резервний маршрут. Cisco надсилатиме трафік клієнтів через свою внутрішню глобальну мережу до DC, який втратив зв 'язок.

Узгодження тунелю 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 (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (або еквівалентна команда)

    Список доступу має бути спеціально для протоколу "GRE", а протокол "IP" не працюватиме.

Якщо повідомлення журналу не відображають жодної активності узгодження для фази IKEv2, можливо, знадобиться захоплення пакетів.

Після правильного налаштування наступне запускає тунель IPsec та першу фазу узгодження IKEv2:

• Підтримка активності GRE від інтерфейсу тунелю GRE на стороні CPE до інтерфейсу тунелю GRE на стороні виділеного екземпляра.

• TCP-сеанс BGP-сусіда від BGP-сусіда на стороні CPE до BGP-сусіда на стороні виділеного екземпляра.

• Виконайте команду ping з IP-адреси тунелю на стороні CPE до IP-адреси тунелю на стороні виділеного екземпляра.

  Ping не може бути IP-адресою тунельного транспорту до IP-адреси тунельного транспорту, це має бути IP-адреса тунелю до IP-адреси тунелю.

Якщо для трафіку IKEv2 потрібне трасування пакетів, встановіть фільтр для UDP та порт 500 (коли посередині кінцевих точок IPsec немає пристрою NAT) або порт 4500 (коли посередині кінцевих точок IPsec вставлено пристрій NAT).

Перевірте, чи пакети IKEv2 UDP з портом 500 або 4500 надсилаються та отримуються на IP-адресу DI IPsec та з неї.

Перш ніж виправляти несправності другої фази IPsec, переконайтеся, що перша фаза IPsec (тобто зв'язок безпеки IKEv2) активна. Виконайте команду "show crypto ikev2 sa" або еквівалентну, щоб перевірити сеанс IKEv2. У виводі перевірте, чи сеанс IKEv2 працює більше кількох секунд і чи не переривається він. Час безперебійної роботи сеансу відображається у виводі як «Активний час» сеансу або еквівалент.

Після того, як сеанс IKEv2 буде підтверджено як активний, перевірте сеанс IPsec. Як і у випадку з сеансом IKEv2, виконайте команду "show crypto ipsec sa" або еквівалентну команду для перевірки сеансу IPsec. Як сеанс IKEv2, так і сеанс IPsec мають бути активними, перш ніж буде встановлено тунель GRE. Якщо сеанс IPsec не відображається як активний, перевірте журнали IPsec на наявність повідомлень про помилки або помилок узгодження.

Деякі з найпоширеніших проблем, які можуть виникнути під час переговорів IPsec:

Налаштування на стороні CPE не відповідають налаштуванням на стороні виділеного екземпляра, перевірте налаштування ще раз:

• Перевірте, чи параметри шифрування та автентифікації відповідають налаштуванням на стороні виділеного екземпляра.

• Перевірте налаштування Perfect Forward Secrecy та чи відповідають вони налаштуванням на стороні виділеного екземпляра.

• Перевірте налаштування терміну служби.

• Перевірте, чи IPsec налаштовано в тунельному режимі.

• Перевірте IPsec-адреси джерела та призначення.

Коли сеанси IPsec та IKEv2 підтверджено як активні, пакети підтримки активності тунелю GRE можуть передаватися між кінцевими точками виділеного екземпляра та тунелю CPE. Якщо інтерфейс тунелю не відображає статус, деякі поширені проблеми:

• Транспортний VRF інтерфейсу тунелю не збігається з VRF інтерфейсу зворотного зв'язку (якщо на інтерфейсі тунелю використовується конфігурація VRF).

  Якщо конфігурація VRF не використовується на тунельному інтерфейсі, цю перевірку можна проігнорувати.

• Функції keepalive не ввімкнено на тунельному інтерфейсі на стороні CPE.

  Якщо на обладнанні CPE не підтримуються keepalive, то Cisco необхідно повідомити, щоб keepalive за замовчуванням на стороні виділеного екземпляра також було вимкнено.

  Якщо підтримуються keepalive, перевірте, чи keepalive увімкнено.

• Маска або IP-адреса тунельного інтерфейсу неправильна та не відповідає очікуваним значенням виділеного екземпляра.

• Транспортна адреса тунелю джерела або призначення неправильна та не відповідає очікуваним значенням виділеного екземпляра.

• Брандмауер блокує надсилання GRE-пакетів у тунель IPsec або отримання з тунелю IPsec (тунель GRE транспортується через тунель IPsec).

Тест ping має перевірити, чи працює локальний тунельний інтерфейс, а також чи є підключення до віддаленого тунельного інтерфейсу належним. Виконайте перевірку ping з IP-адреси тунелю (не транспортної IP-адреси) до IP-адреси віддаленого тунелю.

Перевірка ping призводить до створення GRE-пакета, який генерується з IP-адреси транспортного тунелю джерела до IP-адреси транспортного тунелю призначення, тоді як корисним навантаженням GRE-пакета (внутрішня IP-адреса) буде IP-адреса тунелю джерела та призначення.

Якщо тест ping не пройшов успішно, а попередні пункти перевірено, може знадобитися захоплення пакета, щоб переконатися, що результатом запиту icmp ping є GRE-пакет, який потім інкапсулюється в IPsec-пакет і надсилається з IPsec-адреси джерела на IPsec-адресу призначення. Лічильники на інтерфейсі тунелю GRE та лічильники сеансів IPsec також можуть допомогти показати, чи збільшується кількість пакетів надсилання та отримання.

Окрім трафіку ping, захоплення також має показувати GRE-пакети keepalive навіть під час простою трафіку. Зрештою, якщо BGP налаштовано, пакети BGP keepalive також слід надсилати як GRE-пакети, інкапсульовані в IPSEC-пакети, через VPN.

На стороні виділеного екземпляра ввімкнено дві функції для динамічного налаштування MTU для великих розмірів пакетів. Тунель GRE додає більше заголовків до IP-пакетів, що проходять через сеанс VPN. Тунель IPsec додає додаткові заголовки поверх заголовків GRE, що ще більше зменшить найбільший MTU, дозволений у тунелі.

Тунель GRE налаштовує функцію MSS, а шлях тунелю GRE у функції виявлення MTU увімкнено на стороні виділеного екземпляра. Налаштуйте команду "ip tcp adjust-mss 1350" або еквівалентну, а також "tunnel path\u0002mtu-discovery" або еквівалентну команду на стороні клієнта, щоб допомогти з динамічним налаштуванням MTU трафіку через VPN-тунель.