ufw lockout होने पर VPS का एक्सेस कैसे वापस पाएं

वापस एक्सेस प्राप्त करना

यदि ufw ने आपको आपके VPS से बाहर कर दिया है, तो वापस अंदर जाने का एकमात्र तरीका provider console या rescue mode है, क्योंकि एक बार blocking rule लागू हो जाने के बाद SSH आधारित कोई समाधान काम नहीं करता है। Kernel आपके packet को sshd तक पहुँचने से पहले ही drop कर देता है, इसलिए network के माध्यम से न तो login करने के लिए कुछ बचता है और न ही सुधारने के लिए। अपने provider के control panel में console खोलें, उस prompt पर login करें और एक command चलाएँ।

sudo ufw disable

आपको Firewall stopped and disabled on system startup दिखाई देना चाहिए। नए SSH connections एक या दो second के भीतर फिर से काम करने लगेंगे। आपके द्वारा configure की गई कोई भी चीज़ नष्ट नहीं होती है: disable kernel से rules को हटा देता है और /etc/ufw/ufw.conf में ENABLED=no लिख देता है, जबकि आपके rules /etc/ufw/user.rules में disk पर सुरक्षित रहते हैं और अगले ufw enable की प्रतीक्षा करते हैं।

Reboot करके उम्मीद न लगाएँ। ufw boot के समय खुद को start कर लेता है, इसलिए ENABLED=yes का मतलब है कि network चालू होने से पहले ही वही ruleset फिर से load हो जाएगा। Reboot करने से ufw lockout की स्थिति में कोई बदलाव नहीं आता है।

कंसोल के लिए ऐसे पासवर्ड की आवश्यकता है जो शायद आपके पास न हो

वेब कंसोल (VNC या सीरियल) मशीन से जुड़ा एक कीबोर्ड है। यह नेटवर्क पाथ नहीं है, इसलिए कोई भी firewall rule इसे ब्लॉक नहीं कर सकता। इसके लिए local login की आवश्यकता होती है, और यहीं पर केवल key-based सेटअप विफल हो जाते हैं: यदि आपने अपने sudo user के लिए कभी पासवर्ड सेट नहीं किया है, और root login लॉक है, तो कंसोल आपको एक ऐसा प्रॉम्प्ट दिखाएगा जिसका आप उत्तर नहीं दे पाएंगे। अभी वह पासवर्ड सेट करें, जब तक आपके पास SSH एक्सेस है: sudo passwd yourname। अधिकांश पैनल root पासवर्ड को रीसेट भी कर सकते हैं, जिसके लिए आमतौर पर रीबूट की आवश्यकता होती है।

यदि कंसोल अनुपयोगी है, तो प्रदाता के rescue 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 नहीं होता है। सामान्य सिस्टम में रीबूट करें और ufw तब तक बंद रहेगा जब तक आप इसे मैन्युअल रूप से सक्षम नहीं करते।

न्यूनतम रिकवरी अनुक्रम

इस क्रम में कार्य करें। पहले चार चरण सुरक्षित हैं। उसके बाद वाला चरण सुरक्षित नहीं है।

1. नियमों को हटाने और अपना एक्सेस वापस पाने के लिए sudo ufw disable का उपयोग करें।
2. आपके द्वारा जोड़े गए नियमों को उन कमांड्स के रूप में प्रिंट करने के लिए sudo ufw show added का उपयोग करें, जिनसे उन्हें जोड़ा गया था। यह तब भी काम करता है जब ufw निष्क्रिय हो, जो कि ufw status नहीं करता है।
3. यह पुष्टि करने के लिए sudo sshd -T | grep -i '^port' का उपयोग करें कि sshd वास्तव में किस पोर्ट पर लिसन (listen) कर रहा है। यदि आपने इसे बदला नहीं है, तो यह port 22 प्रिंट करता है।
4. अपने वास्तविक पोर्ट का उपयोग करते हुए sudo ufw allow 22/tcp चलाएं, ताकि अगली बार enable करने पर आप फिर से लॉकआउट न हों।
5. रोलबैक शेड्यूल करने के बाद sudo ufw enable चलाएं। यह इस पेज पर आगे दिया गया है।

