kubectl, özel küme API'sini OpenVPN üzerinden çözemiyor

kubectl, tünel açıkken ve API'nin özel adresi hâlâ ping'e yanıt verirken ad çözümlemede başarısız olur. Yol doğru; istemci, kümenin özel bölgesini hiç duymamış bir çözümleyiciye soruyor. En sık iki düzeltme kullanılır: sanal ağın çözümleyicisini her VPN istemcisine göndermek veya adı yerel olarak bir hosts girdisi ya da koşullu yönlendiriciyle sabitlemek. Aynı belirtiyi farklı sahiplikle çözerler ve bunları karıştırmak, ekiplerin her uç nokta yeniden oluşturulduğunda hosts dosyalarını düzenlemesine yol açar.

Çözümleme ve erişilebilirlik farklı katmanlarda başarısız olur

Herhangi bir şeyi değiştirmeden önce aramayı kendiniz çalıştırın. getent hosts Linux'ta veya nslookup Windows'ta istemcinin hiç yanıt alıp almadığını söyler; zaman aşımı veya NXDOMAIN çözümleyiciye işaret ederken yanlış adresli bir yanıt eski bir kayda veya genel bir kaçağa işaret eder.

Ardından kubectl'in gerçekte hangi sunucuya bağlandığını doğrulayın. kubeconfig bağlamı bir URL saklar ve VPN yolu onu yeniden yazmaz: bağlam genel bir uç nokta adlandırıyorsa DNS kusursuz olabilir ve komut yine de başarısız olur.

getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40

Üçüncü sinyal, aramadan sonraki hatanın şeklidir. Özel adrese çözülen ve ardından TCP zaman aşımına uğrayan bir ad, güvenlik duvarı veya yetkili ağ sorunudur. Genel bir adrese çözülen ad, sorgunun özel bölgeden kaçtığı anlamına gelir. Bu üç sonucu ayrı tutun; her biri sizi farklı bir sahibine gönderir.

Seçenek A: sanal ağın çözümleyicisini tünele gönderin

VPN sunucusu sanal ağın içinde çalıştığında istemciler sunucu ana bilgisayarıyla aynı çözümleyiciyi kullanabilir. OpenVPN Community'de sunucu bir DNS seçeneği gönderir; Access Server aynı ayarı yönetim arayüzünde gösterir ve istemciler profili yeniden indirmelidir çünkü DNS yönergesi onun içinde taşınır.

# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"

Yol satırı split tunnel profillerinde önemlidir. Bir çözümleyici adresi göndermek onu erişilebilir kılmakla aynı şey değildir: tünelden yalnızca kümenin alt ağı geçiyorsa 10.0.0.4'e giden sorgu yerel LAN üzerinden çıkar ve ölür. Çözümleyici için bir ana bilgisayar yolu gönderin veya alt ağını tünele dahil edin.

Alıcı tarafın da bir politikası vardır. İstemcinin adres aralığından erişilebilen bir çözümleyici yine de oradan gelen sorguları reddedebilir ve sanal ağa bağlı özel bir bölge yalnızca o ağın DNS yolundan gelen istemcilere yanıt verir. Göndermeden sonra arama zaman aşımına uğrarsa istemciye tekrar dokunmadan önce çözümleyicinin kendi günlüklerine bakın.

İstemcide neyin uygulandığını doğrulayın: resolvectl status systemd-resolved Linux'ta, scutil --dns macOS'ta, ipconfig /all Windows'ta. Hiç görünmeyen gönderilmiş bir DNS sunucusu, profilin yeniden yüklenmediği anlamına gelir.

Seçenek B: hosts girdileri ve koşullu yönlendirme

Bir hosts girdisi mümkün olan en küçük düzeltmedir ve en kırılgandır. Tek bir adı tek bir makinede tek bir adrese eşler, bu yüzden bir gösterim için çalışır ve özel uç nokta ya da IP'si yeniden oluşturulduğunda bozulur. Ayrıca gerçek boşluğu ekibin geri kalanından gizler.

Koşullu bir yönlendirici, DNS'i her istemciye göndermeden daha iyi ölçeklenir. dnsmasq bir bölgeyi VNet çözümleyicisine gönderebilir ve gerisini rahat bırakabilir: server=/cluster.internal/10.0.0.4. Windows DNS'te koşullu yönlendiriciler vardır ve Windows istemcileri aynı bölünme için bir NRPT kuralı kullanabilir. Yönlendiricinin yine de VNet çözümleyicisine bir yolu olmalıdır.

Yönlendirme normal gezinmeyi yerel tutar, bu da split tunnel'da önemlidir. Ayrıca özel bölge için sorguları günlüğe kaydedecek tek bir yer ve yönlendirici ana bilgisayarı taşındığında bozulacak tek bir yer verir.

Kolaylığa göre değil, sahipliğe göre seçin

VPN profilini kontrol ediyorsanız ve yalnızca API değil her özel adın çalışmasını istiyorsanız çözümleyiciyi gönderin. İstemciler geri kalan her şey için yerel DNS'lerini korumak zorundaysa veya VPN kümeden farklı bir ekip tarafından yönetiliyorsa bir yönlendirici seçin.

hosts girdileri bir teşhistir, dağıtım değil. API'nin erişilebilir olduğunu kanıtlamak için birini kullanın, sonra kaldırın ve çözümleyici yolunu düzeltin; yerinde bırakmak bir yönlendirme sorusunu sonradan bir hazine avına çevirir. Hangi seçeneği seçerseniz seçin, bölgeyi, çözümleyici adresini ve sorguyu taşıyan yolu yazın.

API uç noktasını test edin, yalnızca adı değil

Arama başarılı olduğunda API'nin sürüm uç noktasını kümenin CA'sıyla alın. curl --cacert ca.crt https://api.internal.example:6443/version TLS ve yetkilendirme hatalarını DNS'ten ayırır. 403, adın ve bağlantının çalıştığı, kimliğin çalışmadığı anlamına gelir.

İstemci adres aralığının kümenin yetkili ağları veya güvenlik duvarı tarafından izin verilip verilmediğini de kontrol edin. Özel kümeler genellikle API trafiğini yalnızca VNet veya eşlenmiş aralıklardan kabul eder, bu yüzden başka bir havuzdan adres atayan bir tünel ağ katmanında bağlanır ve API'de düşürülür.

Yükseltme yaparken dört gerçeği not edin: istemcinin kullandığı çözümleyici, döndürdüğü adres, seçilen kubeconfig bağlamındaki sunucu URL'si ve başarısız olan ilk işlem. Bu kayıt, sonraki mühendise DNS, yönlendirme veya güvenlik duvarı politikasının değiştirilip değiştirilmeyeceğini söyler ve bir sonraki hosts dosyası düzenlemesini durdurur.

Aramayla başlayın, bölgenin sahibine uyan çözümleyici yolunu seçin ve ardından uç noktayı doğrulayın. Üçü de geçerse kalan sorun yetkilendirmedir, ad çözümleme değil.