Kubernetes-এ VPN ক্লায়েন্ট IP: এটি সংরক্ষণ করবেন নাকি SNAT করবেন?
Kubernetes-এ VPN ক্লায়েন্টের প্রকৃত ঠিকানা ও সোর্স NAT-এর মধ্যে তিনটি শর্তের ভিত্তিতে বেছে নিন, তারপর ফেরার পথ ও pod পরিবর্তন যাচাই করুন।
কোথাও টানেল ও backend-এর মধ্যে ক্লায়েন্টের ঠিকানা হয় টিকে থাকে নয় প্রতিস্থাপিত হয়, এবং দুটি ফলাফলই যুক্তিযুক্ত। পছন্দটি গ্রহণকারী সেবার মালিকের, CNI ইনস্টলকারীর নয়। যখন প্রতি-ক্লায়েন্ট অনুমোদন, কোটা বা অডিট রেকর্ড গুরুত্বপূর্ণ, তখন ঠিকানাকে প্রতিটি হপ পার হতে হবে। যখন ভাগ করা আরোপণ গ্রহণযোগ্য, তখন সোর্স NAT সেই রাউটিং সমস্যা সরিয়ে দেয় যা নাহলে আপনি চিরকাল রক্ষণাবেক্ষণ করতেন।
ঠিকানাটি আসলে কোথায় হারায়
একটি দূরবর্তী ক্লায়েন্টের প্যাকেট VPN pod-এ পৌঁছায় টানেল পরিসরের ভেতরের অভ্যন্তরীণ সোর্স নিয়ে, ধরা যাক 10.90.0.42। যখন pod সেই প্যাকেটটি ClusterIP বা pod IP-এর দিকে এগিয়ে পাঠায়, তখন তিনটি ভিন্ন প্রক্রিয়া সোর্স পুনরায় লিখতে পারে। নোডের CNI masquerade নিয়ম সেই ট্র্যাফিক ঢাকে যা pod ক্লাস্টার CIDR-এর বাইরে পাঠায়। গন্তব্য নোডে kube-proxy-এর conntrack এন্ট্রি নিজেই Service হপ ঢাকে। যে প্রক্সি সংযোগ শেষ করে সে প্যাকেট একেবারেই এগিয়ে পাঠায় না, তাই শেষে যে সোর্স দেখেন তা প্রক্সির।
এর প্রত্যেকটি ভিন্ন স্তরে থাকে, তাই একটি Service ফিল্ড প্রায় কখনোই পুরো পথ ঠিক করে না।
VPN-এর পাবলিক Service-এ externalTrafficPolicy কেবল বহিঃসংযোগের বিষয়ে সিদ্ধান্ত নেয়: Local দূরবর্তী ঠিকানাটি যে নোড পেয়েছে সেখানে রাখে, অন্যদিকে Cluster kube-proxy-কে প্যাকেটটি অন্য নোডে দিতে এবং সেখানে masquerade করতে দেয়। সেই সেটিং আপনার ক্লায়েন্টরা যে লিসেনারে সংযোগ করে তা নিয়ন্ত্রণ করে। এটি আপনার VPN প্রক্রিয়া পরে ক্লাস্টারে পাঠায় এমন ডিক্রিপ্ট করা প্যাকেট সম্পর্কে কিছুই বলে না।
তিনটি শর্ত যা বিতর্ক নিষ্পত্তি করে
এই বিষয়টি এলেই আমি একই তিনটি প্রশ্ন একই ক্রমে করি, কারণ প্রথমটি সাধারণত আলোচনা শেষ করে। এগুলোর উত্তর নির্দিষ্ট ওয়ার্কলোডের জন্য দিন, পুরো ক্লাস্টারের জন্য নয়। একই কোম্পানির দুই ক্লাস্টার ভিন্ন উত্তরে পৌঁছাতে পারে এবং দুটিই সঠিক হতে পারে।
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
যদি backend প্রথম প্রশ্নের উত্তর হ্যাঁ এবং দ্বিতীয়টির না দেয়, তাহলে আপনার নেটওয়ার্কের কাজ আছে, manifest সম্পাদনার নয়। যদি তৃতীয় সারি প্রক্সি বলে, তাহলে ঠিকানা কখনোই টিকত না, আর উল্টো দাবি করতে এক সপ্তাহের প্যাকেট ক্যাপচার লাগে।
preserve মোড নেটওয়ার্কের কাছে কী দাবি করে
সোর্স সংরক্ষণ মানে গন্তব্য নোডকে ট্র্যাফিক সক্রিয় VPN গেটওয়ের মাধ্যমে 10.90.0.42-এ ফেরত পাঠাতে হবে। VPN পুল ক্লাস্টার CIDR নয়, তাই কোনো CNI এটি আপনার হয়ে ডিফল্টভাবে রাউট করে না। আপনি নিজেই রুট যোগ করেন এবং তারপর নিশ্চিত হন যে গেটওয়ের যে প্রান্তবিন্দুতে এটি ইঙ্গিত করে তা পুনঃনির্ধারণ থেকে টিকে যায়।
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2সেই পরবর্তী হপ হলো pod-এর ঠিকানা, আর pod-এর ঠিকানা নড়াচড়া করে। রুটটি Service VIP বা জায়গায় থাকা নোড ঠিকানার দিকে ঘোরান, অথবা মেনে নিন প্রতিটি উচ্ছেদের পর আপনি গেটওয়ের পেছনে ছুটবেন। উল্টো পথের ফিল্টারিং আরেকটি ফাঁদ: কঠোর মোড সেই প্যাকেট ফেলে দেয় যাদের ফেরার পথ যে ইন্টারফেস দিয়ে এসেছে তার সঙ্গে মেলে না, এবং এটি ঠিক সংরক্ষিত VPN প্রবাহের আকার।
ঢিলা যাচাই প্রায়ই কার্যকর ফেরার পথ আর backend ছাড়ার পর হারিয়ে যাওয়া উত্তরগুলোর মধ্যে পার্থক্য। VPN নোডের masquerade নিয়মগুলোকে টানেল পরিসরও বাদ দিতে হবে, নাহলে এগিয়ে পাঠানো প্যাকেট pod-এর ঠিকানা নিয়ে বেরোবে, আপনি যে রুটই তৈরি করুন না কেন। এই ব্যতিক্রমটি iptables হাতে সম্পাদনা করার বদলে CNI-এর নিজস্ব কনফিগারেশনে প্রকাশ করুন, কারণ এজেন্ট পুনরায় চালু হলে তার চেইন আবার লেখে এবং আপনার হাতে লেখা নিয়ম ঠিক পরবর্তী আপগ্রেড পর্যন্ত টেকে।
NetworkPolicy হলো অ্যাক্সেস নিয়ন্ত্রণ, রাউটিং নয়। কোনো নীতি কঠোর করলে masquerade যে ঠিকানা ইতিমধ্যে বদলে দিয়েছে তা কখনোই পুনরুদ্ধার হবে না।
SNAT-এর কী খরচ, এবং এটি কীভাবে লিখবেন
ক্লাস্টারের দিকে সোর্স NAT সস্তা নকশা, এবং এটি ভুল নয়। backend VPN pod বা নোডের ঠিকানা দেখে, লগগুলো পরস্পরের সঙ্গে মেলে, এবং কোনো ফেরার রুট থাকা আবশ্যক নয়। আপনি যা হারান তা হলো নেটওয়ার্ক স্তরে দুই ক্লায়েন্টকে আলাদা করার ক্ষমতা, তাই কোটা, নিষেধাজ্ঞা ও অডিট চিহ্ন অন্য জায়গা থেকে আসতে হবে।
সাধারণত সেই অন্য জায়গাটি হলো অ্যাপ্লিকেশন: সেশন টোকেন, স্বাক্ষরিত হেডার, বা PROXY প্রোটোকলের লাইন যা আপনার নিয়ন্ত্রণাধীন প্রক্সি লেখে। এগুলো গ্রহীতাকে এমন পরিচয় দেয় যাতে সে কেবল তখনই ভরসা করতে পারে যখন প্রক্সি পথে থাকে এবং হেডার ক্লায়েন্টের দিক থেকে সেট করা যায় না। runbook-এ স্পষ্ট করুন কোনটি প্রযোজ্য, কারণ পরবর্তী ইঞ্জিনিয়ার ধরে নেবে লগে দেওয়া ঠিকানাই ক্লায়েন্ট। তা নয়, এবং একটি ঘটনাই সেই অনুমানকে ব্যয়বহুল করতে যথেষ্ট।
বিনিময়টি লেখা থাকা পর্যন্ত সৎ থাকে।
যে যাচাই কার্যকর পথকে ভাগ্যবান পথ থেকে আলাদা করে
তাজা সংযোগ দিয়ে পরীক্ষা করুন, ক্যাশ করা সংযোগ দিয়ে নয়, এবং দুই দিকেই পরীক্ষা করুন। কয়েকটি ব্যর্থতা কেবল তখনই বিরতিহীন মনে হয় যখন নতুন প্রবাহ পুনর্লিখিত পথ নেয়।
একটি অনুমোদিত অনুরোধের সময় tuple তিনটি বিন্দুতে ধরুন: ডিক্রিপশনের পরপরই, VPN pod-এর নির্গমন ইন্টারফেসে, এবং backend-এ। যদি সোর্স দ্বিতীয় ও তৃতীয় ধরার মধ্যে বদলায়, কারণটি pod-এর নিচে। যদি দ্বিতীয়টির আগে বদলায়, pod নিজেই অনুবাদ করছে।
তারপর VPN pod মুছুন এবং পুনঃনির্ধারণের সময় পরীক্ষাটি পুনরাবৃত্তি করুন। সংরক্ষিত পথ যা উচ্ছেদে ভেঙে যায় তা অসম্পূর্ণ, এবং যে NAT নিয়ম এমন ঠিকানায় পিন করা যা আর নেই তাও। শেষে এমন উৎস থেকে একটি অনুরোধ পাঠান যার প্রত্যাখ্যান প্রত্যাশা করেন এবং নিশ্চিত করুন প্রত্যাখ্যান নীতি থেকে আসে, কোনো অনুপস্থিত রুট থেকে নয়।