AWS Client VPN uç noktası DNS'i: çözümlenen IP'yi sabitlemek neden başarısız olur

Geçen hafta dig +short size AWS Client VPN profilinizdeki uç nokta adı için bir adres verdi ve tünel bağlandı. Bu hafta aynı profil dizüstü bilgisayarınızda 'Connecting' durumunda bekliyor, iş arkadaşınızın dokunulmamış kopyası ise hâlâ çalışıyor. Hiçbir şey engellenmedi ve sertifikanın süresi dolmadı. Birisi uç noktanın ana bilgisayar adını o çözümlenen adresle değiştirdi ve hizmet artık orada yanıt vermiyor. Dışa aktarılan ad, o değişikliği atlatmak için oluşturulmuş kısımdır.

Profilinizdeki ad, sorgulanan ad olmayabilir

Client VPN'den dışa aktarılan profiller genellikle remote-random-hostname içerir. Bu seçenek açıkken istemci tek kullanımlık bir etiket oluşturur, bunu noktayla uç nokta adına ekler ve birleşik adı çözümler. Uç noktanın bölgesindeki joker kaydı her etikete yanıt verir, bu yüzden uydurma bir önek de çözümlenir ve sorguyu elle yeniden üretmeye çalıştığınızda bu hile görünmez kalır.

Yani uç nokta adını bir terminale yapıştırıp yanıt aldığınızda, istemcinin bağlanırken kullandığından farklı bir adı çözümlemiş olursunuz. Bu uyuşmazlık profilde düzeltilecek bir kusur değildir. Etiket kasıtlı olarak yeniden üretilir: seçenek önbelleklerin eski bir yanıt tutmasını engeller ve makinenizi ya da oturumunuzu asla tanımlamaz.

İstemcinin seçeneği tamamen yok saydığı uyumluluk durumuyla karşılaştım. AWS çözümü belgeler: gerçek uç nokta adını koruyun ve önüne rastgele bir dize ile bir nokta ekleyin, bunu yapıştırılacak bir değer değil adlandırma deseni olarak görün. Bunu eski bir istemciye uygulamak makuldür; önekli dizeyi uç nokta olarak sabit kodlamak değildir.

Kaydedilmiş bir yanıt neden doğru kalamaz

Client VPN uç nokta adresleri AWS tarafından yönetilir ve zamanla değişir; en iyi uygulamalar belgesi bunu açıkça söyler. Yakalanan yanıt tek bir çözümlemenin anlık görüntüsüdür. Bunu sabit kodlayan profil, hizmet taşındığı anda hizmetten çıkarılmış bir ana bilgisayarı hedefleyen profil olur ve arıza nadiren DNS gibi görünür: bağlantı zaman aşımı veya takılmış bir el sıkışma alırsınız, bu yüzden insanlar yönlendirme ve sertifikaların peşine düşer.

/etc/hosts içindeki aynı yanıt aynı sona ermeyi ek bir sorunla devralır. hosts girişi yeniden başlatmalardan, yeniden dışa aktarmalardan ve 'istemciyi yeniden kur' düzeltmelerinden sağ çıkar, bu yüzden adres her taşındığında arıza geri döner. Birinin haftalarca zararsız durduğunu, sonra onu taşıyan her makineyi devre dışı bıraktığını, yeni kurulumların ise normal bağlandığını gördüm. Aynı hesapta bir grubun başarısız olması diğerinin iyi olması biçimindeki bu bölünme, alacağınız en ucuz ipucudur.

Rastgeleleştirmenin kapsamını doğru belirleyin. Her bağlantı denemesinde gerçekleşir. Kurulmuş bir tünel uç noktasını yeniden çözümlemez, oturum ortasında sunucu değiştirmez ve tek tek uygulama istekleri her biri yeni bir VPN ana bilgisayarı seçmez. Yalnızca sonraki deneme yeniden çözümler, bu yüzden öğleden sonra boyunca çalışan bir oturum yarın sabah hakkında hiçbir şey söylemez.

Tünel açılırken hizmet neyi denetler

Client VPN, bağlı olduğunuz adresin uç noktanın DNS adı için çözümlenen bir adresle eşleşmesini şart koşar. Bu tek koşul, ilgisiz görünen birkaç arızayı açıklar: başka bir yeri işaret eden özel bir DNS kaydı, gerçek uç nokta adresine yönlendiren özel bir ön yüz ve ham bir adrese yeniden yazılmış bir profil. AWS, özel kayıt artı yönlendirme düzenini yeni AWS istemcileriyle bir arıza olarak belgeler. Denetim dardır; her takma adın yasak olduğuna dair bir hüküm değildir.

