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 उत्तर कोणत्या बाजूला जाईल ते सांगते।

तक्ता क्रमांक, स्रोत नियम आणि अपवाद प्रोफाइलमध्येच नोंदवा। तिन्ही एकाच रचनेचे आहेत आणि एकत्र संपादित होतील।