का /32 होस्ट रूट VPN एंडपॉइंट पोहोचण्यायोग्य ठेवतो

कनेक्ट झाल्यावर राउटिंग टेबल उघडल्यावर एक पत्ता टनेलमधून जात असल्याचे दिसते, तर त्याच्या आसपासचे सबनेट अजूनही स्थानिक गेटवेकडे जाते. ती नोंद होस्ट रूट आहे: एक पत्ता, सर्व एकांच्या प्रीफिक्सशी जुळणारा. हे महत्त्वाचे आहे कारण राउटिंग निर्णय सर्वात लांब जुळणाऱ्या प्रीफिक्सचा वापर करतात, त्यामुळे /32 दोन्हीपैकी काहीही न बदलता /24 किंवा डीफॉल्टला मागे टाकू शकतो. हा काळजीपूर्वक अपवाद आहे की भविष्यातील अडथळा, हे तो कोणत्या पत्त्याचे नाव घेतो आणि त्याची काळजी कोण घेतो यावर अवलंबून आहे.

एक पत्ता, टेबलमध्ये एक नोंद

IPv4 होस्ट रूट /32 प्रीफिक्स घेतो आणि IPv6 होस्ट रूट /128 घेतो, याचा अर्थ नोंद अगदी एका गंतव्य पत्त्याशी जुळू शकते. टेबलमध्ये दुसरे काहीही हलत नाही: झाकणारे सबनेट आणि डीफॉल्ट रूट जिथे होते तिथेच राहतात. अरुंद नोंद त्या पत्त्यासाठी जिंकते कारण तिचा प्रीफिक्स लांब आहे, नंतर जोडली गेली म्हणून नाही.

हा गुणधर्म होस्ट रूटला चांगला अपवाद आणि वाईट सवय बनवतो. सेवेच्या मुख्य दाराचे नाव घेणाऱ्या दोन /32 नोंदी तिचा दुसरा पत्ता, तिचा IPv6 पत्ता किंवा पुढील महिन्यात ती जिथे जाते तो पत्ता झाकत नाहीत. अस्पष्ट एक-पत्ता नोंदींनी भरलेले टेबल सहसा असे सांगते की कोणी सबनेट निर्णय घेण्याऐवजी त्याभोवती पॅच करत राहिले. आधी प्रीफिक्सची लांबी वाचा, मग नोंद कशापासून संरक्षण करायची आहे ते विचारा.

नोंद क्लायंटपासून बाहेरच्या दिशेने वाचा

समस्या असलेल्या मशीनपासून सुरुवात करा, कारण तोच पत्ता लॅपटॉपवर आणि त्याच्या समोरील गेटवेवर वेगळ्या पद्धतीने राउट होऊ शकतो. टेबल वरून वाचण्याऐवजी कर्नेलला विचारा की अनुप्रयोग जो नेमका पत्ता वापरतो त्यासाठी तो कोणता मार्ग निवडेल. उत्तरात इंटरफेस आणि पुढील हॉप यांचा समावेश आहे, जे एकत्रितपणे निर्णय आहेत.

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

अनुप्रयोग प्रत्यक्षात निवडतो त्या पत्ता-कुटुंबासाठी क्वेरीची पुनरावृत्ती करा, कारण क्लायंट IPv6 ला प्राधान्य देऊन IPv4 अपवाद शांतपणे टाळू शकतो. टनेल उभे राहण्यापूर्वी आणि नंतर निकालाची तुलना करा, आणि दोन्ही आउटपुट ठेवा. ही तुलना दाखवते की क्लायंटने कनेक्ट होताना नोंद जोडली होती की ती आधीपासून होती.

कायमस्वरूपी नोंद आणि रनटाइम नोंद वेगळ्या पद्धतीने अयशस्वी होतात. रनटाइमची सत्रासोबत नाहीशी होते, तर कायमस्वरूपी रीबूटनंतरही टिकते आणि आता अस्तित्वात नसलेल्या गेटवेकडे रहदारी पाठवत राहते.

एंडपॉइंट अपवाद आणि रिकर्शन सापळा

VPN क्लायंट सहसा डीफॉल्ट रूट बदलण्यापूर्वी मूळ गेटवेमधून सर्व्हरच्या बाह्य पत्त्यावर होस्ट रूट स्थापित करतात. ती नोंद नसती तर एन्क्रिप्टेड पॅकेट ते बनवू पाहत असलेल्या टनेलमध्येच पाठवले गेले असते, आणि कनेक्शन वेळ संपेपर्यंत लूपमध्ये फिरत राहिले असते.

टनेलच्या स्वीकारलेल्या सबनेटमध्ये तो एंडपॉइंट पत्ता योगायोगाने आला, किंवा दुसऱ्या प्रोफाइलने नंतर अधिक रुंद रूट जोडला तेव्हा सापळा दिसतो. तेव्हा एंडपॉइंट नोंद लांब प्रीफिक्सकडून हरते आणि रहदारी जाऊ लागताच सत्र कोसळते. स्वीकारलेल्या सबनेटच्या शेजारी एंडपॉइंट पत्ता लिहिणे हा वापरकर्त्यांपूर्वी टक्कर लक्षात घेण्याचा सर्वात स्वस्त मार्ग आहे. तोच प्रोफाइल एका नेटवर्कमधून का चालतो आणि दुसऱ्यामधून का अयशस्वी होतो हेही यामुळे स्पष्ट होते.

अनुप्रयोग प्रत्यक्षात वापरतो तो मार्ग पडताळा

अनुप्रयोग वेगळ्या पत्त्यावर किंवा वेगळ्या कुटुंबावर कनेक्ट होतो तेव्हा होस्टनावावरचे यशस्वी ping हा कमकुवत पुरावा आहे. क्लायंट चालवणाऱ्या मशीनवरून पत्ता, कुटुंब, पोर्ट आणि इंटरफेसचे नेमके संयोजन पडताळा.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

मार्ग चुकीचा असल्यास, काहीही संपादित करण्यापूर्वी आवश्यकता नेटवर्क आहे की एक पत्ता हे ठरवा. एक-पत्त्याची आवश्यकता टिप्पणी आणि मालकासह होस्ट रूटला न्याय्य ठरवते; फिरत्या पत्त्यांच्या सेवेला डोमेन-आधारित राउटिंग किंवा प्रामाणिक सबनेट निर्णय आवश्यक आहे.

आता खऱ्या गंतव्याशी जुळत नसलेल्या नोंदी काढून टाका आणि ठेवत असलेल्या नोंदी लिहून ठेवा. अस्पष्ट /32 तीन महिन्यांनंतर बगपासून वेगळे ओळखता येत नाही, आणि पुढची व्यक्ती त्यावर काय अवलंबून होते हे न जाणूनच ती पुसून टाकेल.