ज़्यादातर VPN समस्याएँ कुछ गिने-चुने कारणों तक सिमट जाती हैं, और उन्हें सही क्रम में जाँचने से पूरी शाम बच जाती है। जब तक किसी कदम में कुछ और न कहा गया हो, कमांड सर्वर पर चलाएँ। उदाहरणों में WireGuard अपने डिफ़ॉल्ट पोर्ट 51820/udp पर है; OpenVPN या Xray के लिए अपनी सर्विस का नाम और पोर्ट डालें।
अंतिम जाँच 2026-11-13।
1. क्या सर्वर अपने IPv4 वाले प्लान पर है?
VPN क्लाइंट बाहर से आपके सर्वर की ओर कनेक्ट करता है। NAT प्लान बाहर से सिर्फ़ एक पोर्ट अंदर आने देता है, यानी आपका निजी SSH पोर्ट, इसलिए उस पर कोई भी VPN नहीं चल सकता। अगर डैशबोर्ड में पता 20xxx जैसे पोर्ट के साथ दिखता है, तो आप NAT पर हैं। अपने IPv4 पर जाने से आपका डेटा बना रहता है और दोबारा इंस्टॉल नहीं करना पड़ता; देखें IP पता बदलना।
2. क्या सर्विस चल रही है?
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 30 --no-pager
OpenVPN में यूनिट आमतौर पर openvpn-server@server होती है, Xray में xray। जो सर्विस शुरू नहीं हो पाई, वह लगभग हमेशा अपने लॉग की आख़िरी लाइनों में कारण बताती है: कॉन्फ़िग में टाइपो, कुंजी फ़ाइल ग़ायब, या पोर्ट पहले से इस्तेमाल में।
3. क्या वह उसी पोर्ट पर सुन रही है जिसकी आप उम्मीद करते हैं?
ss -ulpn | grep 51820 # UDP: WireGuard, OpenVPN over UDP
ss -tlpn | grep 443 # TCP: Xray / VLESS, OpenVPN over TCP
कोई आउटपुट न आए तो सर्विस वहाँ नहीं सुन रही, कॉन्फ़िग में चाहे जो लिखा हो। पोर्ट को अपने क्लाइंट वाले पोर्ट से मिलाएँ।
4. क्या फ़ायरवॉल उसे आने देता है?
ufw status verbose
अगर फ़ायरवॉल चालू है और आपका पोर्ट सूची में नहीं है, तो उसे खोलें:
ufw allow 51820/udp
प्रोटोकॉल पर ध्यान दें: WireGuard को UDP चाहिए, और 51820/tcp का नियम उसके किसी काम का नहीं। फ़ायरवॉल चालू या रीलोड करने से पहले SSH का नियम बना रहने दें, वरना आप ख़ुद को बाहर बंद कर लेंगे। अगर फिर भी ऐसा हो जाए, तो डैशबोर्ड का ब्राउज़र कंसोल आपको वापस अंदर ले आएगा।
5. क्या क्लाइंट सच में सर्वर तक पहुँच रहा है?
WireGuard में handshake यह बताता है:
wg show
किसी peer पर latest handshake: N seconds ago का मतलब है कि क्लाइंट सर्वर तक पहुँचा और कुंजियाँ मेल खाती हैं। अगर handshake की लाइन ही नहीं है, तो वह कभी पहुँचा ही नहीं। तब इसी क्रम में जाँचें: क्लाइंट कॉन्फ़िग में endpoint का IP और पोर्ट, चरण 4 का फ़ायरवॉल, और क्या क्लाइंट की पब्लिक कुंजी सर्वर के [Peer] ब्लॉक में है (और उल्टा भी)।
6. कनेक्ट तो है, पर कुछ नहीं खुलता?
टनल काम कर रही है, लेकिन सर्वर ट्रैफ़िक को इंटरनेट पर नहीं भेज रहा। फ़ॉरवर्डिंग जाँचें:
sysctl net.ipv4.ip_forward
इसका नतीजा 1 होना चाहिए। अगर नहीं, तो इसे स्थायी रूप से चालू करें:
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-vpn.conf
sysctl --system
फिर NAT नियम जाँचें। WireGuard कॉन्फ़िग में यह MASQUERADE वाली PostUp लाइन है, और उसमें इंटरफ़ेस का नाम आपके सर्वर के असली इंटरफ़ेस का होना चाहिए:
ip -br addr
अगर लाइन में -o eth0 लिखा है लेकिन आपके इंटरफ़ेस का नाम कुछ और है, तो कॉन्फ़िग ठीक करें और सर्विस को रीस्टार्ट करें।
7. किसी दूसरे नेटवर्क से आज़माएँ
घर के Wi-Fi की जगह मोबाइल डेटा से कनेक्ट करें, या किसी दूसरे देश के व्यक्ति से कोशिश करने को कहें। अगर वहाँ VPN चलता है लेकिन आपके सामान्य नेटवर्क से नहीं, तो सर्वर ठीक है और बीच में कुछ कनेक्शन को ब्लॉक कर रहा है।
- यह देखने के लिए कि आपका सर्वर किसी ख़ास देश से पहुँच में है भी या नहीं: कैसे जाँचें कि आपके VPS का IP रूस और ईरान से पहुँच में है या नहीं।
- जहाँ WireGuard और OpenVPN पहचाने और ब्लॉक किए जाते हैं, वहाँ VLESS + Reality सामान्य HTTPS जैसा दिखता है और उसे ब्लॉक करना कहीं ज़्यादा मुश्किल है।
8. अब भी अटके हैं?
एक टिकट खोलें और बताएँ कि आपने क्या-क्या जाँचा: चरण 2–5 का आउटपुट और अपने VPN क्लाइंट का नाम। इससे हम आमतौर पर पहले ही जवाब में बता देते हैं कि दिक्कत कहाँ है।
टिप्पणियाँ
अभी तक कोई टिप्पणी नहीं। पहले बनें।