WireGuard के ज़रिए एक ऐप: बाइंडिंग राउटिंग नहीं है

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

इस तंत्र के दो आधे हिस्से हैं: एक राउटिंग तालिका जिसका इस्तेमाल सिर्फ़ टनल का ट्रैफ़िक करे, और एक नियम जो मेल खाते स्रोत को वहाँ भेजे।

बाइंडिंग सिर्फ़ स्रोत पता तय करती है, और कुछ नहीं

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

इसीलिए यह विफलता इतनी अजीब दिखती है। ऐप निश्चित रूप से टनल का पता इस्तेमाल कर रहा है, टनल निश्चित रूप से चालू है, और ट्रैफ़िक निश्चित रूप से गलत इंटरफ़ेस से बाहर जा रहा है। हर कथन सच है, और साथ मिलकर वे ऐसी व्यवस्था बताते हैं जहाँ किसी चीज़ ने पते को रूट से नहीं जोड़ा था।

टनल को उसकी अपनी तालिका दें

wg-quick रूट वहाँ लगाता है जहाँ प्रोफ़ाइल कहता है। [Interface] के नीचे Table = 40 जोड़ने से वे मुख्य तालिका की जगह तालिका 40 में चले जाते हैं। इंटरफ़ेस ऊपर करें और पुष्टि करें कि वे पहुँच गए: ip -4 route ls table 40 को टनल के रूट दिखाने चाहिए, और ip -4 route get 10.66.127.142 दिखाता है कि कर्नल अभी उनमें से एक को कैसे हल करता है। रूट अपनी तालिका में होने पर मुख्य तालिका बाकी सब के लिए काम करती रहती है।

यही काम IPv6 के लिए करें, चौड़े प्रीफ़िक्स से मिलान करने के बजाय। ip -6 rule add from fd00::2/128 lookup 40 एक पता तय करता है; fc00::/8 होस्ट पर दूसरे इंटरफ़ेस से टकरा सकता है और ऐसा नियम बना सकता है जो इरादे से ज़्यादा मेल खाए।

स्रोत नियम जोड़ें और काउंटर देखें

फिर दोनों आधों को जोड़ें: ip -4 rule add from 10.66.127.142/32 lookup 40, उसी पते को WireGuard इंटरफ़ेस से जोड़े रखते हुए। दोनों नियम PostUp में डालें ताकि दोबारा कनेक्ट होने पर वे बहाल हो जाएँ। सेटिंग से नहीं, असली अनुरोध से जाँचें: ip route get 1.1.1.1 from 10.66.127.142 को टनल डिवाइस का नाम बताना चाहिए, और curl --interface wg0 ifconfig.me को घर के पते के बजाय टनल का पता बताना चाहिए।

जब फिर भी विफल हो, तो ip -s rule पढ़ें। जो नियम मौजूद है पर कभी मेल नहीं खाया, वह शून्य काउंटर दिखाता है, और यही गलत नियम को नियम के बिल्कुल न होने से अलग करता है। वह एक कमांड इस बारे में बहुत अनुमान बचाता है कि ऐप ने अपनी इंटरफ़ेस सेटिंग नज़रअंदाज़ की या नहीं।

उल्टा मामला: SSH को टनल से बाहर रखें

उल्टी समस्या भी उतनी ही आम है: wg-quick डिफ़ॉल्ट रूट का मालिक है और सर्वर तक SSH सत्र बीच में ही मर जाता है। उसके नियम निचले प्राथमिकता नंबर पर बैठते हैं, इसलिए अपवाद का मूल्यांकन उनसे पहले होना चाहिए। ip rule add dport 22 ipproto tcp table main priority 123 हाल के iproute2 पर यही करता है; जहाँ सेलेक्टर उपलब्ध नहीं है, वहाँ nftables में फ़्लो पर मार्क लगाएँ और उसके बजाय मार्क का मिलान करें।

जवाब का रास्ता भी देखें। जो SSH सत्र बनकर फिर शांत हो जाता है, उसमें आमतौर पर असममित राउटिंग होती है: एक दिशा टनल से बाहर जाती है और दूसरी भौतिक इंटरफ़ेस से। सर्वर पते के लिए ip route get बताता है कि जवाब किस ओर जाएगा।

तालिका संख्या, स्रोत नियम और अपवाद प्रोफ़ाइल में ही दर्ज करें। तीनों एक ही डिज़ाइन के हैं और साथ में संपादित किए जाएँगे।