ভাঙা ufw ruleset থেকে কীভাবে ফিরে আসবেন

প্রথমে আবার প্রবেশাধিকার ফিরিয়ে নিন

ufw আপনার VPS-এ প্রবেশাধিকার বন্ধ করে দিলে ফিরে আসার উপায় হলো provider console অথবা rescue mode। কারণ blocking rule সক্রিয় হয়ে গেলে SSH-ভিত্তিক কোনো সমাধান কাজ করে না। sshd প্যাকেটটি দেখার আগেই kernel সেটি বাতিল করে। তাই নেটওয়ার্কের মাধ্যমে login করার বা সমস্যা ঠিক করার কোনো সুযোগ থাকে না। আপনার provider-এর control panel-এ console খুলুন, সেই prompt-এ login করুন এবং একটি command চালান।

sudo ufw disable

আপনি Firewall stopped and disabled on system startup দেখতে পাবেন। এক বা দুই সেকেন্ডের মধ্যে নতুন SSH connection আবার কাজ করবে। আপনার কোনো configuration হারায় না: disable kernel থেকে rules unload করে এবং ENABLED=no-কে /etc/ufw/ufw.conf-এ লিখে রাখে। এদিকে আপনার rules /etc/ufw/user.rules-এ disk-এ থেকে যায় এবং পরবর্তী ufw enable-এর জন্য অপেক্ষা করে।

reboot করে সমস্যার সমাধান হবে—এমন আশা করবেন না। ufw boot-এর সময় নিজে থেকে চালু হয়। তাই ENABLED=yes করলে network চালু হওয়ার আগেই একই ruleset আবার load হবে। reboot করলে ufw lockout-এর কোনো পরিবর্তন হয় না।

কনসোলে এমন একটি password প্রয়োজন হতে পারে, যা আপনার কাছে নেই

Web console (VNC বা serial) হলো মেশিনের সঙ্গে সংযুক্ত একটি keyboard। এটি কোনো network path নয়, তাই কোনো firewall rule এটিকে block করতে পারে না। তবে এতে local login প্রয়োজন। এখানেই key-only setup ব্যর্থ হয়: আপনি যদি আপনার sudo user-এর জন্য কখনো password সেট না করে থাকেন এবং root login locked থাকে, তাহলে console এমন একটি prompt দেখাবে, যার উত্তর আপনি দিতে পারবেন না। SSH চালু থাকা অবস্থায় এখনই সেই password সেট করুন: sudo passwd yourname। অধিকাংশ panel থেকেই root password reset করা যায়। এতে সাধারণত reboot বাধ্যতামূলক হয়।

Console ব্যবহার করা না গেলে provider-এর rescue system-এ boot করুন। এটি আপনার disk unmounted অবস্থায় একটি আলাদা operating system চালায়। তাই বাইরে থেকে ufw বন্ধ করা যায়।

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

প্রথমে lsblk চালান, কারণ root partition সব সময় /dev/vda1 নাও হতে পারে। স্বাভাবিক system-এ reboot করুন। আপনি নিজে enable না করা পর্যন্ত ufw বন্ধই থাকবে।

ন্যূনতম recovery sequence

এই ক্রমে কাজ করুন। প্রথম চারটি ধাপ নিরাপদ। এর পরের ধাপটি নিরাপদ নয়।

1. sudo ufw disable চালিয়ে rule unload করুন এবং আপনার access পুনরুদ্ধার করুন।
2. sudo ufw show added চালিয়ে আপনার যোগ করা rule-গুলো যে command দিয়ে যোগ করা হয়েছিল, সেই form-এ দেখুন। ufw inactive থাকা অবস্থায় এটি কাজ করে, কিন্তু ufw status কাজ করে না।
3. sudo sshd -T | grep -i '^port' চালিয়ে sshd আসলে কোন port-এ listen করছে তা নিশ্চিত করুন। port পরিবর্তন না করলে এটি port 22 দেখায়।
4. sudo ufw allow 22/tcp চালান, যেখানে আপনার প্রকৃত port ব্যবহার করবেন, যাতে পরবর্তী enable আবার lockout ঘটাতে না পারে।
5. sudo ufw enable চালান, তবে এর আগে rollback schedule করুন। এই পৃষ্ঠার আরও নিচে এর বর্ণনা আছে।

