CIDR klienta w AWS Client VPN nie może nakładać się na zakres VPC

Punkt końcowy AWS Client VPN przydziela adresy klientów z puli, którą wybierasz, a AWS sprawdza tę pulę względem sieci docelowej, zanim utworzy punkt końcowy. Sprawdzenie nie dotyczy tego, czy podsieć wygląda na wolną. Dotyczy tego, czy pula nakłada się na zakres VPC, i odpowiedź jest taka sama niezależnie od tego, czy instancja EC2 używa dziś tych adresów. Nakładanie to kwestia zakresów, nie przydziałów.

Przejdź pięć kontroli po kolei. Zatrzymaj się na pierwszej, która zawiedzie, bo żaden późniejszy krok nie naprawi wcześniejszej decyzji.

Nakładanie to test zakresów, a nie test wolnych adresów

Zacznij od CIDR VPC, a nie od podsieci, którą planujesz powiązać. Pula 172.20.0.0/22 leży wewnątrz VPC 172.20.0.0/16 i jest odrzucana, nawet gdy żadna podsieć jej nie zajmuje, bo nakładanie jest właściwością zakresów, a nie bieżących przydziałów. Następnie dodaj cele, do których punkt końcowy kieruje ruch: peered VPC, brama tranzytowa i zakresy lokalne przez połączenie site-to-site. Każdy zakres, do którego klient może potrzebować dostępu, należy do listy.

Zbierz je z konta, a nie z pamięci: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", plus wpisy tabeli tras dla podsieci, którą zamierzasz powiązać.

Rozmiar puli ustala się przed budową

AWS akceptuje pulę klientów IPv4 między /22 a /12 w Client VPN. /24 jest zbyt mała, /8 wykracza poza udokumentowany zakres, a oba błędy wynikają z wymiarowania puli jak podsieci obciążenia. Wymiaruj ją według oczekiwanych jednoczesnych klientów plus zapas, a potem zaokrąglij do dozwolonego prefiksu.

Sprawdź arytmetykę, zanim wpiszesz ją w konsoli, bo błędnie wpisany prefiks zmienia rozmiar puli bez żadnego ostrzeżenia:

python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"

To wypisuje liczbę adresów, długość prefiksu i to, czy kandydat koliduje z zakresem VPC, co jest szybsze niż rozważanie masek sieci na końcu okna zmian.

Resolver ma własną rolę adresową

Resolver VPC odpowiada pod adresem bazowym zakresu VPC plus dwa, który nie musi leżeć w powiązanej podsieci. Założenie, że resolver musi mieszkać w puli klientów, albo zbudowanie podsieci wokół tego adresu dodaje obiekty, niczego nie zmieniając. Liczy się to, że punkt końcowy niesie ustawienie DNS, które klient może zastosować, i że resolver jest osiągalny z tunelu.

Zapisz resolver, pulę klientów i powiązaną podsieć jako trzy odrębne pozycje w planie adresacji. Zawodzą niezależnie, a to, że jedna jest poprawna, nic nie mówi o pozostałych dwóch.

Cztery pola, które ustalasz przy tworzeniu

CIDR IPv4 klienta jest ustalony przy tworzeniu. Zmiana serwera DNS, dodanie powiązania, zamiana grupy zabezpieczeń, edycja reguł autoryzacji lub zmiana tras split-tunnel to zwykłe edycje i żadna z nich nie zmienia nazwy puli. Ta asymetria jest powodem, dla którego warto to przejrzeć: tanie ustawienia to te, które zechcesz zmienić później, a drogie to to, które ustalasz najpierw. Przeczytaj opis punktu końcowego, zanim zaplanujesz okno zmian.

Sprawdź wdrożony punkt końcowy, zanim założysz odbudowę. aws ec2 describe-client-vpn-endpoints zwraca pulę, DNS, flagę split-tunnel i powiązania w jednej odpowiedzi, co zwykle wystarcza, by wykluczyć odbudowę.

Zastąp punkt końcowy, zamiast go łatać

Nowy punkt końcowy to nowy punkt końcowy, nie migracja. Istniejące sesje nie przechodzą na niego, profile klientów wskazują inną nazwę, a każde ustawienie, które uważałeś za oczywiste, trzeba odtworzyć: certyfikat serwera, uwierzytelnianie, powiązania, trasy, grupy autoryzacji, logowanie. Zweryfikuj jednym klientem wobec wymaganej usługi prywatnej i wobec celu, który musi zostać odrzucony, a potem poszerz dostęp. Wszystko, co pominiesz, stanie się później zgłoszeniem do wsparcia.

Utrzymuj stary punkt końcowy w działaniu, dopóki ta weryfikacja nie przejdzie, i zachowaj ścieżkę administracyjną niezależną od nowego.

Jedna granica warta podania: to obejmuje pulę klientów IPv4. Ustawienia ruchu dual-stack i IPv6 w Client VPN podlegają własnemu modelowi adresacji, więc nie kopiuj tej listy bez przeczytania dokumentacji tego trybu.