GCP BYOIP: публічне оголошення — це не приватний маршрут
Поділ префікса BYOIP між майданчиком і хмарою потребує двох планів. Відокремте публічне оголошення, делегування та приватний наступний крок.
Частина публічного блоку залишається на майданчику, а частина переходить у Google Cloud. Це речення описує два плани, а не один: план оголошення в інтернеті та план приватного пересилання. Розглядати їх як одну задачу маршрутизації — саме там проєкти BYOIP ідуть не так.
Задіяні об'єкти відповідають на різні питання, і лише один із них про те, куди пакети йдуть далі.
Три об'єкти, три питання
Публічно оголошений префікс — це одиниця, яку Google оголошує в інтернеті від вашого імені. Публічно делегований префікс — це те, як імпортований простір розподіляється між підтримуваними ресурсами Cloud. Маршрут у VPC, зокрема вивчений через Cloud Router із VPN, вибирає приватний наступний крок. Кожен має власні межі, власний API і власне повідомлення про помилку.
Таблична версія коротша.
| Object | Question it answers |
|---|---|
| Public advertised prefix | Which authorized range Google announces publicly |
| Public delegated prefix | How imported space is allocated to Cloud resources |
| VPN or Cloud Router route | Which private next hop carries a destination |
Лише третій рядок про пересилання всередині вашої мережі.
Що охоплює попередження BYOIP про перекриття
Документація Google щодо BYOIP розглядає оголошений префікс як одиницю оголошення і попереджає про зовнішні оголошення, що перекриваються, зокрема субпрефікс, оголошений за межами Google. Це попередження стосується плану публічного оголошення. Воно не є твердженням про кожен приватний маршрут, який ви можете додати.
Делегування меншого розподілу всередині імпортованого префікса саме по собі не дає вам права оголошувати залишок з іншого джерела.
Поставте питання з погляду того, хто що оголошує. Якщо Google оголошує весь імпортований префікс, друге джерело, що оголошує субпрефікс, створює саме те перекриття, про яке попереджає документація, хоч би як охайно виглядали ваші маршрути VPC.
Що вирішує приватний маршрут
Префікс, вивчений через VPN, не є оголошенням в інтернеті, і жодна кількість BGP цього не змінить. Це запис у таблиці маршрутів VPC, який каже, який тунель або шлюз має нести трафік до цього призначення. Чи є цей запис придатним, вибраним або придатним до використання, залежить від власних правил маршрутизації VPC.
Збіг за найдовшим префіксом діє всередині таблиці маршрутів, тож довший маршрут VPN може перемогти локально, нічого не змінюючи на публічному краї.
Поділ префікса: рішення, яке надходить першим
Якщо архітектура вимагає, щоб половина блоку оголошувалася з центру обробки даних, а половина з Google, вирішіть план оголошення до того, як щось імпортувати. Підтвердьте, які діапазони Google може оголошувати, які залишаються оголошеними в іншому місці і чи перекриваються вони. Потім спроєктуйте приватний шлях для кожного призначення та його зворотний шлях. Якщо постачальники не підтримують потрібний вам поділ, змініть поділ, замість сподіватися, що довший префікс VPN скасує рішення на публічному краї.
Цей порядок важливий, бо другий план не може виправити перший.
Перевірте обидва плани окремо
Перевірте публічний бік за допомогою gcloud compute public-advertised-prefixes list і підтвердьте діапазони та їхній стан. Перевірте приватний бік за допомогою gcloud compute routes list і gcloud compute routers get-status, що показує, чим BGP фактично обмінявся.
Один набір вихідних даних каже, що бачить інтернет. Інший — куди йде ваш трафік. Жоден не замінює інший.