एउटा सबनेटले अझै किन तपाईंको 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 जाँच छुट्टै दोहोर्याउनुहोस्।
• बाँकी रुटलाई यो स्थापना गर्ने फाइल, प्रोफाइल वा फिल्टरसम्म पछ्याउनुहोस्।
• ठीक भयो भन्नुअघि पुनः जोडेर प्रश्न फेरि चलाउनुहोस्।

सातै प्रोफाइलसँग मिले टनेलले जे गर्न कन्फिगर गरिएको थियो ठ्याक्कै त्यही गरिरहेको छ, र सुधार मेट्रिकमा होइन, प्रोफाइलमा पर्छ।