Docker কেন UFW বাইপাস করে এবং কীভাবে এটি সমাধান করবেন

কেন Docker UFW-কে এড়িয়ে যায়

Docker UFW-কে এড়িয়ে যায় কারণ প্রকাশিত কন্টেইনার পোর্টগুলো UFW-এর পরিচালিত ফায়ারওয়াল রুলগুলোর মধ্য দিয়ে যায় না। আপনি যখন docker run -p 8080:80 চালান, তখন Docker কার্নেলের nat টেবিলের PREROUTING চেইনে একটি DNAT (destination network address translation) রুল লিখে দেয়। কার্নেল প্যাকেটটি কোথায় যাবে তা সিদ্ধান্ত নেওয়ার আগেই সেই রুলটি প্রতিটি প্যাকেটের গন্তব্য পরিবর্তন করে কন্টেইনারের প্রাইভেট ঠিকানায় পাঠিয়ে দেয়। এরপর পরিবর্তিত প্যাকেটটি FORWARD চেইনের মাধ্যমে কন্টেইনারে ফরোয়ার্ড করা হয়, যা Docker নিয়ন্ত্রণ করে। UFW-এর রুলগুলো INPUT চেইনে থাকে, তাই প্যাকেটটি কখনোই সেখানে পৌঁছায় না। ফলে ufw status ডিফল্ট ডিনাই দেখালেও, sudo ufw deny 8080 সফল হওয়ার রিপোর্ট দেয় এবং পোর্ট 8080 পুরো ইন্টারনেটের জন্য উন্মুক্ত থাকে।

এটি Docker-এর কোনো বাগ নয় এবং UFW-ও নষ্ট নয়। উভয় টুলই একই কার্নেল ফায়ারওয়াল প্রোগ্রাম করে। Docker-এর রুলগুলো প্যাকেটের যাত্রাপথের অনেক আগেই কাজ শুরু করে, তাই UFW-এর কাছে কোনো অনুরোধই পৌঁছায় না। এই নির্দেশিকাটি কীভাবে এই বাইপাস ঘটে তা প্রদর্শন করে, এর কার্যপদ্ধতি ব্যাখ্যা করে এবং কার্যকর দুটি সমাধান তুলে ধরে: 127.0.0.1-এ পোর্ট পাবলিশ করা এবং DOCKER-USER চেইনে ফিল্টারিং করা। আপনি যদি UFW-এর সাথে নতুন পরিচিত হন, তবে প্রথমে UFW ফায়ারওয়াল বেসিকস গাইড দেখে এটি সেটআপ করে নিন, কারণ একটি ডিফল্ট-ডিনাই ফায়ারওয়াল সার্ভারের অন্য সবকিছুর জন্য সঠিক ভিত্তি।

আপনার নিজের সার্ভারে বাইপাসটি দেখুন

এমন একটি VPS থেকে শুরু করুন যেখানে UFW সক্রিয় আছে এবং ইনকামিং ট্র্যাফিকের জন্য ডিফল্ট পলিসি হিসেবে deny সেট করা আছে। একটি প্রকাশিত পোর্টসহ একটি ওয়েব কন্টেইনার চালান:

sudo ufw status verbose
docker run -d --name web -p 8080:80 nginx:1.29-alpine

ufw status verbose কমান্ডটি Default: deny (incoming), allow (outgoing) দেখায় এবং পোর্ট 8080-এর জন্য কোনো রুল নেই। ফায়ারওয়ালের নিজস্ব রিপোর্ট অনুযায়ী, পোর্টটি বন্ধ। এখন সার্ভার থেকে নয়, বরং অন্য একটি মেশিন থেকে পরীক্ষা করুন:

curl -I http://your-vps-ip:8080/

HTTP/1.1 200 OK

কন্টেইনারটি উত্তর দিচ্ছে। একটি স্পষ্ট deny রুল যোগ করুন এবং আবার পরীক্ষা করুন:

sudo ufw deny 8080/tcp

পোর্টটি এখনও উত্তর দিচ্ছে, কারণ deny রুলটি এমন একটি চেইনে রয়েছে যেখানে প্যাকেটটি কখনোই পৌঁছায় না। UFW ব্যর্থ হয়নি। এটি কখনোই যাচাই করা হয়নি। এই কারণেই সমস্যাটি খুব ভালোভাবে লুকিয়ে থাকে: কোথাও কোনো ত্রুটি প্রদর্শিত হয় না, ডিপ্লয়মেন্ট কাজ করে এবং ফায়ারওয়ালের স্ট্যাটাস আউটপুট দেখতে একটি সুরক্ষিত সার্ভারের মতোই মনে হয়।

