হোস্ট IPsec সহকর্মীর কাছে পৌঁছায়, Docker কন্টেইনার পৌঁছায় না
ব্রিজ কন্টেইনার অন্য উৎস ব্যবহার করে এবং ফরওয়ার্ডিং দিয়ে ঢোকে, তাই হোস্টের টানেল বেশি কিছু প্রমাণ করে না। Docker পুনরায় চালু করার আগে সিলেক্টরগুলি যাচাই করুন।
আপনি Linux মেশিন থেকে দূরবর্তী হোস্টে ping করেন এবং সেটি সাড়া দেয়, অর্থাৎ টানেল কাজ করছে। পাশের কন্টেইনারটি এখনও সময় শেষে আটকে যায়, আর পরবর্তী স্বাভাবিক ধাপ হল Docker পুনরায় চালু করা। ব্রিজ নেটওয়ার্কের কন্টেইনার সাধারণত অন্য একটি উৎস ঠিকানা দিয়ে শুরু হয় এবং হোস্টে অ্যাপ্লিকেশনের নিজস্ব প্রস্থান পথের বদলে ফরওয়ার্ডিং দিয়ে ঢোকে, তাই সফল পরীক্ষাটি অন্য একটি প্যাকেট মেপেছে। নীতি-ভিত্তিক strongSwan টানেলের জন্য দূরবর্তী সাবনেটের দিকে সাধারণ রুট যথেষ্ট নয় যখন ফরওয়ার্ড করা প্যাকেট ইনস্টল করা IPsec নীতির সঙ্গে মেলে না।
নিচের নির্দেশিকাটি একটি গন্তব্যকে দুই উৎসের মধ্যে দিয়ে অনুসরণ করে এবং কিছু বদলানোর আগে অবস্থা পড়ে।
একটি গন্তব্য ও দুই উৎস দিয়ে শুরু করুন
প্রথমে IP দিয়ে পরিচিত একটি সেবা বেছে নিন, যাতে একই সঙ্গে DNS ঠিক না করতে হয়। তিনটি তথ্য লিখুন: কন্টেইনারের ব্রিজ প্রিফিক্স, সফল হোস্ট অনুরোধের উৎস ঠিকানা, এবং টানেলের জন্য সম্মত স্থানীয় ও দূরবর্তী ট্রাফিক সিলেক্টর। এই তিনটি সংখ্যা এই লক্ষণের প্রায় প্রতিটি ক্ষেত্রেই ব্যাখ্যা দেয়।
তারপর ব্যর্থ অনুরোধটি কন্টেইনারের ভেতর থেকে পুনরাবৃত্তি করুন এবং যে উৎসটি সত্যিই ব্যবহার হয় তা ধরে নিন। যদি সেই ঠিকানা স্থানীয় সিলেক্টরে ঢাকা না পড়ে, ফলাফল আপনি আগেই জানেন, এবং কন্টেইনার নতুন করে বানালে তা বদলাবে না।
Docker স্পর্শ করার আগে নীতিগুলি পড়ুন
শুধু-পড়ার হোস্ট যাচাই রাউটিং সিদ্ধান্ত, নীতি ডেটাবেস এবং তাদের মধ্যে বাছাই করা নিয়মগুলি ঢেকে রাখে:
ip rule show
ip route show table all
ip xfrm policyনীতি তালিকা সিলেক্টর ও অভিমুখ দেখায়, কী উপাদানে ভরা IPsec অবস্থার ডাম্প ছাড়াই, তাই এটি টিকিটে আটকানো নিরাপদ। এমন স্থানীয় সিলেক্টর খুঁজুন যা হোস্ট ঠিকানা ঢাকে কিন্তু ব্রিজ প্রিফিক্স ঢাকে না। ওভারল্যাপও দেখুন: দূরবর্তী গন্তব্যকে স্থানীয় ধরা কন্টেইনার রুট কখনও প্রত্যাশিত ফরওয়ার্ড করা প্যাকেট তৈরি করবে না, আর দোষ টানেলের উপর চাপে। ওই তালিকাটি কন্টেইনারের উৎস ঠিকানার পাশে রাখুন, কারণ দুটি মিলেই পুরো তুলনা।
যদি কন্টেইনার প্রিফিক্স না থাকে, থামুন এবং অন্য কিছু সম্পাদনার আগে স্থাপত্য ঠিক করুন। বাকি নির্দেশিকা ধরে নেয় যে আপনারা ঠিক করেছেন কোন উৎস ঠিকানা নেটওয়ার্কে দেখা উচিত।
ফিল্টারিং ও অনুবাদ ক্রমানুসারে যাচাই করুন
Docker-এর Linux ব্রিজ ফায়ারওয়াল IPsec থেকে স্বাধীনভাবে ফরওয়ার্ডিং আটকাতে পারে। iptables ব্যাকএন্ডে FORWARD পথ এবং DOCKER-USER সিদ্ধান্ত দেখুন, মনে রাখুন আগের রায়ের পরে যোগ করা নিয়ম হয়তো কখনও চলবে না। nftables ব্যাকএন্ড ভিন্নভাবে একীভূত হয়, তাই শুধু এই কারণে DOCKER-USER চেইন বানাবেন না যে কোনো iptables উদাহরণ এটিকে ওই নাম দিয়েছে; দেখুন আপনার daemon আসলে কোন ব্যাকএন্ড ব্যবহার করে।
তারপর উৎস অনুবাদ যাচাই করুন। বিস্তৃত MASQUERADE নিয়ম এমন প্যাকেটকে, যা আগে IPsec সিলেক্টরের সঙ্গে মিলত, এমন প্যাকেটে বদলে দিতে পারে যা আর মেলে না, আর ব্যর্থতা দেখতে ঠিক রাউটিং সমস্যার মতো। strongSwan ফরওয়ার্ডিং নির্দেশিকা এমন অনুবাদের আগে প্রয়োজনীয় NAT ব্যতিক্রমের নথিভুক্ত করে, সেই ট্রাফিকের জন্য যা আগেই নীতির সঙ্গে মেলে।
ওই ব্যতিক্রম টানেলে অনাবৃত কন্টেইনার উৎস যোগ করার উপায় নয়। এটি কেবল সেই ট্রাফিক রক্ষা করে যা আগেই নকশার সঙ্গে খাপ খায়, তাই আগে সিলেক্টর ও ফেরার পথের প্রশ্ন নিষ্পত্তি করুন, তারপর NAT ও ফিল্টারিংকে উত্তরের সঙ্গে মিলিয়ে দিন। যদি ব্যতিক্রমটাই বাড়াতে শুরু করেন, তবে বদলানোর জিনিস সিলেক্টর, NAT নিয়ম নয়।
তারপর ঠিক করুন রাউটেড না অনূদিত
রাউটেড কন্টেইনার সাবনেটের জন্য দরকার দুই সহকর্মীই সেই সাবনেট গ্রহণ করবে এবং সেখানে দূরবর্তী ফেরার পথ থাকবে, যার সাধারণ অর্থ দুই প্রান্তে সিলেক্টর বদল এবং দূরবর্তী পক্ষের মালিকের সঙ্গে আলোচনা। ইচ্ছাকৃতভাবে অনূদিত নকশাকে বদলে সংশ্লিষ্ট লুকআপ ধাপে নীতি-আচ্ছাদিত ঠিকানা উপস্থাপন করতে হয়, যার সাধারণ অর্থ ডিফল্ট MASQUERADE-এর বদলে সংকীর্ণ ও নথিভুক্ত নিয়ম।
এই দুই বিন্যাসের কোনওটিই হোস্টের কাজ করা টানেল থেকে নিজে থেকে আসে না, আর এদের মধ্যে বাছাই মালিকসহ নকশা সিদ্ধান্ত। কোনটি বেছেছেন লিখুন, নইলে পরের প্রকৌশলী এটি আবার ফায়ারওয়াল কাউন্টার থেকে বের করবেন।
মিশ্র ব্যর্থতাও লক্ষ্য করুন: নিয়মসমূহের অর্ধেক অনূদিত আর অর্ধেক নয়, যা থেমে থেমে সাফল্য দেয় যা গন্তব্য পোর্টের উপর নির্ভর করে, নেটওয়ার্কের কোনো কিছুতে নয়।
নতুন সংযোগ দিয়ে যাচাই করুন, পুনরায় চালু দিয়ে নয়
নতুন অ্যাপ্লিকেশন সংযোগ ব্যবহার করুন এবং একই সঙ্গে সংকীর্ণ ফায়ারওয়াল কাউন্টার ও দূরবর্তী গ্রাহক দেখুন, যাতে প্রতিটি পর্যবেক্ষণের উৎস থাকে। Docker পুনরায় চালু করলে নিয়মের অবস্থা বদলাতে পারে এবং কাজের ভারও ব্যাহত হবে, যা আপনার কাঙ্ক্ষিত পরিষ্কার সংকেত কেড়ে নেয়।
টেকসই ফলাফল চারটি বিবৃতি যা আপনি দেখাতে পারেন: কন্টেইনারের উৎস, মিলে যাওয়া সুরক্ষিত পথ, অনুমোদিত ফরওয়ার্ডিং, এবং ফিরে আসা উত্তর। চারটিই যখন খাটে, কন্টেইনার যে কারণে হোস্ট পৌঁছায় সেই একই কারণে সহকর্মীর কাছে পৌঁছায়।