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 हेर्नुहोस्।
- मार्ग खोजले गलत इन्टरफेस देखाउँछ: मार्गको मालिक म्यानेजर वा कन्टेनर हो, तपाईंको फाइल होइन।
- सङ्ख्यात्मक ठेगाना ठीक र होस्टनाम बिग्रिएको: पुरानो सन्दर्भ, राउटिङ लूप होइन।
- पुनःसुरु भएपछि पनि नयाँ प्रिफिक्स प्रयोग भएपछि मात्र परिवर्तन पूरा हुन्छ।