WireGuard में होस्ट प्रीफ़िक्स: क्यों एक पता काम करता है और बाकी नहीं

टनल चालू है, handshake हर दो मिनट में होता है, और दूसरी तरफ़ ठीक एक पता जवाब देता है। पीयर के टनल पते पर ping काम करते हैं; उसके पीछे कुछ नहीं। कोई इंटरफ़ेस की कॉन्फ़िगरेशन पढ़ता है, होस्ट प्रीफ़िक्स देखता है और नतीजा निकालता है कि मास्क ग़लत है। इसे /24 तक बढ़ाना ping को कुछ देर ठीक करता है और फिर कुछ और तोड़ देता है। प्रीफ़िक्स कभी वजह नहीं था, और ग़ायब रूट वह नहीं है जिसे मास्क नियंत्रित करता है।

इंटरफ़ेस प्रीफ़िक्स वास्तव में क्या बनाता है

Linux में किसी इंटरफ़ेस को पता देने से उस प्रीफ़िक्स के लिए एक जुड़ा हुआ रूट बनता है। होस्ट प्रीफ़िक्स दें तो जुड़ा हुआ रूट एक पता कवर करता है। /24 दें तो वह 256 कवर करता है, और उनमें से हर एक अब उस लिंक पर पहुँचने योग्य माना जाता है।

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

होस्ट प्रीफ़िक्स पॉइंट-टू-पॉइंट टनल के लिए पूरी तरह सामान्य विकल्प है, क्योंकि दूसरे सिरे पर ठीक एक पीयर होता है। तीसरा कमांड वही है जो उपयोगकर्ता के सवाल का जवाब देता है: यह बताता है कि कर्नेल उस गंतव्य के लिए कौन-सा इंटरफ़ेस इस्तेमाल करेगा, और अगर कोई रूट मेल नहीं खाता तो यह कुछ काम का नहीं दिखाएगा।

लक्षण की पूरी व्याख्या यही है। एक पता जवाब देता है क्योंकि उसके लिए जुड़ा हुआ रूट मौजूद है, या क्योंकि पीयर की अनुमत सूची संयोग से उसे शामिल करती है। बाकी सबका कोई रूट नहीं और WireGuard के शामिल होने से पहले ही उसे गिरा दिया जाता है। टनल पूरे समय स्वस्थ रहती है, इसीलिए handshake काउंटर आश्वस्त करता दिखता रहता है।

AllowedIPs एक नाम के नीचे दो नियम हैं

WireGuard की प्रति-पीयर अनुमत सूची एक साथ दो काम करती है, और कॉन्फ़िगरेशन सिंटैक्स उन्हें एक जैसा दिखाता है। अंदर आने पर यह तय करती है कि पीयर कौन से स्रोत पते पेश कर सकता है। बाहर जाने पर यह चुनती है कि पैकेट किस पीयर को भेजा जाए, सबसे विशिष्ट मिलान खोजकर।

इन दोनों में से कोई काम रूटिंग नहीं है। कर्नेल को अब भी तय करना होता है कि पैकेट टनल इंटरफ़ेस का है, इससे पहले कि WireGuard उसे देखे, और यह निर्णय रूटिंग तालिका से आता है। विस्तृत अनुमत सूची वाली पीयर प्रविष्टि अपने आप कोई रूट नहीं लगाती।

इसीलिए कोई कॉन्फ़िगरेशन पूरा दिख सकता है और असममित व्यवहार कर सकता है। क्लाइंट दूसरी तरफ़ भेजता है क्योंकि रूट मौजूद है, और जवाब कभी नहीं पहुँचते क्योंकि दूसरी तरफ़ की अनुमत सूची क्लाइंट के स्रोत को अनुमति नहीं देती, या क्योंकि दूसरी तरफ़ के पास वापसी पथ नहीं है। दोनों दिशाएँ अलग-अलग निर्णय हैं अलग-अलग विफलता ढंगों के साथ। यह लिखना कि आप किसकी जाँच कर रहे हैं, निदान का आधा हिस्सा है।

रूट कहाँ से आता है