ufw reset আসলে কী করে

ufw reset হলো শেষ অবলম্বন, প্রথম পদক্ষেপ নয়। এটি firewall নিষ্ক্রিয় করে, প্রতিটি rules file-এর backup তৈরি করে এবং default policy-তে incoming traffic deny ও outgoing traffic allow সেট করে। প্রতিটি file-এর জন্য একটি করে backup line দেখায়:

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

reset-এর পরে কোনো allow rule থাকে না। তাই SSH-এর মাধ্যমে নয়, console থেকে এটি চালান এবং আবার enable করার আগে SSH rule যোগ করুন। এই backup-গুলো plain text। sudo grep -n dport /etc/ufw/user.rules.20260813_101500 দেখে পুরোনো rule-গুলো কী ছিল তা জানা যায়। আপনি যে ruleset মুছে ফেলতে চাননি, সেটি এভাবেই পুনর্গঠন করতে পারবেন।

ufw তার নিয়মগুলো কোথায় সংরক্ষণ করে

স্মৃতি থেকে অনুমান করার চেয়ে ফাইল পড়া বেশি নির্ভরযোগ্য। পাঁচটি path-এ পুরো অবস্থা সংরক্ষিত থাকে:

• /etc/ufw/user.rules এবং /etc/ufw/user6.rules: আপনি যোগ করা নিয়মগুলো, যে ক্রমে সেগুলো মূল্যায়ন করা হয় সেই ক্রমে।
• /etc/ufw/before.rules এবং /etc/ufw/after.rules, পাশাপাশি 6 variant-গুলো: আপনার নিয়মগুলোর চারপাশে ufw যে framework ব্যবহার করে, যার মধ্যে established connection-এর জন্য accept এবং loopback নিয়মও আছে।
• /etc/default/ufw: default policy এবং IPV6 switch।
• /etc/ufw/ufw.conf: ENABLED এবং log level।
• /var/log/ufw.log: logging চালু থাকলে কী block করা হয়েছে।

ufw কোনো file পুনর্লিখনের আগে তার timestamp-সহ একটি copy তৈরি করে। তাই ls /etc/ufw/-এ user.rules.20260813_101500-এর মতো name জমতে থাকে। এগুলো আপনার undo history। কোনো পরিবর্তন ফিরিয়ে দেওয়ার আগে এই history পড়া উপযোগী।

Disk-এ থাকা configuration নয়, kernel-এ load হওয়া configuration দেখতে sudo ufw show raw ব্যবহার করুন। বিকল্পভাবে sudo iptables -S এবং sudo ip6tables -S ব্যবহার করতে পারেন। Ubuntu 22.04 এবং 24.04-এ এই command-গুলো nft ভিত্তিক version ব্যবহার করে। তাই sudo nft list ruleset নতুন syntax-এ একই নিয়ম দেখায়।

ufw সক্রিয় করার পর আমার SSH session কেন বিচ্ছিন্ন হয়ে গেল?

ডিফল্ট incoming policy হলো deny। SSH port-এর জন্য কোনো rule ছাড়া ufw সক্রিয় করলে প্রতিটি নতুন connection বিচ্ছিন্ন হয়ে যায়। ufw আপনাকে সতর্ক করে: Command may disrupt existing ssh connections. Proceed with operation (y|n)? SSH allow rule সেট না রেখেই y-এর উত্তর দেওয়া এই পৃষ্ঠার সব সমস্যার সবচেয়ে সাধারণ কারণ।