VPN protokolleri hakkında genel bir kural da değildir. Sayısal remote, olağan bir OpenVPN kurulumunda tamamen geçerlidir ve birçoğu böyle çalışır. Kısıtlama yönetilen düzenlemelerden gelir, altındaki protokolden değil.

Bu da sertifika doğrulamasını gevşetmeyi yanlış refleks yapar. Bir profil adres değişiminden sonra başarısız olursa, sunucu doğrulamasını kapatmak çözümlemeyi veya adres eşleşmesi şartını düzeltmek yerine hatayı taşır ve her şeye güvenecek bir istemci bırakır. Dışa aktarılan CA'yı, sunucu doğrulamasını ve karşılıklı kimlik doğrulama ayarlarını geldikleri gibi koruyun.

İzin listeleri, çıkış ve özel DNS üç ayrı sorundur

Dizüstü bilgisayar bağlanmadan önce bir hedefe izin vermesi gereken güvenlik duvarı kuralı dış dinleyiciyle ilgilidir. Ağ sahibine uç nokta adını, taşımayı ve yapılandırılmış bağlantı noktasını verin, sonra kontrollerinin hizmetin DNS davranışını izleyip izleyemeyeceğini sorun. Yakalanmış tek bir adresi tutan kural, yazılmamış son kullanma tarihi olan bir anlık görüntüdür. Kontrol yalnızca değişmez hedefleri kabul ediyorsa, sessizce bir yanıtı sabit kodlamak yerine bu boşluğu devreye almadan önce kapatın.

Tünel açıldıktan sonra yapılan istekler için sabit kaynak adresi gereken bir ortağın başka bir gereksinimi vardır: çıkış. Bir web sitesinin gördüğü şey uygulama rotasına ve bölünmüş tünel ilkesine bağlıdır, istemcinin bağlandığı adrese değil. Bölünmüş tünel trafiği AWS'ye hiç dokunmayabilir.

Tünel içindeki özel DNS üçüncü katmandır. İstemcilere verilen çözümleyici bağlantıdan sonra iç adlara yanıt verir; tünel var olmadan genel uç noktayı çözemez. Uç nokta çözümleme arızası ile iç uygulama çözümleme arızası farklı aşamalarda olur ve bunları karıştırmak sizi yanlış günlüğe gönderir.

Adres ailesi de aynı listeye aittir. IPv4 yanıtı, IPv6 veya çift yığın uç noktanın izin verilen yolu hakkında hiçbir şey söylemez, bu yüzden bir ailede alınan anlık görüntü diğeri için kanıt değildir.

Hiçbir şeyi sabitlemeden bir bağlantıyı denetleyin

Dışa aktarıldığı biçimdeki profille başlayın ve gerçekte ne istediğini okuyun:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Sonra üç şeyi karşılaştırın: profilin tuttuğu uç nokta adı, istemcinin yeni bir deneme için bildirdiği adres ve adın şu anda neye çözümlendiği. Çözümlenen bir ad yalnızca kaydın yanıt verdiğini kanıtlar; taşıma ve kimlik doğrulama ayrıdır ve uç noktanın ping'e yanıt vermesi gerekmez. Ortadaki öğe için tek kaynak istemcinin kendi günlüğüdür, bu yüzden onu deneme sırasında yakalayın, sonrasında değil.

Bugün yanıt veren bir adres bugün hakkında kanıttır; ad, hizmetin geçerli tuttuğu şeydir. Gözlemi kaydedin, uç noktanın sahibine gönderin ve profili ada işaret eder bırakın.

Bırakılacak iki alışkanlık: takılmış bir el sıkışmayı aşmak için sertifika denetimlerini kapatmak ve birinin tutunacağı umuduyla uç nokta adının önüne etiketler yığmak. Etiket joker kayıt üzerinden çözümlenir ya da sorun başka yerdedir. Doğru yapılandırılmış bir profil yine de başarısız olursa, daha uzun bir ana bilgisayar adı değil, tam sorguyu ve bağlantı olayını gönderin.

Kapatmadan önce: profil hâlâ dışa aktarılan uç nokta adını taşıyor, hiçbir hosts dosyası adresi sabitlemiyor, istemci günlüğündeki remote güncel bir çözümlemeyle eşleşiyor ve güvenlik duvarı kuralı adres yerine uç noktayı adlandırıyor. Bir sonraki kişiye devredilecek durum da budur.