Docker পোর্ট প্রকাশ ও VPN উৎস: যে দুটি মিল আপনি মিস করেন

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

ভ্রান্ত ধারণা: VPN সার্ভারকে অনুমতি দিন, কাজ শেষ

রাউটেড VPN ক্লায়েন্ট টানেল ঠিকানাটি Docker হোস্ট পর্যন্ত ধরে রাখতে পারে। যে গেটওয়ে উৎস অনুবাদ করে, সে ঠিকানাটি নিজের ঠিকানা দিয়ে বদলে দিতে পারে। দুটি নকশাই বৈধ, এবং একই ব্যবহারকারীর কাজের জন্য তারা আলাদা উৎস তৈরি করে।

তাই VPN সার্ভার IP বাক্যটি একটি অনুমান বোঝায়, পর্যবেক্ষণ নয়। আপনার সামনে দুই নকশার কোনটি আছে তা না জানা পর্যন্ত নিয়মটি একটি আন্দাজ।

উৎস: ক্লায়েন্ট পুল নাকি অনূদিত গেটওয়ে

চারটি বিষয় ক্রমানুসারে দেখুন। প্রথম, ক্লায়েন্ট ঠিকানা পুল, যেমন 10.90.0.0/24। দ্বিতীয়, গেটওয়ে সেই পুলটি হোস্টে পৌঁছানোর আগে অনুবাদ করে কি না। তৃতীয়, একটি নতুন সংযোগের জন্য হোস্ট আসলে যে উৎস দেখে। চতুর্থ, অ্যাপ্লিকেশন প্রমাণীকরণ পৃথক ব্যবহারকারীদের আলাদা করে কি না, কারণ একটি ভাগ করা অনূদিত ঠিকানা তা পারে না।

পুলটি ধরে রাখলে, কেবল গেটওয়ের সার্বজনীন ঠিকানার সঙ্গে মেলা নিয়ম প্রতিটি ক্লায়েন্টকে মিস করে। গেটওয়ে ইচ্ছাকৃতভাবে অনুবাদ করলে, অনূদিত ঠিকানাকে অনুমতি দিলে তার পেছনের প্রত্যেক ব্যবহারকারী ঢুকে পড়ে, যা নিজস্ব লগইনসহ সেবার জন্য গ্রহণযোগ্য হতে পারে আর অন্য কিছুর জন্য অগ্রহণযোগ্য।

পোর্ট: DNAT যে সংখ্যাটি মেলান সেটি বদলে দেয়

Docker iptables-সহ সাধারণ Linux ব্রিজ প্রকাশে, 8443 থেকে কনটেইনার পোর্ট 443-এ হোস্ট ম্যাপিং ফরওয়ার্ডিং ফিল্টার চলার আগেই অনূদিত হয়। প্যাকেটটি ফিল্টারে পৌঁছায় গন্তব্য পোর্ট 443 নিয়ে। সেই বিন্দুতে 8443-এর সঙ্গে মেলা নিয়ম কখনো কাজ করে না, যদিও ক্লায়েন্ট টাইপ করেছে 8443।

প্রকাশিত পোর্টটি এখনো সংযোগ ট্র্যাকিংয়ে থাকে, তাই সত্যিই দরকার হলে সেখানে মূল গন্তব্য মেলানো যায়।

কোন সংখ্যাটি উদ্দেশ্য প্রকাশ করে তা ঠিক করুন। নিয়মটি কনটেইনারের ভেতরের সেবা রক্ষা করলে DNAT-পরবর্তী কনটেইনার পোর্ট মেলান। নিয়মটিকে ক্লায়েন্ট কী চেয়েছে তা বর্ণনা করতে হলে conntrack অপশন দিয়ে মূল গন্তব্য মেলান, এবং তার সঙ্গে আসা অতিরিক্ত মেলানোর খরচ ও নিয়মের ক্রমের সতর্কতা মেনে নিন।

চেইন: INPUT নয়, DOCKER-USER

Docker-এর iptables নির্দেশিকা ব্যবহারকারীর ফরওয়ার্ডিং নীতি DOCKER-USER চেইনে রাখে, যা Docker-এর নিজস্ব ফরওয়ার্ডিং নিয়মের আগে মূল্যায়িত হয়। হোস্ট সেবা থেকে INPUT চেইনে কপি করা নিয়ম হোস্টে ঠিকানাকৃত ট্রাফিক ফিল্টার করে, কনটেইনারে ফরওয়ার্ড হওয়া ট্রাফিক নয়। এই ভুল এমন নিয়ম তৈরি করে যা ঠিক দেখায় কিন্তু কনটেইনারের পথে কোনো প্রভাব ফেলে না।

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

নতুন সংযোগ দিয়ে যাচাই করুন

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

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