Linux पर port open है या नहीं, यह कैसे चेक करें

Linux पर port open है या नहीं यह जाँचें: पहले सही प्रश्न चुनें

Linux पर यह जाँचने के लिए कि कोई port open है या नहीं, पहले यह तय करें कि आप क्या पूछ रहे हैं, क्योंकि "open" का अर्थ हर उस स्थान पर अलग होता है जहाँ से आप जाँच कर रहे हैं। सर्वर पर स्वयं, open का अर्थ है कि एक process उस port से bound है और प्रतीक्षा कर रही है। किसी अन्य मशीन से, open का अर्थ है कि एक packet उस process तक पहुँचता है और उत्तर वापस आता है। जब कोई उत्तर वापस नहीं आता है, तो वास्तविक प्रश्न यह है कि किस device ने packet को drop किया है। sudo ss -ltnp पहले प्रश्न का उत्तर देता है। nc -z या nmap दूसरे प्रश्न का उत्तर देते हैं। Firewall counters और tcpdump तीसरे प्रश्न का उत्तर देते हैं।

गलत जाँच करने में ही लोगों का पूरा दोपहर का समय बर्बाद हो जाता है। सर्वर पर चलाया गया test कभी भी आपके provider के network firewall को नहीं छूता है, क्योंकि वह filter box के बाहर स्थित होता है। यदि port numbers आपके लिए अभी भी नए हैं, तो Linux पर ports और sockets कैसे काम करते हैं उस मॉडल को कवर करता है जिसे यह guide मानकर चलती है।

इस बॉक्स पर कौन सी सर्विस listening है? ss आउटपुट को पढ़ें

ss, iproute2 के साथ आता है, इसलिए यह हर वर्तमान डिस्ट्रीब्यूशन पर मौजूद है। netstat, net-tools से आता है, जिसे Ubuntu ने वर्षों से डिफ़ॉल्ट रूप से इंस्टॉल नहीं किया है, इसलिए netstat -tulpn अक्सर netstat: command not found का उत्तर देता है। ss सीखें और निराशा से बचें।

sudo ss -ltnp

-l केवल listening sockets दिखाता है। -t सूची को केवल TCP तक सीमित करता है। -n नामों को रिज़ॉल्व करने के बजाय नंबर प्रिंट करता है, इसलिए कमांड तुरंत परिणाम देता है। -p ओनर प्रोसेस का नाम बताता है, और इसके लिए root की आवश्यकता होती है: sudo के बिना, आपके द्वारा ओनर न की गई हर प्रोसेस के लिए Process कॉलम खाली रहता है। 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 कॉलम सब कुछ निर्धारित करता है, और यही वह कॉलम है जिसे लोग जल्दी में पढ़कर छोड़ देते हैं।

• 0.0.0.0:22 का अर्थ है मशीन का हर IPv4 एड्रेस, इसलिए यदि फ़ायरवॉल अनुमति देता है तो यह बाहर से एक्सेस किया जा सकता है।
• [::]:22 IPv6 के लिए भी यही है।
• 127.0.0.1:8080 का अर्थ है केवल loopback। इस मशीन के बाहर से कोई भी इसे एक्सेस नहीं कर सकता।
• 10.20.0.5:5432 का अर्थ है केवल वह एक इंटरफ़ेस एड्रेस और कोई अन्य नहीं, जो प्राइवेट नेटवर्क सेटअप में सामान्य है।
• खाली Process कॉलम का अर्थ आमतौर पर missing sudo है, न कि missing प्रोसेस।

किसी एक पोर्ट के बारे में पूछने के लिए, पूरी सूची को grep करने के बजाय ss के भीतर फ़िल्टर करें:

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

तीनों से खाली आउटपुट का मतलब है कि उस पोर्ट को कोई होल्ड नहीं कर रहा है। सर्विस बंद है, यह स्टार्ट होने में विफल रही, या यह कहीं और listening है। किसी भी फ़ायरवॉल नियम को छूने से पहले 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 मानकर discard कर दिया जाता है। इसलिए process चलती रहती है, ss दिखाता है कि वह listening मोड में है, ufw allow 8080 सफलता की रिपोर्ट देता है, और आपके laptop से connection फिर भी fail हो जाता है। यह तुरंत Connection refused के साथ fail होता है, क्योंकि packet आपके public address तक पहुँचता है, वहाँ कोई socket bound नहीं मिलता, और kernel TCP reset के साथ जवाब देता है।

