WireGuard पूर्ण टनल: AllowedIPs 0.0.0.0/0 पर्याप्त नहीं है

पीयर के AllowedIPs में 0.0.0.0/0, ::/0 डालना वह कदम है जो सबको याद रहता है, और यह केवल तय करता है कि पीयर को कौन-सा ट्रैफ़िक ढोने की अनुमति है। ये प्रीफ़िक्स कोई रूट नहीं बनाते, दूसरी तरफ़ कुछ फ़ॉरवर्ड नहीं करते, और हर एप्लिकेशन के रिज़ॉल्वर को ठीक वहीं छोड़ देते हैं जहाँ वह था। पूर्ण टनल के वास्तव में पूर्ण होने के लिए चार अलग बातें एक साथ सत्य होनी चाहिए, और उन्हें नीचे दिए क्रम में जाँचना सबसे अच्छा है, क्योंकि बाद की जाँच पहले की जाँच को नहीं बचा सकती। नीचे की हर जाँच एक तथ्य है जिसे मशीन से पढ़ा जा सकता है, ऐसी सेटिंग नहीं जिसके लागू होने की आशा आप रखते हैं।

पीयर प्रीफ़िक्स क्या चुनता है, और क्या नहीं

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

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

क्लाइंट को रूट करना, केवल पीयर सूची नहीं

जैसे मैनेजर wg-quick आपके लिए होस्ट की रूटिंग तालिका प्रोग्राम करते हैं, इसीलिए दो समान कॉन्फ़िगरेशन फ़ाइलें इस पर निर्भर करके अलग व्यवहार करती हैं कि इंटरफ़ेस कैसे ऊपर आया। न्यूनतम प्रोफ़ाइल एक बार में पढ़ने के लिए काफ़ी छोटी है:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

काम दो विवरण उठाते हैं। Address फ़ील्ड एक ही होस्ट प्रीफ़िक्स है, ऐसा सबनेट नहीं जिसे क्लाइंट अपना मानता है, और मैनेजर ही डिफ़ॉल्ट AllowedIPs को वास्तविक डिफ़ॉल्ट रूट में बदलता है। वही फ़ाइल ip link और wg setconf से ऊपर लाएँ और कोई भी रूट दिखाई ही नहीं देगा, जो टूटी टनल जैसा लगता है और वास्तव में रूटिंग चरण छोड़ दी गई एक स्वस्थ टनल है। wg-quick मैनुअल उस रूटिंग और Table व्यवहार का दस्तावेज़ीकरण करता है जो वे मैनेजर जोड़ते हैं।

फ़ाइल के बजाय परिणाम पढ़ें: ip route get 1.1.1.1 टनल इंटरफ़ेस का नाम बताना चाहिए, और wg show हिलते ट्रांसफ़र काउंटर के साथ हाल का हैंडशेक दिखाना चाहिए। रूट के बिना हैंडशेक का मतलब है कि मैनेजर कभी चला ही नहीं, और प्रोफ़ाइल को फिर से संपादित करने से यह ठीक नहीं होगा। इंटरफ़ेस को वैसे ही शुरू करें जैसे उपयोगकर्ता करेगा, वरना परीक्षण तैनाती के बजाय आपका शेल मापेगा।

एंडपॉइंट को टनल के बाहर रखना

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

यदि एंडपॉइंट ऐसा होस्टनेम है जो कई पतों पर, या ऐसे परिवार पर हल होता है जिसे आप नहीं ढोते, तो अपवाद बुरी तरह पुराना हो जाता है और नियमित लगने वाले पुनः कनेक्शन के बाद टनल विफल हो सकती है। एंडपॉइंट को ऐसे पते पर पिन करें जिसे आप नियंत्रित करते हैं, या पुष्टि करें कि मैनेजर उसका पुनर्मूल्यांकन करता है, और हर नेटवर्क परिवर्तन के बाद होस्ट रूट फिर से पढ़ें।

यही तंत्र बताता है कि पूर्ण टनल और कैप्टिव पोर्टल क्यों लड़ते हैं। पोर्टल उस ट्रैफ़िक को रोकने की अपेक्षा करता है जिसे अब आपकी टनल पकड़ती है, इसलिए होटल और हवाई अड्डे के नेटवर्क पर आप पोर्टल लॉगिन के बाद टनल ऊपर लाते हैं, पहले कभी नहीं।

गेटवे पर फ़ॉरवर्डिंग और वापसी पथ

गेटवे पर, जिस परिवार को आप ढोते हैं उसके लिए फ़ॉरवर्डिंग सक्षम करें, अनुवाद करते समय forward श्रृंखला को दोनों दिशाओं में अनुमति दें, और स्रोत-विशिष्ट लुकअप से वापसी पथ की पुष्टि करें। इनमें से कुछ भी सफल हैंडशेक से नहीं निकलता, क्योंकि हैंडशेक केवल यह साबित करता है कि दोनों पीयर UDP का आदान-प्रदान कर सकते हैं। यह इस बारे में कुछ नहीं कहता कि बाद में डीकैप्सुलेटेड पैकेट का क्या होता है।

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

लुकअप क्लाइंट पर नहीं, गेटवे पर चलता है, वरना आप दूसरी रूटिंग तालिका पढ़ेंगे। यदि वह गलत इंटरफ़ेस का नाम बताए, या कहे कि कोई रूट नहीं है, तो क्लाइंट पक्ष का कोई भी परिवर्तन इंटरनेट एग्ज़िट नहीं देगा। जब गेटवे बाहर जाते समय क्लाइंट पतों का अनुवाद करता है, तो उत्तर उसी अनुवाद स्थिति पर निर्भर करता है, इसलिए नियम केवल बाहर जाने वाली दिशा के लिए नहीं, प्रवाह की दोनों दिशाओं के लिए होना चाहिए।

DNS और विफलता स्थिति, अलग-अलग जाँची गई

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

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

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