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 के लिए अग्रेषित करता है, तो प्रवेश संदर्भ और वापसी पथ का भी मेल खाना चाहिए। जब वे मेल न खाएँ, तो पूरी मशीन के लिए सत्यापन ढीला करने के बजाय रूट का स्वामित्व ठीक करें।