कई programs जानबूझकर loopback पर bind होते हैं, और database या admin interface के लिए यही सही default है। आपके पास दो उचित विकल्प हैं। Program की अपनी config में bind address बदलें (postgresql.conf में listen_addresses, redis.conf में bind, या वह host argument जो आपका application लेता है) और फिर 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 के लिए expose करता है। -p 127.0.0.1:8080:8080, loopback को bind करता है और इसे local ही रखता है।

Linux पर किसी दूसरे मशीन से यह कैसे जाँचें कि कोई पोर्ट खुला है या नहीं

इस परीक्षण को किसी अलग नेटवर्क से चलाएँ। सर्वर से किया गया परीक्षण केवल यह सिद्ध करता है कि loopback path काम कर रहा है। यहाँ तक कि सर्वर से अपने स्वयं के public IP से कनेक्ट करना भी आपके प्रदाता के नेटवर्क फायरवॉल को छोड़ देता है, क्योंकि वह फ़िल्टर VPS के बाहर चलता है।

nc -zv -w 3 203.0.113.10 443

-z डेटा भेजे बिना कनेक्ट होता है और बंद हो जाता है। -w 3 तीन सेकंड के बाद प्रयास छोड़ देता है, और वह flag महत्वपूर्ण है: बिना timeout के, एक dropped packet क्लाइंट को kernel के रुकने से पहले दो मिनट से अधिक समय तक SYN को पुनः प्रयास करने के लिए छोड़ देता है। सफलता कुछ इस तरह दिखती है:

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

यदि टूल मौजूद नहीं है (nc: command not found), तो Debian या Ubuntu पर netcat-openbsd इंस्टॉल करें, या bash के इन-बिल्ट नेटवर्क रीडायरेक्शन का उपयोग करें, जिसके लिए किसी पैकेज की आवश्यकता नहीं है:

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

वह सिंटैक्स एक bash फीचर है, इसलिए इसे bash के साथ चलाएँ। Debian और Ubuntu पर /bin/sh, dash है, जिसमें /dev/tcp नहीं होता है और यह रिपोर्ट करता है कि पथ मौजूद नहीं है। पोर्ट्स की एक रेंज के लिए, या जब आप चाहते हैं कि स्थिति आपके लिए नामित हो, तो उन hosts के विरुद्ध nmap का उपयोग करें जिनके लिए आप जिम्मेदार हैं:

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

-Pn होस्ट डिस्कवरी को छोड़ देता है। अधिकांश VPS होस्ट ICMP echo को ड्रॉप कर देते हैं, इसलिए -Pn के बिना nmap यह तय कर लेता है कि होस्ट डाउन है और कुछ भी स्कैन नहीं करता है। nmap open प्रिंट करता है जब किसी ने उत्तर दिया और कनेक्शन स्वीकार किया, closed जब किसी ने रीसेट के साथ उत्तर दिया, और filtered जब किसी ने बिल्कुल भी उत्तर नहीं दिया। वेब सर्विस के लिए, curl -sS -o /dev/null -w '%{http_code}\n' https://example.com नेटवर्क फॉल्ट को एप्लिकेशन फॉल्ट से अलग करता है, क्योंकि एक स्टेटस कोड यह सिद्ध करता है कि पूरा पाथ काम कर रहा था।

ब्लॉक किया गया पोर्ट हैंग क्यों होता है और बंद पोर्ट तुरंत रिफ्यूज क्यों करता है

एक त्वरित इनकार (Instant refusal)। पैकेट मशीन तक पहुँच गया और किसी चीज़ ने उसका उत्तर दिया।

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

दो अलग-अलग कारण बिल्कुल वही परिणाम देते हैं। या तो उस एड्रेस और पोर्ट पर कोई प्रोसेस बाउंड (bound) नहीं है, इसलिए कर्नल ने TCP रिसेट के साथ उत्तर दिया, या फिर किसी फायरवाल नियम ने रिसेट या ICMP पोर्ट अनरीचेबल मैसेज के साथ पैकेट को रिजेक्ट कर दिया। रिफ्यूज एक निश्चित उत्तर है और यह एक राउंड ट्रिप में वापस आ जाता है।

एक ठहराव, फिर टाइमआउट। किसी चीज़ ने पैकेट को ड्रॉप कर दिया और वापस कुछ नहीं कहा।

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

