WireGuard: सबनेट बदलने के बाद पीयर तक कोई रूट नहीं — दो रास्ते
सबनेट बदलाव WireGuard को दो जगह तोड़ता है: AllowedIPs और वापसी का रास्ता। जगह पर फिर से नंबर देने की तुलना इंटरफ़ेस दोबारा बनाने से करें।
wg show में हैंडशेक ताज़ा है, एंडपॉइंट सही है, कुंजियाँ कभी नहीं बदलीं — और ping अब भी कहता है कि पीयर तक कोई रूट नहीं है। एक घंटा पहले आपने टनल का सबनेट बदला था। वह लक्षण कुंजी की समस्या नहीं, प्रीफ़िक्स के बेमेल का हस्ताक्षर है: WireGuard ने हैंडशेक पूरा किया और फिर डेटा गिरा दिया, क्योंकि स्रोत पता अब उससे मेल नहीं खाता जिसे प्राप्त करने वाला पीयर स्वीकार करेगा। सबनेट बदलाव लागू करने के दो समझदार तरीके हैं, और वे अलग-अलग जगहों पर विफल होते हैं।
बदलाव लागू करने के दो तरीके, और हर एक की कीमत
विकल्प A जगह पर फिर से नंबर देना है: इंटरफ़ेस का पता, पीयर की श्रेणियाँ, रूट और कॉन्फ़िग की हर प्रति संपादित करें, फिर दोबारा लोड करें। विकल्प B पुराने के बगल में नए प्रीफ़िक्स पर दूसरा इंटरफ़ेस बनाना, पीयर को वहाँ ले जाना, और ट्रैफ़िक वास्तव में जाने के बाद पुराना इंटरफ़ेस हटाना है।
| A: renumber in place | B: parallel interface | |
|---|---|---|
| Downtime | The reload window, per host | None if peers are added to both |
| Rollback | Re-apply the previous files | Point peers back at the old interface |
| Risk | Half-applied change: new address, old ranges | Two live interfaces with overlapping intent |
| Effort | Small, if the deployment has one owner | Higher, and needs a cleanup step |
| Fits | Two or three peers you control | Many peers, remote sites, or no maintenance window |
आधा लागू हुआ हाल ही विकल्प A को ख़तरनाक बनाता है, क्योंकि वह टूटा नहीं दिखता। इंटरफ़ेस ऊपर आता है, हैंडशेक सफल होता है, और केवल डेटा का रास्ता विफल होता है। विकल्प B अधिक काम माँगता है पर जब तक आप हर संदर्भ खोजते हैं, एक काम करता रास्ता ज़िंदा रखता है।
आपके छोर पर क्या साथ-साथ बदलना होगा
स्थानीय होस्ट पर चार चीज़ें एक ही सबनेट बताती हैं, और एक में बदलाव सब में बदलाव है: इंटरफ़ेस का पता, हर पीयर का AllowedIPs, वह रूट जो सिस्टम उन गंतव्यों के लिए इस्तेमाल करता है, और मैनेजर आपकी ओर से जो कुछ स्थापित करता है। wg-quick के साथ अंतिम दो हर बार इंटरफ़ेस उठने पर कॉन्फ़िग से बनते हैं, इसलिए पुरानी प्रति चुपचाप पुराना प्रीफ़िक्स फिर से स्थापित कर देती है।
किसी एक पर भरोसा करने के बजाय कॉन्फ़िगर किए गए की तुलना जीवित से करें:
wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5रूट खोज वह कदम है जिसे लोग छोड़ देते हैं। यह बताती है कि कर्नेल किसी गंतव्य के लिए वास्तव में क्या करेगा, जिसमें मैनेजर या कंटेनर रनटाइम द्वारा छोड़ा गया अधिक विशिष्ट रूट भी शामिल है। अगर यह टनल से अलग इंटरफ़ेस बताती है, तो कॉन्फ़िग समस्या नहीं है।
चालू इंटरफ़ेस के लिए, टनल तोड़े बिना संपादित फ़ाइल लागू करें:
wg syncconf wg0 <(wg-quick strip wg0)यह पीयर और श्रेणियाँ जगह पर ही अद्यतन करता है। यह इंटरफ़ेस का पता या रूट अद्यतन नहीं करता, क्योंकि वे WireGuard की सेटिंग नहीं हैं — इसलिए फिर से नंबर देने के लिए अब भी इंटरफ़ेस दोबारा बनाना या ip से पता बदलना, और फिर रूटिंग जाँचना ज़रूरी है।
दूर के छोर पर क्या साथ-साथ बदलना होगा
यहीं आमतौर पर सबनेट बदलाव मरता है। AllowedIPs केवल रूटिंग का संकेत नहीं है; यह उन स्रोत पतों की सूची भी है जो एक पीयर प्रस्तुत कर सकता है। जब आप क्लाइंट को फिर से नंबर देते हैं और सर्वर का AllowedIPs पुराने प्रीफ़िक्स पर छोड़ देते हैं, तो सर्वर हैंडशेक स्वीकार करता है, एन्क्रिप्टेड पैकेट प्राप्त करता है और उन्हें फेंक देता है, क्योंकि भीतरी स्रोत उस पीयर से जुड़ी किसी भी श्रेणी से मेल नहीं खाता। कोई त्रुटि लॉग नहीं होती, और क्लाइंट को टाइमआउट दिखता है।
इसलिए प्राप्त करने वाले छोर को सोच-समझकर अद्यतन करें: सर्वर पर पीयर प्रविष्टि में नया क्लाइंट प्रीफ़िक्स होना चाहिए, सर्वर का अपना वापसी रूट उस प्रीफ़िक्स के लिए टनल की ओर इशारा करना चाहिए, और सर्वर के पीछे का कोई भी डाउनस्ट्रीम नेटवर्क नया रास्ता सीखना चाहिए। पुरानी श्रेणी का नाम लेने वाली फ़ायरवॉल नीति को भी वही इलाज चाहिए, और स्रोत-आधारित चयन करने वाली हर चीज़ को भी।
दोनों विफलताओं को अलग करने वाला निदान सस्ता है। ताज़ा हैंडशेक पर डेटा न होना मतलब टनल ऊपर है और भीतरी एड्रेसिंग सहमत नहीं है। बिल्कुल हैंडशेक न होना मतलब आप पहुँच या कुंजियाँ देख रहे हैं। प्रीफ़िक्स की समस्या के लिए कुंजियाँ न घुमाएँ; यह उस एक चीज़ को रीसेट करता है जो काम कर रही थी।
आपके संपादन से अधिक जीने वाली पुरानी प्रतियाँ
फ़ाइल संपादित करना चालू सिस्टम बदलने के बराबर नहीं है, और प्रतियाँ लोगों की अपेक्षा अधिक होती हैं: इंटरफ़ेस का मालिक यूनिट या मैनेजर, किसी दूसरी डिरेक्टरी में उसी नाम की दूसरी प्रोफ़ाइल, इमेज में कॉन्फ़िग बेक किया हुआ कंटेनर, अपना संपादित संस्करण रखने वाला राउटर UI, और शुरू होने पर सहेजी गई टनल फिर से आयात करने वाला क्लाइंट ऐप। आपका बदलाव पूरा दिखने के बाद भी इनमें से हर एक पुराना प्रीफ़िक्स लौटा सकता है।
नाम भी यात्रा करते हैं। अगर संख्यात्मक रूट काम करता है पर होस्टनाम विफल होता है, तो कोई आंतरिक DNS रिकॉर्ड या सेवा कॉन्फ़िग अब भी पुराने टनल पते की ओर इशारा करता है। हर पीयर श्रेणी चौड़ी करने के बजाय संदर्भ ठीक करें, क्योंकि उससे असली समस्या ढँक जाती और साथ ही स्रोत ACL बड़ा होता।
काम करते समय एक रिकवरी रास्ता खुला रखें: होस्ट में प्रवेश का दूसरा तरीका, सीरियल कंसोल, या कॉन्फ़िग फ़ाइलों का निर्धारित रोलबैक। जो टनल बदलाव आपको उस मशीन से बाहर बंद कर दे जिसे आप बदल रहे हैं, इस काम के शाम बन जाने का सबसे आम तरीका वही है।
दोनों में से चुनना, और कट की पुष्टि
A चुनें जब हर पीयर आपका हो, संख्या कम हो, और छोटा व्यवधान स्वीकार्य हो। B चुनें जब पीयर दूर के हाथ हों जिन्हें आप नियंत्रित नहीं करते, जब साइट-से-साइट लिंक चालू रहना चाहिए, या जब आप गारंटी नहीं दे सकते कि हर प्रति एक ही पास में अद्यतन होगी। उस स्थिति में नया प्रीफ़िक्स दोनों इंटरफ़ेस में जोड़ें, पीयर को एक-एक करके ले जाएँ, नए पर ट्रैफ़िक देखें, और तभी पुराना इंटरफ़ेस और उसके रूट हटाएँ।
किसी भी विकल्प में बदलाव तब पूरा होता है जब चार जाँच पास हों: हैंडशेक ताज़ा है, नए प्रीफ़िक्स के गंतव्य के लिए रूट खोज टनल का नाम लेती है, कुछ सौ बाइट का पेलोड दोनों दिशाओं में जाता है, और होस्ट या मैनेजर के रीस्टार्ट के बाद भी वही रहता है। इसके लिए wg(8) मैनुअल हर दिशा में AllowedIPs का अर्थ क्या है, इसका संदर्भ है, और किसी लक्षण को गायब करने के लिए श्रेणी चौड़ी करने से पहले इसे दोबारा पढ़ना उचित है।
- हैंडशेक ताज़ा और डेटा नहीं: कुंजियों को छूने से पहले प्राप्तकर्ता पर AllowedIPs देखें।
- रूट खोज गलत इंटरफ़ेस दिखा रही है: रूट का मालिक मैनेजर या कंटेनर है, आपकी फ़ाइल नहीं।
- संख्यात्मक पता ठीक और होस्टनाम टूटा: पुराना संदर्भ, रूटिंग लूप नहीं।
- बदलाव तभी पूरा है जब रीस्टार्ट के बाद भी नया प्रीफ़िक्स इस्तेमाल होता है।