ufw reset वास्तव में क्या करता है

ufw reset अंतिम उपाय है, न कि पहला कदम। यह firewall को disable कर देता है, प्रत्येक rules file का backup लेता है, और defaults को incoming के लिए deny और outgoing के लिए allow पर वापस सेट कर देता है। यह प्रति file एक backup line print करता है:

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

reset के बाद आपके पास कोई भी allow rule नहीं बचता है, इसलिए इसे SSH के बजाय console से चलाएं, और enable करने से पहले SSH rule को फिर से जोड़ें। वे backups plain text में होते हैं। sudo grep -n dport /etc/ufw/user.rules.20260813_101500 दिखाता है कि पुराने rules क्या थे, और इसी तरह आप उस ruleset को फिर से बना सकते हैं जिसे आप हटाना नहीं चाहते थे।

ufw अपने rules कहाँ रखता है

याददाश्त के भरोसे अनुमान लगाने से बेहतर है कि आप फाइलों को पढ़ें। पाँच paths में पूरी स्थिति (state) सुरक्षित रहती है:

• /etc/ufw/user.rules और /etc/ufw/user6.rules: आपके द्वारा जोड़े गए rules, उसी क्रम में जिसमें उनका मूल्यांकन (evaluation) होता है।
• /etc/ufw/before.rules और /etc/ufw/after.rules, साथ ही 6 variants: वह framework जिसे ufw आपके rules के चारों ओर लपेटता है, जिसमें established connections के लिए accept और loopback rules शामिल हैं।
• /etc/default/ufw: default policies और IPV6 switch।
• /etc/ufw/ufw.conf: ENABLED और log level।
• /var/log/ufw.log: logging चालू होने पर क्या ब्लॉक किया गया था।

ufw किसी फाइल को rewrite करने से पहले उसकी एक timestamped copy बनाता है, इसलिए ls /etc/ufw/ में user.rules.20260813_101500 जैसे नाम भर जाते हैं। यह आपका undo history है, और चीजों को वापस बदलने से पहले इसे पढ़ना उपयोगी होता है।

डिस्क पर मौजूद फाइलों के बजाय kernel में क्या load है यह देखने के लिए, sudo ufw show raw, या sudo iptables -S और sudo ip6tables -S का उपयोग करें। Ubuntu 22.04 और 24.04 पर ये commands nft समर्थित संस्करण हैं, इसलिए sudo nft list ruleset उन्हीं rules को नए syntax में print करता है।

UFW enable करने पर मेरा SSH session क्यों drop हो गया?

Incoming traffic के लिए default policy 'deny' होती है। SSH port के लिए नियम बनाए बिना UFW enable करने से सभी नए connections बंद हो जाते हैं। UFW आपको चेतावनी भी देता है: Command may disrupt existing ssh connections. Proceed with operation (y|n)? बिना SSH allow नियम के y का उत्तर देना इस पृष्ठ पर दी गई समस्याओं का सबसे आम कारण है।

भ्रम का मुख्य कारण इसमें होने वाली देरी है। /etc/ufw/before.rules आपके द्वारा बनाए गए नियमों से पहले ही ESTABLISHED और RELATED state वाले packets को स्वीकार कर लेता है, इसलिए जिस session में आपने command टाइप की है, वह सामान्य रूप से काम करता रहता है। lockout केवल अगले connection पर दिखाई देता है, जो शायद घंटों बाद हो, और तब तक firewall में किया गया बदलाव संबंधित नहीं लगता। हमेशा एक दूसरा SSH session खोलें और यह सुनिश्चित करें कि वह काम कर रहा है, उसके बाद ही पहले वाले को बंद करें।

पॉलिसी बदलने के बाद apt और DNS ने काम करना क्यों बंद कर दिया?

sudo ufw default deny outgoing आउटबाउंड DNS (domain name system) क्वेरी और आउटबाउंड HTTP को ब्लॉक करता है, इसलिए नाम रिज़ॉल्यूशन विफल हो जाता है और पैकेज अपडेट रुक जाते हैं। apt update, Temporary failure resolving 'archive.ubuntu.com' रिपोर्ट करता है। इनबाउंड SSH अभी भी काम करता है, क्योंकि इसके उत्तर ESTABLISHED होते हैं और फ्रेमवर्क नियमों से गुजर जाते हैं, जिससे फायरवॉल निर्दोष दिखता है जबकि वास्तव में वही इसका कारण होता है।

