Linux-এ port খোলা আছে কি না পরীক্ষা করার উপায়

Linux-এ port খোলা আছে কি না পরীক্ষা করুন: প্রথমে সঠিক প্রশ্নটি নির্ধারণ করুন

Linux-এ কোনো port খোলা আছে কি না পরীক্ষা করতে প্রথমে আপনি কোন প্রশ্নের উত্তর খুঁজছেন তা নির্ধারণ করুন। কারণ আপনি কোথা থেকে পরীক্ষা করছেন তার ওপর “খোলা” শব্দটির অর্থ বদলে যায়। সার্ভারের নিজে থেকে দেখলে, খোলা মানে কোনো process ওই port-এ bind করা আছে এবং সংযোগের অপেক্ষা করছে। অন্য কোনো machine থেকে দেখলে, খোলা মানে packet ওই process-এ পৌঁছাচ্ছে এবং সেখান থেকে উত্তর ফিরে আসছে। কোনো উত্তর না ফিরলে আসল প্রশ্ন হলো কোন device packet-টি বাদ দিয়েছে। sudo ss -ltnp প্রথম প্রশ্নের উত্তর দেয়। nc -z বা nmap দ্বিতীয় প্রশ্নের উত্তর দেয়। Firewall counter এবং tcpdump তৃতীয় প্রশ্নের উত্তর দেয়।

ভুল পরীক্ষা চালানোর কারণেই অনেকের একটি বিকেল নষ্ট হয়। সার্ভারে চালানো কোনো test আপনার provider-এর network firewall-এ কখনো পৌঁছায় না, কারণ ওই filter সার্ভারের বাইরের স্তরে থাকে। Port number আপনার কাছে নতুন হলে, Linux-এ port ও socket কীভাবে কাজ করে এই নির্দেশিকার পরবর্তী অংশে ব্যবহৃত মডেলটি ব্যাখ্যা করে।

এই মেশিনে কোন service port-এ listening করছে? ss-এর output পড়ুন

ss iproute2-এর সঙ্গে থাকে, তাই এটি বর্তমান প্রতিটি distribution-এ উপস্থিত। netstat net-tools থেকে আসে, যা Ubuntu বহু বছর ধরে default হিসেবে install করে না। তাই netstat -tulpn প্রায়ই netstat: command not found-এর উত্তর দেয়। ss শিখুন এবং এই হতাশা এড়িয়ে চলুন।

sudo ss -ltnp

-l শুধু listening socket দেখায়। -t তালিকাটি শুধু TCP-তে সীমিত করে। -n নাম resolve না করে সংখ্যাগুলো দেখায়, তাই command সঙ্গে সঙ্গে ফল দেয়। -p কোন process socketটির মালিক তা দেখায়, এবং এর জন্য root প্রয়োজন: sudo ছাড়া আপনি যে process-এর মালিক নন, সেগুলোর প্রতিটির Process column খালি থাকে। UDP দেখতে -t-এর পরিবর্তে -u ব্যবহার করুন।

State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   127.0.0.53%lo:53    0.0.0.0:*   users:(("systemd-resolve",pid=612,fd=14))
LISTEN 0      128    0.0.0.0:22          0.0.0.0:*   users:(("sshd",pid=921,fd=3))
LISTEN 0      511    127.0.0.1:8080      0.0.0.0:*   users:(("node",pid=1442,fd=19))
LISTEN 0      128    [::]:22             [::]:*      users:(("sshd",pid=921,fd=4))

Local Address column-ই সব নির্ধারণ করে, অথচ মানুষ সাধারণত এই column-টি এড়িয়ে যায়।

• 0.0.0.0:22 মানে মেশিনের প্রতিটি IPv4 address, তাই firewall অনুমতি দিলে এটি বাইরে থেকে reachable।
• [::]:22 IPv6-এর ক্ষেত্রে একই অর্থ বহন করে।
• 127.0.0.1:8080 মানে শুধু loopback। এই মেশিনের বাইরে থেকে কেউ এটিতে পৌঁছাতে পারবে না।
• 10.20.0.5:5432 মানে শুধু ওই একটি interface address; অন্য কোনো address নয়। Private network setup-এ এটি সাধারণ।
• খালি Process column সাধারণত sudo না থাকার কারণে হয়, process না থাকার কারণে নয়।

একটি নির্দিষ্ট port সম্পর্কে জানতে পুরো তালিকায় grep না করে ss-এর ভেতর filter করুন:

sudo ss -ltnp 'sport = :8080'
sudo lsof -nP -iTCP:8080 -sTCP:LISTEN
sudo fuser 8080/tcp

