एक सबनेट अजूनही तुमचा VPN डीफॉल्ट रूट का बायपास करतो

तुम्ही VPN पूर्ण टनेलवर बदलता, बहुतेक रहदारी मान्य करते, आणि मग एक पत्ता थेट उत्तर देतो — प्रिंटर, NAS, 10.x वरचा जंप होस्ट। स्पष्ट अर्थ असा की टनेल गळत आहे, म्हणून तुम्ही डीफॉल्ट रूटवरील मेट्रिक कमी करता आणि काहीच बदलत नाही। तो अपयशी प्रयत्नच सुगावा आहे: डीफॉल्ट रूट हा पर्याय आहे, निर्णय नाही। रूट शोध मेट्रिकची तुलना करण्यापूर्वीच सर्वात लांब जुळणारा प्रीफिक्स घेतो, त्यामुळे /24 कोणतेही संख्या जोडली तरी /0 वर जिंकत राहतो। हा क्रम स्पष्ट झाल्यावर, गळती सहसा कोणी तडजोडीने बसवलेला रूट, किंवा क्लायंटने कधीही झाकण्याचा हेतू नसलेला प्रीफिक्स असते।

डीफॉल्ट रूट प्रत्यक्षात काय वचन देतो

0.0.0.0/0 शून्य बिट विशिष्टतेसह प्रत्येक IPv4 गंतव्याशी जुळतो। होस्टला त्याच्या तक्त्याने अधिक चांगल्या प्रकारे वर्णन न केलेल्या कशापर्यंतही पोहोचता यावे म्हणून तो आहे। 192.168.1.0/24 कडे जाणारा रूट 24 जुळणारे बिट वाहतो, त्यामुळे 192.168.1.40 साठी कोणी मेट्रिक, प्रशासकीय अंतर किंवा क्लायंट ज्याला प्राधान्य क्षेत्र म्हणतो त्याची तुलना करण्यापूर्वीच तो जिंकतो। तोच नियम Linux FIB, Windows राउटिंग तक्ता आणि macOS मागील BSD स्टॅकमध्ये लागू होतो।

सामान्य LAN वर हे वर्तन एक वैशिष्ट्य आहे। स्थानिक सबनेट थेट जोडलेले आहे, टनेल तुमचे ब्राउझिंग वाहत असताना प्रिंटर कार्यरत राहतो, आणि काहीही चुकीचे कॉन्फिगर केलेले नाही। विचारण्यासारखा प्रश्न तो एक पत्ता थेट का जातो हा नाही, तर कोणत्या तक्त्यातील कोणता प्रीफिक्स त्याच्याशी जुळतो, आणि तो तिथे कोणी ठेवले हा आहे।

अर्ध-डीफॉल्ट, किंवा डीफॉल्ट नोंद अजूनही अस्पर्शित का दिसू शकते

सर्वात स्वच्छ उदाहरण redirect-gateway def1 OpenVPN मध्ये आहे। तुमचा डीफॉल्ट हटवून बदलण्याऐवजी, तो 0.0.0.0/1 आणि 128.0.0.0/1 जोडतो। एकत्रितपणे ती जोडी संपूर्ण IPv4 व्यापते, प्रत्येक प्रीफिक्स /0 पेक्षा लांब आहे, आणि दोन्ही राउटरच्या डीफॉल्टला त्याच्या जागी ठेवून त्याला हरवतात। नंतर रूट यादी चालवा आणि मूळ डीफॉल्ट अजूनही तिथे आहे, अजूनही तुमच्या गेटवेकडे निर्देश करतो; तो फक्त इंटरनेट गंतव्यांसाठी कधीही निवडला जात नाही।

WireGuard चा wg-quick धोरण-आधारित राउटिंगद्वारे तोच निकाल गाठतो। AllowedIPs 0.0.0.0/0 व्यापतो तेव्हा तो स्वतःचा तक्ता तयार करतो, चिन्हांकित पॅकेट तिथे पाठवतो, आणि मुख्य तक्त्याच्या शून्य लांबीच्या प्रीफिक्सकडे दुर्लक्ष करणारा नियम जोडतो। मुख्य तक्ता त्याची डीफॉल्ट नोंद ठेवतो, आणि इंटरफेसच्या मालकीच्या रहदारीसाठी आधी टनेल तक्ता विचारला जातो असे नियम ठरवतात।

