PPP को peer ठेगाना वा VPN अन्त्य बिन्दु: via मा कुन जान्छ

PPP इन्टरफेसमा एक लाइनले VPN बक्सको धेरैजसो राउटिङ बहस टुंग्याउँछ: भित्री ठेगाना र त्यसको छेउमा छापिएको peer। त्यो जोडीलाई सानो सबनेटका रूपमा पढ्नुहोस् र तपाईं नभएको गेटवे खोज्नुहुनेछ। यसलाई एउटै लिङ्कका दुई छेउका रूपमा पढ्नुहोस् र अर्को हप स्पष्ट हुन्छ। यहाँको तुलना यी दुई पढाइबीचको हो, किनकि पछि बनाइने हरेक तालिकाले तपाईंले छानेको कुरा नै पाउँछ। बाहिरी VPN अन्त्य बिन्दुबारे यीमध्ये कुनैले केही तय गर्दैन।

एउटै इन्टरफेस लाइनका दुई पढाइ

इन्टरफेसले inet 10.64.3.9 peer 10.64.3.1/32 भनी जनाउने सत्र लिनुहोस्। सबनेट पढाइले 10.64.3.9 लाई /32 टापुमा एक्लो होस्ट मान्छ र त्यसपछि त्यसभन्दा पर केही पुग्न राउटर खोज्छ। लिङ्कमा अर्को एक मात्र ठेगाना peer भएकाले त्यो पढाइ अन्ततः 10.64.3.9 लाई नै गेटवे प्रस्ताव गर्छ, जुन चक्रीय हो।

अन्त्य बिन्दुको पढाइ भनेको अभिलेखित हो। पोइन्ट-टु-पोइन्ट इन्टरफेसमा peer ले त्यही एउटा लिङ्कको टाढाको छेउलाई नाम दिन्छ, त्यसैले 10.64.3.1 प्रयोगयोग्य अर्को हप हो र 10.64.3.9 सधैं स्रोत ठेगाना मात्र हो।

यो भिन्नताले via मा के राख्न सकिन्छ भन्ने तय गर्छ। त्यहाँ स्थानीय ठेगाना लेख्दा कर्नेलले छिमेकीसँग मिलाउन नसक्ने मार्ग बन्छ, त्यसैले प्रविष्टि या त प्रमाणीकरणमा असफल हुन्छ या सूचीमा पूर्ण स्वस्थ देखिँदै ट्राफिक निल्छ। peer काम गर्छ किनकि त्यो लिङ्कमा वास्तविक गन्तव्य हो। दुवै पढाइ बाहिरी VPN अन्त्य बिन्दुमा सहमत छन्, जो पूर्ण रूपमा छुट्टै पहिचान हो: त्यहाँ अण्डरलेबाट पुगिन्छ, त्यसले अन्त्य गर्ने सुरुङबाट होइन।

सत्रले पहिले नै के स्थापना गरिसकेको छ

आफ्नै तालिका लेख्नुअघि लिङ्कसँग के आयो त्यो प्रिन्ट गर्नुहोस्। समर्थित PPP एकीकरणले सामान्यतया सत्र स्थापना गर्दा यन्त्र मार्ग र peer मार्ग स्थापना गर्छ, र यी दुई प्रविष्टिले पहिले नै सही पढाइ सङ्केत गर्छन्।

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 जस्तो यन्त्र मार्गले गेटवे बोक्दैन किनकि इन्टरफेस आफैं मार्ग हो। via ले peer को नाम लिने मार्ग अर्कै आयु भएको अर्कै वस्तु हो, र सत्र झर्दा त्यो हराउँछ। दुईमध्ये कुनै पनि रूपलाई पुनः कसरी स्थापना हुन्छ नहेरी दिगो तालिकामा प्रतिलिपि गर्नु नै चलिरहेको सुरुङ पुनः जडानपछि आफ्नो मार्ग गुमाउने सामान्य कारण हो।

सम्झनामा भर पर्नुको सट्टा दुवै सूची तुलना गर्नुहोस्। peer मार्ग main मा भए पनि तपाईंको थप तालिका खाली छ भने, ठेगाना लाइनले कहिल्यै नभनेको कुरा तपाईंले सिक्नुभयो।

नियम र तालिका छुट्टाछुट्टै निर्णय हुन्

