Введение

Virtual Connect – это дополнительный параметр для подключения облака к выделенному экземпляру для Webex Calling (выделенный экземпляр). Virtual Connect позволяет Клиентам безопасно расширять свою Частную Сеть через Интернет с помощью IP VPN-туннелей. Этот параметр подключения обеспечивает быстрое установление подключения к частной сети с помощью существующего локального оборудования клиента (CPE) и подключения к Интернету.

Cisco размещает, управляет и обеспечивает резервирование туннелей IP VPN и необходимый доступ к Интернету в регионах центров обработки данных выделенного экземпляра Cisco, где требуется служба. Аналогичным образом администратор отвечает за соответствующие службы CPE и Интернета, необходимые для создания Virtual Connect.

Каждый заказ Virtual Connect в определенном регионе выделенного экземпляра будет включать два общих туннеля инкапсуляции маршрутизации (GRE), защищенных шифрованием IPSec (GRE поверх IPSec), по одному для каждого центра обработки данных Cisco в выбранном регионе.

Виртуальный 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, то 2 туннеля в направлении центров обработки данных Cisco (DC1 и DC2) в каждом регионе будут поступать от этого устройства CPE. У клиента также есть опция для 2 устройств CPE, после чего каждое устройство CPE должно подключаться к 1 туннелю только в направлении центров обработки данных Cisco (DC1 и DC2) в каждом регионе. Дополнительная избыточность может быть достигнута путем закрытия каждого туннеля в отдельном физическом объекте/местоположении в инфраструктуре Заказчика.

Технические сведения

Модель развертывания

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

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

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

Virtual Connect – VPN – это конструкция узла, при которой узлы узла клиента подключаются к DC1 и DC2 центров обработки данных выделенного экземпляра в пределах определенного региона.

Для улучшения избыточности рекомендуется использовать два узла, однако один узл с двумя туннелями также является поддерживаемой моделью развертывания.


 

Пропускная способность каждого тоннеля ограничена 250 Мбит/с.


 

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

Ожидается, что партнеры будут тесно взаимодействовать с Клиентами, обеспечивая наиболее оптимальный путь для региона обслуживания 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 отправит клиентский трафик через внутреннюю сеть WAN к постоянному току, который потерял подключение.

Процесс подключения

В приведенных ниже шагах высокого уровня описывается, как установить соединение с виртуальным Connect для выделенного экземпляра.
1.

Размещение заказа в Cisco CCW

2.

Активация Virtual Connect из Control Hub

3.

Cisco выполняет конфигурацию сети

4.

Клиент выполняет конфигурацию сети

Этап 1. Заказ CCW

Virtual Connect является надстройкой для выделенного экземпляра в CCW.

1.

Перейдите на веб-сайт заказа CCW и щелкните "Вход", чтобы войти на веб-сайт.

2.

Выберите Create Estimate (Создать предложение с расценками).

3.

Добавить "A-FLEX-3" SKU.

4.

Выберите Редактировать параметры.

5

На открывшейся вкладке "Подписка" выберите "Параметры" и "Надстройки".

6

В разделе Дополнительные надстройки установите флажок рядом с параметром "Виртуальное подключение для выделенного экземпляра". SKU называется "A-FLEX-DI-VC".

7.

Введите количество и количество регионов, в которых требуется виртуальное соединение.


 
Количество виртуального подключения не должно превышать общее количество регионов, приобретенных для выделенного экземпляра. Кроме того, для региона разрешен только один заказ Virtual Connect.
8

Если вас устраивает ваш выбор, щелкните Verify (Подтвердить), а затем Save (Сохранить) в правой верхней части страницы.

9

Щелкните Save (Сохранить), а затем Continue (Продолжить), чтобы оформить заказ. Ваши завершенные заказы теперь будут добавлены в таблицу заказов.

Этап 2. Активация Virtual Connect в Control Hub

1.

Войдите в Control Hub https://admin.webex.com/login.

2.

В разделе Службы перейдите к меню Calling > Выделенный Instacnce > Подключение к облаку.

3.

В карточке Virtual Connect отображается приобретенное количество Virtual Connect. Теперь администратор может щелкнуть Активировать, чтобы инициировать активацию Virtual Connect.


 
Процесс активации может быть запущен только администраторами с ролью «Администратор клиента с полными правами». В то время как администратор с Ролью «Администратор с правами только на чтение» может просматривать только состояние.
4.

