VPN रुटले ip route को आउटपुटमा गेटवे किन देखाउँदैन
यन्त्र भएको तर गेटवे नभएको लाइन सीधा रुट हो, बिग्रिएको होइन। गन्तव्य, dev र scope पढ्नुहोस्, त्यसपछि ip route get ले पुष्टि गर्नुहोस्।
गेटवे स्तम्भ खाली देखिने बित्तिकै राउटिङ तालिकाहरू बिग्रिएको भनी पढिन्छ, जबकि लाइन सामान्यतया आफैंमा पूर्ण हुन्छ। via फिल्ड तब मात्र देखिन्छ जब कर्नेलले प्याकेटलाई अर्को हपको ठेगानामा सुम्पिन्छ; इन्टरफेसमा जोडिएको रुटले आफ्ना गन्तव्यहरूमा बरु लिङ्क-तह विश्लेषण वा पोइन्ट-टु-पोइन्ट साथीमार्फत पुग्छ। स्तम्भहरू बायाँबाट दायाँ पढ्दा तपाईं कुन अवस्थामा हुनुहुन्छ भन्ने थाहा हुन्छ, र त्यो पढाइ कसैले डिफल्ट रुट सम्पादन गर्नुअघि नै हुनुपर्छ। हराएको गेटवेबारेका अधिकांश टिकट यही भिन्नतामा टुंगिन्छन्।
रुटको लाइन स्तम्भैपिच्छे पढ्नुहोस्
प्रत्येक प्रविष्टि गन्तव्य र यसको प्रिफिक्स लम्बाइबाट सुरु हुन्छ, त्यसपछि स्थिर शब्दावलीमा परिमार्जकहरू थप्छ: via, dev, proto, scope, src र metric। 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 जस्तो लाइन घना तर पूर्ण रूपमा निर्दिष्ट छ। यसमा केही पनि छुटेको छैन, र कुनै राउटर ठेगाना निहित गरिएको छैन।
via को अनुपस्थिति नै रोचक भाग हो। अर्को हप नभए कर्नेलले गन्तव्यलाई सिधै नामित इन्टरफेसमा समाधान गर्छ, जसको टनेलका लागि अर्थ फ्रेम टनेल यन्त्रलाई दिएर इन्क्याप्सुलेसनलाई त्यहीँबाट सम्हाल्न दिनु हो। proto kernel ले ठेगाना तोकिँदा प्रविष्टि स्वतः स्थापित भएको थियो भनी अभिलेख गर्छ, कुनै प्रशासकले टाइप गरेको होइन। scope link ले गन्तव्य त्यो लिङ्कमा राउटर नगई पुग्न सकिने बताउँछ, र src ले कर्नेलले मिल्ने ट्राफिकका लागि स्रोतका रूपमा रुचाउने ठेगानाको नाम दिन्छ।
अब डिफल्ट रुट त्यही तरिकाले पढ्नुहोस्: default via 192.0.2.254 dev eth0 proto static metric 100। यहाँ via छ किनभने प्याकेटलाई साँच्चै अर्को हप चाहिन्छ, र त्यो हप आफैं eth0 मा पुग्न सकिने हुनुपर्छ। ती दुई लाइनहरू एकअर्काका प्रकार होइनन्; तिनीहरू ट्राफिक कहाँ जान्छ भन्नेबारे फरक प्रश्नहरूको जवाफ दिन्छन्।
एकअर्कासँग भ्रमित हुने दुई रुट आकार
टनेल सबनेट रुट र डिफल्ट रुट स्क्रिनसटमा उस्तै देखिन्छन् र पूरै फरक व्यवहार गर्छन्। तलको तालिकालाई फिल्ड पढ्ने सहायता रूपमा प्रयोग गर्नुहोस्, त्यसपछि कुनै गाइडको नमुनामा भरोसा गर्नुको सट्टा तपाईं डिबग गरिरहनुभएको मेसिनमै वास्तविक अंकहरू पुष्टि गर्नुहोस्।
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
तालिकाले भन्न नसक्ने कुरा मनसाय हो। टनेलमार्फत निजी दायरातर्फ सीधा रुट जानाजान बनाइएको स्प्लिट-टनेल डिजाइन हो; जुन होस्टले सबै कुरा VPN मार्फत पठाउनुपर्ने हो त्यहाँ त्यही आकार देखिनु लक्षण हो। मनसाय प्रविष्टि बनाउने कन्फिगरेसनमा बस्छ, त्यसैले कर्नेलले केही गलत गर्यो भन्ने निष्कर्ष निकाल्नुअघि त्यसलाई स्थापित गर्ने औजारलाई हेर्नुहोस्।
त्यसैगरी, हराएको गेटवे एउटा बनाउने अनुमति होइन। यदि रुटलाई साँच्चै अर्को हप चाहिन्छ भने, त्यो हप त्यसलाई बोक्ने इन्टरफेसमा पुग्न सकिने हुनुपर्छ, र पोइन्ट-टु-पोइन्ट टनेलका लागि साथीको ठेगाना स्थानीय ठेगानासँगै एउटै वस्तु होइन। स्थानीय टनेल ठेगानालाई इथरनेट राउटर मान्नु सही देखिने तर केही पनि अगाडि नपठाउने रुट बनाउने सामान्य तरिका हो।
कर्नेललाई सोध्नुहोस् कि यसले वास्तवमा कुन लाइन प्रयोग गर्छ
तालिका पढ्नु खोज गर्नुसँग उस्तै होइन, किनभने जवाफ दिनुअघि कर्नेलले नीति नियम, धेरै तालिका र क्यास गरिएका प्रविष्टिहरूसँग परामर्श गर्छ। वास्तविक खोज गर्ने क्रियापद ip route get हो, र यसले ती गुण भएको प्याकेटले लिने रुट छाप्छ।
ip route get 203.0.113.37 from 198.51.100.2 iif tun0तपाईंलाई साँच्चै महत्त्वपूर्ण गन्तव्य राख्नुहोस्, त्यसपछि ट्राफिक स्रोतअनुसार छानिएको वा अगाडि पठाइएको बेला from वा iif थप्नुहोस्, किनभने सामान्य स्थानीय खोजले अगाडि पठाइएको क्लाइन्टभन्दा फरक बाटो छान्न सक्छ। जवाफले इन्टरफेस, छानिएको स्रोत ठेगाना र कुनै पनि अर्को हप बताउँछ, जुन त्यो क्षणमा प्याकेटलाई रुट गर्न प्रयोग हुने त्यही जानकारी हो।
जवाफले तपाईंलाई अचम्मित बनायो भने, केही पनि बदल्नुअघि नियमहरू छाप्नुहोस्: ip -4 rule show ले तिनलाई प्राथमिकता क्रममा सूचीबद्ध गर्छ, र आफ्नै तालिका वा चिन्हित प्याकेटका लागि नियम स्थापित गर्ने VPN क्लाइन्ट मुख्य तालिकामा पटक्कै देखिँदैन। हरेक तालिका सूचीबद्ध गर्नाले त्यो खाडल भरिन्छ।
ip -4 route show table all | grep -E 'tun|default'डिफल्ट बदल्नुअघि अन्डरले जाँच्नुहोस्
टनेलका आफ्नै प्याकेटहरू टाढाको अन्त्य बिन्दुमा पुग्नुपर्छ, र तिनीहरू VPN उठ्नुअघि रहेको रुट प्रयोग गरी भौतिक इन्टरफेसमार्फत त्यसो गर्छन्। त्यो अन्त्य बिन्दु पिन नगरी पूरै डिफल्ट रुट बदल्दा इन्क्याप्सुलेट गरिएका प्याकेटहरू तिनले बनाउनुपर्ने टनेलभित्रै जान्छन्, र जडान भताभुङ्ग हुन्छ। पहिले केवल अन्त्य बिन्दुको ठेगानाको खोज गरी अन्त्य बिन्दुको बाटो पुष्टि गर्नुहोस्।
परिवर्तन गर्दा तीन कुरा अलग राख्नुहोस्: भौतिक इन्टरफेसमा रहनुपर्ने अन्त्य बिन्दुको रुट, टनेलभित्र जानुपर्ने निजी दायरा, र बाँकी सबै निर्णय गर्ने डिफल्ट। तिनलाई त्यही क्रममा अलग गर्नुहोस्, एकैचोटि एउटा लागू गर्नुहोस्, र प्रत्येक चरणपछि खोज फेरि चलाउनुहोस्। पछि असफल पिंगले आफैंमा धेरै थोरै प्रमाणित गर्छ, किनभने अनुमति, जवाफ राउटिङ, DNS र सेवा आफैं सबै सही रुटको तल बसेका हुन्छन्।
सम्पादनअघि लाइनले दिएका चार मान लेख्नुहोस्: गन्तव्य, अर्को हप वा त्यसको अनुपस्थिति, यन्त्र, र छानिएको स्रोत। पछिको परिवर्तनले तीमध्ये कुनै पनि सार्यो भने, कुन निर्णय साँच्चै बदलियो भन्ने तपाईंलाई थाहा हुन्छ, र पूरै तालिकाको अनुमान गर्नुको सट्टा एउटा प्रविष्टि पुनर्स्थापित गर्न सक्नुहुन्छ।