GCP Classic VPN у Terraform: зробіть тунель маршрутним
У Classic VPN мітка не визначає поведінку. Маршрутний режим — це локальний селектор 0.0.0.0/0, відповідні віддалені селектори та явний маршрут.
План застосовується чисто, тунель піднімається, а консоль називає його заснованим на політиках. Трафік усе одно не проходить, а пошук перемикача маршрутного режиму в ресурсі Terraform нікуди не веде, бо такого поля немає. У Classic VPN маршрутна поведінка — це не режим, який ви обираєте. Це те, що виходить, коли локальний селектор трафіку — 0.0.0.0/0, віддалені селектори перелічують мережі, які справді потрібні, а маршрут указує на тунель. Три речі, і мітка йде за ними.
Міф: поле режиму тунелю
Мітка в консолі відображає те, що API бачить у селекторах. Ніщо в ресурсі не каже маршрутний, тому нема чого встановити в значення істина.
Пошук цього поля з'їдає першу годину проблеми, а читання значень селекторів забирає останні п'ять хвилин.
Що тут означає маршрутний
Google документує маршрутні тунелі Classic VPN як тунелі на основі політик, локальний селектор яких — 0.0.0.0/0. Називаються лише віддалені діапазони, а локальний бік розглядається як будь-яка адреса. Тому маркер у вашій конфігурації — це значення, а не режим. Запишіть обидва селектори явно і прочитайте їх у виводі плану:
local_traffic_selector = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]
Префікс партнера в цьому фрагменті ілюстративний; важлива форма.
Маршрут — окремий об'єкт
Об'єкт тунелю не встановлює маршрут. Пакети можуть відповідати політиці тунелю і все одно не мати куди йти, бо наступний крок визначає таблиця маршрутизації VPC. Маршруту потрібні діапазон призначення, мережа, тунель як наступний крок і пріоритет, який перемагає все ширше. Якщо про це забути, вийде тунель, що повідомляє про встановлене з'єднання, і перевірка, яка ніколи не покидає VPC.
resource "google_compute_route" "office" {
name = "office-via-vpn"
dest_range = "10.20.0.0/16"
network = google_compute_network.vpc.name
next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
priority = 1000
}
Створюйте маршрут у тому самому модулі, що й тунель, щоб вони не розійшлися під час перегляду.
Віддзеркальте селектори на партнері
Віддалений пристрій потрібно налаштувати дзеркально: його локальний діапазон — це ваш віддалений селектор, а його віддалений діапазон має покривати підмережі GCP, які ви плануєте використовувати. Якщо будь-яка сторона звузиться, фаза 2 не вдається, хоча фаза 1 успішна. Це найпоширеніша форма конфігурації, яка виглядає правильно в консолі й не пропускає трафік.
Надрукуйте селектори обох сторін поруч під час перегляду зміни.
Розділіть статичну адресу на два застосування
Створення зарезервованої адреси й тунелю, що на неї посилається, в одному застосуванні — відоме джерело нестабільності, бо адреса має існувати до того, як правило пересилання зможе її використати. Спершу застосуйте лише ресурс адреси, потім додайте шлюз, правила пересилання й тунель і застосуйте знову. Terraform читає наявну адресу зі стану під час другого запуску й використовує її повторно. Якщо це пропустити, тунель може отримати нову публічну адресу при кожному застосуванні, що щоразу ламає конфігурацію партнера.
Два застосування зараз дешевші, ніж зміна партнера при кожному випуску.
Перевіряйте узгодження, а не мітку
Після застосування перевірте три окремі факти: тунель повідомляє про встановлене з'єднання, маршрут існує з потрібним наступним кроком, а партнер повідомляє, що і фаза 1, і фаза 2 підняті.
Тунель працює, але фаза 2 опущена — отже, сторони не сходяться щодо селекторів:
- Одна сторона перелічує підмережу, якої інша не перелічує.
- Одна сторона використовує агрегат, який інша звузила.
- Маршрут існує, але вказує на інший тунель.
Classic VPN — це один тунель із нижчим SLA, ніж у HA VPN, а HA VPN використовує два інтерфейси, два тунелі та BGP з іншими типами ресурсів. Копіювати класичний приклад у конфігурацію HA й очікувати, що поля селекторів поводитимуться так само, — окрема помилка, якої варто уникати. Самі поля тунелю описано в довідці google_compute_vpn_tunnel.