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 اینڈ پوائنٹ آزمائیں، صرف نام نہیں

تلاش کامیاب ہونے پر API کا ورژن اینڈ پوائنٹ کلسٹر CA کے ساتھ حاصل کریں۔ curl --cacert ca.crt https://api.internal.example:6443/version TLS اور اجازت کی ناکامیوں کو DNS سے الگ کرتا ہے۔ 403 کا مطلب ہے کہ نام اور کنکشن کام کرتے ہیں اور شناخت نہیں۔

یہ بھی دیکھیں کہ کلائنٹ کے پتہ رینج کو کلسٹر کے مجاز نیٹ ورکس یا فائر وال اجازت دیتے ہیں یا نہیں۔ نجی کلسٹر عموماً API ٹریفک صرف VNet یا peered رینجز سے قبول کرتے ہیں، اس لیے ایسا ٹنل جو دوسرے پول سے پتے دے، نیٹ ورک تہہ پر جڑتا ہے اور API پر خارج ہو جاتا ہے۔

ترقی دیتے وقت چار حقائق لکھیں: وہ ریزالور جو کلائنٹ نے استعمال کیا، وہ پتہ جو اس نے واپس کیا، منتخب kubeconfig سیاق میں سرور URL، اور پہلا عمل جو ناکام ہوا۔ وہ ریکارڈ اگلے انجینئر کو بتاتا ہے کہ DNS، روٹنگ یا فائر وال پالیسی بدلنی ہے یا نہیں، اور اگلی hosts فائل ترمیم روک دیتا ہے۔

تلاش سے شروع کریں، وہ ریزالور راستہ چنیں جو زون کے مالک سے مطابقت رکھتا ہو، پھر اینڈ پوائنٹ کی تصدیق کریں۔ اگر تینوں گزر جائیں تو باقی مسئلہ اجازت ہے، نام کا حل نہیں۔