kubectl OpenVPN पर निजी क्लस्टर का API हल नहीं कर सकता

kubectl नाम खोज में विफल होता है जबकि टनल चालू है और API का निजी पता अभी भी ping का जवाब देता है। रास्ता ठीक है; क्लाइंट ऐसे रिज़ॉल्वर से पूछ रहा है जिसने क्लस्टर के निजी ज़ोन के बारे में कभी नहीं सुना। दो सुधार सबसे अधिक उपयोग होते हैं: वर्चुअल नेटवर्क का रिज़ॉल्वर हर VPN क्लाइंट को भेजना, या नाम को स्थानीय रूप से hosts प्रविष्टि या सशर्त फ़ॉरवर्डर से पिन करना। दोनों एक ही लक्षण को अलग ज़िम्मेदारी के साथ हल करते हैं, और इन्हें मिलाना ही वजह है कि टीमें हर बार एंडपॉइंट दोबारा बनने पर hosts फ़ाइलें संपादित करती हैं।

रिज़ॉल्यूशन और पहुँच अलग-अलग परतों में विफल होते हैं

कुछ भी बदलने से पहले खोज स्वयं चलाएँ। Linux पर getent hosts या Windows पर nslookup बताता है कि क्लाइंट को जवाब मिलता है या नहीं; समय-सीमा या NXDOMAIN रिज़ॉल्वर की ओर इशारा करते हैं, जबकि गलत पते वाला जवाब पुराने रिकॉर्ड या सार्वजनिक रास्ते की ओर इशारा करता है।

फिर पुष्टि करें कि kubectl वास्तव में किस सर्वर से जुड़ता है। kubeconfig कॉन्टेक्स्ट URL संग्रहीत करता है, और VPN रूट उसे फिर से नहीं लिखता: यदि कॉन्टेक्स्ट सार्वजनिक एंडपॉइंट बताता है, तो DNS उत्तम हो सकता है और कमांड फिर भी विफल होगा।

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

तीसरा संकेत खोज के बाद विफलता का आकार है। जो नाम निजी पते पर हल होकर फिर TCP समय-सीमा पाता है वह फ़ायरवॉल या अधिकृत नेटवर्क की समस्या है। जो नाम सार्वजनिक पते पर हल होता है उसका अर्थ है कि क्वेरी निजी ज़ोन से बाहर निकल गई। इन तीनों परिणामों को अलग रखें; हर एक आपको अलग ज़िम्मेदार व्यक्ति तक भेजता है।

विकल्प A: वर्चुअल नेटवर्क रिज़ॉल्वर को टनल में भेजें

जब VPN सर्वर वर्चुअल नेटवर्क के अंदर चलता है, तो क्लाइंट वही रिज़ॉल्वर उपयोग कर सकते हैं जो सर्वर होस्ट करता है। OpenVPN Community में सर्वर DNS विकल्प भेजता है; Access Server वही सेटिंग एडमिन इंटरफ़ेस में दिखाता है, और क्लाइंट को प्रोफ़ाइल दोबारा डाउनलोड करनी होती है क्योंकि DNS निर्देश उसके अंदर यात्रा करता है।

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

रूट पंक्ति split tunnel प्रोफ़ाइल में मायने रखती है। रिज़ॉल्वर का पता भेजना उसे पहुँच-योग्य बनाने के समान नहीं है: यदि टनल से केवल क्लस्टर का सबनेट गुज़रता है, तो 10.0.0.4 की क्वेरी स्थानीय LAN से बाहर जाकर मर जाती है। रिज़ॉल्वर के लिए होस्ट रूट भेजें, या उसका सबनेट टनल में शामिल करें।

प्राप्त करने वाले पक्ष की भी नीति होती है। क्लाइंट के पता-परास से पहुँच-योग्य रिज़ॉल्वर फिर भी वहाँ से आने वाली क्वेरी अस्वीकार कर सकता है, और वर्चुअल नेटवर्क से जुड़ा निजी ज़ोन केवल उन क्लाइंट को जवाब देता है जो उस नेटवर्क के DNS रास्ते से आते हैं। यदि भेजने के बाद खोज समय-सीमा पर पहुँचे, तो क्लाइंट को दोबारा छूने से पहले स्वयं रिज़ॉल्वर के लॉग देखें।

