Dodawanie lokalnej podsieci do AWS VPN: VGW czy Transit Gateway

Istniejący Site-to-Site VPN przenosi 10.60.0.0/16, za tą samą lokalną bramą pojawia się nowa sieć usługowa jako 10.70.0.0/16, i ktoś pyta, czy potrzebny jest proxy. Zwykle nie: ścieżka routowana może przenieść prefiks, ale tylko jeśli zbiegną się trzy rzeczy, a które trzy, zależy od architektury AWS, którą już prowadzisz. Wirtualna brama prywatna ma jedną granicę tabeli routingu; transit gateway dodaje drugą. Poprawna reklama i błędna tabela dają sesję, która wygląda zdrowo i niczego nie dostarcza.

Opublikuj prefiks, który brama naprawdę może dostarczyć

Lokalna brama potrzebuje drogi do nowej sieci, zanim jakakolwiek reklama nabierze sensu. Reklamowanie 10.70.0.0/16 przez BGP mówi AWS, gdzie wysyłać pakiety tego zakresu; nie tworzy lokalnej ścieżki przekazywania, która czyni zakres osiągalnym na drugim końcu. Potwierdź, że brama ma trasę dla prefiksu wskazującą urządzenie, które go trzyma, i że urządzenie jest skonfigurowane do odpowiadania na te adresy. Polityka eksportu i akceptowane limity prefiksów to kolejne ograniczenie, bo prefiks odfiltrowany przez sesję nigdy nie dociera do AWS.

Trzymaj agregaty i bardziej szczegółowe trasy świadomie. Nakładające się ścieżki przychodzące z dwóch kierunków to decyzja projektowa, a nie szczegół odkrywany później.

Ścieżka pierwsza: granica wirtualnej bramy prywatnej

W przypadku wirtualnej bramy prywatnej dokumentacja routingu AWS VPN opisuje dwa tryby dystrybucji, trasy statyczne i reklamy BGP, i oba zależą od tabeli routingu podsieci, której aplikacja naprawdę używa. Propagacja jest wygodna, gdy kontrolujesz cały zakres, a jawna trasa jest łatwiejsza do uzasadnienia, gdy chcesz mieć miejsce docelowe obok celu. W obu przypadkach sprawdzenie jest takie samo: czy tabela konkretnej podsieci aplikacji zawiera działającą ścieżkę do celu VPN dla nowego prefiksu i czy wygrywa z czymś bardziej szczegółowym?

Zdrowa sesja BGP dowodzi, że kanał istnieje. Nie mówi nic o tym, czy dana tabela podsieci przyjęła trasę.

Ścieżka druga: transit gateway dodaje tabelę

Transit gateway dzieli to jedno pytanie na dwa. Podsieć VPC musi wysłać miejsce docelowe do przyłączenia transit gateway, a następnie tabela routingu transit gateway musi wybrać przyłączenie VPN dla tego samego prefiksu. Wybory skojarzenia i propagacji decydują, które przyłączone sieci otrzymają trasę, więc prefiks może być poprawnie reklamowany przez VPN i mimo to nigdy nie dotrzeć do VPC, którego tabela nigdy nie została skojarzona z właściwą tabelą routingu.

Częsta awaria to trasa, która istnieje w jednej tabeli, a w drugiej nie, przy czym każdy zespół jest przekonany, że jego strona jest poprawna. Porównując obie architektury, ta dodatkowa granica to cała różnica: więcej miejsc do sprawdzenia i precyzyjniejsza kontrola nad tym, kto dostaje trasę.

Propagacja tras też nie daje prefiksu każdemu przyłączeniu. Rozdziela go do tabel skonfigurowanych do jego odbioru.

Ścieżka powrotna to odrębna decyzja polityczna

Ruch przychodzący to tylko połowa wymiany. Nowa sieć lokalna potrzebuje trasy powrotnej do prefiksów źródłowych AWS przez właściwą bramę, a polityka bezpieczeństwa po obu stronach musi zezwalać na tę parę źródła i celu. Jeśli tunel negocjuje zakres ochrony z selektorami ruchu, nowy prefiks musi się w nim znajdować, inaczej pakiet jest odrzucany, zanim zostanie sprawdzona jakakolwiek tabela routingu.

Nakładanie się adresów to druga pułapka. Rozłączne, jawnie posiadane zakresy utrzymują to prostym; nakładające się zakresy oznaczają translację lub przeprojektowanie, a żadne z nich nie jest wymiennym wariantem tej samej recepty.

Testuj ze źródłem w nowej sieci i celem w podsieci aplikacji, a potem powtórz w drugą stronę. Test jednokierunkowy dowodzi tylko jednego kierunku.

Kiedy proxy naprawdę jest lepszą granicą

Proxy zasługuje na swoje miejsce, gdy wymaganiem jest wąski interfejs usługi, gdy aplikacja już oczekuje tej architektury, albo gdy ścieżki sieciowej nie da się zmusić do przenoszenia prefiksu bez translacji, której nie chcesz. Nie jest rozwiązaniem zapasowym dla wpisu w tabeli routingu, którego nikt nie sprawdził.

Decyduj w tej kolejności: lokalne przekazywanie, reklama, granica tabeli, polityka powrotu. Napraw pierwszy, który zawiedzie, i dopiero potem pytaj, czy ścieżka routowana jest w ogóle właściwą odpowiedzią.