তিনটি command-এই output খালি হলে কোনো কিছু ওই portটি ধরে রাখেনি। service বন্ধ আছে, start হতে ব্যর্থ হয়েছে, অথবা অন্য কোথাও listening করছে। একটি firewall rule-ও পরিবর্তন করার আগে systemctl status <unit> এবং journalctl -u <unit> -n 50 পড়ুন।

Local Address-এ 127.0.0.1 কেন একটি বিকেল নষ্ট করে

127.0.0.1-এ bind করা socket অন্য কোনো host থেকে পৌঁছানো যায় না, এবং কোনো firewall rule পরিবর্তন করেও তা সম্ভব নয়। Kernel 127.0.0.0/8-কে শুধু loopback interface-এ route করে। তাই প্রকৃত network card-এ এই destination address-সহ কোনো packet এলে সেটি martian হিসেবে বাতিল হয়। ফলে process চলছে, ss দেখাচ্ছে যে এটি listening অবস্থায় আছে, ufw allow 8080 success দেখাচ্ছে, কিন্তু আপনার laptop থেকে connection এখনও ব্যর্থ হয়। এটি সঙ্গে সঙ্গে Connection refused-এ ব্যর্থ হয়। কারণ packet আপনার public address-এ পৌঁছে, সেখানে bind করা কোনো socket খুঁজে পায় না, এবং kernel TCP reset পাঠায়।

অনেক program ইচ্ছাকৃতভাবে loopback-এ bind করে। Database বা admin interface-এর জন্য এটিই সঠিক default। এখানে আপনার সামনে দুটি বাস্তবসম্মত পছন্দ আছে। Program-এর নিজস্ব config-এ bind address পরিবর্তন করুন (listen_addresses-এ postgresql.conf, bind-এ redis.conf, অথবা আপনার application গ্রহণ করে এমন host argument), তারপর firewall খুলুন। অথবা এটিকে loopback-এই রেখে অন্য কোনো উপায়ে পৌঁছান, যেমন nginx reverse proxy ব্যবহার করে, অথবা আপনার laptop থেকে SSH tunnel তৈরি করে:

ssh -L 8080:127.0.0.1:8080 user@203.0.113.10

Docker তার publish flag-এ একই পার্থক্য বজায় রাখে। -p 8080:8080 0.0.0.0-এ bind করে এবং container-কে Internet-এ উন্মুক্ত করে। -p 127.0.0.1:8080:8080 loopback-এ bind করে এবং এটিকে local রাখে।

Linux-এ অন্য মেশিন থেকে কোনো port খোলা আছে কি না কীভাবে পরীক্ষা করবেন

এই পরীক্ষা ভিন্ন network থেকে চালান। সার্ভার থেকেই পরীক্ষা করলে শুধু loopback path কাজ করছে বলে প্রমাণ হয়। সার্ভার থেকে নিজের public IP-তে সংযোগ করলেও provider-এর network firewall এড়িয়ে যায়, কারণ ওই filter VPS-এর বাইরে কাজ করে।

nc -zv -w 3 203.0.113.10 443

-z কোনো data না পাঠিয়েই সংযোগ করে এবং বন্ধ হয়ে যায়। -w 3 তিন সেকেন্ড পরে চেষ্টা বন্ধ করে, এবং এই flag গুরুত্বপূর্ণ: timeout না থাকলে dropped packet-এর কারণে client দুই মিনিটেরও বেশি সময় SYN পুনরায় পাঠাতে থাকে, তারপর kernel তা বন্ধ করে। সফল ফলাফল এ রকম:

Connection to 203.0.113.10 443 port [tcp/https] succeeded!

tool-টি না থাকলে (nc: command not found), Debian বা Ubuntu-তে netcat-openbsd install করুন। অথবা bash-এর built-in network redirection ব্যবহার করুন; এর জন্য কোনো package প্রয়োজন হয় না:

timeout 3 bash -c '</dev/tcp/203.0.113.10/443' && echo open || echo "no answer"

এই syntax bash-এর একটি feature। তাই এটি bash দিয়ে চালান। Debian এবং Ubuntu-তে /bin/sh হলো dash, যার /dev/tcp নেই এবং এটি জানায় যে path-টি বিদ্যমান নয়। একাধিক port-এর range পরীক্ষা করতে, অথবা port-এর অবস্থা স্পষ্টভাবে জানতে, আপনার নিয়ন্ত্রণাধীন host-এর বিরুদ্ধে nmap ব্যবহার করুন:

sudo nmap -Pn -p 22,80,443 203.0.113.10
sudo nmap -Pn -p 1-1024 203.0.113.10

