لماذا يعمل kubectl عبر VPN بينما يتوقّف AKS عن التوسّع

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

قائمة السماح تطابق عنوانًا لا شخصًا

--api-server-authorized-ip-ranges تقبل كتل CIDR، لا المستخدمين أو المجموعات. عندما يغادر طلب المطوّر خادم VPN نحو Azure، يكون عنوان المصدر عند خادم API هو مخرج خادم VPN العام. لذلك يشترك كل شخص على تلك الشبكة في مدخل واحد، ويُرفض أي شخص خارجها قبل أن تحدث المصادقة أصلًا.

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

أول ما ينكسر ليس kubectl عادةً

تنطبق قائمة السماح على نقطة النهاية العامة لخادم API، لذا يتوقف كل شيء خارج العناوين المدرجة لديك فورًا. الضحايا الواضحون هم المكتب الثاني بلا مسار VPN، وعامل CI في خط أنابيب مستضاف، وحاسوب محمول نسي الاتصال. وهؤلاء يسهل التعرف عليهم لأن إنسانًا ينتظر.

الحالة الأقل وضوحًا هي التشغيل الآلي الذي يقوده Azure أو أدواتك الخاصة. فبعض العمليات التي تُطلقها المنصة تصل إلى خادم API من عناوين ليست شبكة VPN الخاصة بك، وعندما يبدأ أحدها بالفشل مباشرة بعد تشديد القائمة، يكون التوقيت هو الدليل. لا تفترض أن القائمة كاملة لأن الوصول التفاعلي يعمل؛ تحقق مما تتطلبه الميزة في منطقتك واشتراكاتك قبل أن تستنتج أن العنقود معطوب.

بصمة الفشل تساعد. إذا لم يصل الطلب أبدًا إلى المصادقة، فالمرشّح هو السبب. وإذا صادق ثم حصل على خطأ صلاحيات، فقد أدى المرشّح عمله والمشكلة في التحكم بالوصول القائم على الأدوار، الذي لا تمسه قائمة السماح إطلاقًا.

ابنِ القائمة كاملة بأمر واحد

معامل التحديث يستبدل القائمة بأكملها بدلًا من إضافة مدخل، لذا فإن أمرًا يحمل عنوان VPN فقط يُسقط بصمت كل ما كان موجودًا. اقرأ القيمة الحالية أولًا، واحتفظ بها، ثم أرسل الاتحاد:

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

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

رتّب التغيير بحيث تكون أول محاولة مسموحة هي الاختبار نفسه. أعلن القائمة الجديدة، وطبّقها، واتصل من VPN فورًا؛ ففعل ذلك بالترتيب المعاكس يترك فترة لا يستطيع فيها أحد الوصول إلى خادم API لإصلاح خطأ مطبعي في كتلة CIDR.

ما لم تغطّه قائمة السماح أبدًا

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

لا علاقة لها بأحمال العمل. تظل Pods وServices تعمل مع تفعيل القائمة، و الوصول إلى تطبيق عبر VPN مشكلة منفصلة: فالخدمة التي تملك عنوان IP داخل العنقود فقط تحتاج إلى موازن تحميل داخلي أو ingress أو port-forward قبل أن يستطيع حاسوب محمول فتحها. وخلط التصميمين ينتج تذكرة تغيير تدّعي تقييد المطوّرين ولا تقيّد شيئًا فعليًا في التطبيقات.

تحقّق من الجانبين، ثم نفّذ عملية حقيقية واحدة

اختبر بعميل جديد على VPN وبعميل خارجها. ينبغي رفض المحاولة الخارجية عند خادم API، لا عند تحليل الاسم؛ إذا لم يُحلّ الاسم، فأنت تختبر DNS ولم تتعلّم شيئًا عن المرشّح. ثم نفّذ عملية ليست استدعاء kubectl تفاعليًا، مثل توسيع مجموعة عُقد أو فحص ترقية، وتأكد من اكتمالها بدلًا من افتراض ذلك.

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