kubectl VPN پر کیوں کام کرتا ہے مگر AKS اسکیلنگ کیوں روک دیتا ہے

آپ دفتر کے VPN کا عوامی پتہ AKS API سرور کی اجازت یافتہ فہرست میں شامل کرتے ہیں، اور kubectl کام کرتا ہے۔ ایک ہفتے بعد node pool کی اسکیلنگ ناکام ہو جاتی ہے، کوئی CI کام کلسٹر تک نہیں پہنچ سکتا، اور پورٹل ایسی غلطی دکھاتا ہے جس میں IP رینجز کا کوئی ذکر نہیں۔ اجازت یافتہ فہرست کسی نے تبدیل نہیں کی۔ آپ نے جو کنٹرول فعال کیا وہ API سرور کے سامنے ایک عوامی IP فلٹر ہے، اور یہ نہیں جانتا کہ کون کال کر رہا ہے، صرف یہ جانتا ہے کہ کال کس پتے سے آئی۔ VPN کلسٹر کو درکار کئی پتوں میں سے ایک ہے، اور پہلے ٹوٹنے والا وہی ہو، یہ کم ہی ہوتا ہے۔

اجازت یافتہ فہرست پتے سے میل کھاتی ہے، شخص سے نہیں

--api-server-authorized-ip-ranges یہ CIDR بلاک وصول کرتی ہے، صارفین یا گروہ نہیں۔ جب ڈویلپر کی درخواست VPN سرور چھوڑ کر Azure کی طرف جاتی ہے، تو API سرور پر ماخذ پتہ VPN سرور کا عوامی اخراج ہوتا ہے۔ اسی لیے اُس VPN پر ہر شخص ایک ہی اندراج ساجھا کرتا ہے، اور 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

اس پر انحصار کرنے سے پہلے VPN سرور کے لیے محفوظ عوامی IP استعمال کریں۔ متحرک پتہ دوبارہ جڑنے پر بدلتا ہے، اور ہر تبدیلی ٹیم کو خاموشی سے کلسٹر سے باہر بند کر دیتی ہے جب تک کوئی اب بھی اجازت یافتہ نیٹ ورک سے فہرست اپ ڈیٹ نہ کرے۔ اگر فالتو پن کے لیے دو VPN اخراجی مقامات ہوں تو دونوں درج کریں، کیونکہ فلٹر میں ترجیحی راستے کا کوئی تصور نہیں۔

تبدیلی کو ایسے ترتیب دیں کہ پہلی اجازت یافتہ کوشش ہی جانچ ہو۔ نئی فہرست کا اعلان کریں، اسے لاگو کریں، اور فوراً VPN سے جڑیں؛ اُلٹ ترتیب میں کرنے سے وہ وقفہ رہ جاتا ہے جب کوئی CIDR بلاک میں ٹائپو درست کرنے کے لیے API سرور تک نہیں پہنچ سکتا۔

اجازت یافتہ فہرست نے کبھی کیا نہیں ڈھکا

یہ API سرور کو نجی نہیں بناتی۔ نجی کلسٹر نجی اینڈ پوائنٹ اور نجی DNS استعمال کرتا ہے، اور اجازت یافتہ رینجز کی فہرست وہ کنٹرول نہیں جو اس کی جگہ لے۔ یہ یہ بھی نہیں بدلتی کہ اندر لیے گئے کال کرنے والے کیا کر سکتے ہیں، اس لیے لیک ہوا ایڈمن kubeconfig اب بھی کسی بھی اجازت یافتہ پتے سے کام کرتا ہے۔ اسناد کو حفاظتی حد اور فہرست کو نیٹ ورک سہولت سمجھیں۔

اس کا ورک لوڈ سے کوئی تعلق نہیں۔ فہرست فعال ہونے پر بھی Pods اور Services چلتے رہتے ہیں، اور VPN کے ذریعے کسی ایپلیکیشن تک پہنچنا الگ مسئلہ ہے: جس Service کے پاس صرف کلسٹر IP ہے، لیپ ٹاپ کے کھول سکنے سے پہلے اسے اب بھی اندرونی لوڈ بیلنسر، ingress یا port-forward درکار ہے۔ ان دو ڈیزائنوں کو ملانے سے ایسا تبدیلی ٹکٹ بنتا ہے جو ڈویلپرز کو محدود کرنے کا دعویٰ کرتا ہے اور درحقیقت ایپلیکیشنز کے بارے میں کچھ بھی محدود نہیں کرتا۔

دونوں طرف سے تصدیق کریں، پھر ایک حقیقی کارروائی چلائیں

VPN پر نئے کلائنٹ اور اس کے باہر کے کلائنٹ سے جانچیں۔ باہر کی کوشش نام کی تحلیل پر نہیں، API سرور پر مسترد ہونی چاہیے؛ اگر نام حل نہ ہو، تو آپ DNS جانچ رہے ہیں اور فلٹر کے بارے میں کچھ نہیں سیکھا۔ پھر ایسی کارروائی چلائیں جو متقابل kubectl کال نہ ہو، مثلاً node pool اسکیلنگ یا اپ گریڈ جانچ، اور ہو جائے گا فرض کرنے کے بجائے مکمل ہونے کی تصدیق کریں۔

تبدیلی کے پاس پچھلی فہرست کی قدر درج رکھیں، اور ٹائپ کی گئی کمان پر بھروسا کرنے کے بجائے اپ ڈیٹ کے بعد مؤثر قدر دوبارہ پڑھیں۔ AKS کی اجازت یافتہ IP رینجز سے متعلق دستاویز معاون پیرامیٹرز اور اسی فہرست میں آنے والی پلیٹ فارم ضروریات کی فہرست دیتی ہے، اور یہی وہ حصہ ہے جو زیادہ تر ٹکٹ تفصیلات چھوڑ دیتی ہیں۔