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 साठी पुढे पाठवत असेल, तर प्रवेश संदर्भ आणि परतीचा मार्गही जुळले पाहिजेत। ते जुळत नसतील, तर संपूर्ण यंत्रासाठी पडताळणी सैल करण्याऐवजी मार्गाची मालकी दुरुस्त करा।