क्लाइंट पर जाँचें कि क्या लागू हुआ: systemd-resolved Linux पर resolvectl status, macOS पर scutil --dns, Windows पर ipconfig /all। भेजा गया DNS सर्वर जो कभी दिखाई न दे, इसका अर्थ है कि प्रोफ़ाइल दोबारा लोड नहीं हुई।

विकल्प B: hosts प्रविष्टियाँ और सशर्त फ़ॉरवर्डिंग

hosts प्रविष्टि सबसे छोटा संभव सुधार और सबसे नाज़ुक है। यह एक नाम को एक मशीन पर एक पते से जोड़ती है, इसलिए डेमो के लिए काम करती है और निजी एंडपॉइंट या उसका IP दोबारा बनने पर टूट जाती है। यह वास्तविक अंतर को बाकी टीम से छिपा भी देती है।

सशर्त फ़ॉरवर्डर हर क्लाइंट को DNS भेजे बिना बेहतर स्केल करता है। dnsmasq एक ज़ोन VNet रिज़ॉल्वर को भेज सकता है और बाकी सबको छोड़ सकता है: server=/cluster.internal/10.0.0.4। Windows DNS में सशर्त फ़ॉरवर्डर हैं, और Windows क्लाइंट उसी विभाजन के लिए NRPT नियम उपयोग कर सकते हैं। फ़ॉरवर्डर को अभी भी VNet रिज़ॉल्वर तक रूट चाहिए।

फ़ॉरवर्डिंग सामान्य ब्राउज़िंग को स्थानीय रखती है, जो split tunnel में मायने रखता है। यह आपको निजी ज़ोन की क्वेरी लॉग करने की एक जगह और एक ऐसी जगह देती है जो फ़ॉरवर्डर होस्ट के सरकने पर टूटती है।

ज़िम्मेदारी से चुनें, सुविधा से नहीं

रिज़ॉल्वर तब भेजें जब आप VPN प्रोफ़ाइल नियंत्रित करते हैं और चाहते हैं कि हर निजी नाम काम करे, केवल API नहीं। फ़ॉरवर्डर तब चुनें जब क्लाइंट को बाकी सबके लिए अपना स्थानीय DNS रखना हो, या जब VPN को क्लस्टर से अलग टीम संभालती हो।

hosts प्रविष्टियाँ निदान हैं, तैनाती नहीं। एक का उपयोग यह साबित करने के लिए करें कि API पहुँच-योग्य है, फिर उसे हटाएँ और रिज़ॉल्वर का रास्ता ठीक करें; उसे यथावत छोड़ना बाद में रूटिंग के सवाल को खजाने की खोज में बदल देता है। कोई भी विकल्प चुनें, ज़ोन, रिज़ॉल्वर का पता और वह रूट लिख लें जो क्वेरी ले जाता है।

API एंडपॉइंट जाँचें, केवल नाम नहीं

खोज सफल होने पर, क्लस्टर CA के साथ API का संस्करण एंडपॉइंट प्राप्त करें। curl --cacert ca.crt https://api.internal.example:6443/version TLS और अनुमति की विफलताओं को DNS से अलग करता है। 403 का अर्थ है कि नाम और कनेक्शन काम करते हैं और पहचान नहीं।

यह भी जाँचें कि क्लाइंट का पता-परास क्लस्टर के अधिकृत नेटवर्क या फ़ायरवॉल से अनुमत है या नहीं। निजी क्लस्टर अक्सर API ट्रैफ़िक केवल VNet या peered परासों से स्वीकार करते हैं, इसलिए दूसरे पूल से पते देने वाली टनल नेटवर्क परत पर जुड़ती है और API पर छोड़ दी जाती है।

एस्केलेट करते समय चार तथ्य लिखें: क्लाइंट द्वारा उपयोग किया गया रिज़ॉल्वर, उसने लौटाया गया पता, चयनित kubeconfig कॉन्टेक्स्ट में सर्वर URL, और पहला असफल ऑपरेशन। वह रिकॉर्ड अगले इंजीनियर को बताता है कि DNS, रूटिंग या फ़ायरवॉल नीति बदलनी है या नहीं, और अगला hosts फ़ाइल संपादन रोक देता है।

खोज से शुरू करें, ज़ोन के मालिक से मेल खाने वाला रिज़ॉल्वर रास्ता चुनें, फिर एंडपॉइंट सत्यापित करें। यदि तीनों पास हों, तो शेष समस्या अनुमति है, नाम रिज़ॉल्यूशन नहीं।