यदि आप आउटगोइंग पॉलिसी को deny करना चाहते हैं, तो केवल वही खोलें जिसकी मशीन को वास्तव में आवश्यकता है:

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

अंतिम नियम के बिना घड़ी का समय गलत (drift) हो जाता है, और गलत समय TLS (transport layer security) सर्टिफिकेट वैलिडेशन को तोड़ देता है, इसलिए curl पोर्ट के बजाय तारीखों पर विफल होने लगता है। यह लक्षण बदलाव के कुछ दिनों बाद दिखाई देता है, यही कारण है कि आउटगोइंग को deny करना उन मशीनों के लिए एक पॉलिसी है जिनकी आप निगरानी करते हैं, न कि उस बॉक्स के लिए जिसे आप एक बार सेट करके छोड़ देते हैं।

मेरा ufw rule कभी match क्यों नहीं होता?

ufw उपयोगकर्ता द्वारा बनाए गए नियमों का मूल्यांकन क्रम में करता है और पहले match पर रुक जाता है। एक व्यापक allow के बाद जोड़ा गया deny कभी काम नहीं करता, क्योंकि allow नियम ने पैकेट के बारे में पहले ही निर्णय ले लिया होता है। नियमों के क्रम को संख्याओं के साथ देखने के लिए कमांड चलाएँ, फिर नियम को अपनी आवश्यकतानुसार सही स्थान पर 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 उन नियमों को print करता है जो लिखे जाएंगे, यह किसी भी सेटिंग में बदलाव नहीं करता है। किसी नियम को लागू करने से पहले उसे पढ़ने का यह सबसे सुरक्षित तरीका है।

एक और समस्या application profiles में होती है। sudo ufw allow OpenSSH, /etc/ufw/applications.d/openssh-server में मौजूद profile का उपयोग करता है, और उस profile का अर्थ port 22 होता है। यदि sshd, 2222 port पर listen कर रहा है, तो यह नियम एक ऐसे port को खोल देगा जिसका उपयोग कोई नहीं कर रहा है, और आप एक ऐसे ruleset के साथ locked out हो जाएंगे जो देखने में सही लगता है। port बदलने के बाद हमेशा port संख्या का ही उपयोग करें। बाकी syntax की जानकारी VPS के लिए ufw firewall की बुनियादी बातें में दी गई है।

IPv4 नियम मेरी देखी हुई स्थिति को स्पष्ट क्यों नहीं करते?

क्योंकि आधा traffic IPv4 नहीं है। Ubuntu में IPV6=yes, /etc/default/ufw में मौजूद होता है, और ufw फिर /etc/ufw/user6.rules में एक समानांतर v6 नियम-सेट (ruleset) बनाए रखता है। IPv4 पते के साथ लिखा गया नियम, जैसे कि ufw allow from 203.0.113.10 to any port 22, कोई v6 नियम नहीं बनाता है। यदि आपके VPS में AAAA रिकॉर्ड है, तो आपका client IPv6 को प्राथमिकता देता है, और आपका connection time out हो जाता है जबकि ufw status एक ऐसा नियम दिखाता है जो सही दिखता है। ssh -6 user@host के विरुद्ध ssh -4 user@host के साथ अंतर का परीक्षण करें। यदि पहला काम करता है और दूसरा नहीं, तो कमी v6 नियम-सेट में है।

सुरक्षा के लिए विपरीत स्थिति और भी खराब है। IPV6=no के साथ, ufw ip6tables को बिल्कुल भी प्रबंधित नहीं करता है, इसलिए v6 नीति kernel के डिफ़ॉल्ट ACCEPT पर बनी रहती है। एक port जिसे आप बंद मानते हैं, वह अपने IPv6 पते पर प्रतिक्रिया देता है, और कोई भी ufw कमांड कभी इसका उल्लेख नहीं करेगा। sudo ip6tables -S और ss -tlnp के साथ जाँच करें, और पूरी जानकारी के लिए ufw IPv6 ports को कैसे संभालता है पढ़ें।