বিভ্রান্তিকর বিষয়টি হলো বিলম্ব। /etc/ufw/before.rules আপনার নিজস্ব rule প্রয়োগের আগে ESTABLISHED,RELATED state-এর packet গ্রহণ করে। তাই যে session-এ আপনি command চালিয়েছেন, সেটি স্বাভাবিকভাবে কাজ করতে থাকে। Lockout কেবল পরবর্তী connection-এ দেখা দেয়। সেটি কয়েক ঘণ্টা পরেও হতে পারে। তখন firewall পরিবর্তনের সঙ্গে সমস্যাটির সম্পর্ক আর স্পষ্ট থাকে না। প্রথম session বন্ধ করার আগে সবসময় একটি দ্বিতীয় SSH session খুলে সেটি কাজ করছে কি না নিশ্চিত করুন।

apt এবং DNS policy পরিবর্তনের পরে কেন কাজ করা বন্ধ করল?

sudo ufw default deny outgoing outbound DNS (domain name system) query এবং outbound HTTP block করে। তাই name resolution বন্ধ হয়ে যায় এবং package update থেমে যায়। apt update, Temporary failure resolving 'archive.ubuntu.com' report করে। Inbound SSH এখনও কাজ করে, কারণ এর reply-গুলো ESTABLISHED এবং framework rule পাস করে। ফলে firewall-কে নির্দোষ মনে হয়, যদিও সমস্যার কারণ সেটিই।

আপনি যদি deny outgoing policy ব্যবহার করতে চান, তাহলে মেশিনটির বাস্তবে যা প্রয়োজন তা খুলে দিন:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

শেষ rule ছাড়া clock-এর সময় ধীরে ধীরে ভুল হয়ে যায়। ভুল clock TLS (transport layer security) certificate validation ব্যর্থ করে। তাই curl port-এর কারণে নয়, date-এর কারণে ব্যর্থ হতে শুরু করে। এই সমস্যা policy পরিবর্তনের কয়েক দিন পরে দেখা দেয়। এ কারণেই deny outgoing এমন মেশিনের জন্য উপযুক্ত policy, যেগুলো আপনি monitor করেন; একবার setup করে রেখে দেওয়া মেশিনের জন্য নয়।

আমার ufw rule কখনো match করে না কেন?

ufw ব্যবহারকারীর rule-গুলো ক্রম অনুযায়ী মূল্যায়ন করে এবং প্রথম match পাওয়ার পর থেমে যায়। একটি বিস্তৃত allow-এর পরে যোগ করা deny কখনো কার্যকর হয় না, কারণ allow rule-টি তার আগেই packet-এর সিদ্ধান্ত নিয়ে ফেলে। সংখ্যাসহ ক্রম দেখুন, তারপর প্রয়োজনীয় অবস্থানে rule insert করুন।

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp যে rule-গুলো লেখা হবে সেগুলো দেখায়, কিন্তু কোনো পরিবর্তন করে না। কোনো rule কার্যকর করার আগে পড়ার এটিই নিরাপদ পদ্ধতি।

Application profile-এ আরও একটি সমস্যা থাকে। sudo ufw allow OpenSSH /etc/ufw/applications.d/openssh-server-এর profile ব্যবহার করে, এবং সেই profile-এর অর্থ port 22। sshd যদি 2222-এ listen করে, তাহলে rule এমন একটি port খুলবে যা কোনো service ব্যবহার করছে না। এতে দেখতে সঠিক হলেও ruleset আপনাকে server-এ ঢুকতে বাধা দিতে পারে। Port পরিবর্তন করার পরে port number সরাসরি ব্যবহার করুন। বাকি syntax VPS-এর ufw firewall-এর মৌলিক বিষয়-এ ব্যাখ্যা করা হয়েছে।

IPv4 নিয়মে আমি যা দেখছি তার ব্যাখ্যা নেই কেন?

