GCP Cloud VPN: перевіряйте шлюз, тунель і firewall по порядку

Тунель, який повідомляє про встановлене з'єднання, поки кожна перевірка завершується тайм-аутом, зазвичай не має правила firewall у VPC. Перевіряйте шлюз, селектори та тип маршрутизації саме в цьому порядку.

Консоль показує зелений тунель, локальний моніторинг досі не досягає жодного екземпляра, і перестворення тунелю виглядає очевидним рішенням. Так буває рідко. Встановлений тунель доводить лише те, що два шлюзи завершили обмін IKE. Він нічого не каже про те, чи пакет колись був допущений у ваш VPC.

Між цією зеленою іконкою та відповіддю стоять чотири рішення, і вони відмовляють у передбачуваному порядку. Почніть із найдешевшого.

Три об'єкти, і лише один із них шифрує

VPN-шлюз володіє зовнішньою адресою, на яку шифрує ваш партнер. У консолі ви ніколи не створюєте його вручну: виберіть або зарезервуйте адресу у формі підключення, і шлюз з'явиться разом із нею. HA-шлюз займає дві адреси на двох інтерфейсах, що важливо під час перевірки квот пізніше.

Тунель — це сполучення того шлюзу й партнера. Він несе спільний секрет і селектори трафіку, які обіцяє захищати. Саме з цих селекторів починається більшість тихих відмов. Тунель, локальний селектор якого охоплює 10.0.0.0/24, не доставить 10.0.1.0/24, хоч би як здорово виглядав статус.

Віддалена сторона тримає свій список, зазвичай званий доменом шифрування, і термінальне обладнання порівнює його з вашим. Жодна сторона не узгоджує селектор, який їй ніколи не давали.

Тип маршрутизації вирішує, що потрапляє до таблиці маршрутів

Cloud VPN пропонує три форми маршрутизації, і вони не змішуються чисто. Маршрутизація на основі політик зберігає статичні пари селекторів, маршрутизація на основі маршрутів очікує, що статичні маршрути додасте ви самі, а динамічна оголошує префікси через Cloud Router по BGP. Виберіть одну свідомо.

Динамічний тунель із написаними вручну статичними маршрутами поруч дає таблицю маршрутів, яка спорожніє щоразу, коли сесія BGP хитається.

Динамічна — єдина форма, що дозволяє захищеним префіксам змінюватися без перестворення тунелю, і вона втягує Cloud Router до набору об'єктів, які треба перевірити. Статичні селектори залишаються робочими, коли партнер — апаратний firewall, який не вміє говорити BGP. Тоді обом кінцям потрібні однакові діапазони, і конкретніший запис має перемогти з обох боків. Пара, що розходиться на одну підмережу, встановлюється й потім несе половину вашого трафіку.

Неявна заборона стоїть за тунелем

Вхідний трафік оцінюється проти неявної заборони з найнижчим пріоритетом, і цьому правилу байдуже, що пакет прийшов зашифрованим. Доки правило firewall не назве локальний діапазон і використовуваний порт, пакет розшифровується, перевіряється й відкидається. Журнал VPN залишається чистим увесь час, бо тунель зробив рівно те, що обіцяв.

Натомість читайте журнал відмов firewall, коли тунель працює, а перевірка завершується тайм-аутом, потім обмежте правило вихідним діапазоном і потрібними портами:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Робота лише одного напрямку — підказка про firewall

Вихідний трафік поводиться інакше, бо неявне правило дозволу дає змогу екземплярам надсилати будь-куди. Центр обробки даних, який не досягає VM, часто стоїть за бездоганно робочим вихідним шляхом у зворотному напрямку. Ця асиметрія відокремлює пропуск у firewall від збою маршрутизації, адже збій маршрутизації ламає обидва напрямки одразу. Перевірте зворотний напрямок, перш ніж правити ще одне правило.

Створення адрес — теж операція з квотами. Проєкт близько межі використовуваних зовнішніх адрес відхиляє підключення з помилкою, що читається як відмова в правах.

Селектори, квоти, потім чотири перевірки

Тунелі, створені в консолі, іноді повертають порожній віддалений селектор трафіку з gcloud compute vpn-tunnels describe, хоча згенеровані маршрути правильно несуть трафік. Порівняйте те, що фіксує API, з діапазонами, які ви справді захищаєте, перш ніж вирішити, що тунель неправильний. Створення через API або SDK зберігає селектор явним.

Квоти — інший простий недогляд. Запитуйте збільшення до вікна обслуговування, а не під час нього, і перевіряйте кількість адрес у тому самому проєкті, що й шлюз.

Працюйте ззовні всередину: статус партнера, обидва списки селекторів, маршрут для кожної сторони, вхідне правило для вихідного діапазону й порту, потім захоплення пакетів. Запишіть адресу шлюзу, обидва списки селекторів і тип маршрутизації в заявку на зміну, поки тунель новий, бо наступному інженеру, який додасть підмережу, знадобляться всі три.

Схожі статті