DROP नियम यही करता है, और यही काम प्रोवाइडर फायरवाल या क्लाउड सिक्योरिटी ग्रुप करते हैं। चुप्पी ड्रॉप की पहचान है, क्योंकि भेजने वाला यह नहीं बता सकता कि पैकेट ड्रॉप हुआ है या होस्ट डेड है।

यह लक्षण आपको बताता है कि आगे कहाँ देखना है। रिफ्यूज्ड का मतलब है कि पैकेट नेटवर्क से सही तरह से गुजर रहे हैं, इसलिए ss -ltnp पर वापस जाएं और बाइंड एड्रेस तथा पोर्ट नंबर की जांच करें। टाइमआउट का मतलब है कि पैकेट ड्रॉप किए जा रहे हैं, इसलिए बाहर से अंदर की ओर फायरवाल को पढ़ें। port 22 पर रिफ्यूज्ड बनाम टाइमआउट में इसी अंतर को पोर्ट 22 के लिए समझाया गया है, जहाँ ज्यादातर लोग इसका सामना करते हैं।

ufw जानबूझकर दोनों व्यवहार प्रदान करता है: ufw deny 8080 ड्रॉप करता है, और ufw reject 8080 रिजेक्शन भेजता है। nftables में दो टारगेट drop और reject हैं, और iptables में वे -j DROP और -j REJECT हैं। डिफ़ॉल्ट नीतियां लगभग हमेशा ड्रॉप की होती हैं, यही कारण है कि एक अनुपस्थित नियम एरर मैसेज के बजाय हैंग पैदा करता है।

पोर्ट को कौन ब्लॉक कर रहा है? बाहर से अंदर की ओर जाँच करें

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

-v काउंटर सबसे उपयोगी हिस्सा हैं। बाहर से अपना nc टेस्ट चलाएं, iptables कमांड को फिर से चलाएं, और उस काउंटर को देखें जो बढ़ा है: जिस नियम (rule) का पैकेट काउंट बढ़ता है, वही नियम आपके ट्रैफिक को हैंडल कर रहा है। यह अनुमान लगाने के बजाय सबूतों पर आधारित है।

निर्णायक टेस्ट सर्वर पर चलता है, जो बाहर से कनेक्ट करते समय वायर (नेटवर्क) पर नजर रखता है:

sudo tcpdump -ni any tcp port 8080

यदि एक SYN पैकेट आता है लेकिन कोई SYN-ACK वापस नहीं जाता है, तो इसका मतलब है कि पैकेट आपके VPS तक पहुँच गया है और होस्ट ने उसे ड्रॉप कर दिया है। इसका मतलब है कि प्रोवाइडर का फायरवॉल ठीक है और आपकी लोकल रूल्स में समस्या है। यदि कोई आउटपुट नहीं आता है, तो इसका मतलब है कि पैकेट कभी पहुँचा ही नहीं, इसलिए प्रोवाइडर फायरवॉल, सिक्योरिटी ग्रुप, या गलत IP एड्रेस इसका कारण है। यह एक अंतर अधिकांश काम को आसान बना देता है।

दो परतें ऐसे परिणाम देती हैं जो असंभव लगते हैं। पहला, IPv6: यदि होस्टनेम में AAAA रिकॉर्ड है, तो आपका क्लाइंट IPv6 के माध्यम से कनेक्ट हो सकता है जबकि आपका नियम केवल IPv4 को कवर करता है। इसलिए किसी भी परिणाम पर भरोसा करने से पहले nc -4 और nc -6 के साथ प्रत्येक फैमिली का टेस्ट करें। VPS पर ufw रूल्स और IPv6 पोर्ट्स इस बेमेल स्थिति को कवर करता है। दूसरा, Docker: एक पब्लिश किया गया कंटेनर पोर्ट इंटरनेट से जवाब देता है, भले ही ufw status उस पोर्ट को denied के रूप में लिस्ट करे, क्योंकि उन पैकेट्स को ufw की चेन के देखने से पहले ही हैंडल कर लिया जाता है। Docker क्यों ufw के ऊपर से पोर्ट्स पब्लिश करता है में इसका मैकेनिज्म और समाधान दिया गया है, और नए VPS पर सेट करने के लिए ufw रूल्स वह आधारभूत सेट है जिसे पहले रखना चाहिए।

UDP के उत्तर डिज़ाइन के अनुसार अस्पष्ट क्यों होते हैं