При нажатии кнопки Activate (Активировать) для администратора отображается форма Activate Virtual Connect для предоставления технических сведений Virtual Connect, необходимых для конфигураций пиринга на стороне Cisco.


 
Форма также содержит статическую информацию на стороне Cisco в зависимости от выбранного региона. Эта информация будет полезна администраторам клиента для настройки CPE на своей стороне для установления соединения.
  1. IP-адрес туннельного транспорта GRE: Клиент должен указать IP-адреса туннельного транспорта на стороне клиента, и Cisco будет динамически распределять IP-адреса после завершения активации. IPSec ACL для интересного трафика должен разрешить локальный туннельный транспорт IP/32 удаленный туннельный транспорт IP/32. ACL также должен указать только протокол GRE IP.


     
    IP-адрес, предоставленный клиентом, может быть частным или общедоступным.
  2. Узлы IPSec: Клиент должен предоставить исходные IP-адреса туннеля IPSec, а Cisco выделяет IP-адрес назначения IPSec. При необходимости также поддерживается перевод NAT внутреннего адреса туннеля IPSEC на общедоступный адрес.​


     

    IP-адрес, предоставленный клиентом, должен быть общедоступным.


     
    Вся остальная статическая информация, отображаемая на экране активации, соответствует стандартам безопасности и шифрования на стороне Cisco. Эта статическая конфигурация не настраивается или изменяется. Для получения дальнейшей помощи в отношении статических конфигураций на стороне Cisco клиенту необходимо обратиться в TAC.
5

Нажмите кнопку Активировать после заполнения всех обязательных полей.

6

После заполнения формы активации виртуального подключения для региона раздела клиент может экспортировать форму активации из Control Hub на вкладке "Вызовы" > "Выделенный экземпляр" > "Подключение к облаку" и щелкнуть "Параметры экспорта".


 
По соображениям безопасности в экспортированном документе будут недоступны аутентификация и пароль BGP, однако администратор может просматривать их в Control Hub, щелкнув на вкладке Просмотр настроек в Control Hub, "Вызовы" > "Выделенный экземпляр" > "Подключение к облаку".

Этап 3. Cisco выполняет конфигурацию сети

1.

После заполнения формы активации Virtual Connect состояние будет обновлено до параметра Activation In-Progress in Calling > Dedicated Instance > Cloud Connectivity Virtual Connect.

2.

Cisco завершит необходимые конфигурации на боковом оборудовании Cisco в течение 5 рабочих дней. После успешного завершения состояние будет обновлено до «Активировано» для этого конкретного региона в Control Hub.

Этап 4. Клиент выполняет конфигурацию сети

Состояние изменено на "Активировано", чтобы уведомить администратора клиента о том, что на стороне конфигураций для подключения IP VPN от Cisco выполнено на основании входов, предоставленных клиентом. Однако ожидается, что администратор клиента завершит настройку конфигураций на CPE и протестирует маршруты подключения для туннеля Virtual Connect в режиме Онлайн. В случае возникновения каких-либо проблем во время настройки или подключения клиент может обратиться за помощью в Cisco TAC.

Устранение неполадок

Устранение неполадок и проверка IPsec на первом этапе (согласование IKEv2)

Согласование туннеля IPsec включает в себя две фазы: фазу IKEv2 и фазу IPsec. Если согласование фазы IKEv2 не завершено, то второй фазы IPsec не запускается. Во-первых, выдайте команду "show crypto ikev2 sa" (на оборудовании Cisco) или аналогичную команду на стороннем оборудовании, чтобы проверить, активен ли сеанс IKEv2. Если сеанс IKEv2 не активен, возможными причинами могут быть:

  • Интересный трафик не запускает туннель IPsec.

  • Список доступа к туннелю IPsec настроен неправильно.

  • Отсутствует соединение между клиентом и IPsec конечной точки туннеля выделенного экземпляра.

  • Параметры сеанса IKEv2 не совпадают между стороной выделенного экземпляра и стороной клиента.

  • Брандмауэр блокирует пакеты IKEv2 UDP.

Во-первых, проверьте журналы IPsec на наличие любых сообщений, которые показывают прогресс согласования туннеля IKEv2. Журналы могут указывать, где есть проблема с согласованием IKEv2. Отсутствие сообщений в журнале также может указывать на то, что сеанс IKEv2 не активируется.

