Skip to content
VDS · समस्या निवारण

मशीन पर नेटवर्क चला गया

जब मशीन SSH पर जवाब न दे और खुद भी इंटरनेट पर न जा पाए तो क्या जाँचें: कंसोल, इंटरफ़ेस स्टेटस, डिफ़ॉल्ट रूट, और फ़िल्टर नियम।

23 अगस्त 2026 को अपडेट किया गया

"नेटवर्क गया" दो अलग-अलग स्थितियों को कवर करता है: बाहर से मशीन तक कुछ नहीं पहुँचता, और मशीन खुद कहीं नहीं पहुँच पाती। कंसोल से शुरू करें, क्योंकि इस स्थिति में SSH उपलब्ध नहीं होता, और कंसोल हमेशा काम करता है — यह नेटवर्क को बायपास करते हुए सीधे मशीन से जुड़ा होता है।

चरण 1. कंसोल के ज़रिए अंदर जाएँ

/hosting/vds/m/<id> खोलें, "Console" टैब। टेक्स्ट कंसोल (सीरियल पोर्ट) किसी भी कमांड के लिए काम करता है; "Screen" (VNC) की ज़रूरत तब पड़ती है जब सिस्टम सीरियल लाइन पर प्रॉम्प्ट न दिखाए। अगर कंसोल लॉगिन प्रॉम्प्ट दिखाता है, तो मशीन ज़िंदा है और समस्या नेटवर्क की है, बूट की नहीं।

अगर कोई प्रॉम्प्ट नहीं है और "Screen" कर्नेल एरर मैसेज दिखाता है, तो देखें Kernel panic: आगे क्या करें।

चरण 2. इंटरफ़ेस और एड्रेस जाँचें

ip -brief address
ip route

इंटरफ़ेस पर "Overview" टैब से आपका पब्लिक IPv4 एड्रेस होना चाहिए, और रूट में default via ... लाइन शामिल होनी चाहिए। आम तौर पर मिलने वाली बातें:

  • इंटरफ़ेस DOWN स्टेट में है — इसे अप करें: ip link set dev ens18 up;
  • मैनुअल कॉन्फ़िग एडिट के बाद एड्रेस गायब हो गया — सेटिंग्स फ़ाइल बहाल करें और नेटवर्क सर्विस रीस्टार्ट करें (Ubuntu पर systemctl restart systemd-networkd या netplan apply);
  • कोई डिफ़ॉल्ट रूट नहीं है — एक्सेस वापस पाने के लिए इसे अस्थायी रूप से ip route add default via <gateway> से बहाल करें, फिर कॉन्फ़िगरेशन ठीक करें, वरना रीबूट के बाद यह फिर होगा।

ip के ज़रिए किए गए बदलाव सिर्फ़ रीबूट तक टिकते हैं। असली ठीक कॉन्फ़िगरेशन फ़ाइल में ही होता है।

चरण 3. "कनेक्टिविटी नहीं" और "नाम नहीं" में फ़र्क़ करें

ping -c3 1.1.1.1
ping -c3 millida.net

अगर एड्रेस पिंग होता है पर नाम नहीं, तो नेटवर्क ठीक है और नाम रिज़ॉल्यूशन टूटा है: देखें नाम रिज़ॉल्व नहीं हो रहे (DNS)।

चरण 4. पैकेट फ़िल्टर देखें

एक्सेस खोने का सबसे आम कारण आपका खुद का वह नियम है जिसने लॉगिन बंद कर दिया। जाँचें:

nft list ruleset
iptables -S
ufw status verbose

अगर इनकमिंग ट्रैफ़िक पर DROP पॉलिसी दिखती है और पोर्ट 22 की अनुमति नहीं है, तो आपने खुद को SSH से काट लिया है। कंसोल के ज़रिए एक्सेस बहाल करें:

ufw allow 22/tcp
ufw reload

फ़ायरवॉल चालू करने से पहले, हमेशा उसी कमांड सेट में SSH पोर्ट की अनुमति दें। "पहले मना करें, बाद में अनुमति दें" वाला तरीका आपको एक्सेस से हाथ धोना पड़ता है।

चरण 5. SSH डेमन खुद जाँचें

नेटवर्क काम कर सकता है जबकि पोर्ट बंद हो क्योंकि सर्विस क्रैश हो गई:

systemctl status ssh
ss -tlnp | grep :22

सर्विस की स्थिति का निदान कैसे करें, यह देखें सर्विस शुरू नहीं हो रही: systemd ट्रबलशूटिंग में।

अगर कुछ भी काम न आया

"Access" टैब से SystemRescue रिकवरी डिस्क में बूट करें: बिना पासवर्ड के रूट लॉगिन, और मशीन की डिस्क /dev/sda के रूप में दिखती है। रूट माउंट करें और नेटवर्क कॉन्फ़िगरेशन को सिस्टम के "बाहर से" ठीक करें। काम पूरा होने पर, सामान्य बूट मोड पर वापस स्विच करें और मशीन रीबूट करें — वरना यह SystemRescue में ही बूट होती रहेगी।