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 फाइल संपादन थांबवतो।

शोधाने सुरुवात करा, झोनच्या मालकाशी जुळणारा रिझॉल्व्हर मार्ग निवडा, नंतर एंडपॉइंट सत्यापित करा। तिन्ही उत्तीर्ण झाले तर उर्वरित समस्या अधिकृतता आहे, नाव रिझोल्यूशन नाही।