दोन्ही रचनांना टनेलबाहेर नेमका एक रूट लागतो: मूळ गेटवेद्वारे VPN सर्व्हरच्या स्वतःच्या पत्त्याकडे होस्ट रूट। त्याशिवाय क्लायंट टनेल तयार करणारी पॅकेट टनेलच्या आत नेण्याचा प्रयत्न करेल, आणि कनेक्शन कधीही पूर्ण होणार नाही। म्हणून कठोर पूर्ण-टनेल प्रोफाइलवरही तुमच्या तक्त्यात टनेल नसलेला रूट सामान्य आहे। प्रश्न विचारण्यासारखे रूट ते आहेत जे तुम्हाला खरोखर महत्त्वाची असलेली गंतव्ये व्यापतात।

मेट्रिक बरोबरी ठरवतात, प्रीफिक्स विजेते ठरवतात

मेट्रिकची तुलना फक्त त्या उमेदवारांमध्ये होते जे गंतव्याशी समान चांगल्या प्रकारे जुळतात। Linux वर ip route get 10.20.5.9 विजेत्याला त्याच्या तक्त्यासह छापतो, आणि ip route show table all उमेदवारांची यादी करतो, त्यात कोणतेही अर्ध-डीफॉल्ट आणि नियम ज्या तक्त्याकडे निर्देश करतो तो समाविष्ट आहे। Windows वर Find-NetRoute -RemoteIPAddress 10.20.5.9 निवडलेला रूट आणि स्रोत पत्ता परत करतो, तर Get-NetRoute कच्चा तक्ता दाखवतो — पण प्रभावी खर्च रूट मेट्रिक अधिक इंटरफेस मेट्रिक आहे, म्हणून संथ अडॅप्टर जिंकत असलेली बरोबरी हरवू शकतो।

तुम्ही जे पाहाल त्यातील बहुतेक तीन प्रकरणे व्यापतात:

• समान गंतव्य, /24 विरुद्ध /0: मेट्रिक काय म्हणोत, प्रीफिक्स लांबीवर /24 जिंकतो।
• समान गंतव्य, वेगवेगळ्या मेट्रिकचे दोन /24: कमी प्रभावी मेट्रिक जिंकतो।
• समान गंतव्य, दोन तक्ते, एक धोरण नियमाने निवडलेला: नियम आधी तक्ता निवडतो, आणि प्रीफिक्स तुलना त्याच्यात होते।

तिसरे प्रकरण म्हणजे या अहवालांचा बहुतेक भाग जिथे संपतो। Linux चा ip rule किंवा Windows VPN रहदारी फिल्टर रहदारी अशा तक्त्याकडे पाठवू शकतो ज्यात कधीही टनेल डीफॉल्ट नव्हता, आणि मुख्य तक्ता सर्व वेळ परिपूर्ण दिसतो।

हा बायपास सहसा कोणाच्या मालकीचा असतो

तक्त्यापासून नाही, प्रोफाइलपासून सुरुवात करा। Split-tunnel संरचना आणि प्रति-ॲप VPN सेटिंग्ज नाव दिलेले प्रीफिक्स जाणीवपूर्वक टनेलबाहेर ठेवतात; एक खाजगी सबनेट संरक्षित करणारे आणि सामान्य ब्राउझिंग थेट जाऊ देणारे कार्य प्रोफाइल जसे रचले तसेच वागते, आणि ते ओव्हरराइड केल्यास ते लागू करायचे होते ते धोरण मोडते। Microsoft चे VPN राउटिंग मार्गदर्शन जबरदस्ती टनेल केलेली रहदारी आणि स्पष्ट अपवाद यांमध्ये तीच रेषा काढते, ज्यामुळे काहीही संपादित करण्यापूर्वी ते उपयुक्त क्रॉस-चेक बनते।

