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 फाइल सम्पादन रोक्छ।

खोजबाट सुरु गर्नुहोस्, जोनको मालिकसँग मिल्ने रिजोल्भर मार्ग छान्नुहोस्, त्यसपछि अन्त्य बिन्दु प्रमाणित गर्नुहोस्। तीनवटै पास भए बाँकी समस्या अधिकार हो, नाम समाधान होइन।