কার্যপদ্ধতি: PREROUTING চলে INPUT-এর আগে

কার্নেল একটি নির্দিষ্ট ক্রমে ইনকামিং প্যাকেট প্রসেস করে এবং পুরো সমস্যাটি এই ক্রমের মধ্যেই নিহিত।

1. PREROUTING সবার আগে চলে। এখানকার রুলগুলো প্যাকেটের গন্তব্য পরিবর্তন করতে পারে এবং কোনো পোর্ট পাবলিশ করার জন্য Docker-এর রুল ঠিক এই কাজটিই করে।
2. এরপর রাউটিং সিদ্ধান্ত নেওয়া হয়। হোস্টের উদ্দেশ্যে আসা প্যাকেট INPUT চেইনে যায়। অন্য কোনো মেশিনের উদ্দেশ্যে আসা প্যাকেট FORWARD চেইনে যায়।
3. UFW-এর রুলগুলো INPUT-এ থাকে। Docker-এর রুলগুলো FORWARD-এ থাকে।

আপনার সদ্য চালু করা কন্টেইনারের জন্য Docker-এর রুলটি দেখুন:

sudo iptables -t nat -L DOCKER -n

Chain DOCKER (2 references)
target   prot opt source       destination
RETURN   0    --  0.0.0.0/0    0.0.0.0/0
DNAT     6    --  0.0.0.0/0    0.0.0.0/0    tcp dpt:8080 to:172.17.0.2:80

DNAT লাইনটিই মূল বিষয়। পোর্ট 8080-তে আসা যেকোনো প্যাকেটের গন্তব্য পরিবর্তন করে 172.17.0.2:80 করে দেওয়া হয়, যা Docker-এর প্রাইভেট ব্রিজ নেটওয়ার্কে কন্টেইনারের ঠিকানা। এই পরিবর্তনের পর প্যাকেটটি আর হোস্টের উদ্দেশ্যে থাকে না, তাই রাউটিং সিদ্ধান্ত অনুযায়ী এটি FORWARD পথে চলে যায়, যেখানে Docker আগেই তার নিজস্ব নেটওয়ার্কে ট্রাফিক গ্রহণ করার জন্য রুল যোগ করে রেখেছে। আপনার deny 8080/tcp রুলটি INPUT-এ এমন একটি প্যাকেটের অপেক্ষায় থাকে যা কখনোই সেখানে পৌঁছায় না।

Ubuntu 24.04-এ iptables কমান্ডটি nftables-এর একটি ফ্রন্ট-এন্ড হিসেবে কাজ করে, কিন্তু চেইনের ক্রম এবং ফলাফল একই। UFW এবং Docker উভয়ই একই কার্নেল প্যাকেট পাইপলাইনে লেখে এবং Docker-এর এন্ট্রি পয়েন্ট আগে থাকে। এটি শুধুমাত্র UFW-এর জন্য সীমাবদ্ধ নয়: Rocky বা AlmaLinux VPS-এ firewalld একই পাইপলাইনের পয়েন্টে ফিল্টার করে এবং একই DNAT রুলের কারণে তা এড়িয়ে যায়, তাই নিচের সমাধানগুলো সেখানেও কার্যকর।

প্রতিদিনের সমাধান: 127.0.0.1-এ পোর্ট পাবলিশ করা

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

docker run -d --name web -p 127.0.0.1:8080:80 nginx:1.29-alpine

অথবা একটি Compose ফাইলে:

services:
  web:
    image: nginx:1.29-alpine
    ports:
      - "127.0.0.1:8080:80"

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

sudo ss -tlnp | grep 8080

আউটপুটে আপনার 127.0.0.1:8080 থাকা প্রয়োজন, 0.0.0.0:8080 বা [::]:8080 নয়। এরপর অন্য একটি মেশিন থেকে নিশ্চিত করুন যে curl http://your-vps-ip:8080/ সংযোগ প্রত্যাখ্যান করছে।

যেসব সার্ভিস ইন্টারনেটের মুখোমুখি হওয়া উচিত, সেগুলোর জন্য একটি রিভার্স প্রক্সি চালান যা 80 এবং 443 পোর্ট নিয়ন্ত্রণ করবে এবং হোস্টনাম অনুযায়ী রাউট করবে; এছাড়া অন্য কিছু পাবলিশ করবেন না। এটিই সেই প্যাটার্ন যা Traefik reverse proxy guide অনুসরণ করে এবং এভাবেই Nextcloud on a VPS-এর মতো একটি সেলফ-হোস্টেড অ্যাপ প্রক্সির বাইরে থেকে নাগালের বাইরে থাকে। কীভাবে ports: এন্ট্রি ঘোষণা করতে হয় এবং বাকি Compose ওয়ার্কফ্লো সম্পর্কে the Docker Compose basics guide-এ আলোচনা করা হয়েছে।

