Dlaczego ponowny import certyfikatu Client VPN wymaga nowego punktu końcowego

Połączenie Client VPN się zrywa, certyfikat w ACM zostaje wymieniony i nic się nie zmienia. Obiekt certyfikatu nigdy nie był tym, czego używał punkt końcowy. Punkt końcowy przy tworzeniu zapisuje powiązanie z certyfikatem, wraz z klienckim CA, wobec którego będzie weryfikował, typem uwierzytelniania, podsieciami i regułami autoryzacji, i żadne z tych powiązań nie ma wywołania modyfikacji, które przyjęłoby certyfikat zastępczy. Zastąpienie bajtów za ARN jest zmianą certyfikatu, a nie punktu końcowego, który go zapisał.

Punkt końcowy przechowuje odwołania, a nie certyfikaty

Mechanizm warto ująć precyzyjnie, bo wyjaśnia całą awarię. create-client-vpn-endpoint przyjmuje ARN certyfikatu serwera i ARN łańcucha certyfikatów głównych klienta, a powstały punkt końcowy zachowuje te odwołania wraz z opcjami uwierzytelniania jako stałe właściwości. API nie oferuje operacji, która podmienia certyfikat serwera w istniejącym punkcie końcowym.

Powiązanie można potwierdzić bez zgadywania. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 wypisuje ARN certyfikatu, ARN łańcucha głównego klienta, typ uwierzytelniania, CIDR klienta i powiązane podsieci, czyli cały zestaw właściwości, które trzeba by odtworzyć. Uruchom go przed ponownym importem i po nim, a wynik się nie zmieni. To dowód, że ponowny import nigdy nie miał pomóc.

Dlaczego ponowny import nie może dotrzeć do punktu końcowego

Ponowny import zapisuje nową treść certyfikatu pod istniejącym ARN. To legalna operacja, gdy certyfikat jest bliski wygaśnięcia, i ACM ją przyjmie, o ile klucz prywatny się zgadza, a łańcuch się weryfikuje. Czego nie robi, to ponowne uruchomienie walidacji z momentu utworzenia punktu końcowego, więc powiązanie i materiał za nim pozostają takie, jakie były przy budowie punktu końcowego.

Dlatego objaw czyta się jak awaria sieci. Uzgadnianie TLS kończy się niepowodzeniem lub resetem zanim autoryzacja zostanie w ogóle oceniona, więc grupy zabezpieczeń, trasy i reguły autoryzacji wyglądają na niewinne, i takie są.

Łańcuch jest częścią certyfikatu klienta

Druga połowa awarii tkwi w certyfikacie klienta i łatwiej ją zlekceważyć. Certyfikat klienta trzeba zaimportować z łańcuchem, który go wydał, choć formularz importu pokazuje to pole jako opcjonalne. Bez łańcucha punkt końcowy nie zbuduje ścieżki od certyfikatu klienta do klienckiego CA głównego, z którym został skonfigurowany, a połączenie kończy się miękkim resetem, który brzmi jak zapora odrzucająca pakiety. openssl verify -CAfile root-ca.pem client.crt odpowiada na to pytanie lokalnie w sekundę i powinno to być pierwsze polecenie, które uruchomisz.

Ponowny import z łańcuchem to prawdziwa naprawa tej połowy, ale sama w sobie wciąż nie wystarcza. Gdy obiekt w ACM się zmienił, punkt końcowy z dawnym powiązaniem jest niewłaściwym obiektem do dalszych testów. Oba kroki należą do tej samej naprawy, dlatego dwuczęściowa poprawka nie jest sprzecznością.

Odtworzenie punktu końcowego to migracja

Utworzenie zastępczego punktu końcowego to migracja, a nie ponowna próba, i traktowanie tego jako ponownej próby jest sposobem, w jaki zespoły kończą z dwoma na wpół skonfigurowanymi punktami końcowymi. Nowy punkt końcowy dostaje nowy identyfikator i, jeśli tego nie zaplanowano, nową nazwę DNS dla każdego użytkownika. Utrzymuj profil klienta wskazujący nazwę, a nie adres, aby zamiana stała się zmianą rekordu, a nie redystrybucją.

Kolejność, która to zabezpiecza, jest krótka: utwórz nowy punkt końcowy z tym samym CIDR, podsieciami i regułami autoryzacji, wyeksportuj świeży profil przez aws ec2 export-client-vpn-client-configuration i zweryfikuj na jednym użytkowniku. Dopiero potem stary punkt końcowy jest wyłączany.

Wycofanie starego punktu końcowego ma własną kolejność. Unieważnij certyfikaty klientów, które chciałeś wycofać, zanim go usuniesz, ponieważ nowy punkt końcowy, który nadal ufa staremu CA, dalej przyjmuje certyfikaty, które uważałeś za usunięte. Następnie usuń stary punkt końcowy i jego reguły autoryzacji, aby nieaktualny profil nie mógł ponownie połączyć się z siecią docelową, którą uważałeś za zamkniętą. Zapisz identyfikator starego punktu końcowego i identyfikatory powiązań w zapisie zmian, ponieważ migracja porównywana z pamięcią to sposób, w jaki działający punkt końcowy bywa budowany dwa razy.

Uporządkuj diagnozę

Rozdziel trzy awarie, zanim zmienisz jakąkolwiek konfigurację. Klient nie może ukończyć TLS, klient kończy TLS i nie jest autoryzowany, albo klient się łączy i nie osiąga celu. Powiązanie certyfikatu dotyczy pierwszej, reguła autoryzacji, która nie obejmuje adresu klienta, drugiej, a trasa lub grupa zabezpieczeń trzeciej, gdzie odtworzenie punktu końcowego prawie zawsze jest złym ruchem.

Punkt końcowy, który działał miesiącami, a potem stanął, bez zmiany certyfikatu lub polityki, jest osobnym przypadkiem. Odbudowa z identycznymi ustawieniami może przywrócić usługę, ale to powód, by utrzymywać konfigurację odtwarzalną, a nie powód, by odbudowywać przy każdym incydencie.

Trzymaj cztery rzeczy pod kontrolą wersji, aby następna odbudowa była diffem, a nie improwizacją: parametry punktu końcowego, ARN certyfikatu i łańcucha, reguły autoryzacji oraz CIDR klienta. Dokumentacja uwierzytelniania Client VPN wymienia, który certyfikat pełni jaką rolę, co warto sprawdzić, zanim w ogóle założysz, że problemem jest certyfikat. Jeśli ponowny import nic nie zmienia, a punkt końcowy nadal się resetuje, podejrzanym jest powiązanie, a odpowiedzią jest nowy punkt końcowy zbudowany z zapisanych parametrów. Jeśli punkt końcowy faktycznie przejmuje nowy obiekt, powiązanie było już poprawne, a usterka tkwi w łańcuchu klienta lub warstwie autoryzacji.