Некоторые распространенные ошибки при согласовании IKEv2 являются:

  • Настройки для IKEv2 на стороне CPE не совпадают со стороной Cisco, перепроверьте указанные настройки.

    • Проверьте, что IKE версия версии 2.

    • Убедитесь, что параметры шифрования и аутентификации соответствуют ожидаемому шифрованию на стороне выделенного экземпляра.


       

      При использовании шифра "GCM" протокол GCM обрабатывает аутентификацию и устанавливает для параметра аутентификации значение NULL.

    • Проверьте настройку срока службы.

    • Проверьте группу модуля Diffie Hellman.

    • Проверьте настройки псевдослучайной функции.

  • Для списка доступа к карте криптографии не задано:

    • Разрешение GRE (local_tunnel_transport_ip) 255.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 keepalives. Если оборудование не поддерживает keepalives GRE, компания Cisco получает уведомление, поскольку GRE keepalives будет включена на стороне выделенного экземпляра по умолчанию.

  • Убедитесь, что BGP включен и настроен с помощью соседнего адреса IP туннеля выделенного экземпляра.

При правильной настройке начинается туннель IPsec и согласование первой фазы IKEv2:

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

  • Смежный сеанс TCP BGP от смежного BGP CPE к смежному BGP со стороны CPE к смежному BGP со стороны выделенного экземпляра.

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


     

    Ping не может быть IP-адресом туннельного транспорта в IP-адрес туннеля, он должен быть IP-адресом туннеля в IP-адрес туннеля.

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

Убедитесь, что IKEv2 UDP пакеты с портом 500 или 4500 отправляются и принимаются на IPsec и с него.


 

Центр обработки данных выделенного экземпляра не всегда может начать первый пакет IKEv2. Требование заключается в том, что устройство CPE способно инициировать первый пакет IKEv2 в сторону выделенного экземпляра.

Если локальный брандмауэр разрешает это, то также попытайтесь сделать ping на удаленный IPsec адрес. Если не удается выполнить проверку с локального на удаленный адрес IPsec, выполните маршрут трассировки, чтобы помочь, и определите место сброса пакета.

Некоторые брандмауэры и интернет-оборудование могут не разрешить трассировку маршрута.

Устранение и проверка IPsec на втором этапе (согласование 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 не совпадают со стороной выделенного экземпляра. Проверьте настройки.

  • Убедитесь, что параметры шифрования и аутентификации соответствуют настройкам на стороне выделенного экземпляра.

  • Проверьте настройки Perfect Forward Secret (Идеальная секретность переадресации) и соответствие настроек на стороне выделенного экземпляра.

  • Проверьте настройки срока службы.

  • Убедитесь, что IPsec настроен в туннельном режиме.

  • Проверьте IPsec адреса источника и назначения.

Устранение неполадок и проверка интерфейса туннеля

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

  • Транспортный VRF интерфейса туннеля не соответствует VRF интерфейса петли (если в интерфейсе туннеля используется конфигурация VRF).


     

    Если конфигурация VRF не используется в интерфейсе туннеля, эту проверку можно проигнорировать.

  • Keepalives не включены в интерфейсе бокового туннеля CPE


     

    Если keepalives не поддерживаются на оборудовании CPE, необходимо уведомить компанию Cisco, чтобы также отключить функции keepalives по умолчанию на стороне выделенного экземпляра.

    Если keepalives поддерживаются, убедитесь, что keepalives включены.

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

  • Адрес туннельного транспорта источника или назначения некорректен и не соответствует ожидаемым значениям выделенного экземпляра.

  • Брандмауэр блокирует пакеты GRE от отправленных в туннель IPsec или полученных от туннеля IPsec (туннель GRE передается через туннель IPsec)

Тест ping должен убедиться в том, что локальный интерфейс туннеля работает, а подключение хорошо к интерфейсу удаленного туннеля. Выполните проверку ping от IP-адреса туннеля (не транспортного IP) к IP-адресу удаленного туннеля.


 

Список криптодоступа для туннеля IPsec, который несет трафик туннеля GRE, позволяет пересекать только пакеты GRE. В результате пинги не будут работать с 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.

Устранение неполадок и проверка BGP

Сеансы BGP

BGP требуется в качестве протокола маршрутизации через туннель VPN IPsec. Локальный сосед 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.

Важно, чтобы при активном обоих туннелях центр обработки данных Туннель не использовался для отправки трафика в центр обработки данных 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\u0002mtu-discovery" или эквивалентную команду на стороне клиента, чтобы помочь с динамической регулировкой MTU трафика через VPN туннель.