প্রতিটি ইন্টারনাল কন্টেইনার লুপব্যাকে থাকলে, UFW তার স্বাভাবিক কাজ করতে পারে: হোস্ট নিজে যে পোর্টগুলো সার্ভ করে সেগুলোকে সুরক্ষিত রাখা। এখানে রুল সেট তৈরি করুন, তারপর ক্রমানুসারে কমান্ডগুলো চালান:

বাস্তব ফিল্টারিং: DOCKER-USER চেইন

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

কমান্ড চালানোর আগে একটি সতর্কতা: প্যাকেট যখন DOCKER-USER-এ পৌঁছায়, তখন DNAT রিরাইট সম্পন্ন হয়ে যায়। প্যাকেটের গন্তব্য পোর্ট তখন কন্টেইনার পোর্ট (আমাদের উদাহরণে 80), প্রকাশিত পোর্ট (8080) নয়। তাই --dport 8080-এর সাথে মিল রেখে তৈরি করা রুল কোনো কাজ করবে না। নির্ভরযোগ্য উপায় হলো ক্লায়েন্ট শুরুতে যে পোর্টে ডায়াল করেছিল তা মেলানো, যা কার্নেলের কানেকশন ট্র্যাকার মনে রাখে:

sudo iptables -I DOCKER-USER -i eth0 -p tcp -m conntrack --ctorigdstport 8080 --ctdir ORIGINAL ! -s 10.0.0.10 -j DROP

এটি এভাবে পড়ুন: যে প্যাকেটগুলো eth0 দিয়ে প্রবেশ করেছে এবং এমন একটি কানেকশনের অংশ যার মূল গন্তব্য পোর্ট ছিল 8080, সেগুলোর মধ্যে যেগুলো 10.0.0.10 থেকে আসেনি তা ড্রপ করুন। --ctdir ORIGINAL ম্যাচটি রুলটিকে শুধুমাত্র ক্লায়েন্ট-থেকে-কন্টেইনার অভিমুখে সীমাবদ্ধ রাখে, যাতে রিপ্লাই প্যাকেটগুলো ভুলবশত আটকে না যায়। eth0-এর জায়গায় আপনার পাবলিক ইন্টারফেস বসান; ip route | grep default সেটিকে নির্দেশ করে। আগের মতোই পরীক্ষা করুন: অনুমোদিত অ্যাড্রেস থেকে curl সফল হবে এবং অন্য যেকোনো জায়গা থেকে কানেকশন টাইম-আউট হবে। এই হ্যাং বা ঝুলে থাকা হলো একটি DROP রুলের কাজ করার লক্ষণ, যা কোনো পোর্ট খালি থাকার চেয়ে আলাদা। একটি রিফিউজড কানেকশন এবং টাইম-আউট হওয়া কানেকশনের পার্থক্য হলো ফিল্টার করা পোর্ট এবং যে পোর্টে কোনো সার্ভিস চলছে না, তা বোঝার দ্রুততম উপায়।

iptables কমান্ড দিয়ে যোগ করা রুলগুলো রিবুটের পরে মুছে যায়। যেহেতু UFW ইতিমধ্যে এই ফায়ারওয়াল পরিচালনা করে, তাই এগুলো স্থায়ী করার সঠিক জায়গা হলো /etc/ufw/after.rules। ফাইলের শেষে একটি ব্লক যুক্ত করুন:

*filter
:DOCKER-USER - [0:0]
-A DOCKER-USER -i eth0 -p tcp -m conntrack --ctorigdstport 8080 --ctdir ORIGINAL ! -s 10.0.0.10 -j DROP
COMMIT

এরপর sudo ufw reload চালান। UFW প্রতিবার রিলোড এবং রিবুটের সময় এই ফাইলটি পুনরায় কার্যকর করে, তাই আপনার কন্টেইনার ফিল্টারিং এখন আপনার ফায়ারওয়ালের বাকি অংশের সাথেই থাকবে এবং এটি রিবুট ও Docker আপগ্রেড—উভয় ক্ষেত্রেই টিকে থাকবে।

কেন Docker-এর iptables ইন্টিগ্রেশন নিষ্ক্রিয় করা উচিত নয়

