- Главная
- /
- Статья
Благодарим вас за обратную связь.
Подключение выделенного экземпляра к виртуальному
В этой статье
Отправить обратную связь?Virtual Connect — это дополнительная опция для облачного подключения к выделенному инстансу Webex Calling. Virtual Connect позволяет клиентам безопасно расширять свою частную сеть через Интернет с помощью IP-туннелей типа «точка-точка». Здесь мы расскажем о заказе, активации и настройке Virtual Connect.
Введение
Virtual Connect — это дополнительная опция для облачного подключения к выделенному инстансу Webex Calling (выделенному инстансу). Virtual Connect позволяет клиентам безопасно расширять свою частную сеть через Интернет с помощью IP-туннелей типа «точка-точка». Этот вариант подключения обеспечивает быстрое подключение к частной сети с использованием существующего клиентского оборудования (CPE) и подключения к Интернету.
Cisco размещает, управляет и обеспечивает резервные IP-VPN-туннели и необходимый доступ в Интернет в регионах (регионах) центров обработки данных Cisco с выделенными инстансами, где требуется услуга. Кроме того, администратор отвечает за соответствующие услуги CPE и Интернет, необходимые для создания Virtual Connect.
Каждый заказ Virtual Connect в определенном регионе выделенных инстансов будет включать два универсальных туннеля с инкапсуляцией маршрутизации (GRE), защищенных шифрованием IPsec (GRE over IPsec), по одному в каждый центр обработки данных Cisco в выбранном регионе.
Ограничение пропускной способности Virtual Connect составляет 250 Мбит/с на туннель, поэтому рекомендуется для небольших развертываний. Поскольку используются два VPN-туннеля типа «точка-точка», весь трафик в облако должен проходить через сервер CPE головного компьютера клиента, поэтому оно может оказаться непригодным для использования там, где много удаленных сайтов. Другие альтернативные варианты пиринга см. в разделе Подключение к облаку.
Прежде чем отправлять пиринговый запрос на Virtual Connect, убедитесь, что услуга выделенного инстанса активирована в соответствующем регионе.
Предварительные требования
Необходимые условия для создания Virtual Connect включают:
-
Заказчик предоставляет
-
Подключение к Интернету с достаточной пропускной способностью для поддержки развертывания
-
Публичные IP-адреса для двух туннелей IPsec
-
Транспортные IP-адреса GRE на стороне клиента для двух туннелей GRE
-
-
Партнер и заказчик
-
Совместно оцените требования к полосе пропускания
-
Убедитесь, что сетевые устройства поддерживают маршрутизацию по протоколу пограничного шлюза (BGP) и конструкцию туннеля GRE через IPsec
-
-
Партнер или заказчик предоставляет
-
Сетевая команда, владеющая технологиями VPN-туннелей типа «сеть-сеть»
-
Сетевая команда со знанием BGP, eBGP и общих принципов маршрутизации
-
-
Cisco
-
Cisco назначила номера частных автономных систем (ASN) и временную IP-адресацию для туннельных интерфейсов GRE
-
Cisco присвоила облачной адресации выделенных инстансов общедоступную, но не маршрутизируемую через Интернет сеть класса C (/24)
-
Если у клиента только 1 устройство CPE, то два туннеля, ведущих к центрам обработки данных Cisco (DC1 и DC2) в каждом регионе, будут осуществляться с этого устройства CPE. Заказчик также может выбрать два устройства CPE, тогда каждое устройство CPE должно подключаться только к одному туннелю, ведущему к центрам обработки данных Cisco (DC1 и DC2) в каждом регионе. Дополнительное резервирование можно обеспечить, проложив каждый туннель на отдельном физическом объекте/месте в инфраструктуре Заказчика.
Технические сведения
Модель развертывания
Virtual Connect использует двухуровневую архитектуру головного узла, в которой плоскости маршрутизации и управления GRE предоставляются одним устройством, а плоскость управления IPsec — другим .
По завершении подключения Virtual Connect между корпоративной сетью Заказчика и центрами обработки данных Cisco для выделенных инстансов будут созданы два туннеля GRE over IPsec. По одному на каждый резервный центр обработки данных в соответствующем регионе. Дополнительные сетевые элементы, необходимые для пиринга, передаются партнером или заказчиком Cisco с помощью формы активации Control Hub Virtual Connect.
На рисунке ниже показан пример модели развертывания виртуального соединения для варианта с двумя концентраторами на стороне заказчика.
Virtual Connect — VPN — это конструкция концентратора, в которой узловые сайты клиента подключены к центрам обработки данных выделенных инстансов DC1 и DC2 в определенном регионе.
Для повышения резервирования рекомендуется использовать два узла-концентратора, но также поддерживаемой моделью развертывания является сайт «Один концентратор» с двумя туннелями.
Пропускная способность каждого туннеля ограничена 250 Мбит/с. Для обеспечения эффективного переключения при отказе совокупный трафик в обоих туннелях не должен превышать 250 Мбит/с, поскольку в случае сбоя весь трафик будет перенаправлен через один туннель.
Удаленным узлам Заказчика, расположенным в том же регионе, необходимо будет снова подключиться к узловому узлу (узлам) через локальную сеть Заказчика, и 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 компания Cisco объявляет о возврате каждой сети /25 компании CPE через соответствующие VPN-туннели типа «точка-точка» (переходный канал)
-
CPE необходимо настроить с использованием соответствующих соседей eBGP. При использовании одного CPE будут использоваться два соседа eBGP, по одному из которых указывает на каждый удаленный туннель. При использовании двух CPE у каждого CPE будет один сосед eBGP, указывающий на единственный удаленный туннель для CPE.
-
Сторона Cisco в каждом туннеле GRE (IP-адрес туннельного интерфейса) настроена в качестве соседа BGP на CPE
-
CPE требуется для объявления маршрута по умолчанию по каждому из туннелей
-
CPE отвечает за перераспределение по мере необходимости изученных маршрутов в корпоративной сети клиента.
-
-
В случае отказа канала связи один CPE будет иметь два активных/активных туннеля. Для двух узлов CPE каждый CPE будет иметь один активный туннель, и оба узла CPE должны быть активны и пропускать трафик. В сценарии без сбоев трафик должен быть разделен на два туннеля, идущих в правильные пункты назначения (/25). Если один из туннелей выйдет из строя, трафик по оставшемуся туннелю сможет пройти по обоим туннелям. При таком сценарии сбоя при отключении сети /25 сеть /24 используется в качестве резервного маршрута. Cisco будет направлять трафик клиентов через свою внутреннюю глобальную сеть на постоянный ток, который потерял связь.
Поток трафика виртуальных подключений
Транспортный поток, когда оба туннеля открыты
На этом рисунке показана сетевая архитектура 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.0/25
- Подсеть постоянного тока: 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 и IP-адреса назначения 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.X.0/25 и x.x.x.0/24. Опционально, если IaaS будет запрошен и настроен для клиентов, маршруты YYY.0/25 и YY.0/24 будут объявлены Cisco.
- Для DC-B: от Cisco будут объявлены маршруты X.X.X.128/25 и X.X.X.0/24. Опционально, если IaaS будет запрошен и настроен для клиентов, маршруты YY.Y.128/25 и Y.Y.0/24 будут объявлены Cisco.
- Заказчику необходимо объявить Cisco маршрут 0.0.0./0 через оба соединения (туннели)
- Когда оба туннеля будут запущены, клиент должен использовать маршруты с самым длинным префиксом (/25), чтобы отправить трафик в Cisco через соответствующие туннели.
- Cisco будет возвращать трафик через те же туннели, чтобы трафик оставался симметричным.
Поток трафика:
- Трафик, предназначенный для «приложений DC-A UC» (X.X.X.0/25) из помещения клиента, проходит через туннель 1.
- Трафик, предназначенный для «приложений DC-B UC» (X.X.X.128/25) из клиентской базы, проходит через туннель 2.
Сценарий аварийного переключения: поток трафика при выходе из строя одного из туннелей
Как показано на диаграмме выше, когда туннель, ведущий к DC-A, будет отключен, сеть BGP, проложенная через туннель к DC-A, будет отключена.
Воздействие на BGP: при выходе из строя туннеля 1 сеанс BGP в этом туннеле также прекратится. Следовательно, DC-A больше не сможет рекламировать клиентам свои маршруты (в частности, X.X.X.0/25) по этому пути. Следовательно, маршрутизатор клиента сочтет этот путь недоступным.
Теперь, когда туннель 1 отключен, клиентский маршрутизатор на территории заказчика автоматически удалит маршруты, полученные по туннелю 1, из своей таблицы маршрутизации или пометит их как недоступные.
- Трафик, предназначенный для сети приложений UC (X.X.X.0/24) или подсети DC-A (X.X.X.0/25), затем будет перенаправлен через рабочий туннель в DC-B, который продолжает рекламировать X.X.X.0/24, включая сеть X.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 |
В разделе «Дополнительные дополнения» установите флажок рядом с пунктом «Виртуальное подключение к выделенному инстансу». Название SKU — «A-FLEX-DI-VC». |
| 7 |
Укажите количество и количество регионов, в которых требуется Virtual Connect. Количество виртуальных подключений не должно превышать общее количество регионов, приобретенных для выделенного инстанса. Кроме того, в каждом регионе разрешен только один заказ на Virtual Connect. |
| 8 |
Когда вы будете удовлетворены выбранным выбором, нажмите «Подтвердить» и «Сохранить» в верхней правой части страницы. |
| 9 |
Нажмите «Сохранить» и «Продолжить», чтобы завершить оформление заказа. Ваш окончательный заказ теперь отображается в таблице заказов. |
Шаг 2. Активация виртуального подключения в Control Hub
| 1 |
Войдите в Центр управления https://admin.webex.com/login. |
| 2 |
В разделе «Службы» выберите «Вызовы» > «Выделенный экземпляр» > «Подключение к облаку». |
| 3 |
На карте Virtual Connect указано количество приобретенных устройств Virtual Connect. Теперь администратор может нажать «Активировать», чтобы начать активацию Virtual Connect. 
Процесс активации может быть запущен только администраторами с ролью «Полноправный администратор клиента». В то время как администратор с ролью «Администратор, доступный только для чтения», может просматривать только статус. |
| 4 |
При нажатии кнопки «Активировать виртуальное подключение» отображается форма Activate Virtual Connect, в которой администратор может предоставить технические сведения о Virtual Connect, необходимые для конфигураций пиринга на стороне Cisco. В форме также содержится статическая информация на стороне Cisco в зависимости от выбранного региона. Эта информация будет полезна администраторам клиентов при настройке CPE на своей стороне для установления соединения. |
| 5 |
Нажмите кнопку «Активировать», как только все обязательные поля будут заполнены. |
| 6 |
После заполнения формы активации Virtual Connect для определенного региона клиент может экспортировать форму активации из Control Hub, выбрав > Выделенный экземпляр > вкладку Cloud Connectivity, и нажать «Экспорт настроек». 
По соображениям безопасности аутентификация и пароль BGP не будут доступны в экспортированном документе, но администратор может просмотреть их в Control Hub, нажав «Просмотреть настройки» в разделе Control Hub, выбрав «Выделенный экземпляр» > «Подключение к облаку». |
Шаг 3. Cisco выполняет настройку сети
| 1 |
Как только форма активации Virtual Connect будет заполнена, статус будет обновлен на «Выполняется активация» в разделе «Вызов» > «Выделенный экземпляр» > «Карта виртуального подключения к облаку». |
| 2 |
Cisco выполнит необходимые настройки на стороннем оборудовании Cisco в течение 5 рабочих дней. После успешного завершения статус в Control Hub будет обновлен на «Активировано» для данного региона. |
Шаг 4. Заказчик выполняет настройку сети
|
Состояние меняется на «Активировано», чтобы уведомить администратора заказчика о том, что на основе данных, предоставленных Заказчиком, все настройки Cisco для подключения к IP-VPN завершены. Однако ожидается, что администратор заказчика завершит настройку CPE и протестирует маршруты подключения туннеля Virtual Connect для перевода туннеля Virtual Connect в оперативный режим. В случае возникновения проблем во время настройки или подключения заказчик может обратиться Cisco TAC за помощью. |
устранение неполадок
Устранение неполадок и проверка протокола IPsec на первом этапе (согласование IKEv2)
Согласование туннелей IPsec состоит из двух этапов: фазы IKEv2 и фазы IPsec. Если согласование фазы IKEv2 не будет завершено, вторая фаза IPsec не начнется. Сначала выполните команду «show crypto ikev2 sa» (на оборудовании Cisco) или аналогичную команду на стороннем оборудовании, чтобы проверить, активен ли сеанс IKEv2. Если сеанс IKEv2 неактивен, потенциальные причины могут быть следующими:
-
Интересный трафик не запускает туннель IPsec.
-
Список доступа к туннелям IPsec настроен неправильно.
-
Между клиентом и IP-адресом конечной точки туннеля IPsec выделенного инстанса нет связи.
-
Параметры сеанса IKEv2 не совпадают на стороне выделенного инстанса и на стороне клиента.
-
Брандмауэр блокирует пакеты IKEv2 UDP.
Сначала проверьте журналы IPsec на наличие сообщений, отражающих ход согласования туннеля IKEv2. В журналах может быть указано, где возникла проблема с согласованием IKEv2. Отсутствие сообщений в журнале также может указывать на то, что сеанс IKEv2 не активирован.
Некоторые распространенные ошибки при согласовании IKEv2:
-
Настройки IKEv2 на стороне CPE не совпадают с настройками на стороне Cisco. Перепроверьте указанные настройки:
-
Убедитесь, что версия IKE — версия 2.
-
Убедитесь, что параметры шифрования и аутентификации соответствуют ожидаемому шифрованию на стороне выделенного инстанса.
Когда используется шифр «GCM», протокол GCM обрабатывает аутентификацию и присваивает параметру аутентификации значение NULL.
-
Проверьте настройку срока службы.
-
Проверьте группу модулей Диффи Хеллмана.
-
Проверьте настройки функции Pseudo Random.
-
-
Список доступа к криптокарте не настроен следующим образом:
-
Разрешите GRE (local_tunnel_transport_ip) 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 включён для сообщений Keepalive GRE. Если оборудование не поддерживает кэплайвы GRE, компания Cisco уведомит об этом, поскольку по умолчанию кэплайвы GRE будут включены на стороне выделенного инстанса.
-
Убедитесь, что протокол BGP включен и настроен с использованием соседнего IP-адреса туннеля выделенного инстанса.
При правильной настройке начинается туннель IPsec и первая фаза согласования IKEv2:
-
Протокол GRE передается от туннельного интерфейса GRE на стороне CPE к туннельному интерфейсу GRE на стороне выделенного инстанса.
-
Сеанс TCP соседа BGP от соседа BGP на стороне CPE к соседу BGP на стороне выделенного инстанса.
-
Отправьте запрос с IP-адреса бокового туннеля CPE на IP-адрес туннеля на стороне выделенного инстанса.
Ping не может быть IP-адресом туннельного транспорта для туннельного транспорта, это должен быть IP-адрес туннельного транспорта для туннеля.
Если для трафика IKEv2 требуется трассировка пакетов, задайте фильтр для UDP и порт 500 (когда в середине конечных точек IPsec нет устройства NAT) или порт 4500 (когда устройство NAT вставлено в середину конечных точек IPsec).
Убедитесь, что пакеты IKEv2 UDP с портом 500 или 4500 отправляются и принимаются на IP-адрес DI IPsec и обратно.
Центр обработки данных выделенного инстанса не всегда может начать передачу первого пакета IKEv2. Требуется, чтобы устройство CPE могло инициировать первый пакет IKEv2 на стороне выделенного инстанса.
Если локальный брандмауэр разрешает это, попробуйте также выполнить эхо-запрос на удаленный адрес IPsec. Если эхо-запрос с локального адреса на удаленный адрес IPsec не удался, выполните трассировку маршрута и определите, куда был сброшен пакет.
Некоторые брандмауэры и интернет-оборудование могут не разрешать трассировку маршрута.
Второй этап IPsec (согласование IPsec) Устранение неполадок и проверка
Убедитесь, что первая фаза IPsec (то есть ассоциация безопасности IKEv2) активна, прежде чем устранять неполадки на втором этапе IPsec. Выполните команду «show crypto ikev2 sa» или аналогичную команду для проверки сеанса IKEv2. В выходных данных убедитесь, что сеанс 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 не используется в туннельном интерфейсе, эту проверку можно проигнорировать.
-
На боковом туннельном интерфейсе CPE функция Keepalives не включена
Если оборудование CPE не поддерживает keepalive, необходимо уведомить компанию Cisco о том, что текущие файлы по умолчанию на стороне выделенного инстанса также будут отключены.
Если keepalives поддерживается, убедитесь, что они включены.
-
Маска или IP-адрес туннельного интерфейса неверны и не соответствуют ожидаемым значениям выделенного инстанса.
-
Транспортный адрес исходного или целевого туннеля неверен и не соответствует ожидаемым значениям выделенного инстанса.
-
Брандмауэр блокирует отправку пакетов GRE в туннель IPsec или получение из туннеля IPsec (туннель GRE передается по туннелю IPsec)
Тестирование ping должно убедиться, что интерфейс локального туннеля работает, а подключение к удаленному туннельному интерфейсу хорошее. Выполните проверку связи с IP-адресом туннеля (а не транспортного IP-адреса) на IP-адрес удаленного туннеля.
Криптографический список доступа к туннелю IPsec, по которому проходит трафик туннеля GRE, позволяет пересекать только пакеты GRE. В результате пинг не будет работать с IP-адреса туннельного транспорта на IP-адрес удаленного туннельного транспорта.
В результате проверки ping пакет GRE генерируется из исходного IP-адреса туннельного транспорта на IP-адрес туннельного транспорта назначения, а полезной нагрузкой пакета GRE (внутренний IP-адрес) будет IP-адрес исходного и целевого туннелей.
Если тест ping не увенчался успехом и предыдущие элементы проверены, может потребоваться перехват пакетов, чтобы убедиться, что в результате пинга icmp будет получен пакет GRE, который затем инкапсулируется в пакет IPsec, а затем отправляется с исходного адреса IPsec на целевой адрес IPsec. Счетчики на туннельном интерфейсе GRE и счетчики сеансов IPsec также могут помочь показать, увеличивается ли количество отправляемых и получаемых пакетов.
Помимо трафика ping, при захвате должны также отображаться пакеты GRE, поддерживающие работоспособность, даже во время бездействия трафика. Наконец, если BGP настроен, пакеты BGP keepalive также следует отправлять в виде пакетов GRE, инкапсулированных в пакеты IPSEC, а также через VPN.
Устранение неполадок и проверка BGP
Сеансы BGP
В качестве протокола маршрутизации через VPN-туннель IPsec требуется протокол BGP. Локальный сосед BGP должен установить сеанс eBGP с соседом выделенного инстанса BGP. IP-адреса соседей eBGP совпадают с IP-адресами локального и удаленного туннелей. Сначала убедитесь, что сеанс BGP завершен, а затем убедитесь, что выделенный инстанс получает правильные маршруты и отправляет выделенному инстансу правильный маршрут по умолчанию.
Если туннель GRE запущен, убедитесь в успешности пинга между локальным и удаленным IP-адресами туннеля GRE. Если пинг выполнен успешно, но сеанс BGP не начинается, изучите журнал BGP на наличие ошибок при установлении BGP.
Вот некоторые из наиболее распространенных проблем при согласовании BGP:
-
Номер удаленной AS не совпадает с номером 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.
Важно, чтобы, когда оба туннеля активны, туннель центра обработки данных A не использовался для отправки трафика в центр обработки данных B и наоборот. В этом сценарии, если трафик отправляется в центр обработки данных A с адресатом в центр обработки данных B, центр обработки данных A перенаправит трафик в центр обработки данных B, а затем центр обработки данных B попытается отправить трафик обратно источнику через туннель центра обработки данных B. Это приведет к неоптимальной маршрутизации, а также к нарушению работы трафика, проходящего через брандмауэры. Поэтому важно, чтобы оба туннеля находились в активной/активной конфигурации во время нормальной работы.
Маршрут 0.0.0.0/0 должен быть объявлен со стороны клиента на сторону центра обработки данных, предназначенного для выделенных инстансов. Сторона выделенных инстансов не примет более конкретные маршруты . Убедитесь, что маршрут 0.0.0.0/0 объявлен как из туннеля центра обработки данных выделенного инстанса A, так и из туннеля центра обработки данных выделенного инстанса B.
Конфигурация MTU
На стороне выделенного инстанса доступны две функции, позволяющие динамически настраивать MTU для больших размеров пакетов. Туннель GRE добавляет больше заголовков к IP-пакетам, проходящим через сеанс VPN. Туннель IPsec добавляет дополнительные заголовки поверх заголовков GRE, что еще больше снизит максимально допустимое значение MTU в туннеле.
Туннель GRE настраивает функцию MSS, а туннельный путь GRE в функции обнаружения MTU включен на стороне выделенного инстанса. Настройте команду «ip tcp adjust-mss 1350» или аналогичную команду, а также команду «tunnel path > mtu-discovery» или аналогичную команду на стороне клиента, чтобы динамически регулировать MTU трафика через VPN-туннель.
