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

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

Малюнок 1 показує приклад моделі розгортання Virtual Connect для опції 2-концентратора на стороні клієнта.

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

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

Очікується, що партнери будуть тісно співпрацювати з Клієнтами, забезпечуючи вибір найбільш оптимального шляху для регіону обслуговування «Virtual Connect».

Малюнок 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 мережа рекламується 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 не відбувається. Спочатку видайте команду «показати крипто 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 до сусіда виділеного екземпляра.

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

  Ping не може бути IP-адресою тунельного переходу до IP-адреси тунельного переходу. Вона повинна бути IP-адресою тунелю до IP-адреси тунелю.

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

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

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

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

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

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

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

• Переконайтеся, що параметри Perfect Forward Secrecy збігаються з параметрами виділеного екземпляра.

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

• Переконайтеся, що IPsec налаштовано в режимі тунелю.

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

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

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

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

• Збереження даних не ввімкнено на інтерфейсі тунелю на боці CPE

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

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

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

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

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

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

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

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

На додаток до трафіку пінгів, запис повинен також показувати живі пакети GRE навіть під час бездіяльності трафіку. Нарешті, якщо налаштовано 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.