-Pn host discovery বাদ দেয়। অধিকাংশ VPS host ICMP echo বাদ দেয়। তাই -Pn ছাড়া nmap host-টিকে down মনে করে এবং কিছু scan করে না। কোনো কিছু উত্তর দিয়ে connection গ্রহণ করলে nmap open দেখায়, কোনো কিছু উত্তর দিয়ে reset পাঠালে closed দেখায়, এবং একেবারেই কোনো উত্তর না এলে filtered দেখায়। কোনো web service-এর ক্ষেত্রে curl -sS -o /dev/null -w '%{http_code}\n' https://example.com network fault এবং application fault আলাদা করতে সাহায্য করে, কারণ status code প্রমাণ করে যে সম্পূর্ণ path কাজ করেছে।

কেন blocked port অপেক্ষা করায়, আর closed port সঙ্গে সঙ্গে প্রত্যাখ্যান করে

সঙ্গে সঙ্গে প্রত্যাখ্যান। প্যাকেটটি মেশিনে পৌঁছেছে এবং কোনো একটি উপাদান তার উত্তর দিয়েছে।

nc: connect to 203.0.113.10 port 443 (tcp) failed: Connection refused

এই নির্দিষ্ট ফলাফলের পেছনে দুটি ভিন্ন কারণ থাকতে পারে। হয় ওই address ও port-এ কোনো process bind করা নেই, তাই kernel TCP reset দিয়ে উত্তর দিয়েছে; অথবা কোনো firewall rule reset দিয়ে প্যাকেটটি প্রত্যাখ্যান করেছে, কিংবা ICMP port unreachable message পাঠিয়েছে। Refusal একটি নির্দিষ্ট উত্তর, এবং এটি এক round trip-এর মধ্যেই ফিরে আসে।

কিছুক্ষণ অপেক্ষার পর timeout। কোনো একটি উপাদান প্যাকেটটি বাদ দিয়েছে এবং কোনো উত্তর দেয়নি।

nc: connect to 203.0.113.10 port 443 (tcp) timed out: Operation now in progress

DROP rule এটাই করে। Provider firewall বা cloud security group-ও একই কাজ করে। Drop-এর লক্ষণ হলো নীরবতা, কারণ sender বুঝতে পারে না প্যাকেটটি drop হয়েছে, নাকি host-টি সক্রিয় নেই।

এই লক্ষণ পরবর্তী কোথায় পরীক্ষা করতে হবে তা জানায়। Refused হলে বোঝা যায় প্যাকেট network পার হচ্ছে, তাই ss -ltnp-এ ফিরে গিয়ে bind address এবং port number পরীক্ষা করুন। Timed out হলে বোঝা যায় প্যাকেট drop হচ্ছে, তাই বাইরে থেকে ভেতরের দিকে firewall পরীক্ষা করুন। SSH-তে refused এবং timed out-এর পার্থক্য port 22-এর ক্ষেত্রে একই বিভাজনটি ব্যাখ্যা করে; বেশিরভাগ মানুষ প্রথমে এখানেই এই সমস্যা দেখতে পান।

ufw ইচ্ছাকৃতভাবে দুই ধরনের আচরণই দেয়: ufw deny 8080 প্যাকেট drop করে, আর ufw reject 8080 rejection পাঠায়। nftables-এ এই দুই target হলো drop এবং reject, আর iptables-এ হলো -j DROP এবং -j REJECT। Default policy প্রায় সবসময় drop থাকে। তাই কোনো missing rule error message না দেখিয়ে connection hang করায়।

পোর্ট কে ব্লক করছে? বাইরে থেকে ভেতরের দিকে পরীক্ষা করুন

sudo ufw status verbose
sudo iptables -L INPUT -n -v --line-numbers
sudo nft list ruleset

-v counter-গুলোই কার্যকর অংশ। বাইরে থেকে আপনার nc test চালান, আবার iptables command চালান, এবং কোন counter-এর মান পরিবর্তিত হয়েছে তা দেখুন: যে rule-এর packet count বাড়ে, সেটিই আপনার traffic পরিচালনা করছে। এতে অনুমানের বদলে প্রমাণের ভিত্তিতে সিদ্ধান্ত নেওয়া যায়।

সিদ্ধান্তমূলক test সার্ভারেই চালাতে হবে। বাইরে থেকে connect করার সময় network traffic পর্যবেক্ষণ করুন:

sudo tcpdump -ni any tcp port 8080

