AWS Client VPN z tunelem dzielonym: które trasy publikować

Konsola oferuje przełącznik tunelu dzielonego, więc decyzja wygląda jak pole wyboru. Nie jest. To, co faktycznie dociera do klienta, to opublikowany zestaw tras punktu końcowego, a ta lista decyduje, które prefiksy prywatne korzystają z tunelu, czy ogólny ruch internetowy pozostaje lokalny, czy wychodzi przez AWS, i z którym resolverem klient wciąż może rozmawiać. Trzy pytania rozstrzygają projekt, a na każde można odpowiedzieć źle, podczas gdy połączenie nadal się udaje.

Flaga tunelu dzielonego to nie lista miejsc docelowych

AWS opisuje tunel dzielony jako dodanie tras punktu końcowego do tabeli tras klienta podczas nawiązywania połączenia. Trasa do prywatnego VPC ogranicza tunel do tego celu; wszystko inne podąża zwykłą drogą klienta. Trasa domyślna to inna instrukcja o innym efekcie, dlatego dokumentacja tunelu dzielonego ostrzega przed publikowaniem 0.0.0.0/0 w punkcie końcowym skonfigurowanym dla tego trybu: zwykle psuje to łączność, zamiast ją rozszerzać. Tabela tras punktu końcowego to polityka, a tabela tras klienta to wynik, który możesz sprawdzić.

Czytaj tabelę tras punktu końcowego i zainstalowane trasy klienta razem. Etykieta opisuje intencję; trasy opisują, co się dzieje.

Pierwsza decyzja: czy ogólny ruch internetowy ma pozostać lokalny?

Jeśli przeglądanie ma korzystać z własnego połączenia użytkownika, publikuj tylko te prywatne cele, których potrzebuje praca, i na tym poprzestań. Nie dodawaj trasy internetowej dlatego, że poradnik pełnego tunelu zawierał jedną, i nie zakładaj, że dodatkowa trasa poprawia bezpieczeństwo. Zmienia ścieżkę, nie dodaje polityki i zwykle kosztuje opóźnienie, którego nie zaplanowałeś.

Jeśli ruch internetowy ma wychodzić przez AWS, zbuduj udokumentowaną architekturę dostępu do internetu: trasę punktu końcowego, reguły autoryzacji, ścieżkę powiązanej podsieci, politykę bezpieczeństwa i działające wyjście nadrzędne. Sama trasa domyślna nie zapewnia niczego z tego.

Druga decyzja: które prefiksy prywatne i za czyją autoryzacją?

Publikuj najmniejszy zbiór celów, który obsługuje rzeczywiste obciążenie, i sprawdź, czy każda powiązana podsieć potrafi routować do nich. Cel trasy punktu końcowego i routing VPC podsieci to różne warstwy, a trasa istniejąca w jednej nie jest dowodem na drugą. Autoryzacja jest znowu osobna: cel może być osiągalny i mimo to odrzucony, bo grupa klienta nie ma reguły, która go pozwala.

Przetestowanie jednej udanej sesji dowodzi jednej ścieżki. Sprawdź każdą powiązaną podsieć, bo powiązanie podsieci dodane później to dokładnie miejsce, w którym zwykle siedzi brakująca trasa.

Gdy cel musi być osiągalny po nazwie, zauważ, że następnym pytaniem jest rozwiązywanie nazw, a nie trasa.

Trzecia decyzja: który resolver podąża za tunelem?

Klient może otrzymać serwer DNS osiągalny tylko przez VPN, a ten resolver działa tylko wtedy, gdy jego adres sam znajduje się w autoryzowanej trasie. Sprawdź obie połowy: adres resolvera podąża za opublikowaną trasą, a serwer odpowiada na nazwy, o które pyta aplikacja. Żądanie, które udaje się po adresie, ale zawodzi po nazwie hosta, wskazuje na nazewnictwo, nie na routing, a debugowanie tunelu w takim przypadku marnuje popołudnie.

Publiczne nazwy powinny być rozwiązywane tak jak przed połączeniem, co jest kolejnym powodem, by być precyzyjnym w tym, co publikujesz.

Zmień zbiór tras, a następnie zweryfikuj oba światy

AWS dokumentuje, że zmiana tras w punkcie końcowym tunelu dzielonego resetuje połączenia klientów. Zaplanuj zmianę z tym zamiarem: zastosuj ją, połącz się ponownie przez obsługiwanego klienta i odczytaj zainstalowane trasy od nowa, zamiast ufać stanowi zastosowanemu przed edycją. Nieaktualny zastosowany stan to najczęstszy powód, dla którego poprawna zmiana wygląda na zepsutą.

Zaakceptuj projekt tylko wtedy, gdy jeden zasób prywatny i jeden cel publiczny zachowują się zgodnie z zamiarem, po nazwie i po adresie, w rodzinach adresów, które naprawdę obsługujesz. Tunel, który uwierzytelnia, to nie to samo co tunel, który poprawnie dzieli.

Zapisz listę tras w runbooku obok uzasadnienia, aby następna osoba odróżniła zamierzone wykluczenie od zapomnianego.