Dwa VPC potrzebują w tym kwartale sieci biura i właśnie na drugim tunelu załamuje się szacunek. AWS Transit Gateway może działać jako wspólne centrum routingu: VPN podłącza się raz, a każde VPC podłącza się do tego samego centrum. Sieć lokalna dociera wtedy do każdego podłączonego VPC przez jedno połączenie. To zmienia, kto posiada decyzję o routingu, i właśnie tę część większość projektów robi źle.

Załącznik VPN i załączniki VPC to osobne obiekty na tej samej bramie, dlatego relacje routingu trzeba zbudować później.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Dlaczego peering nie jest skrótem, na który liczą ludzie

Kuszącą alternatywą jest zakończenie VPN na VPC A i połączenie VPC B peeringiem z nim. Zwykły peering VPC nie daje tranzytu od krawędzi do krawędzi przez połączenie VPN A. Peer dociera tylko do adresów, które zapewnia sam peering, a krawędź VPN nie jest jednym z nich. Tranzyt daje centrum; peering daje parę.

To ograniczenie jest cechą peeringu, a nie limitem, który można podnieść.

Skojarzenie i propagacja wykonują różną pracę

Wewnątrz bramy tranzytowej skojarzenie wybiera tabelę routingu używaną do wyszukiwania ruchu przychodzącego z załącznika. Propagacja decyduje, które tabele otrzymają wyuczone lub połączone prefiksy załącznika. Jeden załącznik może być skojarzony z jedną tabelą i jednocześnie propagować się do kilku. Mylenie tych dwóch pojęć to droga, którą projekt kończy z osiągalnością, której nikt nie planował.

W pełni połączone małe centrum to łatwy przypadek.

Umieść każdy załącznik w jednej tabeli, a VPN wraz z oboma prefiksami VPC rozwiązuje się czysto. To pozwala też na osiągalność między VPC, której organizacja może nigdy nie chciała, bo wspólna tabela nie zna pojęcia spoke.

Trasy obciążeń żyją gdzie indziej

Każda podsieć obciążenia nadal potrzebuje własnej trasy do bramy tranzytowej dla zamierzonych prefiksów lokalnych. Te tabele routingu VPC są osobnymi obiektami od własnych tabel bramy tranzytowej. Dodaj potrzebne prefiksy i zachowaj istniejące trasy, zamiast zastępować każde miejsce docelowe nowym defaultem. Trasa podsieci także nic nie ogłasza urządzeniu klienta.

Wybierz routing dynamiczny lub statyczny świadomie; peering nie daje żadnego.

Izoluj spoke'y bez utraty dostępu lokalnego

Gdy A i B mogą oba dotrzeć do biura, ale nie mogą routować do siebie, podziel tabele. Skojarzona tabela załącznika VPN trzyma prefiksy VPC. Skojarzona tabela załączników VPC trzyma prefiksy lokalne, bez trasy łączącej A z B. To propagacja tworzy tę relację, więc nigdy nie musisz akceptować każdego domyślnego skojarzenia.

To izolacja routingu, a nie autoryzacja aplikacji.

Grupy zabezpieczeń, ACL sieci, zapory hostów i własne uprawnienia każdej usługi nadal decydują, jaki ruch jest dopuszczany. Jeśli potrzebna jest inspekcja, zaprojektuj jej obsługiwaną ścieżkę jawnie, zamiast zakładać, że centrum ją wykona.

Czego centrum nie naprawia

Plany adresacji nadal nie mogą się nakładać, bo centrum nie pozwala, aby jeden prefiks oznaczał dwa obciążenia. Każdy załącznik VPC potrzebuje pokrycia Availability Zone, którego oczekują jego obciążenia. W przypadku BGP trasy urządzenia klienta z powrotem do każdego wymaganego prefiksu muszą pasować do projektu i jego polityki importu. Brakujące ogłoszenie wygląda dokładnie jak zerwany tunel.

Połączenie VPN i brama tranzytowa są teraz wspólną infrastrukturą.

Zaplanuj nadmiarowość tuneli, pojemność urządzeń, monitorowanie i konserwację wokół wszystkich zależnych VPC, zamiast traktować każde jako niezależnie podłączone.

Migracja z istniejącego układu virtual private gateway zasługuje na ten sam jawny plan. Zbuduj załączniki i polityki, przenieś jedną kontrolowaną ścieżkę obciążenia i potwierdź relacje dozwolone i zabronione, zanim wycofasz starą ścieżkę. Centralizacja pomaga, gdy daje zespołowi sieci jedno miejsce do zarządzania wspólną łącznością, a szkodzi, gdy ukrywa, kto kogo może osiągnąć, za jedną dużą tabelą.

Powiązane artykuły