SYN এসে যদি কোনো SYN-ACK ফিরে না যায়, তার অর্থ packet আপনার VPS-এ পৌঁছেছে এবং host সেটি drop করেছে। তাই provider firewall ঠিক আছে, কিন্তু local rule ঠিক নেই। একেবারেই কোনো output না থাকলে packet সার্ভারে পৌঁছায়নি। সে ক্ষেত্রে কারণ provider firewall, security group অথবা ভুল IP address। এই পার্থক্যটি বুঝলেই অধিকাংশ troubleshooting কাজ বাদ দেওয়া যায়।

দুটি layer এমন ফল দিতে পারে, যা প্রথমে অসম্ভব মনে হয়। প্রথমটি IPv6: hostname-এ AAAA record থাকলে আপনার client IPv6 ব্যবহার করে connect করতে পারে, অথচ আপনার rule শুধু IPv4 কভার করে। তাই কোনো ফলাফলের ওপর নির্ভর করার আগে nc -4 এবং nc -6 দিয়ে প্রতিটি address family পরীক্ষা করুন। VPS-এ ufw rules এবং IPv6 ports এই mismatch ব্যাখ্যা করে। দ্বিতীয়টি Docker: ufw status কোনো port-কে denied দেখালেও published container port Internet থেকে response দিতে পারে, কারণ ufw-এর chain দেখার আগেই packet-গুলো handle করা হয়। Docker কেন ufw-এর পাশ দিয়ে সরাসরি ports publish করে এতে mechanism এবং fix ব্যাখ্যা করা হয়েছে। আর নতুন VPS-এ যে ufw rules সেট করবেন হলো শুরুতে প্রয়োগ করার উপযোগী base set।

UDP-এর উত্তর নকশাগতভাবেই অস্পষ্ট

UDP-তে কোনো handshake নেই। তাই একটি probe-এর সফল হওয়ার নির্দিষ্ট শর্ত থাকে না। প্যাকেট পাঠানো শুরু হলেই nc -zu 203.0.113.10 53 0 exit status নিয়ে শেষ হয়। এতে শুধু প্রমাণ হয় যে আপনার নিজের মেশিন প্যাকেটটি পাঠিয়েছে; দূরের প্রান্ত সম্পর্কে কিছুই প্রমাণ হয় না। UDP port বন্ধ থাকলে host সাধারণত ICMP port unreachable message পাঠায়। Kernel সেই error connected socket-এ শুধু পরবর্তী write-এর সময় জানায়। তাই একটি মাত্র packet probe এটি ধরতে পারে না। Firewall অভ্যাসগতভাবে ICMP drop করে। ফলে ওই ইঙ্গিতটিও আর থাকে না। এই কারণে অধিকাংশ UDP port-এর জন্য nmap open|filtered দেখায়। কোনো উত্তর না পাওয়া open কিন্তু নীরব service এবং filtered port—উভয় ক্ষেত্রেই একই ফল দেয়।

যে protocol পরীক্ষা করতে চান, সেটি ব্যবহার করেই UDP পরীক্ষা করুন। একটি DNS server dig +short @203.0.113.10 example.com-এর উত্তর হিসেবে address অথবা কিছুই না পাঠায়। একটি WireGuard peer sudo wg show-এ সাম্প্রতিক latest handshake line দেখায়। এরপর server side-এ packet পৌঁছানোর প্রমাণ নিন:

sudo tcpdump -ni any udp port 51820

Client পাঠানোর সময় packet দেখা গেলে বোঝা যায় সেগুলো পৌঁছেছে। সে ক্ষেত্রে সমস্যা service অথবা input chain-এ। একটিও packet দেখা না গেলে সেগুলো server-এ পৌঁছায়নি।

যে ক্রমে ত্রুটি সবচেয়ে দ্রুত শনাক্ত করা যায়, সেই checklist

1. সার্ভারে sudo ss -ltnp 'sport = :8080' চালান। কোনো output না থাকলে কোনো কিছু listening করছে না। তাই আগে service ঠিক করুন।
2. output থাকলে Local Address column দেখুন। 127.0.0.1 হলে rebind না করা পর্যন্ত বা সামনে proxy না বসানো পর্যন্ত বাইরে থেকে access সম্ভব নয়।
3. অন্য একটি network থেকে nc -zv -w 3 <public ip> 8080 চালান।
4. connection refusal হলে ধাপ 1-এ ফিরে যান। address, port বা machine—আপনি যা ভাবছেন, সেটি সঠিক নয়।
5. timeout হলে network traffic drop হচ্ছে। সার্ভারে sudo tcpdump -ni any tcp port 8080 চালু করে test আবার করুন।
6. SYN পৌঁছায়, কিন্তু কোনো response ফিরে যায় না: সমস্যা host firewall-এ। sudo iptables -L INPUT -n -v-এ যে rule-এর counter পরিবর্তিত হয়, সেটি খুঁজুন।
7. SYN পৌঁছায় না: সমস্যা provider firewall, security group বা ভুল IP address-এ।

