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 фактически обменялся.
Один набор выходных данных говорит о том, что видит интернет. Другой — о том, куда идёт ваш трафик. Ни один не заменяет другой.