VPN सर्वर को नए सार्वजनिक IP पर ले जाना: पहले क्या जाँचें
जगह पर बदलाव और समानांतर कटओवर अलग-अलग जगहों पर टूटते हैं। कॉन्फ़िग, NAT और प्रमाणपत्र देखें, फिर देखें कि हर क्लाइंट नाम को कैसे हल करता है।
किसी पते को फिर से आवंटित करने में एक मिनट लगता है। उसके बाद का सप्ताह वह जगह है जहाँ बदलाव टूटता है, और शायद ही वहाँ जहाँ प्रदाता का कंसोल संकेत देता है। नए सार्वजनिक IP का उल्लेख चार जगहों पर होता है: वह सॉकेट जिस पर डेमन सुनता है, वह विश्वास-एंकर जिसे क्लाइंट सत्यापित करते हैं, पुराने पते का नाम लेने वाला हर नियम, और वह DNS रिकॉर्ड जो उन्हें जोड़ता है। दो बदलाव कंट्रोल पैनल से एक जैसे दिखते हैं पर पूरी तरह अलग व्यवहार करते हैं: जिस मशीन को आप चलाते हैं उस पर पता फिर से आवंटित करना, या दूसरा एंडपॉइंट खड़ा करके क्लाइंट को उस पर ले जाना। नीचे की जाँचें सस्ती विफलताओं को पहले रखती हैं, और हर भाग बताता है कि वह किस बदलाव पर लागू होता है।
जगह पर बदलाव और समानांतर कटओवर अलग काम हैं
जगह पर बदलाव मेज़बान, कुंजियाँ, रूटिंग तालिका और उपयोगकर्ता सूची रखता है; केवल पता बदलता है। फ़्लोटिंग IP का पुनः आवंटन यही करता है, और कई प्रदाताओं पर अतिथि को पता भी नहीं चलता, क्योंकि अनुवाद इंस्टेंस के सामने होता है। रीबिल्ड या प्रदाता द्वारा पुनः आवंटन कठोर है: अतिथि बदलाव देखता है, और जिसने भी पुराना मान कैश किया था वह उसे उसी पल जान लेता है।
समानांतर एंडपॉइंट एक दूसरा मेज़बान है जो वही काम करता है। इसे बनाएँ, एक प्रोफ़ाइल से जाँचें, और नए के वास्तविक मार्ग पर खुद को साबित करने तक पुराने को जवाब देने दें। कीमत स्थिति है। साझा peer प्रविष्टियों, निरसन और लॉगिंग के बिना आपके पास दो नेटवर्क हैं जो संयोगवश एक नाम साझा करते हैं।
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
पुराना पता जहाँ भी लिखा है, वह हर जगह खोजें
टेक्स्ट स्कैन से शुरू करें, क्योंकि कॉन्फ़िगरेशन फ़ाइलें आसान आधा हिस्सा हैं। डेमन कॉन्फ़िग, फ़ायरवॉल के टुकड़े, मॉनिटरिंग लक्ष्य और डिस्क पर बना कोई भी क्लाइंट बंडल खोजें। IPv6 पता भी शामिल करें यदि आप एक प्रकाशित करते हैं; केवल A रिकॉर्ड का पीछा करने वाला बदलाव दोहरे स्टैक वाले क्लाइंट को पुराने मार्ग पर छोड़ देता है।
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsफिर कर्नेल को देखें, क्योंकि चल रहा सिस्टम पता ऐसी जगहों पर रखता है जिनका कोई फ़ाइल उल्लेख नहीं करता। स्थिर स्रोत NAT नियम, ipset प्रविष्टि, बाइंड पता और conntrack प्रविष्टि उस कॉन्फ़िग बदलाव से अधिक जीते हैं जिसने उन्हें हटाया था, और कुछ रीबूट भी पार कर जाते हैं क्योंकि वे सहेजे गए नियम-समूह से लौट आए। एक परत ऊपर, प्रदाता के सुरक्षा समूह, लोड बैलेंसर लक्ष्य और मॉनिटरिंग जाँच आपकी फ़ाइल प्रणाली पर हैं ही नहीं।
कुछ भी बदलने से पहले सूची लिख लें; यह रोलबैक स्क्रिप्ट का काम भी करती है।
होस्टनाम वाले क्लाइंट सँभल जाते हैं; शाब्दिक IP वाले क्लाइंट चुप हो जाते हैं
यदि क्लाइंट होस्टनाम से सर्वर तक पहुँचते हैं, तो कटओवर मुख्यतः DNS समस्या है, और कल आपने जो TTL सेट किया था वह तय करता है कि यह कितना बुरा होगा। रिज़ॉल्वर कैश करते हैं, stub रिज़ॉल्वर फिर से कैश करते हैं, और बहुत से क्लाइंट नाम केवल नए कनेक्शन पर देखते हैं, इसलिए स्थापित टनल अपना शुरुआती पता रखती है।
यदि एंडपॉइंट शाब्दिक पता है, तो कुछ भी दोबारा हल नहीं होता और कुछ भी शिकायत दर्ज नहीं करता। WireGuard हल किया गया सॉकेट पता संग्रहीत करता है: Endpoint = vpn.example.net:51820 उसी क्षण IP बन जाता है जब wg-quick up चलता है और तब तक वही IP रहता है जब तक आप उसे न बदलें। OpenVPN अधिक उदार है: यह कनेक्शन के समय remote होस्टनाम हल करता है और resolv-retry infinite के साथ फिर से जुड़ने पर दोबारा DNS आज़माता है। शाब्दिक IP देने पर दोनों ऐसी मशीन पर डायल करते रहते हैं जो अब नहीं है।
लोगों को भ्रमित करने वाली चीज़ दर्पण-छवि है। नए पते की ओर पहले से इंगित क्लाइंट, जब पुराना श्रोता अभी भी जवाब दे रहा हो, आपकी अपनी मेज़ से किया गया हर परीक्षण पास कर जाता है। मुझे भी इससे धोखा मिला: नया एंडपॉइंट फ़ोन पर पहले प्रयास में ऊपर आ गया, और पुरानी प्रोफ़ाइल वाला क्लाइंट तभी सामने आया जब पुराना श्रोता बहुत बाद में बंद किया गया।
विश्वास पते के साथ नहीं जाता
WireGuard पहचान को पहुँच से अलग करता है, जिससे पता बदलना लगभग मुफ़्त हो जाता है। Peer सार्वजनिक कुंजी से पहचाने जाते हैं, और एंडपॉइंट केवल वह जगह है जहाँ पैकेट अभी जाते हैं; मेज़बान सबसे हाल के प्रमाणित पैकेट के स्रोत पते से peer का एंडपॉइंट अद्यतन करता है। निष्क्रिय peer को अभी भी नई जगह से बात करने का कारण चाहिए, और वह पता तभी सीखता है जब उसका सत्र पुराना हो जाए और handshake के पुनः प्रयास किसी दिखने वाली जगह पर विफल हों। WireGuard की त्वरित शुरुआत एंडपॉइंट फ़ील्ड को शामिल करती है।
TLS आधारित सर्वर विपरीत स्थिति हैं। प्रमाणपत्र एक नाम से बंधा है, और पता डायल करने वाला क्लाइंट जो डायल किया उसे विषय के वैकल्पिक नामों से तुलना करता है। केवल DNS SAN वाले प्रमाणपत्र से IP द्वारा जुड़ें और सत्यापन विफल हो जाता है: क्लाइंट ने जो नाम इस्तेमाल किया वह प्रमाणपत्र में नहीं है। IP SAN के साथ पुनः जारी करना उस एक कनेक्शन को ठीक करता है और अगले बदलाव को बदतर बनाता है। प्रोफ़ाइल में होस्टनाम रखना और verify-x509-name को उसकी जगह छोड़ना जाँच को सख्त रखता है जबकि नीचे का पता बदलता रहता है।
फिर जाँचें कि डेमन किससे बंधा है; पुराने पते पर पिन किया गया सॉकेट चुपचाप विफल हो जाता है। local 203.0.113.10 के साथ शुरू किया गया OpenVPN सर्वर उस पते के जाने पर ऊपर आने से इनकार कर देता है, जबकि 0.0.0.0 पर श्रोता बदलाव को मुफ़्त में अपनाता है। NAT इसी तरह बँटता है: MASQUERADE अब मशीन के पास जो भी पता है उसका पीछा करता है, और स्थिर SNAT --to-source 203.0.113.10 उस पते पर फिर से लिखता रहता है जो अब आपका नहीं, इसलिए वापसी ट्रैफ़िक गायब हो जाता है। यदि नया पता अलग upstream गेटवे के साथ आता है, तो rp_filter जाँचें: रिवर्स-पाथ फ़िल्टरिंग उस इंटरफ़ेस पर आने वाला वापसी ट्रैफ़िक गिरा देती है जिसकी कर्नेल को अपेक्षा नहीं थी।
कटओवर का क्रम और इसके काम करने के प्रमाण
एक दिन पहले TTL घटाएँ, नया श्रोता खड़ा करें, और इसे ऐसी प्रोफ़ाइल से साबित करें जो केवल आपके पास हो। उसी नेटवर्क के भीतर से परीक्षण लगभग कुछ साबित नहीं करता, इसलिए सेलुलर पर फ़ोन लें और एंडपॉइंट पर ping के बजाय वह चीज़ जाँचें जिसे टनल को ढोना है।
पूरी अवधि में दोनों पतों पर नज़र रखें। नए मेज़बान पर wg show all latest-handshakes, या OpenVPN स्थिति फ़ाइल, बताती है कि वास्तव में कितने peer बदले। जब नए एंडपॉइंट पर अपेक्षित peer हों और पुराने पर केवल पीछे छूटे हुए, तो पुराने श्रोता को हटाएँ, पुराना NAT नियम हटाएँ और प्रदाता के फ़ायरवॉल से पता निकालें। पुराने श्रोता को हटाना ही वह कदम है जो छूट जाता है, और यह उस अंतराल को बंद करता है जहाँ पुरानी प्रोफ़ाइल अभी भी पुराने नेटवर्क तक पहुँचती है।
शुरू करने से पहले रोलबैक ट्रिगर लिखित रूप में तय करें: यदि सहमत अवधि के बाद नए एंडपॉइंट को किसी एक भी वास्तविक क्लाइंट से handshake न मिले, तो पुराना पता बहाल करें और प्रोफ़ाइल बाँटना बंद करें। बाद में स्कैन दोबारा चलाएँ और पुष्टि करें कि कोई श्रोता अब भी हटाए गए पते से बंधा नहीं है। दो चीज़ें अगले बदलाव में जाती हैं: क्लाइंट प्रोफ़ाइल में होस्टनाम ताकि अगला परिवर्तन DNS संपादन हो, और सर्वर के पुनर्प्राप्ति नोट्स के पास रखी सूची।