Docker পোর্ট প্রকাশ বনাম VPN: উত্তরটি কোথায় যায়

ফুল-টানেল VPN চালু হওয়ার পরও হোস্ট SSH-এ উত্তর দিতে থাকে, অথচ একই মেশিনে Docker-প্রকাশিত একটি সার্ভিস চুপ হয়ে যায়। লিসেনারে কোনো দোষ নেই: কন্টেইনার চলছে, পোর্ট ম্যাপিং আছে, আর প্যাকেট এসে পৌঁছায়। কন্টেইনার সুস্থ এবং অনুরোধ সত্যিই তাতে পৌঁছায়। পার্থক্যটি হলো, Linux তার রুট বেছে নেওয়ার সময় উত্তরটি কোথা থেকে শুরু হয়, এবং সেই পার্থক্যই ঠিক করে নিচের দুটি নকশার মধ্যে আপনার কোনটি দরকার।

গন্তব্য NAT-এর মধ্য দিয়ে টাপলটি অনুসরণ করুন

ধরুন একটি হোস্ট 192.0.2.10 ঠিকানায় TCP 2222 পোর্টটি 172.30.240.5:22 ঠিকানার কন্টেইনারে প্রকাশ করছে। 198.51.100.25 থেকে আসা অনুরোধ কন্টেইনারে পৌঁছানোর আগেই রূপান্তরিত হয়, এবং কন্টেইনার নিজের পরিচয়ে উত্তর দেয়।

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

হোস্টের রুট সিদ্ধান্তের সময় উত্তরটি এখনও কন্টেইনারের উৎস ঠিকানা বহন করে। রিভার্স রূপান্তর পরে প্রকাশিত টাপলটি পুনরুদ্ধার করে, তাই ঠিক যে মুহূর্তে রুট বেছে নেওয়া হয় তখনই প্যাকেটটি ভুল দেখায়।

কেবল হোস্টের জন্য নিয়ম কেন এটি মিস করে

এমন নিয়ম যা কেবল 192.0.2.10 থেকে আসা প্যাকেটের জন্য WAN টেবিল বেছে নেয়, তা হোস্টের নিজস্ব ডেমনগুলি কভার করে এবং এই ফরওয়ার্ড করা উত্তরটি সম্পূর্ণ মিস করে। উত্তরের উৎস ঠিকানা হলো 172.30.240.5, হোস্ট নয়।

অতিরিক্ত সংশোধন হলো কন্টেইনার থেকে সবকিছু WAN দিয়ে রুট করা, যা কন্টেইনারের অসম্পর্কিত আউটবাউন্ড সংযোগগুলিকেও VPN থেকে মুক্ত করে। এটি আপনাকে চাওয়া নীতির চেয়ে ভিন্ন, এবং সাধারণত পরে কাউকে অবাক করে।

DNAT-পরবর্তী ম্যাচিং আলাদা হুক

Docker-এর ফায়ারওয়াল ডকুমেন্টেশন উল্লেখ করে যে সাধারণ ব্যবহারকারী ফিল্টারিং DNAT-পরবর্তী গন্তব্য দেখে, তাই একটি সাধারণ নিয়মে প্রকাশিত পোর্ট 2222 মেলানো আর কন্টেইনার পোর্ট 22 মেলানো এক নয়। যদি আসল টাপলটি গুরুত্বপূর্ণ হয়, তবে কোন পোর্ট দেখা যায় তা অনুমান না করে সমর্থিত মূল-গন্তব্য ব্যবস্থা ব্যবহার করুন।

এই হুক বিভ্রান্তি এমন নিয়ম তৈরি করে যা সঠিক দেখায় কিন্তু কখনও মেলে না। নীতি পুনর্লিখনের আগে নিয়মের নিজের কাউন্টার দেখুন। শূন্য হিটের নিয়ম আপনাকে বলে যে এটি এমন জায়গায় মূল্যায়ন হচ্ছে যেখানে প্যাকেট কখনও পৌঁছায় না।

নকশা A: সিদ্ধান্তটি সংযোগ-অবস্থা হিসেবে বহন করুন

