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 पहा।
- मार्ग शोध चुकीचा इंटरफेस दाखवते: मार्गाचा मालक मॅनेजर किंवा कंटेनर आहे, तुमची फाइल नाही।
- संख्यात्मक पत्ता ठीक आणि होस्टनाव तुटलेले: जुना संदर्भ, मार्गनिर्देशन लूप नाही।
- पुन्हा सुरू केल्यानंतरही नवीन प्रीफिक्स वापरला गेल्यावरच बदल पूर्ण होतो।