सार्वजनिक VPN कॉन्फ़िग ने काम करना बंद कर दिया? विफलता का चरण पढ़ें
डाउनलोड की गई प्रोफ़ाइल एक दिन में एक होस्ट का वर्णन करती है। पढ़ें कि कौन-सा दावा टूटा, सामने वाले पक्ष द्वारा प्रस्तुत प्रमाणपत्र जाँचें, और सत्यापन कभी बंद न करें।
प्रोफ़ाइल मंगलवार को काम कर रही थी, और शुक्रवार को क्लाइंट तीस सेकंड तक घूमता है और हार मान लेता है। आपकी मशीन पर कुछ नहीं बदला। यही मूल बात है: डाउनलोड की गई कॉन्फ़िगरेशन एक क्षण में एक होस्ट का वर्णन करती है, और दूसरी तरफ़ के ऑपरेटर पर उस विवरण को सच रखने का कोई दायित्व नहीं है। लालच यह है कि सुरक्षा सेटिंग्स बदलना शुरू कर दिया जाए जब तक सुरंग फिर से ऊपर न आ जाए। यही प्रवृत्ति लोगों को प्रमाणपत्र सत्यापन बंद किए हुए प्रोफ़ाइल चलाने तक पहुँचाती है, जो सुरंग बिल्कुल न होने से भी बुरा है।
फ़ाइल एक क्षण का वर्णन करती है, अनुबंध का नहीं
कॉन्फ़िगरेशन फ़ाइल दावों का एक समूह है: यह होस्टनाम इस पोर्ट पर इस प्रोटोकॉल के साथ सुनता है, इस नाम से मेल खाता प्रमाणपत्र प्रस्तुत करता है, और इन क्रेडेंशियल को स्वीकार करता है। जब इनमें से कोई भी सच होना बंद कर देता है, फ़ाइल पुरानी हो जाती है और सुधार सीमा के ऑपरेटर पक्ष का होता है, आपकी सेटिंग्स का नहीं।
सार्वजनिक नोड सूचियाँ अपनी प्रकृति से यह स्पष्ट कर देती हैं। नोड स्वयंसेवक चलाते हैं, वे प्रकट होते हैं और गायब हो जाते हैं, पते पुनः उपयोग होते हैं और पोर्ट उस नेटवर्क द्वारा अवरुद्ध होते हैं जिसके पीछे वे हैं। सूची एक स्नैपशॉट है जो फिर से बनाया जाता है, और आपकी डिस्क पर पड़ी प्रति पुराने स्नैपशॉट की तस्वीर है।
व्यावसायिक सेवाएँ धीमी गति से बदलती हैं, पर कभी नहीं ऐसा नहीं है। प्रमाणपत्र प्राधिकरण बदलते हैं, श्रोता साझा पते से समर्पित पते पर जाता है, पुराना प्रोटोकॉल हटाया जाता है और नई साइफ़र सूची आती है। इनमें से हर एक अदृश्य रहता है जब तक आपका क्लाइंट जुड़ने का प्रयास न करे और फ़ाइल की अपेक्षा से भिन्न उत्तर न पाए।
कोई सेटिंग छूने से पहले विफलता का चरण पढ़ें
त्रुटि संदेश बताता है कि कौन-सा दावा टूटा, और हर दावे का सुधार पूरी तरह अलग है। होस्टनाम के हल न होने पर साइफ़र संपादित करना एक दोपहर बर्बाद करता है और किसी को कुछ नहीं सिखाता।
| What happens | The assertion that broke | Supported response |
|---|---|---|
| Name never resolves | The host still exists under that name | Get a current endpoint from the operator |
| TCP connect times out | The listener is on that port and reachable | Check the current published port, then the local network |
| TLS or key exchange fails | The peer presents the expected identity | Compare the certificate, not the cipher list |
| Authentication rejected | The account is still valid | Get credentials reissued or stop using the service |
dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/nullबीच की पंक्ति अवरुद्ध पथ को टूटे हैंडशेक से अलग करती है, और तीसरी वास्तव में प्रस्तुत प्रमाणपत्र का जारीकर्ता और वैधता तिथियाँ दिखाती है। यदि वह जारीकर्ता वह नहीं है जिसे प्रोफ़ाइल ने पिन किया था, तो प्रमाणपत्र बदल गया है, और कोई भी क्लाइंट-पक्ष विकल्प पुराने पिन को फिर सही नहीं बनाएगा।
प्रमाणपत्र और पहचान के बदलाव ही शांत होते हैं
अधिकांश विफलताएँ स्वयं की घोषणा करती हैं। पहचान के बदलाव नहीं करते, क्योंकि प्रमाणपत्र का नाम पिन करने वाला क्लाइंट पूरी तरह अच्छे नए प्रमाणपत्र को ऐसे संदेश के साथ अस्वीकार करेगा जिसे बहुत लोग बग समझते हैं। सुरंग ठीक है। पिन पुराना है।
कोई निष्कर्ष निकालने से पहले पहचान के विकल्प खोजें:
grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -datesयदि प्रोफ़ाइल में एम्बेडेड CA है और ऑपरेटर नए प्राधिकरण पर चला गया है, तो पुरानी फ़ाइल नए सर्वर को सत्यापित नहीं कर सकती। CA ब्लॉक को ऑपरेटर द्वारा प्रकाशित ब्लॉक से बदलना वैध सुधार है। सत्यापन निर्देश हटाना नहीं, और ये वही कीस्ट्रोक हैं जिनका परिणाम बहुत अलग है।
ऑपरेटर में किसी बदलाव के बिना भी क्लाइंट अपग्रेड वही लक्षण पैदा कर सकता है। जिन विकल्पों को चुपचाप सहन किया जाता था, अब वे अस्वीकार होते हैं, या पुराना प्रोटोकॉल हटा दिया जाता है। यह आपके सॉफ़्टवेयर की अनुकूलता सीमा है, और सर्वर को दोष देने से पहले उसी क्लाइंट पर दूसरी प्रोफ़ाइल आज़माना उचित है।
केवल ऑपरेटर ही वैध प्रतिस्थापन प्रकाशित कर सकता है
जब कोई नोड गायब हो जाता है, तो प्रतिस्थापन उसी स्रोत से आना चाहिए जिसने मूल प्रकाशित किया था। सीधे संदेश में आने वाली प्रोफ़ाइल, क्योंकि वह «वही सर्वर नाम उपयोग करती है», किसी अज्ञात पक्ष की असत्यापित कॉन्फ़िगरेशन है, और उसे आयात करना उस पक्ष को आपके राउटिंग पर नियंत्रण देता है।
जाँच सस्ती है। प्रकाशित स्थान से वर्तमान फ़ाइल लाएँ, एंडपॉइंट और प्रोटोकॉल की सूची से तुलना करें, और फ़ाइल के नाम पर भरोसा करने के बजाय CA सामग्री की फ़िंगरप्रिंट की पुष्टि करें:
curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpnयदि दोनों हैश केवल रिक्त स्थान में भिन्न हैं, तो यह स्वरूपण परिवर्तन है। यदि वे एंडपॉइंट में भिन्न हैं, तो ऑपरेटर ने कुछ स्थानांतरित किया है और प्रकाशित फ़ाइल ही प्राधिकार है। यदि प्रकाशित फ़ाइल आपके पास की फ़ाइल से पुरानी है, तो आप संभवतः कैश देख रहे हैं, और पुराना उत्तर आपको गलत दिशा में भेजेगा।
पुरानी प्रविष्टि को हटाएँ और लिखें कि क्या हुआ
काम करने वाला प्रतिस्थापन सत्यापित होने के बाद, पुरानी प्रोफ़ाइल को विकल्प के रूप में रखने के बजाय हटा दें। आधी जुड़ने वाली पुरानी प्रविष्टि एक जाल है: वह किसी व्यवधान के दौरान चुनी जाएगी, वह धीरे-धीरे विफल होगी, और डिबग करने वाला व्यक्ति पहले दस मिनट गलत फ़ाइल पर बिताएगा।
कॉन्फ़िगरेशन के बाहर एक छोटा रिकॉर्ड रखें: तिथि, पुराना एंडपॉइंट, विफलता का चरण और उसका स्थान किसने लिया। सार्वजनिक नोड बदलते हैं, और छह सप्ताह बाद वही प्रश्न किसी दूसरे व्यक्ति के साथ आता है। नोट्स फ़ाइल में एक पंक्ति सेकंडों में उसका उत्तर देती है।
यदि एक नेटवर्क से हर नोड उसी तरह विफल होता है और दूसरे से कोई नहीं, तो प्रोफ़ाइल संपादित करना बंद करें और स्थानीय पथ देखें। कैप्टिव पोर्टल, फ़िल्टर की गई पोर्ट श्रेणी या इंटरसेप्ट करने वाला प्रॉक्सी असंबंधित प्रदाताओं पर समान त्रुटियाँ पैदा करेगा, और यही पैटर्न एकमात्र संकेत है कि समस्या कभी फ़ाइल नहीं थी।