Client VPN sertifikasını yeniden içe aktarmak neden yeni bir uç nokta gerektirir

Bir Client VPN bağlantısı kopar, ACM'deki sertifika değiştirilir ve hiçbir şey değişmez. Sertifika nesnesi hiçbir zaman uç noktanın kullandığı şey değildi. Uç nokta oluşturulurken bir sertifikayla ilişkiyi, birlikte doğrulama yapacağı istemci CA'sını, kimlik doğrulama türünü, alt ağları ve yetkilendirme kurallarını sabit özellikler olarak saklar ve bu ilişkilerin hiçbirinde değiştirme sertifikası kabul eden bir değişiklik çağrısı yoktur. Bir ARN'nin arkasındaki baytları değiştirmek sertifikada değişikliktir, onu yakalayan uç noktada değil.

Uç nokta sertifika değil, başvuru saklar

Mekanizmayı kesin olarak ifade etmeye değer, çünkü tüm arızayı açıklıyor. create-client-vpn-endpoint bir sunucu sertifikası ARN'si ve bir istemci kök sertifika zinciri ARN'si alır ve ortaya çıkan uç nokta bu başvuruları kimlik doğrulama seçenekleriyle birlikte sabit özellikler olarak tutar. API mevcut bir uç noktada sunucu sertifikasını değiştiren bir işlem sunmaz.

İlişkiyi tahmin etmeden doğrulayabilirsiniz. aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 sertifikanın ARN'sini, istemci kök zincirinin ARN'sini, kimlik doğrulama türünü, istemci CIDR'sini ve ilgili alt ağları yazdırır; bu, yeniden üretmeniz gereken özelliklerin tamamıdır. Yeniden içe aktarmadan önce ve sonra çalıştırın, çıktı yerinden oynamaz. Yeniden içe aktarmanın asla yardımcı olamayacağının kanıtı budur.

Yeniden içe aktarma neden uç noktaya ulaşamaz

Yeniden içe aktarma, mevcut bir ARN'nin altına yeni bir sertifika gövdesi yazar. Bu, sertifikanın süresi dolmaya yakınken meşru bir işlemdir ve özel anahtar eşleştiği ve zincir doğrulandığı sürece ACM bunu kabul eder. Yapmadığı şey, uç noktanın oluşturulma anındaki doğrulamayı yeniden çalıştırmaktır, bu yüzden ilişki ve arkasındaki malzeme uç nokta kurulduğundaki gibi kalır.

Belirtinin ağ arızası gibi okunmasının nedeni de budur. TLS el sıkışması, yetkilendirme hiç değerlendirilmeden önce başarısız olur veya sıfırlanır, bu yüzden güvenlik grupları, rotalar ve yetkilendirme kuralları hepsi masum görünür ve öyledirler.

Zincir, istemci sertifikasının bir parçasıdır

Arızanın ikinci yarısı istemci sertifikasındadır ve bunu göz ardı etmek daha kolaydır. İstemci sertifikası onu veren zincirle birlikte içe aktarılmalıdır, içe aktarma formu bu alanı isteğe bağlı gösterse bile. Zincir olmadan uç nokta, istemci sertifikasından yapılandırıldığı istemci kök CA'sına bir yol kuramaz ve bağlantı, paket düşüren bir güvenlik duvarı gibi okunan yumuşak bir sıfırlamayla biter. openssl verify -CAfile root-ca.pem client.crt bu soruyu yerel olarak bir saniyede yanıtlar ve çalıştıracağınız ilk komut bu olmalıdır.

Zincirle yeniden içe aktarma o yarı için gerçek bir düzeltmedir ve tek başına hâlâ yeterli değildir. ACM'deki nesne değiştikten sonra eski ilişkiyi tutan uç nokta, test etmeye devam etmek için yanlış şeydir. İki adım da aynı onarıma aittir, bu yüzden iki parçalı düzeltme bir çelişki değildir.

Uç noktayı yeniden oluşturmak bir geçiştir

Yedek bir uç nokta oluşturmak bir geçiştir, yeni bir deneme değildir ve buna yeni bir deneme gibi davranmak ekiplerin iki yarı yapılandırılmış uç noktayla kalma yoludur. Yeni uç nokta yeni bir ID alır ve planlamadıysanız her kullanıcı için yeni bir DNS adı alır. İstemci profilini adrese değil bir ada işaret eder durumda tutun, böylece geçiş yeniden dağıtım değil kayıt değişikliği olur.

Bunu güvenli tutan sıra kısadır: yeni uç noktayı aynı CIDR, alt ağlar ve yetkilendirme kurallarıyla oluşturun, aws ec2 export-client-vpn-client-configuration ile taze bir profil dışa aktarın ve tek bir kullanıcıyla doğrulayın. Ancak ondan sonra eski uç nokta indirilir.

Eski uç noktayı devreden çıkarmanın kendi sırası vardır. Silmeden önce devre dışı bırakmak istediğiniz istemci sertifikalarını iptal edin, çünkü eski CA'ya hâlâ güvenen yeni bir uç nokta gittiğini sandığınız sertifikaları kabul etmeye devam eder. Sonra eski uç noktayı silin ve yetkilendirme kurallarını kaldırın, böylece eski bir profil kapalı sandığınız bir hedef ağa yeniden bağlanamaz. Eski uç noktanın ID'sini ve ilişki tanımlayıcılarını değişiklik kaydına yazın, çünkü bellekle karşılaştırılan bir geçiş, çalışan bir uç noktanın iki kez yeniden inşa edilmesinin yoludur.

Tanıyı sıralayın

Herhangi bir yapılandırmayı değiştirmeden önce üç arızayı ayırın. İstemci TLS'i tamamlayamıyor, istemci TLS'i tamamlıyor ve yetkili değil, ya da istemci bağlanıyor ve bir hedefe ulaşamıyor. Sertifika ilişkisi birinciye, istemci adresini kapsamayan bir yetkilendirme kuralı ikinciye ve bir rota veya güvenlik grubu üçüncüye aittir; orada uç noktayı yeniden oluşturmak neredeyse her zaman yanlış hamledir.

Aylarca çalışıp sonra sertifika veya ilke değişikliği olmadan duran bir uç nokta kendi başına bir durumdur. Aynı ayarlarla yeniden inşa etmek hizmeti geri getirebilir, ancak bu yapılandırmayı yeniden üretilebilir tutmak için bir nedendir, her olayda yeniden inşa etmek için değil.

Sonraki yeniden inşanın doğaçlama değil diff olması için dört şeyi sürüm denetiminde tutun: uç nokta parametreleri, sertifika ve zincir ARN'leri, yetkilendirme kuralları ve istemci CIDR'si. Client VPN kimlik doğrulama belgeleri hangi sertifikanın hangi rolü oynadığını listeler; sorunun sertifika olduğunu varsaymadan önce bunu kontrol etmeye değer. Yeniden içe aktarma hiçbir şeyi değiştirmiyorsa ve uç nokta hâlâ sıfırlanıyorsa şüpheli ilişkidir ve yanıt, kayıtlı parametrelerden inşa edilmiş yeni bir uç noktadır. Uç nokta yeni nesneyi gerçekten alıyorsa ilişki zaten doğruydu ve arıza istemci zincirinde veya yetkilendirme katmanındadır.