सार्वजनिक 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दोन्ही हॅश फक्त रिकाम्या जागांमध्ये वेगळे असतील तर तो फॉर्मॅटिंग बदल आहे। ते एंडपॉइंटमध्ये वेगळे असतील तर ऑपरेटरने काहीतरी हलवले आहे आणि प्रकाशित फाइल ही प्राधिकृती आहे। प्रकाशित फाइल तुमच्याकडील फाइलपेक्षा जुनी असेल तर तुम्ही कदाचित कॅशे पाहत आहात आणि जुने उत्तर तुम्हाला चुकीच्या दिशेने पाठवेल।
जुनी नोंद सेवानिवृत्त करा आणि काय घडले ते नोंदवा
कार्यरत बदलीची पडताळणी झाल्यावर जुनी प्रोफाइल पर्याय म्हणून ठेवण्याऐवजी हटवा। अर्धवट जोडणारी जुनी नोंद सापळा आहे: ती बिघाडाच्या वेळी निवडली जाईल, ती हळू अपयशी होईल आणि डीबग करणारा पहिले दहा मिनिटे चुकीच्या फाइलवर घालवेल।
कॉन्फिगरेशनबाहेर एक छोटी नोंद ठेवा: तारीख, जुना एंडपॉइंट, अयशस्वी टप्पा आणि त्याची जागा कशाने घेतली। सार्वजनिक नोड बदलतात आणि सहा आठवड्यांनंतर तोच प्रश्न दुसऱ्या व्यक्तीसह येतो। नोट्स फाइलमधील एक ओळ त्याला सेकंदांत उत्तर देते।
एका नेटवर्कमधून प्रत्येक नोड त्याच पद्धतीने अपयशी होत असेल आणि दुसऱ्यातून एकही नाही, तर प्रोफाइल बदलणे थांबवा आणि स्थानिक मार्ग पाहा। कॅप्टिव्ह पोर्टल, गाळलेली पोर्ट श्रेणी किंवा अडवणारा प्रॉक्सी असंबंधित पुरवठादारांमध्ये सारख्याच त्रुटी निर्माण करतील आणि हाच नमुना समस्या कधीच फाइल नव्हती याचा एकमेव संकेत आहे।