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.
Един набор от изходни данни ви казва какво вижда интернет. Другият ви казва накъде отива трафикът ви. Нито един не замества другия.