जब ufw इसे deny करता है, तो Docker port open क्यों रहता है?

Docker, nat table में DNAT (destination network address translation) rules लिखकर और FORWARD में अपनी chain डालकर port publish करता है। ufw के rules INPUT path में स्थित होते हैं। container तक जाने वाला traffic host को deliver होने के बजाय forward किया जाता है, इसलिए यह उस chain तक कभी नहीं पहुँचता जहाँ आपका deny rule मौजूद है। ufw के active होने और सब कुछ 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 चाहे कुछ भी कहे, बाहर से कोई भी इसे access नहीं कर सकता। ufw के साथ Docker publishing ports उन स्थितियों को कवर करता है जहाँ service को public होना आवश्यक है।

नियम लागू करने से पहले रोलबैक शेड्यूल करें

यह वह आदत है जो फायरवॉल के साथ काम करने को सुरक्षित बनाती है। किसी भी जोखिम भरे बदलाव से पहले, उसे पूर्ववत (undo) करने का समय निर्धारित करें। यदि बदलाव के कारण आप लॉक हो जाते हैं, तो मशीन पांच मिनट में खुद को ठीक कर लेती है और आपको कंसोल खोलने की आवश्यकता नहीं पड़ती।

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

systemd Running timer as unit: ufw-rollback.timer प्रिंट करता है। अब अपना बदलाव करें। यदि आप उसके बाद भी एक नया SSH सेशन खोल सकते हैं, तो रोलबैक को रद्द कर दें:

sudo systemctl stop ufw-rollback.timer

यदि आप वह सेशन नहीं खोल सकते हैं, तो प्रतीक्षा करें। ufw अपने आप बंद हो जाता है और आपका अगला प्रयास कनेक्ट हो जाएगा। क्लासिक shutdown -r +5 ट्रिक ufw के साथ काम नहीं करती है, क्योंकि ufw बूट होने पर वही रूल्सेट दोबारा लोड कर लेता है।

एक्सेस का दूसरा तरीका बनाए रखें

• प्रदाता (provider) के कंसोल में एक बार लॉग इन करें, इससे पहले कि आपको इसकी आवश्यकता हो, और पुष्टि करें कि पासवर्ड काम कर रहा है। जिस कंसोल का आपने कभी परीक्षण नहीं किया है, वह बैकअप नहीं है।
• एक दूसरा sudo user रखें जिसकी अपनी key हो, ताकि एक खराब authorized_keys फ़ाइल आपके एक्सेस के अंत का कारण न बने।
• जाँचें कि क्या आपका प्रदाता पैनल में कोई नेटवर्क फ़ायरवॉल चलाता है, जो ufw से अलग हो। यह उन्हीं पोर्ट्स को ब्लॉक करता है, और ufw status कभी इसका उल्लेख नहीं करेगा।
• यदि वह पता डायनामिक है, तो ufw allow from <your home address> को अपना एकमात्र SSH नियम न बनाएं। आपका प्रदाता इसे रात भर में बदल देता है और आप बाहर हो जाते हैं।

यह सब करने का सबसे सस्ता समय एक नए सर्वर पर है, नए VPS पर पहले दस मिनट में किए जाने वाले अन्य सेटअप कार्यों के साथ।

Refused या timed out यह बताते हैं कि कौन सी लेयर विफल हुई है

Connection refused का अर्थ है कि पैकेट सर्वर तक पहुँच गया और किसी चीज़ ने वापस TCP reset भेजा। नेटवर्क पाथ सही है, इसलिए sshd बंद है या किसी अन्य port पर listen कर रहा है। firewall इसका कारण शायद ही कभी होता है, क्योंकि ufw डिफ़ॉल्ट रूप से reject करने के बजाय drop करता है।

Connection timed out का अर्थ है कि वापस कुछ भी नहीं आया। यह drop का संकेत है: ufw, प्रदाता का नेटवर्क firewall, या गलत पता। इन दो त्रुटियों को सही ढंग से पढ़ने से अनुमान लगाने में लगने वाला एक घंटा बच जाता है, और connection refused और timed out के बीच का अंतर शेष मामलों को हल करता है।

