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

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

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

Віртуальне підключення – VPN — це конструкція концентратора, у якій вебсайти концентратора клієнта підключені до DC1 і DC2 центрів обробки даних виділеного екземпляра в межах певного регіону.

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

Пропускна здатність на тунель обмежена 250 Мбіт/с.

Віддалені сайти Клієнта в межах одного регіону повинні будуть підключатися назад до вебсайтів-концентраторів через WAN Клієнта, і Cisco не несе відповідальності за таке підключення.

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

На рисунку 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, який втратив підключення.

Узгодження тунелю 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, може знадобитися захоплення пакетів.

Сторона виділеного екземпляра не завжди може розпочинати обмін IKEv2, і іноді може очікувати, що ініціатором буде сторона CPE клієнта. Перевірте конфігурацію CPE на наявність таких обов’язкових умов для ініціювання сеансу IKEv2: Перевірте список криптодоступу IPsec для трафіку GRE (протокол 50) від транспортної IP-адреси тунелю CPE до транспортної IP-адреси тунелю виділеного екземпляра. Переконайтеся, що інтерфейс тунелю GRE ввімкнено для підтримки активності GRE. Якщо обладнання не підтримує підтримку GRE, тоді Cisco буде сповіщено, оскільки підтримку підтримки GRE буде ввімкнено на стороні виділеного екземпляра за замовчуванням. Переконайтеся, що BGP увімкнено та налаштовано за допомогою адреси сусіда IP-адреси тунелю виділеного екземпляра.

За належного налаштування тунель IPsec і узгодження IKEv2 на першому етапі розпочинається далі.

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

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

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

  Ping не може бути транспортною IP-адресою тунелю до тунельної транспортної IP-адреси. Це має бути IP-адреса тунелю для транспортування тунелю.

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

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

Центр обробки даних виділеного екземпляра не завжди може розпочати перший пакет IKEv2. Вимога полягає в тому, щоб пристрій CPE був здатний ініціювати перший пакет IKEv2 на стороні виділеного екземпляра. Якщо локальний брандмауер дозволяє це, спробуйте також виконати ping на віддалену адресу IPsec. Якщо ping не проходить успішно з локальної на віддалену адресу 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 не використовується в тунельному інтерфейсі, цю перевірку можна ігнорувати.

• В інтерфейсі тунелю сторони CPE не ввімкнено функцію підтримки активності

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

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

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

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

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

Список криптодоступу для тунелю IPsec, який передає трафік тунелю GRE, дозволяє перетинати лише пакети GRE. Як наслідок, ping не працюватиме від транспортної 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.

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

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