VPN प्रदाता बदलना: केवल IP नहीं, होस्टनेम की योजना बनाएँ
नया DNS रिकॉर्ड मौजूदा सत्रों को नहीं हिलाता। योजना बनाएँ कि नाम कौन नियंत्रित करता है, हर क्लाइंट इसे कब हल करता है, और आप पुराने एंडपॉइंट को कैसे सेवानिवृत्त करेंगे।
आपका DNS रिकॉर्ड सही है, प्रतिस्थापन स्वस्थ है, और फिर भी कुछ क्लाइंट घंटों तक पुराने पते पर डायल करते रहते हैं। कुछ ऐसे नाम पर तुरंत विफल हो जाते हैं जो हल होता है और कभी उत्तर नहीं देता। दोनों परिणाम एक ही खाई से आते हैं: होस्टनेम बदलता है कि क्लाइंट क्या खोजता है, यह नहीं कि वह कब खोजता है, और यह भी नहीं कि उत्तर आने पर वह किस पर भरोसा करता है।
लक्षण: सही रिकॉर्ड, पुरानी सुरंगें
नाम संग्रहीत करने वाला प्रोफ़ाइल ऐसा क्लाइंट नहीं है जो उसे लगातार हल करता रहे। अधिकांश एक बार हल करते हैं, कॉन्फ़िगरेशन लागू करते समय या सुरंग के ऊपर आने पर, और फिर सत्र समाप्त होने तक उसी पते का पुन: उपयोग करते हैं। इसके ऊपर लंबा TTL होना ही कारण है कि कटओवर की योजना DNS संपादन के बजाय पुन: कनेक्शनों के आसपास बनानी पड़ती है।
दोनों में से कोई भी व्यवहार दोष नहीं है, और यही लक्षण को भ्रमित करने वाला बनाता है। क्लाइंट उस उत्तर पर काम कर रहा है जो उसे पहले मिला था, और सर्वर की ओर कुछ भी नहीं दिखाता कि वह कौन सा उत्तर था। पुन: कनेक्शन को रखरखाव विंडो में शामिल करें और उपयोगकर्ताओं को बताएँ कि उन्हें क्या दिखेगा, या विंडो टिकटों के उत्तर देने में बिताएँ। एक जैसी रिपोर्टों की कतार सामान्य परिणाम है।
नाम कौन नियंत्रित करता है, और क्लाइंट क्या सत्यापित करता है
ज़ोन पर नियंत्रण तय करता है कि माइग्रेशन कितनी तेज़ी से आगे बढ़ सकता है। रिकॉर्ड ऐसे रजिस्ट्रार के पास रखें जहाँ आप लॉग इन कर सकें, और लिख लें कि और कौन इसे बदल सकता है।
भरोसा नाम का पीछा नहीं करता। TLS-आधारित क्लाइंट प्रमाणपत्र की पहचान या पिन किए गए नाम की जाँच कर सकता है, जबकि WireGuard साथी की सार्वजनिक कुंजी को प्रमाणित करता है और होस्टनेम को पूरी तरह अनदेखा करता है। यही अंतर तय करता है कि DNS संपादन पर्याप्त है या हर प्रोफ़ाइल को नया फ़िंगरप्रिंट चाहिए। रिकॉर्ड परिवर्तन को कभी भी ऐसे एंडपॉइंट को अधिकृत नहीं करना चाहिए जिसे किसी ने स्वीकृत न किया हो।
प्रशासनिक और पुनर्प्राप्ति पहुँच को सार्वजनिक क्लाइंट नाम से दूर रखें। होस्टिंग खाता खोने पर क्लाइंट को रीडायरेक्ट करने वाला रिकॉर्ड भी नहीं जाना चाहिए। पुनर्प्राप्ति पथ को ऐसी जगह संग्रहीत करें जो उस प्रदाता पर निर्भर न हो जिसे आप छोड़ रहे हैं।
हर क्लाइंट नाम को कब फिर से पढ़ता है
हल होने का समय हर क्लाइंट का गुण है, इसलिए कटओवर विंडो का वादा करने से पहले उस कार्यान्वयन की जाँच करें जो आप वास्तव में भेजते हैं। wg-quick इंटरफ़ेस के ऊपर आने पर एंडपॉइंट हल करता है और सुरंग फिर से शुरू होने तक वही पता रखता है। OpenVPN क्लाइंट कनेक्ट होने पर नाम खोजता है, और पुन: कनेक्शन पर फिर देखता है या नहीं, यह उसके विकल्पों पर निर्भर करता है।
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
मोबाइल क्लाइंट आम आश्चर्य हैं, क्योंकि वे नींद या नेटवर्क बदलाव के दौरान हल किया गया पता रख सकते हैं। A और AAAA रिकॉर्ड तभी प्रकाशित करें जब प्रतिस्थापन दोनों परिवारों में उत्तर दे। एक परिवार में उत्तर देने वाला पता दूसरे के बारे में कुछ सिद्ध नहीं करता, और मृत AAAA रिकॉर्ड हर प्रयास में एक समय-सीमा जोड़ता है। आप जिस भी क्लाइंट का समर्थन करते हैं उसके लिए हल करने का व्यवहार दस्तावेज़ करें, फिर उन उपकरणों पर परीक्षण करें जो लोग वास्तव में उपयोग करते हैं।
पुन: कनेक्शन अधिकांश क्लाइंट में उपयोगकर्ता की क्रिया है, और सर्वर इसे थोप नहीं सकता। उस चरण को रखरखाव नोट में रखें, साथ में एक पंक्ति कि जब ऐसा होगा तो उपयोगकर्ता क्या देखेगा।
प्रमाण के आधार पर कटओवर करें, फिर पुराने एंडपॉइंट को सेवानिवृत्त करें
स्विच से पहले प्रतिस्थापन पर हर परत सिद्ध करें: श्रोता उत्तर देता है, फ़ायरवॉल पोर्ट को पार करने देता है, रूट सही दिशा में लौटते हैं, नाम नए पते पर हल होता है, और ज्ञात पहचान स्वीकार की जाती है। कनेक्शन स्वीकार करने वाला श्रोता हैंडशेक पूरा करने वाले के समान नहीं है, इसलिए पोर्ट नहीं, हैंडशेक का परीक्षण करें। वर्तमान निरसन सूची को कॉन्फ़िगरेशन के पास रखें, क्योंकि पुनर्स्थापित बैकअप साथी सूची को वैसा ही फिर से बनाता है जैसी वह थी और आपके द्वारा पहले से बंद किए गए पहुँच को फिर से खोल देगा। लिखें कि आपने किस पहचान से परीक्षण किया, क्योंकि «यह काम करता है» ऐसा प्रमाण नहीं है जिसे कोई दोहरा सके।
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesसंक्रमण के दौरान, एक ही पहचान के लिए दोनों एंडपॉइंट पर कनेक्शन प्रयासों पर नज़र रखें। पुराने पते के विरुद्ध अभी भी प्रमाणित होने वाला क्लाइंट एक प्रोफ़ाइल या कैश किया गया उत्तर है जो कभी नहीं हिला। पुराने एंडपॉइंट को तिथि-युक्त योजना पर सेवानिवृत्त करें, क्योंकि एक पहचान स्वीकार करने वाली दो सेवाएँ दो दरवाज़े खुले छोड़ देती हैं।
कटओवर परीक्षण नए एंडपॉइंट के माध्यम से एक एप्लिकेशन सत्र है, पिंग नहीं। जैसे ही वह सत्र काम करता है और पुराना एंडपॉइंट पूर्ण पुन: कनेक्शन चक्र में कोई अधिकृत प्रयास दर्ज नहीं करता, स्थानांतरण पूरा हो गया है।