একটি সংযোগ মার্ক রূপান্তরের মধ্য দিয়ে ইনগ্রেস সিদ্ধান্ত বহন করতে পারে, তবে গুরুত্বপূর্ণ রুট লুকআপের আগে তা প্যাকেটে পুনরুদ্ধার করতে হবে। ধাপগুলি হলো:

1. এমন একটি মার্ক ফিল্ড ও নিয়ম অগ্রাধিকার সংরক্ষণ করুন যা Docker, VPN বা অন্য নীতি-মালিকের সঙ্গে সংঘর্ষ করে না।
2. কেবল অভীষ্ট নতুন WAN সংযোগটি pre-DNAT পয়েন্টে চিহ্নিত করুন, যেখানে সংযোগ ট্র্যাকিং পাওয়া যায়।
3. মূল অনুরোধটিকে জোর করে WAN টেবিলে না পাঠিয়ে সিদ্ধান্তটি সংযোগ মার্কে লিখুন।
4. উত্তরমুখী দিকে রাউটিংয়ের আগে কেবল নিজের মার্ক বিটগুলি প্যাকেটে পুনরুদ্ধার করুন।
5. একটি সম্পূর্ণ WAN টেবিল যথেষ্ট আগে বেছে নিন যাতে VPN নিয়ম আগে জিততে না পারে।

সেই টেবিলে প্রকৃত কানেক্টেড রুট ও গেটওয়ে দরকার। রুট অনুপস্থিত থাকলে একটি নির্ধারিত আচরণও দরকার। টানেলে নীরব পতন সবচেয়ে খারাপ ফল, কারণ কনফিগারেশন তখনও কাজ করছে বলে মনে হয়। বরং ব্যর্থ হয়ে বন্ধ হোন এবং তা লগ করুন।

নকশা B: হোস্টে টার্মিনেট করুন

উদ্দেশ্যমূলকভাবে কনফিগার করা হোস্ট-সাইড ফ্রন্টএন্ড, যেমন একটি TCP প্রক্সি বা কন্টেইনারের সামনে রিভার্স প্রক্সি, উত্তরটি হোস্ট ঠিকানা থেকেই উৎপন্ন রাখে। তখন হোস্টের জন্য লেখা নিয়ম প্রত্যাশিতভাবে কাজ করে, আর কন্টেইনার তার প্রাইভেট নেটওয়ার্কেই থাকে।

খরচ হলো আরেকটি চলমান অংশ, যার নিজস্ব কনফিগারেশন, উৎস-ঠিকানা হ্যান্ডলিং ও অ্যাক্সেস নিয়ন্ত্রণ আছে। এটি সাধারণত সরলতর সমর্থিত সীমা, এবং রাউটিং নীতি যদি এমন একজন ব্যক্তি রক্ষণাবেক্ষণ করেন যিনি হয়তো চলে যেতে পারেন, তবে এটি প্রায়ই সঠিক উত্তর।

পরিবর্তন যাচাই করুন, অভিপ্রায় নয়

পাবলিক দিক থেকে একটি নতুন অনুমোদিত সংযোগ খুলুন এবং নিশ্চিত করুন উত্তরটি অভীষ্ট ইন্টারফেস দিয়ে বের হচ্ছে। তারপর দেখুন কন্টেইনার-উদ্ভূত একটি অসম্পর্কিত অনুরোধ এখনও VPN অনুসরণ করছে কি না।

একটি নিয়ম পরীক্ষা করতে মেশিনের সংযোগ টেবিল ফ্লাশ করবেন না: বিদ্যমান এন্ট্রিগুলি আগের ম্যাপিং ধরে রাখে, আর ফ্লাশ হোস্টের বাকি সবকিছু ভেঙে দেয়। পোর্ট প্রকাশ করা পৌঁছানোর ক্ষমতা নির্ধারণ করে। এটি উত্তরের পথ নির্ধারণ করে না। বেছে নেওয়া নকশাটি তার টেবিল নামসহ লিখে রাখুন, যাতে পরের ব্যক্তি কোনো ঘটনার সময় তা আবার আবিষ্কার করতে না হয়।