FAQ

নিজের Linux server-এ কোন port খোলা আছে তা কীভাবে পরীক্ষা করব?

TCP-এর জন্য sudo ss -ltnp এবং UDP-এর জন্য sudo ss -lunp চালান। প্রতিটি লাইন একটি listening socket নির্দেশ করে। Local Address column থেকে বোঝা যায় কোন উৎস এটি reach করতে পারে: 0.0.0.0 এবং [::] firewall অনুমতি দিলে যেকোনো উৎস থেকে connection গ্রহণ করে, আর 127.0.0.1 শুধু একই machine থেকে connection গ্রহণ করে। Process column দেখতে root access প্রয়োজন। তাই sudo দিয়ে চালান, নইলে এই column খালি দেখাবে। ss iproute2-এর অংশ এবং এটি সবসময় installed থাকে। netstat net-tools-এর অংশ এবং সাধারণত installed থাকে না।

ss-এ service listening দেখালেও connection করতে পারছি না কেন?

এর দুটি সাধারণ কারণ আছে। একটি command ব্যবহার করে কারণ দুটি আলাদা করা যায়। Local Address যদি 127.0.0.1 হয়, service-টি loopback-এ bound এবং অন্য কোনো host থেকে reachable নয়। কারণ kernel ওই range-এর traffic শুধু loopback interface-এ route করে। Local Address 0.0.0.0 হওয়া সত্ত্বেও connection ব্যর্থ হলে server-এ sudo tcpdump -ni any tcp port <port> চালান এবং বাইরে থেকে connection করার চেষ্টা করুন। কোনো reply ছাড়া SYN পৌঁছালে local firewall rule সেটি drop করছে। কিছুই না পৌঁছালে packet আপনার VPS-এ পৌঁছানোর আগেই থামানো হচ্ছে, সাধারণত provider firewall বা security group দ্বারা।

Refused connection এবং timeout হওয়া connection-এর মধ্যে পার্থক্য কী?

Refusal একটি উত্তর। Packet host-এ পৌঁছেছে এবং TCP reset বা ICMP port unreachable ফিরে এসেছে। এর অর্থ ওই address ও port-এ কিছু listening করছে না, অথবা কোনো rule connection প্রত্যাখ্যান করেছে। Timeout হলো কোনো উত্তর না পাওয়া। কোনো rule packet drop করেছে এবং কিছু ফেরত পাঠায়নি। তাই client ব্যর্থ হওয়া পর্যন্ত retry করে। Refused হলে service এবং তার bind address পরীক্ষা করুন। Timeout হলে firewall পরীক্ষা করুন। বাইরে থেকে সবচেয়ে কাছের firewall দিয়ে পরীক্ষা শুরু করুন।

UDP port খোলা আছে কি না কীভাবে পরীক্ষা করব?

সাধারণ probe ব্যবহার করে নির্ভরযোগ্যভাবে হ্যাঁ বলা যায় না। UDP-তে handshake নেই। তাই কোনো service নীরব থাকলেও সেটি drop হওয়া packet-এর মতোই দেখায়। nc -zu packet পাঠানোর সঙ্গে সঙ্গে success return করে। একই কারণে nmap open|filtered report করে। এর বদলে protocol ব্যবহার করে পরীক্ষা করুন: DNS-এর জন্য dig +short @<host> example.com, অথবা সাম্প্রতিক handshake থাকা WireGuard peer-এর জন্য sudo wg show। Packet পৌঁছাচ্ছে কি না নিশ্চিত করতে client পাঠানোর সময় server-এ sudo tcpdump -ni any udp port <port> চালান।

Port পরীক্ষা করতে কি এখনও telnet host port ব্যবহার করা যায়?

TCP-এর জন্য এটি কাজ করে। Escape character is '^]' মানে connection গ্রহণ করা হয়েছে। Ctrl+] দিয়ে এটি বন্ধ করুন এবং তারপর quit চালান। দুটি কারণে nc -z বেশি উপযোগী: বর্তমান অধিকাংশ server image-এ telnet installed থাকে না, এবং nc-এ -w দিয়ে timeout নির্ধারণ করা যায় ও script-এ পরীক্ষা করার মতো exit status পাওয়া যায়। দুটিই না থাকলে timeout 3 bash -c '</dev/tcp/<host>/<port>' কোনো package ছাড়াই ব্যবহার করা যায়।