কারণ মোট ট্রাফিকের অর্ধেক IPv4 নয়। Ubuntu-তে IPV6=yes, /etc/default/ufw-এ থাকে, এবং ufw এরপর /etc/ufw/user6.rules-এ একটি সমান্তরাল v6 ruleset বজায় রাখে। ufw allow from 203.0.113.10 to any port 22-এর মতো IPv4 address দিয়ে লেখা কোনো rule একেবারেই v6 rule তৈরি করে না। আপনার VPS-এ যদি AAAA record থাকে, client IPv6 পছন্দ করে, এবং connection timeout হয়, অথচ ufw status-এ সঠিক বলে মনে হওয়া একটি rule দেখা যায়, তাহলে এই সমস্যা হতে পারে। ssh -6 user@host-এর বিপরীতে ssh -4 user@host ব্যবহার করে পার্থক্য পরীক্ষা করুন। প্রথমটি কাজ করলে এবং দ্বিতীয়টি কাজ না করলে, সমস্যা v6 ruleset-এ।

নিরাপত্তার দিক থেকে উল্টো ঘটনাটি আরও গুরুতর। IPV6=no থাকলে ufw ip6tables একেবারেই manage করে না, তাই v6 policy kernel-এর default ACCEPT অবস্থায় থাকে। আপনি যে port-কে বন্ধ মনে করছেন, সেটি তার IPv6 address-এ connection গ্রহণ করে, এবং কোনো ufw command-এই সেটির উল্লেখ দেখা যাবে না। sudo ip6tables -S এবং ss -tlnp দিয়ে পরীক্ষা করুন। সম্পূর্ণ বিষয়টি জানতে ufw কীভাবে IPv6 port পরিচালনা করে পড়ুন।

Docker port-এ ufw নিষেধ করলেও সেটি খোলা থাকে কেন?

Docker nat table-এ DNAT (destination network address translation) rule লিখে এবং FORWARD-এ নিজের chain যুক্ত করে port publish করে। ufw-এর rule-গুলো INPUT path-এ থাকে। Container-এ যাওয়া traffic host-এ deliver না হয়ে forward হয়। তাই আপনার deny rule যে chain-এ আছে, traffic সেখানে পৌঁছায় না। ufw সক্রিয় থাকা এবং সবকিছু deny করা সত্ত্বেও docker run -p 5432:5432 Internet থেকে পৌঁছানো যায়।

sudo iptables -t nat -S DOCKER

সবচেয়ে সহজ সমাধান হলো loopback-এ publish করা: -p 127.0.0.1:5432:5432 host side-কে 127.0.0.1-এ bind করে। ufw-এর configuration যা-ই হোক, বাইরে থেকে এতে পৌঁছানো যাবে না। Service-টি public হওয়া প্রয়োজন হলে ufw-এর মাধ্যমে Docker port publish করা অংশে বিভিন্ন পরিস্থিতির ব্যাখ্যা আছে।

নিয়ম প্রয়োগের আগে rollback নির্ধারণ করুন

এই অভ্যাসের কারণে firewall ব্যবস্থাপনা নিরাপদ থাকে। ঝুঁকিপূর্ণ কোনো পরিবর্তনের আগে তা undo করার ব্যবস্থা নির্ধারণ করুন। পরিবর্তনের ফলে সংযোগ বিচ্ছিন্ন হলে মেশিনটি পাঁচ মিনিটের মধ্যে নিজে থেকে আগের অবস্থায় ফিরে যাবে, তাই আপনাকে console খুলতে হবে না।

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd Running timer as unit: ufw-rollback.timer দেখায়। এখন পরিবর্তনটি করুন। এরপরও যদি নতুন SSH session খুলতে পারেন, rollback বাতিল করুন:

sudo systemctl stop ufw-rollback.timer

