Okresowy dostęp przez AWS Client VPN: sprawdź każdą powiązaną podsieć

Użytkownik łączy się, otwiera wewnętrzną aplikację i dostaje odpowiedź; kolega na tym samym punkcie końcowym dostaje przekroczenie czasu z identycznego laptopa w tej samej sieci Wi-Fi. Ten wzorzec to sygnatura punktu końcowego client VPN z więcej niż jedną powiązaną podsiecią, gdzie ścieżki nie są równoważne. Przechodzę przez to od konsoli na zewnątrz, bo dwie karty decydują, czy reszta dochodzenia jest warta zachodu. Nic w konfiguracji klienta tego nie wyjaśnia.

Zacznij od punktu końcowego i wypisz skojarzenia

W konsoli VPC otwórz Client VPN endpoints, wybierz punkt końcowy i przeczytaj kartę Associations. Każde skojarzenie to podsieć w strefie dostępności, a klient ląduje w tej, którą wybierze usługa podczas budowania połączenia. Zanotuj identyfikatory podsieci i tabelę tras, której każda faktycznie używa, bo te dwie listy to porównanie, które zaraz wykonasz.

Jeśli punkt końcowy pokazuje tylko jedno skojarzenie, ta teoria jest błędna, a klient jest lepszym podejrzanym.

Porównaj tabelę tras punktu końcowego z każdym skojarzeniem

Otwórz kartę Route table na tym samym punkcie końcowym. Każdy docelowy CIDR ma tam cel, a w client VPN celem jest skojarzenie, a nie brama. AWS wymaga wpisu celu dla każdej powiązanej podsieci, więc trasa wskazująca tylko jedną z nich uzależnia dostęp od tego, gdzie wylądowała sesja. Sprawdź cel, na którym naprawdę ci zależy, a potem jego regułę autoryzacji, bo trasa dostarcza ścieżkę, a reguła decyduje, kto może jej użyć.

Gdy zestawisz obie warstwy w tabeli, usterkę trudno przeoczyć.

Drugi wiersz to cały błąd w większości zgłoszeń. Trasa punktu końcowego istnieje, więc nikt nie patrzy dalej, a pakiet ginie jeden skok później wewnątrz VPC.

Prześledź każdą podsieć do jej efektywnej tabeli tras

Podsieć bez jawnego skojarzenia z tabelą tras dziedziczy główną tabelę VPC. Czytaj tabelę, która faktycznie obowiązuje, a nie tę, której nazwa wygląda poprawnie, i porównuj cel oraz obiekt docelowy, a nie etykietę w wierszu.

Przewodnik AWS dotyczący okresowego dostępu opisuje to jako pokrycie trasami w obrębie skojarzeń, co jest właściwym modelem. Punkt końcowy dostarcza pakiet do podsieci, a tabela tej podsieci nadal musi wiedzieć, gdzie znajduje się sieć aplikacji.

Napraw brakujący wiersz w tabeli, która jest jego właścicielem. Kopiowanie całej tabeli tras z działającej podsieci kopiuje też wybory dotyczące internetu, urządzeń i izolacji, które nigdy nie były dla tej podsieci przeznaczone, a ta wymiana jest zwykle gorsza od awarii, od której zacząłeś.

Sprawdź reguły autoryzacji, a potem drogę powrotną

Reguły autoryzacji są na cel i na grupę i są oceniane osobno od tras. Cel z trasami wszędzie, ale bez reguły dla grupy użytkownika, zachowuje się jak czarna dziura z tabelą tras wyglądającą zdrowo.

Droga powrotna zasługuje na taką samą uwagę. Połączenie peering wymaga trasy w VPC aplikacji prowadzącej z powrotem do CIDR klienta, reguł grup zabezpieczeń pozwalających na ruch po obu stronach i sieciowych ACL, które go nie odrzucą. Osiągalność jednokierunkowa, gdy ping działa, a uzgadnianie TCP nie, zwykle wskazuje na ACL lub grupę zabezpieczeń, a nie na VPN.

Własne grupy zabezpieczeń punktu końcowego znajdują się na elastycznych interfejsach sieciowych skojarzenia, więc reguła zezwalająca na port aplikacji z CIDR klienta musi być przypięta do skojarzenia, a nie tylko do instancji.

Weryfikuj ponownym połączeniem, a nie jednym szczęśliwym żądaniem

Przy split tunelu trasy punktu końcowego są wysyłane podczas nawiązywania połączenia, więc zmieniony zestaw tras nigdy nie dociera do klienta, który pozostaje połączony. Rozłącz się i połącz ponownie przez obsługiwanego klienta, a potem potwierdź, że nowe trasy są na maszynie.

Na koniec skoreluj dziennik połączeń z adresem, który otrzymał klient, i powtórz test tyle razy, by trafić w więcej niż jedno skojarzenie. Jedno udane żądanie po poprawce dowodzi, że jedna ścieżka działa, a zgłoszenie dotyczyło drugiej.