GKE پوڈز VPN کے ذریعے مقامی میزبانوں تک کیوں نہیں پہنچتے

پنگ نوڈ سے چلتی ہے اور پوڈ سے ناکام ہوتی ہے، اور مقامی طرف کچھ نہیں پہنچتا۔ ٹنل اور راستہ درست ہیں؛ تار پر موجود ماخذ پتہ درست نہیں۔ ان دو صورتوں کا فرق یہ ہے کہ پیکٹ کلسٹر چھوڑتے وقت اپنے آپ کو کیا کہتا ہے، اور GKE کا اس بارے میں اپنا موقف ہے۔ طریقہ کار masquerade استثناؤں کی فہرست ہے، اور اسے پڑھنے کے لیے ایک ہی حکم کافی ہے۔

کچھ بدلنے سے پہلے نافذ فہرست پڑھیں

GKE ایک ایجنٹ فراہم کرتا ہے جو ہر منزل کی حد کے لیے فیصلہ کرتا ہے کہ پوڈ کی ٹریفک باہر جاتے وقت نوڈ کے پتے پر دوبارہ لکھی جائے گی یا نہیں۔ اس کی فراہم کردہ ترتیب تین RFC1918 بلاکس، 10.0.0.0/8, 172.16.0.0/12 اور 192.168.0.0/16, کو مستثنیٰ منزلیں قرار دیتی ہے۔ اس لیے پوڈ سے مقامی 10.x میزبان تک بھیجا گیا ہر چیز نوڈ سے پوڈ کے اپنے پتے کے ساتھ ہی نکلتی ہے۔ خود نوڈ کی ٹریفک دوبارہ نہیں لکھی جاتی، اور اسی وجہ سے اس کی پنگ چلتی ہے۔

مطلوبہ ترتیب اور نصب شدہ قواعد پڑھیں، کیونکہ وہ مختلف ہو سکتے ہیں۔ kubectl -n kube-system get configmap ip-masq-agent -o yaml دکھاتا ہے کہ ایجنٹ سے کیا کہا گیا، اور kubectl -n kube-system get pods -l k8s-app=ip-masq-agent دکھاتا ہے کہ اسے لاگو کرنے کے لیے کچھ چل رہا ہے یا نہیں۔ نوڈ پر iptables-save | grep -i masq وہ قواعد دکھاتا ہے جو کرنل میں واقعی موجود ہیں۔ جب ConfigMap ایک بات کہے اور قواعد دوسری، تو مشتبہ نیٹ ورک نہیں، ایجنٹ ہے۔

کیپچر سے ماخذ پتے کی تصدیق کریں

فہرست بدلنے سے پہلے کیپچر کریں۔ ایک ہی منزل پر فلٹر آؤٹ پٹ کو پڑھنے کے قابل رکھتا ہے: tcpdump -ni any host 10.20.30.40۔

اس کا موازنہ دوسری طرف کی رپورٹ سے کریں۔ مقامی طرف کا کیپچر جو پوڈ کا پتہ دکھائے اور کوئی جواب نہ ہو، دائرہ بند کر دیتا ہے: استثنائی فہرست ٹنل کی کسی خرابی کے بغیر عدم توازن کی وضاحت کرتی ہے۔ ایک ہی ماخذ پتے کے دو مشاہدے CNI کے بارے میں اندازہ لگانا چھوڑنے کے لیے کافی ہیں۔

استثنا کو پوڈ CIDR تک محدود کریں

معاون مرمت استثنا کو ہٹانے کے بجائے محدود کرتی ہے: پوڈ CIDR کو مستثنیٰ رکھیں اور 10.x جگہ کا باقی حصہ چھوڑ دیں۔ وہ فہرست ایجنٹ کے ConfigMap میں nonMasqueradeCIDRs کے تحت ہے، اور اسے بدلنا ایک ترمیم ہے جس کے بعد رول آؤٹ آتا ہے۔ چوڑی اندراج کو کلسٹر کی اصل پوڈ رینج سے بدلیں، کلسٹر کے اندرونی ٹریفک کو اگر اب بھی ضرورت ہو تو دیگر نجی بلاکس رکھیں، اور بغیر وجہ کے resyncInterval کو نہ چھیڑیں۔ لاگو کریں، تصدیق کریں کہ ایجنٹ کے پوڈ دوبارہ شروع ہوئے اور تصدیق کریں کہ کرنل کے قواعد بدلے۔

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

متعدد نوڈ پولز والے کلسٹر میں جانچیں کہ ایجنٹ ان نوڈز پر مقرر ہے جہاں متاثرہ پوڈ واقعی چلتے ہیں۔ DaemonSet کے بغیر پول اپنے پرانے قواعد رکھتا ہے، اور ConfigMap میں اسے دکھانے والا کچھ نہیں ہوگا۔

متبادل اور اس کی قیمت

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

سودا پڑھنے کی صلاحیت بمقابلہ دائرہ ہے۔ ترجمہ مقامی طرف کو فی نوڈ ایک پتہ دکھاتا ہے، جو اجازت فہرست میں ڈالنا آسان ہے اور یہ چھپاتا ہے کہ کون سا پوڈ کیا بھیجتا ہے۔ ترجمہ نہ کرنے سے پوڈ کا پتہ سرے سے سرے تک برقرار رہتا ہے، جو انتساب کے لیے بہتر اور نئی رینج سیکھنے والے راستے کے ہر آلے کے لیے بدتر ہے۔ کوئی بھی آپشن Docker یا CNI کی خرابی نہیں؛ دونوں آپریشنل بل والے روٹنگ فیصلے ہیں۔ وہ چنیں جس کا بل آپ کی ٹیم ادا کر سکے، اور کیوں لکھیں۔

تصدیق کریں اور واپس لائیں

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

پھر مخالف سمت جانچیں، کیونکہ ان تبدیلیوں میں سے نصف صرف باہر کی طرف تصدیق ہوتی ہیں۔ تصدیق کریں کہ جواب اس نوڈ یا پوڈ تک پہنچتا ہے جس نے درخواست بھیجی، اور تصدیق کریں کہ ایپلیکیشن نے صرف SYN لینے کے بجائے مکمل کیا۔ بغیر جواب کے درخواست دکھانے والا کیپچر دوسری طرف کا روٹنگ مسئلہ ہے، اس طرف کا masquerade مسئلہ نہیں۔

واپس لانا پچھلا ConfigMap ہے، اسی طرح لاگو، اسی تصدیق کے ساتھ کہ ایجنٹ دوبارہ شروع ہوا اور قواعد بدلے۔ تبدیلی ریکارڈ میں ایک معلوم درخواست کا ماخذ پتہ پہلے اور بعد رکھیں، کیونکہ وہی ایک سطر ثابت کرتی ہے کہ تبدیلی نے وہ کیا جو آپ نے کہا۔ GKE IP masquerade ایجنٹ گائیڈ ڈیفالٹ اور ConfigMap فیلڈز کی دستاویز کرتی ہے۔ اگر رول آؤٹ کے بعد ماخذ پتہ نہ بدلے تو اس نوڈ پر ایجنٹ نہیں چل رہا اور کتنی ہی YAML ترمیم اسے ٹھیک نہیں کرے گی۔