কেন 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 সম্পাদনাই তা ঠিক করবে না।