kubectl لا يستطيع تحليل واجهة API للعنقود الخاص عبر OpenVPN

يفشل kubectl عند البحث عن الاسم بينما النفق قائم وعنوان API الخاص لا يزال يستجيب للـ ping. المسار سليم؛ العميل يسأل محلّلاً لم يسمع قط بالنطاق الخاص للعنقود. أكثر إصلاحين استخداماً: دفع محلّل الشبكة الظاهرية إلى كل عميل VPN، أو تثبيت الاسم محلياً عبر إدخال hosts أو مُمرِّر شرطي. يحلّان العَرَض نفسه بمسؤولية مختلفة، وخلطهما هو ما يجعل الفرق تعدّل ملفات hosts في كل مرة يُعاد فيها بناء نقطة نهاية.

التحليل وإمكانية الوصول يفشلان في طبقتين مختلفتين

نفّذ البحث بنفسك قبل تغيير أي شيء. يخبرك getent hosts على Linux أو nslookup على Windows ما إذا كان العميل يحصل على إجابة أصلاً؛ انتهاء المهلة أو 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 لتلك الشبكة. إذا انتهت مهلة البحث بعد الدفع، فافحص سجلات المحلّل نفسه قبل لمس العميل مرة أخرى.

على العميل، تحقق مما طُبّق: resolvectl status على Linux مع systemd-resolved، و scutil --dns على macOS، و ipconfig /all على Windows. خادم DNS مدفوع لا يظهر أبداً يعني أن الملف الشخصي لم يُعد تحميله.

الخيار B: إدخالات hosts والتمرير الشرطي

إدخال hosts هو أصغر إصلاح ممكن وأكثره هشاشة. يربط اسماً واحداً بعنوان واحد على جهاز واحد، لذا يصلح لعرض تجريبي ويتعطّل عند إعادة بناء نقطة النهاية الخاصة أو عنوان IP الخاص بها. كما يخفي الفجوة الحقيقية عن بقية الفريق.

المُمرِّر الشرطي يتوسّع بشكل أفضل دون دفع DNS إلى كل عميل. يمكن لـ dnsmasq إرسال نطاق واحد إلى محلّل VNet وترك كل شيء آخر بسلام: server=/cluster.internal/10.0.0.4. يمتلك DNS في Windows مُمرِّرات شرطية، ويمكن لعملاء 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 أو من نطاقات الاقتران فقط، لذا فإن نفقاً يوزّع عناوين من تجمّع آخر يتصل على طبقة الشبكة ويُسقط عند API.

سجّل أربع حقائق عند التصعيد: المحلّل الذي استخدمه العميل، والعنوان الذي أعاده، وعنوان URL للخادم في سياق kubeconfig المحدد، وأول عملية فشلت. يخبر ذلك السجل المهندس التالي ما إذا كان يجب تغيير DNS أو التوجيه أو سياسة جدار الحماية، ويمنع تعديل ملف hosts التالي.

ابدأ بالبحث، واختر مسار المحلّل الذي يطابق مالك النطاق، ثم تحقق من نقطة النهاية. إذا نجحت الثلاثة، فالمشكلة المتبقية هي التفويض، لا تحليل الأسماء.