सार्वजनिक 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दुई ह्यास केवल खाली ठाउँमा फरक भए त्यो ढाँचा परिवर्तन हो। तिनीहरू एन्डपोइन्टमा फरक भए अपरेटरले केही सारेको छ र प्रकाशित फाइल नै अधिकार हो। प्रकाशित फाइल तपाईंसँग भएकोभन्दा पुरानो भए तपाईं सम्भवतः क्यास हेर्दै हुनुहुन्छ, र पुरानो जवाफले तपाईंलाई गलत दिशामा पठाउनेछ।
पुरानो प्रविष्टि हटाउनुहोस् र के भयो लेख्नुहोस्
कार्यरत प्रतिस्थापन प्रमाणित भएपछि, पुरानो प्रोफाइललाई विकल्पको रूपमा राख्नुको सट्टा मेटाउनुहोस्। आधा जोडिने पुरानो प्रविष्टि एउटा जाल हो: यो अवरोधको समयमा छानिनेछ, यो बिस्तारै असफल हुनेछ, र डिबग गर्ने व्यक्तिले पहिलो दस मिनेट गलत फाइलमा बिताउनेछ।
कन्फिगरेसन बाहिर छोटो अभिलेख राख्नुहोस्: मिति, पुरानो एन्डपोइन्ट, असफलताको चरण र यसलाई केले प्रतिस्थापित गर्यो। सार्वजनिक नोड फेरिन्छन्, र छ हप्तापछि त्यही प्रश्न अर्को व्यक्तिसँग आउँछ। नोट फाइलको एक लाइनले सेकेन्डमै त्यसको जवाफ दिन्छ।
यदि एउटा नेटवर्कबाट हरेक नोड उही तरिकाले असफल हुन्छ र अर्कोबाट कुनै पनि हुँदैन भने, प्रोफाइल सम्पादन गर्न छोड्नुहोस् र स्थानीय मार्ग हेर्नुहोस्। क्याप्टिभ पोर्टल, फिल्टर गरिएको पोर्ट दायरा वा अवरोध गर्ने प्रोक्सीले असम्बन्धित प्रदायकहरूमा उही त्रुटि उत्पन्न गर्नेछ, र त्यही ढाँचा समस्या कहिल्यै फाइल नभएको एकमात्र संकेत हो।