Turn logging on before the next change

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

A blocked packet appears like this:

[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 with your own address in SRC= is proof that ufw is the thing blocking you, not the network and not sshd. On a minimal image with no rsyslog there is no /var/log/ufw.log, and the same lines come from sudo journalctl -k | grep UFW. ufw rate limits its own logging rules, so a missing line is not proof that a packet was allowed.

यदि आपको ऐसे नियम मिलते हैं जिन्हें आपने कभी नहीं जोड़ा

यदि ruleset अपने आप बदल गया है, तो यह firewall की समस्या नहीं है। किसी ने root access का उपयोग करके इसे लिखा है। यह देखने के लिए कि कौन से sudo commands और किस account के तहत चलाए गए थे, sudo grep ufw /var/log/auth.log चलाएँ, और फिर उस timestamp के आसपास के logins के लिए last चलाएँ। यदि accounts किसी ऐसे व्यक्ति से मेल नहीं खाते जिसे आप जानते हैं, तो firewall की debugging बंद करें और इसके बजाय compromised VPS के लिए checklist का पालन करें। किसी ऐसे server पर firewall को फिर से enable करना जिसे कोई और नियंत्रित कर रहा है, केवल समस्या को छिपाता है।

सब कुछ वापस व्यवस्थित करें

एक बार जब आप कारण जान लें, तो ufw को इस तरह से फिर से enable करें कि lockout की स्थिति दोबारा न बने। अपने वास्तविक SSH port को allow करें, rollback को schedule करें, enable करें, और फिर किसी अन्य terminal से एक नया SSH session खोलकर पुष्टि करें कि वह connect हो रहा है। उस नए session के चालू होने के बाद ही उस session को बंद करें जिस पर आप काम कर रहे हैं। logging को एक दिन के लिए चालू रहने दें, क्योंकि log आपको यह बहुत तेजी से बता देता है कि आपने क्या allow करना छोड़ दिया था, बजाय इसके कि आप user.rules को पढ़ें।

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 उन्हें list करता है। ufw reset वह command है जो उन्हें clear करती है, और यह पहले हर file का backup लेती है, साथ ही Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500' जैसी एक line print करती है।

क्या VPS को reboot करने से ufw lockout ठीक हो जाएगा?

नहीं। ufw boot के समय /etc/ufw/ufw.conf में स्थित ENABLED=yes से start होता है, इसलिए network active होने से पहले ही वही rules load हो जाते हैं और आप फिर से lock हो जाते हैं। reboot केवल तब मदद करता है जब आपने ufw को बंद कर दिया हो, या rescue mode से disk mount करके उस file को edit कर लिया हो। provider console का उपयोग करें और वहाँ sudo ufw disable चलाएँ।

जब ufw port को deny करता है, तब भी मेरा Docker container क्यों reachable है?

Docker हर published port के लिए अपने स्वयं के DNAT और FORWARD rules लिखता है। वह traffic host तक पहुँचने के बजाय सीधे container को forward कर दिया जाता है, इसलिए वह कभी भी INPUT chain से नहीं गुजरता जहाँ आपका ufw deny rule स्थित होता है। यदि port केवल host के लिए है, तो -p 127.0.0.1:5432:5432 के साथ loopback पर publish करें, और sudo iptables -t nat -S DOCKER के साथ जाँचें कि Docker ने क्या install किया है।

मेरे पास न तो console password है और न ही rescue mode। मेरे पास क्या विकल्प हैं?

बाकी विकल्प आपके provider के पास हैं: control panel से password reset करना, जो आमतौर पर सर्वर को reboot कर देता है, या disk को किसी अन्य instance से attach करना ताकि आप वहाँ से /etc/ufw/ufw.conf को edit कर सकें। सर्वर को rebuild करने से पहले support से बात करें, क्योंकि rebuild करने से उस पर मौजूद data नष्ट हो जाता है। एक बार वापस access मिलने पर, sudo passwd yourname चलाएँ और console login का परीक्षण करें, ताकि अगली बार lockout होने पर आपका केवल दो मिनट का समय बर्बाद हो।