UDP में कोई handshake नहीं होता, इसलिए probe के सफल होने की कोई स्थिति नहीं होती। nc -zu 203.0.113.10 53 जैसे ही packet बाहर भेजता है, यह 0 exit code देता है। यह केवल यह सिद्ध करता है कि आपकी मशीन ने packet भेजा है, लेकिन यह दूरस्थ छोर (far end) के बारे में कुछ भी सिद्ध नहीं करता। जब UDP port बंद होता है, तो host सामान्यतः ICMP port unreachable संदेश के साथ उत्तर देता है। kernel इस त्रुटि को केवल अगले write प्रयास पर ही connected socket को सूचित करता है, इसलिए एक एकल packet probe इसे पकड़ नहीं पाता। Firewalls अक्सर ICMP को drop कर देती हैं, जिससे यह संकेत भी समाप्त हो जाता है। यही कारण है कि nmap अधिकांश UDP ports के लिए open|filtered प्रदर्शित करता है: कोई उत्तर न मिलना, एक open silent service और एक filtered port, दोनों का ही परिणाम हो सकता है।

UDP का परीक्षण उस protocol के माध्यम से करें जिसे आप उपयोग कर रहे हैं। एक DNS server dig +short @203.0.113.10 example.com का उत्तर एक address के साथ या बिना किसी उत्तर के देता है। एक WireGuard peer, sudo wg show में एक हालिया latest handshake पंक्ति दिखाता है। इसके बाद server side पर packet के पहुँचने की पुष्टि करें:

sudo tcpdump -ni any udp port 51820

यदि client द्वारा packet भेजने के दौरान वे दिखाई देते हैं, तो इसका अर्थ है कि वे पहुँच रहे हैं, और समस्या service या input chain में है। यदि कोई packet दिखाई नहीं देता, तो इसका अर्थ है कि वे वहाँ कभी पहुँचे ही नहीं।

दोष का पता सबसे तेजी से लगाने के लिए एक चेकलिस्ट

1. सर्वर पर sudo ss -ltnp 'sport = :8080' चलाएं। यदि कोई आउटपुट नहीं मिलता है, तो इसका मतलब है कि कोई भी सर्विस listening मोड में नहीं है, इसलिए पहले सर्विस को ठीक करें।
2. आउटपुट मिलने पर, Local Address कॉलम को पढ़ें। 127.0.0.1 का मतलब है कि जब तक आप इसे rebind नहीं करते या इसके सामने कोई proxy नहीं लगाते, तब तक बाहरी एक्सेस असंभव है।
3. किसी अन्य नेटवर्क से, nc -zv -w 3 <public ip> 8080 चलाएं।
4. कनेक्शन रिफ्यूज होने का मतलब है कि आपको चरण 1 पर वापस जाना होगा। एड्रेस, पोर्ट या मशीन वह नहीं है जो आप सोच रहे हैं।
5. टाइमआउट का मतलब है कि पैकेट ड्रॉप हो रहे हैं। सर्वर पर sudo tcpdump -ni any tcp port 8080 शुरू करें और टेस्ट को दोहराएं।
6. यदि SYN पैकेट पहुँचता है लेकिन कोई प्रतिक्रिया नहीं मिलती है, तो समस्या host firewall में है। sudo iptables -L INPUT -n -v में उस नियम (rule) को खोजें जिसका काउंटर बढ़ रहा है।
7. यदि SYN पैकेट बिल्कुल नहीं पहुँचता है, तो समस्या provider firewall, security group या गलत IP एड्रेस में है।

FAQ

मैं अपने Linux सर्वर पर यह कैसे देखूँ कि कौन से पोर्ट खुले हैं?

TCP के लिए sudo ss -ltnp और UDP के लिए sudo ss -lunp चलाएँ। प्रत्येक पंक्ति एक listening socket को दर्शाती है, और Local Address कॉलम आपको बताता है कि इसे कौन एक्सेस कर सकता है: 0.0.0.0 और [::] फायरवॉल द्वारा अनुमति प्राप्त कहीं से भी कनेक्शन स्वीकार करते हैं, जबकि 127.0.0.1 केवल उसी मशीन से कनेक्शन स्वीकार करता है। Process कॉलम के लिए root एक्सेस की आवश्यकता होती है, इसलिए इसे sudo के साथ चलाएँ, अन्यथा यह खाली दिखाई देगा। ss, iproute2 का हिस्सा है और हमेशा इंस्टॉल रहता है; netstat, net-tools का हिस्सा है और आमतौर पर इंस्टॉल नहीं होता है।