पुढे शिल्लक शोधा। आता नसलेल्या इंटरफेसकडे किंवा मागील नेटवर्कच्या पत्त्याकडे निर्देश करणारा रूट डॉकिंग स्टेशन, USB अडॅप्टर आणि कंटेनर ब्रिज ये-जा केल्यानंतर दिसतो। एकदा हटवणे हा शेवट नाही: NetworkManager कनेक्शन प्रोफाइल, netplan फाइली आणि Windows चे कायमचे रूट पुढील कनेक्शन किंवा बूटवर तो पुन्हा इंस्टॉल करतात, म्हणून काहीही संपादित करण्यापूर्वी त्याचा मालक असलेली फाइल किंवा प्रोफाइल शोधा।

मग IPv6 स्वतंत्रपणे तपासा। ip -6 route आणि Get-NetRoute -AddressFamily IPv6 स्वतंत्र स्थिती, स्वतंत्र डीफॉल्ट आणि स्वतंत्र क्लायंट वर्तन ठेवतात। फक्त IPv4 ची तपासणी दुहेरी-स्टॅक होस्टबद्दल काहीही सांगत नाही जो शांतपणे स्थानिक IPv6 मार्गाला प्राधान्य देतो, आणि केवळ तेच क्लायंटला split-tunnel दिसू शकते।

ॲप्लिकेशनच्या स्वतःच्या प्रवाहाने पुष्टी करा

ॲप्लिकेशन प्रत्यक्षात वापरत असलेले गंतव्य नोंदवा, मग त्या ॲपने बांधलेल्या स्रोत पत्त्यापासून तो कोणता मार्ग घेईल ते सिस्टमला विचारा। ip route get 10.20.5.9 from 192.168.1.40 Linux वर त्याचे उत्तर देते; Find-NetRoute -RemoteIPAddress 10.20.5.9 अधिक स्थानिक पत्ता Windows वर ते करतो। निकालाची प्रोफाइल ज्या दावा करते त्याशी तुलना करा। ब्राउझरचे सार्वजनिक-IP पान एका प्रोटोकॉलवर एक गंतव्य तपासते आणि तक्रार सुरू केलेल्या खाजगी पत्त्याबद्दल काहीही सांगत नाही।

फरक स्पष्ट करणारी सर्वात अरुंद वस्तू दुरुस्त करा। अपवाद मंजूर असल्यास प्रीफिक्स लिहून ठेवा आणि तो तसाच ठेवा; नसल्यास डीफॉल्टचे मेट्रिक कमी करण्याऐवजी रूट काढा किंवा टनेलमधून स्पष्ट अरुंद रूट जोडा। मेट्रिक कमी करून लांब प्रीफिक्सला मागे टाकता येत नाही, आणि दोन /1 रूट इंटरनेट मार्गाचे मालक असताना डीफॉल्ट संपादित केल्यानेही काहीच बदलत नाही।

मग टनेल पुन्हा जोडा आणि तीच चौकशी पुन्हा करा। क्लायंट प्रत्येक कनेक्शनवर रूट पुन्हा इंस्टॉल करतात, म्हणून पुढील हँडशेकपर्यंत टिकणारा बदल तपासलेला नाही। मार्ग अजूनही वेगळा असल्यास उर्वरित संशयित धोरण नियम, दुसरा तक्ता किंवा क्लायंट-बाजूचा फिल्टर आहे — डीफॉल्ट रूट नाही।

• ॲप प्रत्यक्षात वापरत असलेले गंतव्य आणि स्रोत पत्ता नावाने सांगा।
• जिंकणारा रूट ip route get किंवा Find-NetRoute वापरून छापा।
• इंटरनेट मार्गाचा मालक /1 जोडी आहे की धोरण तक्ता ते तपासा।
• /0 पेक्षा लांब आणि गंतव्याशी जुळणारा प्रत्येक प्रीफिक्स सूचीबद्ध करा।
• IPv6 तपासणी स्वतंत्रपणे पुन्हा करा।
• उरलेला रूट तो इंस्टॉल करणाऱ्या फाइल, प्रोफाइल किंवा फिल्टरपर्यंत मागे शोधा।
• दुरुस्त झाले असे म्हणण्यापूर्वी पुन्हा जोडा आणि चौकशी पुन्हा चालवा।

सातही प्रोफाइलशी सहमत असल्यास, टनेल ज्यासाठी कॉन्फिगर केले होते तेच करत आहे, आणि दुरुस्ती मेट्रिकमध्ये नाही, प्रोफाइलमध्ये येते।