এই সমস্যার পুরনো সমাধানগুলোতে { "iptables": false }-কে /etc/docker/daemon.json-এ সেট করার পরামর্শ দেওয়া হয়। এটি করবেন না। Docker-এর ফায়ারওয়াল রুলগুলো শুধুমাত্র পোর্ট পাবলিশ করার চেয়েও বেশি কাজ করে। Masquerade রুলটি কন্টেইনারগুলোকে হোস্টের অ্যাড্রেসের মাধ্যমে ইন্টারনেটে আউটবাউন্ড অ্যাক্সেস দেয়, তাই এই ইন্টিগ্রেশন বন্ধ থাকলে কন্টেইনারগুলো ইমেজ পুল করতে, প্যাকেজ মিরর অ্যাক্সেস করতে বা কোনো এক্সটারনাল API (application programming interface) কল করতে পারে না। DNAT রুলগুলোই মূলত -p-কে কার্যকর রাখে, তাই এটি বন্ধ করলে পাবলিশ করা পোর্টগুলো পুরোপুরি কাজ করা বন্ধ করে দেবে। এছাড়া, আলাদা Compose নেটওয়ার্কগুলোকে বিচ্ছিন্ন রাখার আইসোলেশন রুলগুলোও আর কাজ করবে না। আপনি হয়তো বাইপাস ঠিক করতে গিয়ে কন্টেইনার নেটওয়ার্কিং ভেঙে ফেলবেন এবং তখন প্রতিটি রুল আপনাকে নিজ হাতে লিখতে ও রক্ষণাবেক্ষণ করতে হবে। Docker-এর নিজস্ব ডকুমেন্টেশনে এই সেটিংটিকে তাদের জন্যই রাখা হয়েছে যারা ঠিক এই কাজটিই করতে চান। DOCKER-USER চেইনটি মূলত এই কারণেই তৈরি করা হয়েছে যাতে কাউকে এই সুইচটি ব্যবহার করতে না হয়।

একই সমস্যার IPv6 দিক

প্রথমে পরীক্ষা করে দেখুন IPv6-এ published port কেমন দেখায়:

sudo ss -tlnp | grep 8080

Docker Engine 27 থেকে, Docker ডিফল্টভাবে ip6tables পরিচালনা করে। IPv6 সক্রিয় আছে এমন একটি Docker network-এ, একটি published port IPv6 tables-এ একই DNAT প্রক্রিয়ার মধ্য দিয়ে যায়। তাই সেখানেও একই bypass বিদ্যমান এবং একই সমাধান প্রযোজ্য: ip6tables-এও DOCKER-USER chain থাকে, তাই sudo ip6tables -I DOCKER-USER ... ব্যবহার করে আপনার rule-টি মিরর করুন এবং আপনার সার্ভারের পাবলিক IPv6 ঠিকানার বিপরীতে curl ব্যবহার করে বাইরে থেকে পরীক্ষা করুন, উদাহরণস্বরূপ curl -6 http://[2001:db8:2a::1]:8080/।

IPv6 নেই এমন নেটওয়ার্কে, IPv6 ক্লায়েন্টদের পরিবর্তে docker-proxy দ্বারা পরিচালনা করা হয়। এটি একটি সাধারণ user-space প্রক্রিয়া যা [::]:8080-এ listen করে এবং IPv4-এর মাধ্যমে কন্টেইনারে ট্রাফিক ফরোয়ার্ড করে। হোস্ট প্রক্রিয়ার ট্রাফিক INPUT-এর মধ্য দিয়ে যায়, তাই UFW সেই পথটি ফিল্টার করতে পারে, তবে শুধুমাত্র তখনই যখন UFW সক্রিয়ভাবে IPv6 পরিচালনা করে। এটি সক্রিয় আছে কি না এবং একটি VPS-এ IPv6 gap তৈরি হওয়ার অন্যান্য উপায়গুলো the UFW and IPv6 guide-এর আলোচ্য বিষয়।

Loopback-এ publish করলে পুরো বিষয়টি এড়ানো যায়: -p 127.0.0.1:8080:80 শুধুমাত্র IPv4 loopback-এ bind করে, তাই কোনো IPv6 listener থাকে না এবং বাইরে থেকে কোনো stack-এই কিছু পৌঁছানো সম্ভব হয় না।

যে প্যাটার্নটি কার্যকর থাকে

• প্রতিটি internal port-কে 127.0.0.1-এ publish করুন, যাতে এগুলো শুরুতেই উন্মুক্ত না থাকে।
• public side-এর দায়িত্ব এমন একটি reverse proxy-কে দিন যা 80 এবং 443 port নিয়ন্ত্রণ করে।
• host-এর জন্য UFW-এর default deny নীতি বজায় রাখুন এবং শুধুমাত্র SSH ও proxy port-গুলোকে অনুমতি দিন।
• প্রকৃত public container port-গুলোকে DOCKER-USER-এ ফিল্টার করুন, যা মূল destination port-এর সাথে মিলে যায় এবং /etc/ufw/after.rules-এ সংরক্ষিত থাকে।
• Docker-এর iptables integration চালু রাখুন।

