Reklamy BGP z VGW a tabela tras VPC: co zmienia co

Brakujący prefiks w tabeli tras podsieci VPC i brakujący prefiks na routerze klienta to dwa różne błędy, a tylko jeden z nich jest naprawiany w tabelach tras AWS. Wirtualna brama prywatna ogłasza bloki CIDR powiązane z jej VPC; tabela tras podsieci decyduje, dokąd obciążenie wysyła odpowiedź. Traktowanie drugiego jako sposobu na zmianę pierwszego to najczęstszy błąd w tej diagnozie. Wykonaj poniższe sprawdzenia po kolei i trzymaj oba kierunki osobno.

Nazwij przypięcie, zanim przeczytasz jakąkolwiek tabelę

VPN site-to-site kończy się albo na wirtualnej bramie prywatnej, albo na bramie tranzytowej, a identyfikatory zasobów decydują, który model routingu obowiązuje. Najpierw je przeczytaj: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Odpowiedź mówi, czy następną tabelą do sprawdzenia jest tabela tras VPC, czy tabela tras bramy tranzytowej.

Jeśli VPN jest przypięty do bramy tranzytowej, przestań traktować tabelę tras VPC jako płaszczyznę sterowania. Tam tabela VPC wskazuje przypięcie bramy, a kojarzenie i propagacja odbywają się w tabeli tras bramy tranzytowej. Mieszanie obu widoków daje pewne siebie wnioski o niewłaściwym obiekcie.

Kierunek z AWS do biura to reklama

Dla przypięcia VGW brama ogłasza bloki CIDR powiązane z jej VPC bramie klienta przez BGP. Dodanie pojedynczej trasy podsieci lub skierowanie trasy do VPC partnerskiego albo urządzenia nie dodaje kolejnego powiązanego CIDR i nie pojawia się w tej reklamie. Jeśli w biurze brakuje prefiksu, porównaj listę odebranych tras ze skojarzeniami VPC, zanim zmienisz jakąkolwiek tabelę tras.

Prosta reguła ma wyjątki, więc trzymaj ją w jej zakresie. Układ VPN CloudHub może ponownie ogłaszać prefiksy lokacji między bramami klienta, a brama tranzytowa ma własne zasady propagacji. Stwierdzenie, że VGW ogłasza tylko własne VPC, jest użytecznym domyślnym założeniem, a nie prawem obejmującym każdą topologię, jaką spotkasz.

Kierunek z biura do AWS to propagacja plus wybór

W kierunku odwrotnym VGW poznaje prefiks biura, ale samo to nie przenosi obciążenia. Tabela tras podsieci musi mieć włączoną propagację dla przypięcia albo zawierać trasę statyczną do tego samego celu. Gdy oba istnieją dla jednego prefiksu, wygrywa trasa statyczna, a dopasowanie najdłuższego prefiksu działa przed oboma.

Czytaj pochodzenie, zamiast je zakładać: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Wpis o pochodzeniu EnableVgwRoutePropagation przyszedł z BGP; wpis o pochodzeniu CreateRoute wpisał człowiek i będzie wygrywał, dopóki ktoś go nie usunie.

Runbook, który trzyma oba kierunki osobno

Zapisz cztery fakty po stronie AWS, zanim cokolwiek zmienisz: typ przypięcia, powiązane CIDR VPC, pochodzenie trasy podsieci dla danego prefiksu oraz stan tunelu i BGP. To samo wywołanie describe zwraca VgwTelemetry z liczbą zaakceptowanych tras na tunel, co mówi, czy AWS w ogóle przyjął jakieś trasy. Następnie porównaj to z tym, co naprawdę zainstalowało urządzenie klienta. Prefiks obecny w BGP, ale nieobecny w tabeli przekazywania, to problem lokalnego importu lub najlepszej ścieżki, a nie problem tabeli tras AWS.

Jeśli w tabeli podsieci w ogóle nie ma prefiksu, włącz propagację lub dodaj trasę statyczną, a następnie odczytaj to samo zapytanie ponownie po interwale propagacji, zamiast zakładać, że zmiana była natychmiastowa. Jeśli prefiks istnieje, a ruch nadal zawodzi, zostaw płaszczyznę sterowania w spokoju i przejdź do ścieżki danych.

Czego nie zmieniać, kiedy tam jesteś

Nie przełączaj propagacji w niepowiązanych tabelach tras, aby naprawić jeden brakujący prefiks, i nie dodawaj trasy domyślnej, aby ukryć jeden brakujący CIDR. Obie zmiany zwiększają zasięg wpływu i utrudniają kolejną diagnozę. Ogranicz edycję do tabeli obsługującej daną podsieć obciążenia.

Ścieżka danych jest oddzielona od tego wszystkiego. Grupy zabezpieczeń są stanowe, listy ACL sieci nie są, a zapora hosta lub asymetryczna ścieżka powrotna mogą odrzucić ruch, który routing dostarczył poprawnie. Ogłoszony agregat również nie autoryzuje każdej usługi w nim, więc ograniczaj dostęp na granicy polityki, zamiast polegać na tym, czy adres przypadkiem pojawia się w reklamie BGP.

Zapisz stan przed i po każdego zapytania do tabeli tras w rejestrze zmian. Jeśli zmiana pogorszy sytuację, przywróć poprzednie trasy i potwierdź tym samym zapytaniem, bo wycofanie, którego nie możesz zweryfikować, jest tylko przypuszczeniem.