AWS Client VPN’de DNS: subnet’i değil VPC resolver’ını kullanın

Endpoint 10.0.8.0/24 içinde, bu yüzden resolver 10.0.8.2 olmalı. En sık duyduğum akıl yürütme bu ve iki kez yanlış. Route 53 Resolver, VPC’nin birincil IPv4 aralığı artı iki üzerinde yanıt verir; bu, 10.0.0.0/16 VPC için, endpoint hangi subnet’i kullanırsa kullansın 10.0.0.2 adresidir. İkinci hata daha sessiz: endpoint’e doğru adresi koymak, istemcinin işletim sisteminin ona hiçbir şey soracağı anlamına gelmez. İki hata da aynı belirtiyi verir: ad çözümlemesi bazı istemcilerde çalışır, bazılarında başarısız olur.

Mit, subnet ilişkilendirmesiyle başlar

İlişkilendirme, istemci bağlantıları için elastik ağ arabirimlerinin nerede yaşadığıyla ilgilidir; hangi resolver adresinin var olduğuyla değil. Endpoint’in subnet’leri istemcilere VPC içinde bir adres verir ve her biri kendi resolver’ını taşımaz.

Bu iki fikri ayırdığınızda aritmetik gizemli olmaktan çıkar ve sorun giderme istemciye kayar; bu vakaların çoğu gerçekte orada biter.

Adresi birincil VPC aralığından hesaplayın

VPC’nin birincil IPv4 CIDR’ını alın ve ağ adresine iki ekleyin. 10.0.0.0/16 10.0.0.2 verir, 172.31.0.0/16 172.31.0.2 verir ve ikincil aralığı olan bir VPC resolver’ı birincil aralıkta tutar. O VPC içindeki 10.0.8.0/24 subnet’i bunu değiştirmez. Endpoint’e dokunmadan önce adresi VPC ID’sinin yanına yazın, çünkü bu sayı bağlantının değil VPC’nin özelliğidir.

VPC ayrıca link-local 169.254.169.253 adresinde de yanıt verir. Bu adres VPC içinden erişilebilir, ancak tünelin diğer ucundaki bir dizüstü için genel olarak yönlendirilen bir hedef değildir.

Yani iki geçerli resolver adresi var ve hiçbiri subnet artı iki değil.

Endpoint ayarının yaptığı ve yapmadığı şeyler

Client VPN endpoint’inde DNS sunucu alanları var ve konsolun VPC resolver seçeneği sunduğu yerde aynı fikri doldurur. Bunları ayarlamak, hizmetin bağlantı kurulumu sırasında istemcilere verdiğini değiştirir. Yönetilmeyen bir OpenVPN istemcisinin bu değerle ne yaptığını değiştirmez, çünkü istemci onu yine işletim sistemine uygulamak zorundadır. «Mac’imde çalışıyor ama Linux makinesinde çalışmıyor» sözü bu boşluktan gelir.

Linux’ta resolver entegrasyonu bağlantı yöneticisine aittir, kullanıcıya değil. /etc/resolv.conf dosyasını elle düzenlemek adresin bir oturum için çalıştığını ve yeniden bağlanınca kaybolduğunu kanıtlar — bu yüzden düzeltilmiş pek çok vaka ertesi sabah geri döner.

Bağlandıktan sonra istemcideki etkin resolver’ı kontrol edin, endpoint’in yapılandırma sayfasını değil.

Split tunneling doğru resolver’ı bozabilir

Split tunneling ile yalnızca tünele itilen yollar kullanılır. Resolver adresi bir yolla kapsanmıyorsa sorgu yerel arabirimden çıkar ve ev yönlendiriciniz yanıtlar. Endpoint’teki adres hâlâ doğru, arama hâlâ başarısız. Resolver için yolu ekleyin, sonra yeniden test edin.

Çakışan yerel aralıklar aynı sonucu daha can sıkıcı biçimde verir: sorgu yanıtlanır, ama yanlış sunucudan.

Amazon DNS adresi için security groups açmayın

Aramalar zaman aşımına uğradığında dürtü, resolver adresine UDP 53 izin veren bir kural eklemektir. AWS, security groups ve ağ ACL’lerinin Amazon DNS trafiğini kendi DNS örneğinize giden trafiği filtrelediği gibi filtrelemediğini belgeler. O kuralları açmak VPC resolver için hiçbir şeyi değiştirmez ve sınırı sebepsiz genişletir. Kendi işlettiğiniz resolver farklı bir durumdur ve gerçekten kendi kurallarına ihtiyaç duyar.

Tasarımınızda ikisi de varsa, herhangi bir kuralı düzenlemeden önce istemcinin gerçekte hangisine baktığını kontrol edin.

Yolu doğrulayın, sonra başka bir şey ölçün

Genel bir adı çözün, VPC ile ilişkili özel barındırılan bölgede kayıtlı özel bir adı çözün ve ikisi arasında istemcinin etkin resolver’ını okuyun. Bu sıra «resolver adresi yanlış» durumunu «bölge ilişkilendirilmemiş» ve «istemci ayarı yok saydı» durumlarından ayırır. Her birinin düzeltmesi farklıdır ve hiçbiri aktarım hızı sorunu değildir.

Başarılı bir arama sürdürülebilir aktarım hızı hakkında hiçbir şey söylemez, bu yüzden rapor verirken bu iki konuşmayı ayrı tutun.