সেই session খুলতে না পারলে অপেক্ষা করুন। ufw নিজে থেকে বন্ধ হয়ে যাবে এবং পরেরবারের চেষ্টায় সংযোগ তৈরি হবে। প্রচলিত shutdown -r +5 কৌশলটি ufw-এর ক্ষেত্রে কাজ করে না, কারণ boot-এর সময় ufw আবার একই ruleset লোড করে।

একটি দ্বিতীয় প্রবেশপথ রাখুন

• প্রয়োজন হওয়ার আগেই provider console-এ একবার লগ ইন করুন এবং password কাজ করছে কি না নিশ্চিত করুন। যে console কখনও পরীক্ষা করা হয়নি, সেটি backup নয়।
• নিজস্ব key-সহ একটি দ্বিতীয় sudo user রাখুন, যাতে একটি নষ্ট authorized_keys file আপনার প্রবেশাধিকার সম্পূর্ণভাবে বন্ধ না করে।
• আপনার provider panel-এ ufw-এর বাইরে আলাদা network firewall চালায় কি না পরীক্ষা করুন। সেটিও একই port block করে, কিন্তু ufw status কখনও সেটির উল্লেখ করবে না।
• ঠিকানাটি dynamic হলে ufw allow from <your home address>-কে আপনার একমাত্র SSH rule বানাবেন না। আপনার provider রাতের মধ্যে ঠিকানাটি পরিবর্তন করতে পারে, তখন আপনি প্রবেশাধিকার হারাবেন।

এসব কাজ করার সবচেয়ে সুবিধাজনক সময় হলো fresh server প্রস্তুত করার সময়। নতুন VPS-এ প্রথম দশ মিনিটের কাজ-এর পাশাপাশি এগুলো সম্পন্ন করুন।

Refused অথবা timed out বার্তা দেখে বোঝা যায় কোন স্তরে সমস্যা হয়েছে

Connection refused বোঝায় যে একটি packet সার্ভারে পৌঁছেছে এবং কোনো process TCP reset পাঠিয়েছে। Network path ঠিক আছে। তাই sshd বন্ধ আছে অথবা অন্য port-এ listening করছে। সাধারণত firewall এর কারণ নয়, কারণ ufw ডিফল্টভাবে connection reject না করে drop করে।

Connection timed out বোঝায় যে কোনো response ফেরত আসেনি। এটি drop-এর লক্ষণ। এর কারণ হতে পারে ufw, provider-এর network firewall অথবা ভুল address। এই দুটি error সঠিকভাবে পড়লে অনুমান করে troubleshooting করতে এক ঘণ্টা নষ্ট হয় না। connection refused এবং timed out-এর পার্থক্য বাকি পরিস্থিতিগুলো ব্যাখ্যা করে।

পরবর্তী পরিবর্তনের আগে logging চালু করুন

sudo ufw logging on
sudo tail -f /var/log/ufw.log

Block করা packet এভাবে দেখা যায়:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22-এ আপনার নিজের address এবং SRC=-এ সংশ্লিষ্ট তথ্য থাকলে প্রমাণ হয় যে আপনাকে ufw block করছে, network বা sshd নয়। rsyslog ছাড়া minimal image-এ কোনো /var/log/ufw.log থাকে না; একই লাইন sudo journalctl -k | grep UFW থেকে আসে। ufw তার নিজস্ব logging rule-এর rate limit প্রয়োগ করে। তাই কোনো লাইন না পাওয়া মানেই packet allow হয়েছে—এমন নয়।

আপনি যোগ না করা rule খুঁজে পেলে

নিজে থেকে পরিবর্তিত হওয়া ruleset firewall-এর সমস্যা নয়। root অধিকার থাকা কেউ এটি লিখেছে। কোন sudo command কখন এবং কোন account-এর অধীনে চালানো হয়েছে তা দেখতে sudo grep ufw /var/log/auth.log চালান। এরপর ওই timestamp-এর কাছাকাছি login-গুলো পরীক্ষা করতে last চালান। account-গুলো আপনার পরিচিত কারও সঙ্গে না মিললে firewall debug করা বন্ধ করুন এবং এর পরিবর্তে compromised VPS checklist অনুসরণ করুন। অন্য কেউ নিয়ন্ত্রণ করছে এমন একটি box-এ firewall পুনরায় চালু করলে সমস্যাটি শুধু আড়াল হবে।

