kubectl tidak dapat menyelesaikan API kluster persendirian melalui OpenVPN

kubectl gagal semasa carian nama walaupun tunnel aktif dan alamat persendirian API masih menjawab ping. Laluannya betul; klien bertanya kepada resolver yang tidak pernah mendengar tentang zon persendirian kluster. Dua pembetulan paling kerap digunakan: menghantar resolver rangkaian maya kepada setiap klien VPN, atau memakukan nama secara setempat dengan entri hosts atau forwarder bersyarat. Kedua-duanya menyelesaikan gejala yang sama dengan pemilikan berbeza, dan mencampurkannya menyebabkan pasukan mengedit fail hosts setiap kali titik akhir dibina semula.

Penyelesaian dan ketercapaian gagal pada lapisan berbeza

Jalankan carian itu sendiri sebelum mengubah apa-apa. getent hosts pada Linux atau nslookup pada Windows memberitahu sama ada klien menerima jawapan langsung; tamat masa atau NXDOMAIN menunjuk kepada resolver, manakala jawapan dengan alamat salah menunjuk kepada rekod lapuk atau laluan keluar awam.

Kemudian sahkan pelayan mana yang benar-benar dihubungi kubectl. Konteks kubeconfig menyimpan URL, dan laluan VPN tidak menulis semula URL itu: jika konteks menamakan titik akhir awam, DNS boleh sempurna dan arahan itu 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

Isyarat ketiga ialah bentuk kegagalan selepas carian. Nama yang diselesaikan ke alamat persendirian kemudian mengalami tamat masa TCP ialah masalah firewall atau rangkaian dibenarkan. Nama yang diselesaikan ke alamat awam bermakna pertanyaan itu terlepas dari zon persendirian. Asingkan ketiga-tiga hasil itu; setiap satu membawa anda kepada pemilik berbeza.

Pilihan A: hantar resolver rangkaian maya ke dalam tunnel

Apabila pelayan VPN berjalan di dalam rangkaian maya, klien boleh menggunakan resolver yang sama dengan hos pelayan. Dalam OpenVPN Community pelayan menghantar pilihan DNS; Access Server memaparkan tetapan yang sama dalam antara muka pentadbir, dan klien mesti memuat turun profil semula kerana arahan DNS bergerak di dalamnya.

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

Baris laluan penting pada profil split tunnel. Menghantar alamat resolver bukan sama dengan menjadikannya boleh dicapai: jika hanya subnet kluster melalui tunnel, pertanyaan ke 10.0.0.4 keluar melalui LAN setempat dan mati. Hantar laluan hos untuk resolver, atau sertakan subnetnya dalam tunnel.

Pihak penerima juga mempunyai dasar. Resolver yang boleh dicapai dari julat alamat klien masih boleh menolak pertanyaan daripadanya, dan zon persendirian yang dikaitkan dengan rangkaian maya hanya menjawab klien yang tiba melalui laluan DNS rangkaian itu. Jika carian tamat masa selepas penghantaran, periksa log resolver itu sendiri sebelum menyentuh klien lagi.

Pada klien, sahkan apa yang digunakan: resolvectl status pada Linux systemd-resolved, scutil --dns pada macOS, ipconfig /all pada Windows. Pelayan DNS yang dihantar tetapi tidak pernah muncul bermakna profil tidak dimuat semula.

Pilihan B: entri hosts dan penghantaran bersyarat

Entri hosts ialah pembetulan terkecil yang mungkin dan paling rapuh. Ia memetakan satu nama kepada satu alamat pada satu mesin, jadi ia berfungsi untuk demo dan rosak apabila titik akhir persendirian atau IP-nya dibina semula. Ia juga menyembunyikan jurang sebenar daripada seluruh pasukan.

Forwarder bersyarat berskala lebih baik tanpa menghantar DNS kepada setiap klien. dnsmasq boleh menghantar satu zon kepada resolver VNet dan membiarkan yang lain: server=/cluster.internal/10.0.0.4. DNS Windows mempunyai forwarder bersyarat, dan klien Windows boleh menggunakan peraturan NRPT untuk pembahagian yang sama. Forwarder masih memerlukan laluan ke resolver VNet.

Penghantaran mengekalkan pelayaran biasa secara setempat, yang penting pada split tunnel. Ia juga memberi satu tempat untuk mencatat pertanyaan bagi zon persendirian, dan satu tempat yang rosak apabila hos forwarder berpindah.

Pilih mengikut pemilikan, bukan kemudahan

Hantar resolver apabila anda mengawal profil VPN dan mahu setiap nama persendirian berfungsi, bukan hanya API. Pilih forwarder apabila klien mesti mengekalkan DNS setempat untuk semua yang lain, atau apabila VPN diuruskan oleh pasukan berbeza daripada kluster.

Entri hosts ialah diagnostik, bukan penggunaan. Gunakan satu untuk membuktikan API boleh dicapai, kemudian buangkannya dan betulkan laluan resolver; membiarkannya menjadikan soalan laluan sebagai pencarian harta karun kemudian. Apa jua pilihan yang anda buat, catat zon, alamat resolver dan laluan yang membawa pertanyaan.

Uji titik akhir API, bukan hanya namanya

Sebaik sahaja carian berjaya, dapatkan titik akhir versi API dengan CA kluster. curl --cacert ca.crt https://api.internal.example:6443/version memisahkan kegagalan TLS dan kebenaran daripada DNS. 403 bermakna nama dan sambungan berfungsi dan identitinya tidak.

Periksa juga sama ada julat alamat klien dibenarkan oleh rangkaian dibenarkan atau firewall kluster. Kluster persendirian selalunya hanya menerima trafik API dari VNet atau julat peer, jadi tunnel yang memberikan alamat dari kumpulan lain bersambung pada lapisan rangkaian dan digugurkan pada API.

Catat empat fakta apabila anda meningkat: resolver yang digunakan klien, alamat yang dikembalikannya, URL pelayan dalam konteks kubeconfig yang dipilih, dan operasi pertama yang gagal. Rekod itu memberitahu jurutera seterusnya sama ada untuk menukar DNS, laluan atau dasar firewall, dan ia menghentikan suntingan fail hosts yang seterusnya.

Mulakan dengan carian, pilih laluan resolver yang sepadan dengan pemilik zon, kemudian sahkan titik akhir. Jika ketiga-tiganya lulus, masalah yang tinggal ialah kebenaran, bukan penyelesaian nama.