GCP BYOIP: publiczne ogłoszenie to nie prywatna trasa
Podział prefiksu BYOIP między siedzibę i chmurę wymaga dwóch planów. Oddziel publiczne ogłoszenie, delegację i prywatny następny skok.
Część publicznego bloku zostaje na miejscu, a część przenosi się do Google Cloud. To zdanie opisuje dwa plany, a nie jeden: plan ogłaszania w internecie i plan prywatnego przekazywania. Traktowanie ich jako jednego problemu routingu to miejsce, w którym projekty BYOIP zawodzą.
Zaangażowane obiekty odpowiadają na różne pytania, a tylko jeden z nich dotyczy tego, dokąd pakiety idą dalej.
Trzy obiekty, trzy pytania
Publicznie ogłoszony prefiks to jednostka, którą Google ogłasza w internecie w Twoim imieniu. Publicznie delegowany prefiks to sposób, w jaki importowana przestrzeń jest przydzielana obsługiwanym zasobom Cloud. Trasa VPC, w tym nauczona przez Cloud Router z VPN, wybiera prywatny następny skok. Każda ma własny zakres, własne API i własny komunikat o błędzie.
Wersja tabelaryczna jest krótsza.
| 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 |
Tylko trzeci wiersz dotyczy przekazywania wewnątrz Twojej sieci.
Co obejmuje ostrzeżenie BYOIP o nakładaniu się
Dokumentacja BYOIP Google traktuje ogłoszony prefiks jako jednostkę ogłaszania i ostrzega przed nakładającymi się ogłoszeniami zewnętrznymi, w tym podprefiksem ogłaszanym poza Google. To ostrzeżenie dotyczy planu publicznego ogłaszania. Nie jest to stwierdzenie o każdej prywatnej trasie, którą możesz dodać.
Delegowanie mniejszego przydziału wewnątrz importowanego prefiksu samo w sobie nie daje Ci pozwolenia na ogłaszanie reszty z innego źródła.
Zadaj pytanie w kategoriach tego, kto co ogłasza. Jeśli Google ogłasza cały importowany prefiks, drugie źródło ogłaszające podprefiks tworzy dokładnie to nakładanie się, przed którym ostrzega dokumentacja, niezależnie od tego, jak uporządkowane wyglądają Twoje trasy VPC.
Co decyduje prywatna trasa
Prefiks nauczony przez VPN nie jest ogłoszeniem internetowym i żadna ilość BGP tego nie zmieni. To wpis w tabeli tras VPC, który mówi, którym tunelem lub bramą ma być przenoszony ruch do tego celu. To, czy wpis jest kwalifikowany, wybrany czy użyteczny, zależy od własnych reguł routingu VPC.
Dopasowanie najdłuższego prefiksu obowiązuje wewnątrz tabeli tras, więc dłuższa trasa VPN może wygrać lokalnie, nie zmieniając niczego na publicznej krawędzi.
Dzielenie prefiksu: decyzja, która przychodzi pierwsza
Jeśli architektura wymaga, aby połowa bloku była ogłaszana z centrum danych, a połowa z Google, rozstrzygnij plan ogłaszania, zanim cokolwiek zaimportujesz. Potwierdź, które zakresy Google może ogłaszać, które pozostają ogłaszane gdzie indziej i czy oba się nakładają. Następnie zaprojektuj prywatną ścieżkę dla każdego celu i jej ścieżkę powrotną. Jeśli dostawcy nie obsługują podziału, którego chcesz, zmień podział, zamiast liczyć na to, że dłuższy prefiks VPN unieważni decyzję na publicznej krawędzi.
Ta kolejność ma znaczenie, ponieważ drugi plan nie może naprawić pierwszego.
Zweryfikuj oba plany osobno
Sprawdź stronę publiczną za pomocą gcloud compute public-advertised-prefixes list i potwierdź zakresy oraz ich status. Sprawdź stronę prywatną za pomocą gcloud compute routes list i gcloud compute routers get-status, co pokazuje, co BGP faktycznie wymienił.
Jeden zestaw danych wyjściowych mówi Ci, co widzi internet. Drugi mówi Ci, dokąd idzie Twój ruch. Żaden nie zastępuje drugiego.