আবার সঠিকভাবে সক্রিয় করুন

কারণ জানার পরে এমনভাবে ufw আবার সক্রিয় করুন, যাতে একই কারণে পুনরায় সংযোগ বিচ্ছিন্ন না হয়। আপনার প্রকৃত SSH port অনুমোদন করুন, rollback-এর সময় নির্ধারণ করুন, ufw সক্রিয় করুন, তারপর অন্য একটি terminal থেকে একেবারে নতুন SSH session খুলে সংযোগ হচ্ছে কি না নিশ্চিত করুন। সেই নতুন session চালু হওয়ার পরেই আপনি যে session-এ কাজ করছেন সেটি বন্ধ করুন। এক দিন logging চালু রাখুন, কারণ user.rules পড়ার চেয়ে log দেখলে কোন অনুমতি দিতে ভুলেছেন তা অনেক দ্রুত বোঝা যায়।

FAQ

ufw disable কি আমার rules মুছে দেয়?

না। disable kernel থেকে ruleset unload করে এবং ENABLED=no-এর মধ্যে /etc/ufw/ufw.conf লিখে। আপনার rules /etc/ufw/user.rules ও /etc/ufw/user6.rules-এ থেকে যায়, এবং firewall inactive থাকলেও sudo ufw show added সেগুলো তালিকাভুক্ত করে। ufw reset হলো rules পরিষ্কার করার command। এটি আগে প্রতিটি file-এর backup তৈরি করে এবং Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'-এর মতো একটি line দেখায়।

আমার VPS reboot করলে কি ufw lockout সরে যাবে?

না। ufw boot-এর সময় /etc/ufw/ufw.conf-এর ENABLED=yes থেকে start হয়। তাই network চালু হওয়ার আগেই একই rules load হয় এবং আপনি আবার lockout হন। আপনি ufw বন্ধ করার পর, অথবা rescue mode-এ disk mount করে ওই file edit করার পরই reboot সাহায্য করতে পারে। Provider console ব্যবহার করে সেখানে sudo ufw disable চালান।

ufw port deny করা সত্ত্বেও আমার Docker container-এ কেন পৌঁছানো যাচ্ছে?

প্রকাশিত প্রতিটি port-এর জন্য Docker নিজস্ব DNAT এবং FORWARD rules লেখে। এই traffic host-এ deliver না হয়ে container-এ forward হয়। তাই এটি INPUT chain-এর মধ্য দিয়ে যায় না, যেখানে আপনার ufw deny rule রয়েছে। Port-টি শুধু host-এর জন্য হলে -p 127.0.0.1:5432:5432 ব্যবহার করে loopback-এ publish করুন। Docker কী install করেছে তা sudo iptables -t nat -S DOCKER দিয়ে পরীক্ষা করুন।

আমার console password নেই এবং rescue mode-ও নেই। আমার কী কী option আছে?

অবশিষ্ট option আপনার provider-এর ওপর নির্ভর করে: control panel থেকে password reset করা, যার ফলে সাধারণত server reboot হয়; অথবা disk-টি অন্য একটি instance-এ attach করে সেখান থেকে /etc/ufw/ufw.conf edit করা। Server rebuild করার আগে support-এর সঙ্গে যোগাযোগ করুন, কারণ rebuild করলে server-এর data নষ্ট হয়ে যায়। আবার access পাওয়ার পর sudo passwd yourname চালান এবং একবার console login পরীক্ষা করুন, যাতে পরের lockout সামলাতে আপনার দুই মিনিটের বেশি না লাগে।