तालिका छान्नु र भर्नु स्वतन्त्र कदम हुन्, र डिबग गर्दा यी दुई प्रायः मिसिन्छन् त्यसैले तुलना यहाँ महत्त्वपूर्ण छ। चिन्ह लगाइएको ट्राफिकलाई तालिका 100 मा पठाउने नियमले तालिका 100 मा मिल्ने मार्ग नभए केही गर्दैन, र राम्रोसँग भरिएको तालिका त्यसतर्फ देखाउने नियम नभए पुग्न नसकिने हुन्छ।

आधा पूर्वनिर्धारित मार्ग पूर्वनिर्धारित मार्ग होइन। एउटा 0.0.0.0/1 ले IPv4 ठाउँको तल्लो आधा ढाक्छ, त्यसैले सबै समात्ने नीतिलाई मिल्ने 128.0.0.0/1 वा साँचो default पनि चाहिन्छ। चलिरहेको कन्फिग पढेर दुई आधामध्ये एउटा मात्र प्रतिलिपि गर्नु नै मानिसहरू केही गन्तव्यमा मात्र बिग्रने राउटिङ लूपमा फस्ने बाटो हो।

LAN मा रहनुपर्ने ठेगानाका लागि जानाजान छुट राख्नुहोस्, र छानिएको तालिकामा खोजले केही नभेट्दा के हुन्छ त्यो तय गर्नुहोस्। स्पष्ट फलब्याक मार्ग खाली तालिकाभन्दा सोच्न सजिलो हुन्छ, जसले पुग्न नसकिने नतिजा फर्काउँछ र अनुप्रयोगलाई गलत मार्गमा भन्दा बिग्रिएको देखाउँछ।

खोजलाई तपाईंको अनुप्रयोगले सोध्ने प्रश्न सोध्नुहोस्

ip route get ले मार्ग समाधान गर्छ; ip route show ले भण्डारण गरिएका प्रविष्टि सूचीबद्ध गर्छ, र दुवै कुनै पनि गलत नहुँदै फरक मत दिन सक्छन्। स्रोत सन्दर्भ समावेश गर्नुहोस्, किनकि स्रोतमा आधारित नियम खोजले स्रोत बोकेको खण्डमा मात्र मिल्छ।

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

पहिलो आदेशले होस्टबाट प्रश्न सोध्छ। दोस्रोले प्रवेश इन्टरफेस थप्छ, जो अगाडि पठाइएको ट्राफिकले भोग्ने कुराको नजिक छ, र जवाफ प्रायः अर्को तालिकातर्फ देखाउँछ। यीमध्ये कुनै पनि गन्तव्य प्रत्यक्ष परीक्षण सेवा होइन; 198.51.100.23 अभिलेख ठेगाना हो, त्यसैले जाँच्न अनुमति पाएको होस्टले बदल्नुहोस्।

सही खोजले पनि मार्ग छानिएको मात्र प्रमाणित गर्छ। अर्को पक्षले ट्राफिक स्वीकार्छ कि उत्तर उही तर्कले फर्कन सक्छ, त्यो यसले भन्दैन।

तुलना कहाँ पल्टिन्छ

होस्ट ट्राफिक र अगाडि पठाइएको ट्राफिकले फरक खोज मात्र गर्दैनन्; फर्कने बाटोमा तिनीहरू फरक फिल्टरसँग भेट्छन्। Linux ले सबै इन्टरफेस र प्राप्त गर्ने इन्टरफेसका सेटिङमध्ये कडा लिनेलाई प्रयोग गरी उल्टो-मार्ग प्रमाणीकरण लागू गर्छ, त्यसैले एउटा इन्टरफेसको मान बदल्दा देखिने प्रभाव नहुन सक्छ। चिन्हमा आधारित राउटिङले src_valid_mark सम्बन्ध थप्छ, जसमा स्रोत वैध मानिनका लागि चिन्ह मिल्नुपर्छ।

बाहिर जाने राउटिङ ठीक देखिँदै उत्तर हराउँछ भने, छुनुअघि प्रभावकारी मान पढ्नुहोस्, र घोषित नीति कारण भएमा मात्र ती बदल्नुहोस्।

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

दुई डिजाइनमध्ये प्रमाणका आधारमा छान्नुहोस्: अनुप्रयोग PPP ठेगानामा बाँधिएको छ भने स्रोत नियम र peer मार्ग भएको तालिका पर्याप्त छ। बक्सले पछाडिको LAN का लागि अगाडि पठाउँछ भने प्रवेश सन्दर्भ र फर्कने मार्ग पनि मिल्नुपर्छ। नमिलेमा पूरै मेसिनको प्रमाणीकरण खुकुलो बनाउनुको सट्टा मार्गको स्वामित्व सुधार्नुहोस्।