একবার সেটআপ করা হলে, এটি অপ্রত্যাশিত পরিস্থিতি দূর করে: ufw status host-এর বর্ণনা দেয় এবং DOCKER-USER container-গুলোর বর্ণনা দেয়। কোনো কিছুই ভুলবশত publish হয় না এবং পরবর্তীতে আপনি যে docker run -p টাইপ করবেন, তা ঠিক ততটুকুই উন্মুক্ত করবে যতটুকু আপনি চেয়েছেন।

FAQ

UFW পোর্ট ব্লক করা সত্ত্বেও আমি কেন আমার Docker কন্টেইনারে পৌঁছাতে পারছি?

কারণ Docker তার পোর্টগুলোকে PREROUTING চেইনে একটি DNAT রুলের মাধ্যমে প্রকাশ করে, যা কোনো ফিল্টারিং হওয়ার আগেই প্যাকেটের গন্তব্যকে কন্টেইনারের ঠিকানায় পরিবর্তন করে ফেলে। এরপর প্যাকেটটি FORWARD পাথ দিয়ে যায়, কিন্তু UFW-এর রুলগুলো থাকে INPUT চেইনে, যেখানে প্যাকেটটি কখনোই প্রবেশ করে না। ফলে ফায়ারওয়ালকে কোনো নির্দেশই দেওয়া হয় না এবং প্রকাশিত কন্টেইনার পোর্টের ওপর এর কোনো deny রুল কাজ করে না।

Docker-এর প্রকাশিত পোর্টগুলোকে আমি কীভাবে UFW দিয়ে ব্লক করব?

UFW নিজে এটি করতে পারে না, কারণ এর রুলগুলো ভুল চেইনে থাকে। হয় পোর্টটিকে 127.0.0.1:8080:80 হিসেবে প্রকাশ করে এক্সপোজ করা বন্ধ করুন যাতে শুধুমাত্র হোস্ট এটি অ্যাক্সেস করতে পারে, অথবা DOCKER-USER চেইনে একটি iptables রুল ব্যবহার করে ফিল্টার করুন যা conntrack-এর মাধ্যমে মূল গন্তব্য পোর্টের সাথে মিলে যায়। এই রুলটিকে /etc/ufw/after.rules-এ স্থায়ী করুন যাতে রিবুট এবং ufw reload-এর পরেও এটি কার্যকর থাকে।

আমার কি Docker-এর daemon.json ফাইলে "iptables": false সেট করা উচিত?

না। এই সেটিংটি Docker-এর সমস্ত ফায়ারওয়াল এবং NAT রুল মুছে ফেলে, যা বাইপাস সমস্যার চেয়েও অনেক বেশি ক্ষতি করে। masquerade রুল না থাকায় কন্টেইনারগুলো আউটবাউন্ড ইন্টারনেট অ্যাক্সেস হারিয়ে ফেলে এবং DNAT রুল না থাকায় প্রকাশিত পোর্টগুলো কাজ করা বন্ধ করে দেয়। এর পরিবর্তে loopback পাবলিশিং এবং DOCKER-USER চেইন ব্যবহার করুন; এগুলো কন্টেইনার নেটওয়ার্কিং নষ্ট না করেই এক্সপোজার সমস্যার সমাধান করে।

Docker কি IPv6-এর ক্ষেত্রেও UFW বাইপাস করে?

Docker Engine 27 এবং পরবর্তী ভার্সনগুলোতে ip6tables ম্যানেজমেন্ট ডিফল্টভাবে চালু থাকে, তাই IPv6-সক্ষম Docker নেটওয়ার্কে প্রকাশিত পোর্টগুলো IPv4-এর মতোই UFW-কে এড়িয়ে যায় এবং একই DOCKER-USER রুলকে ip6tables দিয়ে মিরর করা প্রয়োজন। IPv6 ছাড়া নেটওয়ার্কগুলোতে, docker-proxy প্রসেসটি [::]-এ লিসেন করে এবং সেই ট্রাফিক INPUT দিয়ে যায়, যেখানে UFW যদি IPv6 ম্যানেজ করে তবে তা ফিল্টার করতে পারে। 127.0.0.1-এ পাবলিশ করলে উভয় ক্ষেত্রেই এই সমস্যা এড়ানো যায়, কারণ তখন IPv6-এ কিছুই লিসেন করে না।