kubectl tidak dapat me-resolve API klaster privat melalui OpenVPN

kubectl gagal saat pencarian nama padahal tunnel aktif dan alamat privat API masih menjawab ping. Rutenya benar; klien menanyakan resolver yang belum pernah mendengar zona privat klaster. Dua perbaikan paling sering dipakai: mendorong resolver jaringan virtual ke setiap klien VPN, atau memaku nama secara lokal dengan entri hosts atau forwarder bersyarat. Keduanya menyelesaikan gejala yang sama dengan kepemilikan berbeda, dan mencampuradukkannya membuat tim mengedit berkas hosts setiap kali endpoint dibangun ulang.

Resolusi dan keterjangkauan gagal di lapisan berbeda

Jalankan sendiri pencariannya sebelum mengubah apa pun. getent hosts di Linux atau nslookup di Windows memberi tahu apakah klien mendapat jawaban sama sekali; timeout atau NXDOMAIN menunjuk ke resolver, sedangkan jawaban dengan alamat salah menunjuk ke record usang atau penerusan publik.

Lalu pastikan server mana yang benar-benar dihubungi kubectl. Konteks kubeconfig menyimpan URL, dan rute VPN tidak menulis ulang URL itu: jika konteks menyebut endpoint publik, DNS bisa sempurna dan perintahnya tetap gagal.

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

Sinyal ketiga adalah bentuk kegagalan setelah pencarian. Nama yang ter-resolve ke alamat privat lalu mengalami timeout TCP adalah masalah firewall atau jaringan yang diizinkan. Nama yang ter-resolve ke alamat publik berarti kueri keluar dari zona privat. Pisahkan ketiga hasil itu; masing-masing mengarahkan Anda ke pemilik berbeda.

Opsi A: dorong resolver jaringan virtual ke dalam tunnel

Ketika server VPN berjalan di dalam jaringan virtual, klien dapat memakai resolver yang sama dengan host server. Di OpenVPN Community server mendorong opsi DNS; Access Server menampilkan pengaturan yang sama di antarmuka admin, dan klien harus mengunduh ulang profil karena direktif DNS ikut di dalamnya.

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

Baris rute penting pada profil split tunnel. Mendorong alamat resolver tidak sama dengan membuatnya terjangkau: jika hanya subnet klaster yang lewat tunnel, kueri ke 10.0.0.4 keluar lewat LAN lokal dan mati. Dorong rute host untuk resolver, atau sertakan subnetnya di tunnel.

Sisi penerima juga punya kebijakan. Resolver yang terjangkau dari rentang alamat klien tetap bisa menolak kueri darinya, dan zona privat yang tertaut ke jaringan virtual hanya menjawab klien yang datang lewat jalur DNS jaringan itu. Jika pencarian timeout setelah dorongan, periksa log resolver itu sendiri sebelum menyentuh klien lagi.

Di klien, verifikasi apa yang diterapkan: resolvectl status di Linux systemd-resolved, scutil --dns di macOS, ipconfig /all di Windows. Server DNS yang didorong tetapi tidak pernah muncul berarti profil tidak dimuat ulang.

Opsi B: entri hosts dan penerusan bersyarat

Entri hosts adalah perbaikan terkecil yang mungkin dan yang paling rapuh. Entri itu memetakan satu nama ke satu alamat di satu mesin, jadi berfungsi untuk demo dan rusak ketika endpoint privat atau IP-nya dibangun ulang. Entri itu juga menyembunyikan celah sebenarnya dari anggota tim lain.

Forwarder bersyarat lebih mudah diskalakan tanpa mendorong DNS ke setiap klien. dnsmasq dapat mengirim satu zona ke resolver VNet dan membiarkan sisanya: server=/cluster.internal/10.0.0.4. DNS Windows memiliki forwarder bersyarat, dan klien Windows dapat memakai aturan NRPT untuk pembagian yang sama. Forwarder tetap memerlukan rute ke resolver VNet.

Penerusan menjaga penjelajahan normal tetap lokal, yang penting pada split tunnel. Penerusan juga memberi satu tempat untuk mencatat kueri zona privat, dan satu tempat yang rusak ketika host forwarder berpindah.

Pilih berdasarkan kepemilikan, bukan kemudahan

Dorong resolver ketika Anda mengendalikan profil VPN dan ingin setiap nama privat berfungsi, bukan hanya API. Pilih forwarder ketika klien harus mempertahankan DNS lokal untuk hal lain, atau ketika VPN dikelola tim yang berbeda dari klaster.

Entri hosts adalah diagnostik, bukan penerapan. Pakai satu untuk membuktikan API terjangkau, lalu hapus dan perbaiki jalur resolver; membiarkannya mengubah pertanyaan routing menjadi pencarian harta karun nanti. Opsi mana pun yang Anda pilih, catat zona, alamat resolver, dan rute yang membawa kueri.

Uji endpoint API, bukan hanya namanya

Setelah pencarian berhasil, ambil endpoint versi API dengan CA klaster. curl --cacert ca.crt https://api.internal.example:6443/version memisahkan kegagalan TLS dan otorisasi dari DNS. 403 berarti nama dan koneksi berfungsi dan identitasnya tidak.

Periksa juga apakah rentang alamat klien diizinkan oleh jaringan resmi atau firewall klaster. Klaster privat sering hanya menerima lalu lintas API dari VNet atau rentang peered, jadi tunnel yang memberi alamat dari kumpulan lain terhubung di lapisan jaringan dan dijatuhkan di API.

Catat empat fakta saat melakukan eskalasi: resolver yang dipakai klien, alamat yang dikembalikannya, URL server pada konteks kubeconfig yang dipilih, dan operasi pertama yang gagal. Catatan itu memberi tahu engineer berikutnya apakah harus mengubah DNS, routing, atau kebijakan firewall, dan menghentikan penyuntingan berkas hosts berikutnya.

Mulailah dari pencarian, pilih jalur resolver yang cocok dengan pemilik zona, lalu verifikasi endpoint. Jika ketiganya lolos, masalah yang tersisa adalah otorisasi, bukan resolusi nama.