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 описують навантаження за цим з'єднанням. Копіювання внутрішньої адреси віртуальної машини в поле зовнішнього партнера змішує перші дві ролі, і збій виглядає як проблема переговорів, а не як помилка введення даних.
Сплануйте два відповідні тунелі партнера, по одному на кожен інтерфейс HA VPN. Використання обох хмарних інтерфейсів саме по собі не прибирає локальну точку відмови, бо обидва тунелі все ще можуть опинитися на одному шасі.
Запишіть роль адреси поруч із кожним значенням у робочому аркуші. Ця одна звичка запобігає більшості змішування.
Перенесіть робочий аркуш у реліз Cisco
Почніть із підтримуваної документації партнера або відповідного шаблону конфігурації Google для вашої платформи, а потім узгодьте кожен заповнювач із робочим аркушем. Перевірте автентифікацію IKEv2, пропозиції ESP, PFS і модель тунелю та маршрутизації разом, бо невідповідність в одній із них зазвичай виглядає як невідповідність в іншій. Використовуйте фактичну платформу та реліз програмного забезпечення, щоб вибрати підтримуване, оскільки рецепт Classic VPN — це інша відправна точка.
Тримайте спільний секрет поза знімками екрана, вкладеннями тікетів і нотатками підтримки. Попередньо наданий ключ, вставлений у коментар до справи, — це розкриття облікових даних, а не артефакт діагностики.
Якщо шаблон і робочий аркуш суперечать, зупиніться і вирішіть це на папері. Пристрій не буде вирішувати за вас.
Приймайте кожен тунель за його власними доказами
HA VPN потребує сесій BGP, а успішні переговори IKE встановлюють лише перший етап. Внутрішня сесія має піднятися, передбачені префікси мають бути оголошені та прийняті, а корисні маршрути й дозволи брандмауера мають існувати до того, як рушить трафік навантажень. Запис усього цього як одного зеленого світла приховує, який етап насправді збоїв.
Записуйте докази прийняття для кожного тунелю: узгоджені асоціації безпеки, стан сусіда BGP, очікувані вивчені префікси та передбачений шлях навантаження. Потім виконайте контрольовану перевірку збою та відновлення, бо тунель, який ніколи не збоїв, — це тунель, шлях відновлення якого не перевірено.
Цей запис можна використати повторно наступного разу, коли зміниться дизайн, і це різниця між взаємодією та фрагментом команди, чиї припущення втрачено.