ss यह क्यों दिखाता है कि मेरी सर्विस listening मोड में है, लेकिन मैं फिर भी कनेक्ट नहीं कर पा रहा हूँ?

इसके दो सामान्य कारण हैं और एक कमांड से इनका पता लगाया जा सकता है। यदि Local Address 127.0.0.1 है, तो सर्विस loopback पर बाइंड है और किसी अन्य होस्ट से एक्सेस नहीं की जा सकती, क्योंकि कर्नेल उस रेंज को केवल loopback इंटरफ़ेस पर ही रूट करता है। यदि यह 0.0.0.0 है और कनेक्शन फिर भी विफल हो रहा है, तो सर्वर पर sudo tcpdump -ni any tcp port <port> चलाएँ और बाहर से कनेक्ट करने का प्रयास करें। यदि SYN पैकेट पहुँचता है लेकिन कोई उत्तर नहीं मिलता, तो इसका मतलब है कि स्थानीय फायरवॉल नियम उसे ड्रॉप कर रहा है। यदि कुछ भी नहीं पहुँच रहा है, तो पैकेट आपके VPS तक पहुँचने से पहले ही रुक रहा है, जो आमतौर पर प्रदाता के फायरवॉल या सिक्योरिटी ग्रुप के कारण होता है।

कनेक्शन रिफ्यूज (refused) होने और टाइम आउट (timed out) होने में क्या अंतर है?

रिफ्यूजल एक उत्तर है। पैकेट होस्ट तक पहुँचा और उसे TCP रिसेट या ICMP पोर्ट अनरीचेबल का रिस्पॉन्स मिला, जिसका अर्थ है कि उस एड्रेस और पोर्ट पर कोई सर्विस नहीं चल रही है, या किसी नियम ने इसे रिजेक्ट कर दिया है। टाइम आउट का अर्थ है चुप्पी: नियम ने पैकेट को ड्रॉप कर दिया और कोई उत्तर नहीं भेजा, इसलिए आपका क्लाइंट तब तक प्रयास करता रहता है जब तक वह हार नहीं मान लेता। रिफ्यूज होने पर सर्विस और उसके बाइंड एड्रेस की जाँच करें। टाइम आउट होने पर फायरवॉल की जाँच करें, और सबसे पहले उस फायरवॉल को देखें जो बाहरी नेटवर्क के सबसे करीब है।

मैं यह कैसे जाँचूँ कि UDP पोर्ट खुला है या नहीं?

आप एक सामान्य प्रोब से विश्वसनीय परिणाम प्राप्त नहीं कर सकते, क्योंकि UDP में कोई हैंडशेक नहीं होता और एक साइलेंट सर्विस भी ड्रॉप किए गए पैकेट जैसी ही दिखती है। nc -zu पैकेट भेजते ही सफलता की रिपोर्ट देता है, और nmap भी इसी कारण से open|filtered दिखाता है। इसके बजाय प्रोटोकॉल का उपयोग करके परीक्षण करें: DNS के लिए dig +short @<host> example.com, या हालिया हैंडशेक वाले WireGuard पीयर के लिए sudo wg show का उपयोग करें। यह साबित करने के लिए कि पैकेट पहुँच रहे हैं, क्लाइंट द्वारा पैकेट भेजने के दौरान सर्वर पर sudo tcpdump -ni any udp port <port> चलाएँ।

क्या मैं पोर्ट टेस्ट करने के लिए अभी भी telnet host port का उपयोग कर सकता हूँ?

यह TCP के लिए काम करता है, और Escape character is '^]' का मतलब है कि कनेक्शन स्वीकार कर लिया गया है। इसे Ctrl+] और फिर quit के साथ बंद करें। दो कारणों से nc -z एक बेहतर टूल है: telnet अधिकांश आधुनिक सर्वर इमेज में इंस्टॉल नहीं होता है, और nc में -w के साथ टाइमआउट सेट किया जा सकता है और यह एक ऐसा एग्जिट स्टेटस देता है जिसे आप स्क्रिप्ट में टेस्ट कर सकते हैं। जब इनमें से कोई भी उपलब्ध न हो, तो timeout 3 bash -c '</dev/tcp/<host>/<port>' का उपयोग करें, जिसके लिए किसी पैकेज की आवश्यकता नहीं होती है।