अपनी WireGuard सुरंग से बाहर एक वेबसाइट को कैसे रूट करें

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

सुरंग को छूने से पहले गंतव्य पता पढ़ें

सुरंग चालू रखकर साइट को एक बार लोड करें, फिर उस पीयर पते को देखें जिससे ब्राउज़र ने वास्तव में कनेक्ट किया था। Linux पर, ss -tunp हर खुले सॉकेट का दूरस्थ पता सूचीबद्ध करता है, और dig +short उसी नाम पर दिखाता है कि रिज़ॉल्वर ने क्या लौटाया। दोनों संख्याएँ अपने सामने रखें।

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

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

क्लाइंट पर एक होस्ट रूट डालें

मान लीजिए इंटरफ़ेस का नाम home-wg है और LAN राउटर 192.168.1.1 पर है। NetworkManager ऐसा रूट लेता है जिसका गेटवे वही राउटर है और जिसकी प्रीफ़िक्स लंबाई पूरे 32 बिट को कवर करती है, और कर्नेल उसे पसंद करता है क्योंकि सबसे लंबा प्रीफ़िक्स जीतता है।

nmcli connection modify home-wg +ipv4.routes "198.51.100.20/32 192.168.1.1"
nmcli connection up home-wg
ip route get 198.51.100.20

गेटवे सुरंग के बिना पहुँच में होना चाहिए; अगली हॉप को सुरंग के पते पर इंगित करना मक़सद ही ख़त्म कर देता है, क्योंकि पैकेट फिर उसी इंटरफ़ेस में प्रवेश करेगा जिससे आप बचना चाहते हैं। कनेक्शन फिर से उठने के बाद, ip route get अपवाद के लिए LAN गेटवे प्रिंट होना चाहिए, और किसी सार्वजनिक रिज़ॉल्वर के लिए वही कमांड अभी भी सुरंग डिवाइस प्रिंट करना चाहिए।

wg-quick प्रोफ़ाइल में कोई रूट फ़ील्ड नहीं होता, इसलिए वही अपवाद एक ऐसी PostUp पंक्ति में रहता है जो होस्ट रूट को LAN इंटरफ़ेस को उसका डिवाइस बनाकर मुख्य तालिका में जोड़ती है। संपादन के बाद इंटरफ़ेस को नीचे और फिर ऊपर करें, क्योंकि चलता हुआ इंटरफ़ेस कभी अपनी फ़ाइल दोबारा नहीं पढ़ता। wg-quick जो fwmark नियम स्थापित करता है वे केवल उसके अपने एनकैप्सुलेटेड पैकेट को निर्देशित करते हैं, इसलिए सामान्य ब्राउज़र ट्रैफ़िक अभी भी मुख्य तालिका का पालन करता है और आपका /32 ढूँढ लेता है।

किल स्विच अगली चीज़ है जो इसे रोकती है

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

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

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

DNS तय करता है कि ब्राउज़र किस पते पर डायल करेगा

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

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

राउटर पर वही अपवाद, एक बार, हर डिवाइस के लिए

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

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

राउटर के नोट्स में पता, तारीख़ और कारण लिखें। ऐसे पते के इर्द-गिर्द बना अपवाद जो बाद में खिसक जाए, एक ऐसी ख़राबी बन जाता है जिसे एक साल बाद कोई समझा नहीं सकता, और समाधान तब तक पहेली जैसा लगता है जब तक कोई पुराना नोट न खोज ले।