Google HA VPN к маршрутизатору Cisco: сначала спланируйте ресурс партнёра
Назовите оба интерфейса Google, ресурс партнёра, договор IKEv2 и каждую сессию BGP до настройки маршрутизатора Cisco, затем выберите одного партнёра или двух.
Первое решение в HA VPN от Cisco к Google — не выбор профиля шифрования, а то, одно локальное устройство или два будут завершать туннели. Шлюз HA VPN Google имеет два интерфейса, и каждый ожидает соответствующий туннель партнёра. Это даёт два туннеля независимо от того, есть ли у вас два маршрутизатора, а разница в том, может ли один блок питания или обновление программного обеспечения обрушить весь проект.
Решение — одно устройство партнёра или два
Выберите схему по трём условиям: можете ли вы принять локальную точку отказа, должны ли использоваться оба облачных интерфейса и какую реконвергенцию терпят ваши рабочие нагрузки. Если любое из трёх — жёсткое требование, два устройства партнёра будут честным ответом.
Решите это до открытия консоли, потому что ответ меняет, сколько туннелей и сессий BGP должен описать рабочий лист.
Напишите рабочий лист до любой команды
В рабочем листе пять строк, и каждой нужен владелец:
| Row | What it records |
|---|---|
| Google side | Project, VPC, region, HA VPN gateway, and the external address of each interface |
| Peer side | The Cisco external addresses, plus the external peer VPN gateway resource that represents them |
| Tunnel pairs | Which peer interface maps to each Google interface, with IKE version, secret and crypto parameters |
| Routing | Cloud Router, local and remote AS numbers, and one inside BGP pair per tunnel |
| Workloads | Approved on-premises and VPC prefixes, and what firewall policy should permit between them |
Внешний ресурс партнёра описывает ваши интерфейсы внутри Google Cloud, и его создание не настраивает маршрутизатор Cisco. Эта асимметрия удивляет тех, кто ожидает, что облачная консоль будет источником истины для обоих концов. Это объявление того, что Google должна ожидать, и маршрутизатор всё ещё должен ему соответствовать. руководство по шлюзу партнёра Google сопоставляет это объявление с работой по туннелю, BGP, брандмауэру и IKE, которую вы всё ещё должны.
Если у строки нет владельца, её заполнит тот, кто дежурит во время перехода.
Держите три роли адресов раздельно
Публичные адреса партнёра несут внешний обмен IPsec. Внутренняя пара BGP относится к защищённому логическому соединению, которое идёт поверх него. Анонсируемые префиксы LAN и VPC описывают рабочие нагрузки за этим соединением. Копирование внутреннего адреса VM во внешнее поле партнёра смешивает первые две роли, и сбой выглядит как проблема согласования, а не как ошибка ввода данных.
Запланируйте два соответствующих туннеля партнёра, по одному на каждый интерфейс HA VPN. Использование обоих облачных интерфейсов само по себе не устраняет локальную точку отказа, поскольку оба туннеля всё ещё могут оказаться на одном шасси.
Записывайте роль адреса рядом с каждым значением в рабочем листе. Эта одна привычка предотвращает большую часть смешения.
Переведите рабочий лист в версию Cisco
Начните с поддерживаемой документации партнёра или подходящего шаблона конфигурации Google для вашей платформы, затем согласуйте каждый заполнитель с рабочим листом. Проверяйте аутентификацию IKEv2, предложения ESP, PFS, а также модель туннеля и маршрутизации вместе, потому что несоответствие в одном из них обычно проявляется как несоответствие в другом. Используйте реальную платформу и версию программного обеспечения, чтобы выбрать поддерживаемое, так как рецепт Classic VPN — другая отправная точка.
Держите общий секрет вне скриншотов, вложений заявок и заметок поддержки. Предварительно общий ключ, вставленный в комментарий к делу, — это раскрытие учётных данных, а не артефакт устранения неполадок.
Если шаблон и рабочий лист не совпадают, остановитесь и решите это на бумаге. Устройство не будет арбитром за вас.
Принимайте каждый туннель по его собственным доказательствам
HA VPN требует сессий BGP, и успешное согласование IKE устанавливает только первый этап. Внутренняя сессия должна подняться, намеченные префиксы должны быть анонсированы и приняты, а полезные маршруты и разрешения брандмауэра должны существовать до того, как двинется трафик рабочих нагрузок. Запись этого как одного зелёного света скрывает, какой этап на самом деле не удался.
Записывайте доказательства приёмки по каждому туннелю: согласованные ассоциации безопасности, состояние соседа BGP, ожидаемые изученные префиксы и намеченный путь рабочей нагрузки. Затем проведите контролируемую проверку отказа и восстановления, потому что туннель, который никогда не отказывал, — это туннель, чей путь восстановления не проверен.
Эта запись может быть использована повторно при следующем изменении проекта, и это разница между совместимостью и фрагментом команды, чьи допущения были потеряны.