दोन WireGuard peer एक श्रेणी सामायिक करतात: पॅकेट कोणाला मिळते

दोन peer एकमेकांना स्पर्श करणाऱ्या श्रेणी सूचीबद्ध करतात, आणि रहदारी चुकीच्याकडे पोहोचते। काहीही खराब झालेले नाही: WireGuard गंतव्याला कॉन्फिगर केलेल्या श्रेणींशी जुळवून peer निवडतो, आणि सर्वात विशिष्ट जुळणी जिंकते। काहीही रुंदावण्यापूर्वी कोणत्या peer कडे कोणता प्रीफिक्स असावा हे ठरवा।

WireGuard मध्ये सर्वात लांब प्रीफिक्स जिंकतो

प्रत्येक peer नोंद गंतव्य प्रीफिक्सचा संच बाळगते। पॅकेट इंटरफेसमध्ये राउट होतो तेव्हा, अंमलबजावणी सर्वात विशिष्ट जुळणारा प्रीफिक्स असलेली नोंद शोधते — राउटिंग तक्ता लागू करतो तोच नियम। म्हणून /24 त्याला समाविष्ट करणाऱ्या /16 ला हरवते, आणि अरुंद peer रहदारी प्राप्त करतो।

road-warrior सेटअप हे जाणूनबुजून वापरतात। एक peer साइटसाठी रुंद श्रेणी ठेवतो, आणि वैयक्तिक होस्ट इतर peer च्या /32 नोंदींनी वेगळे केले जातात। हा नमुना कारणास्तव चालतो की वेगळे केलेले भाग अधिक विशिष्ट आहेत, क्रमामुळे नाही।

मालकी प्रीफिक्स आणि peer च्या तक्त्याप्रमाणे लिहा। जर दोन नोंदी एकाच प्रीफिक्सचे वर्णन करतात, तर कॉन्फिगरेशन यापुढे हेतू व्यक्त करत नाही, ते शर्यत व्यक्त करते।

ऑपरेटिंग सिस्टम आधी इंटरफेस निवडते

WireGuard फक्त एका इंटरफेसच्या peer मध्येच निवडतो। कोणता इंटरफेस पॅकेट घेईल हे आधी ठरते, होस्टच्या राउटिंग तक्त्याने, आणि दुसरा डीफॉल्ट मार्ग किंवा जुना मार्ग रहदारी अशा ठिकाणी पाठवू शकतो जिथे peer यादी ती कधीही पाहत नाही। म्हणूनच peer स्तरावरील निदान बरोबर असू शकते आणि तरीही बिघाड समजावून सांगत नाही। peer कॉन्फिगरेशन वाचण्यापूर्वी गंतव्याचा मार्ग तपासा, कारण भौतिक इंटरफेसकडे निर्देश करणारा मार्ग संपूर्ण प्रश्न टाळतो।

साधन सामान्यतः ते मार्ग peer श्रेणींमधून स्थापित करते, म्हणजे एका peer च्या यादीतील बदल पूर्वी दुसऱ्याचा असलेली रहदारी शांतपणे पुनर्निर्देशित करू शकतो। म्हणून peer संपादन हे छद्मवेषातील राउटिंग बदल आहे। दोन्ही एकत्र पाहा, अन्यथा एक दुरुस्त कराल आणि दुसरे तोडाल।

येणारे पॅकेट स्रोतानुसार तपासले जातात

श्रेणी यादी दुहेरी भूमिका बजावते। बाहेर जाणाऱ्या रहदारीसाठी ती गंतव्यानुसार peer निवडते, आणि आत येणाऱ्या रहदारीसाठी ती स्रोत पत्त्याला अधिकृत करते। त्या peer च्या श्रेणींबाहेरील पत्त्यावरून येणारे पॅकेट कोणत्याही फायरवॉलला दिसण्यापूर्वीच टाकून दिले जाते।

कॉन्फिगरेशनची एक बाजू वाचताना ही विषमता चुकवणे सोपे आहे। जो peer सबनेटपर्यंत पोहोचू शकतो त्याला त्यामुळे त्या सबनेटमधून पाठवण्याची परवानगी मिळत नाही, आणि दोन्ही दिशा वेगवेगळ्या तपासण्यांद्वारे लागू केल्या जातात।

अरुंद स्रोत मालकी हे लाभात बदलते। प्रत्येक peer ला त्याच्या स्वतःच्या पत्त्यासाठी /32 द्या आणि खालील फायरवॉलला जुळवण्यासाठी विश्वासार्ह स्रोत मिळेल, कोणताही सदस्य दावा करू शकेल अशा गट-व्यापी श्रेणीऐवजी।

डुप्लिकेट श्रेणी failover नाहीत

एकच प्रीफिक्स दोन peer ना देणे लोड बॅलन्सर किंवा स्टँडबाय मार्ग तयार करत नाही। आरोग्य तपासणी नाही आणि सत्र आसक्ती नाही: जिंकणारी नोंद अंमलबजावणीच्या अंतर्गत क्रमाने ठरते, जो डिझाइन करण्यासाठी करार नाही। तुम्हाला पर्यायी निर्गम हवे असल्यास, निवड जिथे परिभाषित आहे तिथे ते व्यक्त करा। राउटिंग धोरण, मेट्रिक, किंवा प्रत्येकासाठी दस्तऐवजीकृत मालक असलेले दोन भिन्न प्रीफिक्स — यापैकी प्रत्येक अंदाज आणि चाचणी करता येणारे वर्तन निर्माण करते।

असंबंधित बिघाड दुरुस्त करण्यासाठी श्रेणी रुंदावणे ही दुसरी सामान्य चूक आहे। ती रहदारी काम करणाऱ्या peer पासून दूर नेते, आणि जुने समजण्यापूर्वी नवीन लक्षण येते।

संपादनापूर्वी निवड सत्यापित करा

तीन आदेश तीन प्रश्नांची क्रमाने उत्तरे देतात। पहिला प्रत्येक peer दावा करणाऱ्या श्रेणी सूचीबद्ध करतो। दुसरा होस्ट गंतव्यासाठी कोणता इंटरफेस वापरेल ते दाखवतो। तिसरा रहदारी वाहल्यानंतर peer ची थेट स्थिती दाखवतो।

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

बदलापूर्वी आणि नंतर ते चालवा आणि तुलना करा। जर मार्गाचे आउटपुट बदलले पण रहदारी अजूनही चुकीच्या peer कडे पोहोचते, तर प्रीफिक्स याद्या तुम्ही अजून लिहिले नसलेल्या पद्धतीने ओव्हरलॅप होतात। जर मार्गाचे आउटपुट बदलले नाही, तर peer कॉन्फिगरेशन हीच ती गोष्ट कधीही नव्हती ज्याची विचारणा होत होती।

तिकिटात गंतव्य, निवडलेला इंटरफेस आणि निवडलेला peer नोंदवा। तीच त्रिकूट ओव्हरलॅप नंतर पुनरावलोकनयोग्य बनवते, आणि ती कॉन्फिगरेशनच्या स्क्रीनशॉटपेक्षा खूप उपयुक्त आहे।