अगर आप wg-quick इस्तेमाल करते हैं, तो रूट आपके लिए हर पीयर की अनुमत सूची से बनाए जाते हैं, जब तक कि आपने Table = off सेट न किया हो और नियंत्रण ख़ुद न लिया हो। यही उपकरण का दर्ज व्यवहार है, और यही वजह है कि स्पष्ट रूट निर्देशों के बिना भी कॉन्फ़िगरेशन काम करता है।

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

अनुमत सूची की तुलना उन रूटों से करें जो वास्तव में मौजूद हैं। ऐसा पीयर जो पूरा सबनेट अनुमत करता है पर केवल एक होस्ट रूट बनाता है, इसका मतलब है कि सहायक कभी चला ही नहीं, या आप इंटरफ़ेस को सीधे wg और ip से चला रहे हैं, और तब आपके लिए कोई रूट नहीं बनाता।

जब आप इसे हाथ से चलाते हैं, तो रूट एक पंक्ति है और उसका रूप स्पष्ट है: गंतव्य इंटरफ़ेस के रास्ते, बिना गेटवे क्योंकि लिंक पॉइंट-टू-पॉइंट है। उसे जोड़ना ख़राब प्रीफ़िक्स के लिए कोई बचाव नहीं; यह ऐसे डिज़ाइन का ग़ायब आधा हिस्सा है जिसने रूटिंग ख़ुद संभाली।

चौड़ा प्रीफ़िक्स पीयर प्रविष्टि नहीं जोड़ता

लुभावना सुधार यह है कि पता /24 कर दिया जाए ताकि जुड़ा हुआ रूट सर्वर के स्थानीय नेटवर्क को कवर करे। यह काम करता दिखता है, और इसका काम करता दिखने की वजह यह है कि जुड़ा हुआ रूट अब मेल खाता है, न कि WireGuard ने कुछ नया सीखा है।

आपने यह भी किया कि पूरी श्रेणी को उस लिंक पर सीधे पहुँचने योग्य घोषित कर दिया, जिनमें वे पते भी शामिल हैं जो दूसरे पीयरों के हैं या ऐसे स्थानीय नेटवर्क के जो दरअसल सर्वर के पीछे है। उन पतों की आवाजाही अब टनल में जाती है, और वह दूसरी तरफ़ से निकलती है या नहीं यह सर्वर की अपनी रूटिंग और अनुमत सूचियों पर निर्भर है।

क्रिप्टो पक्ष किसी भी हाल में प्रभावित नहीं होता। WireGuard को पीयर चुनने के लिए अनुमत सूची में ऐसी प्रविष्टि चाहिए जो गंतव्य को कवर करे, और दूसरी तरफ़ को आपके स्रोत को स्वीकार करने के लिए ऐसी प्रविष्टि चाहिए जो उसे कवर करे। चौड़ा इंटरफ़ेस प्रीफ़िक्स इनमें से कोई भी नहीं दे सकता।

कुछ बदलने से पहले दोनों दिशाओं की पुष्टि करें

दोनों सिरों को अलग-अलग लें और लिखें कि हर एक क्या कहता है। क्लाइंट पर रूट और पीयर प्रविष्टि; सर्वर पर दर्पण छवि और उसका अपना वापसी पथ:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

कैप्चर वही है जो दिशा के बारे में विवाद तय करता है। अगर बाहर जाते पैकेट टनल इंटरफ़ेस पर दिखें और सर्वर कुछ दर्ज न करे, तो दूर का सिरा उन्हें अस्वीकार कर रहा है, आम तौर पर क्योंकि आपका स्रोत उसकी अनुमत सूची से बाहर है। अगर बिल्कुल कुछ न दिखे, तो रूट ग़ायब है या कहीं और इशारा करता है।

फिर सबसे संकरे सिरे को ठीक करें। सर्वर की तरफ़ आपके क्लाइंट पते के लिए अनुमत सूची में प्रविष्टि और क्लाइंट की तरफ़ गंतव्य सबनेट के लिए प्रविष्टि सामान्य रूप है, और यह इंटरफ़ेस प्रीफ़िक्स को छेड़ता नहीं। प्रीफ़िक्स सिर्फ़ तब बढ़ाएँ जब पता योजना सचमुच उस लिंक पर साझा सबनेट चाहती हो, और इसे डिबगिंग कदम की बजाय योजना परिवर्तन के रूप में करें।