हाताने हटवलेला मार्ग पुढील पुन्हा कनेक्शननंतर परत येतो, आणि टेबल अगदी पूर्वीसारखेच दिसते। ही राउटिंग बग नाही: काहीतरी कॉन्फिगरेशनमधून किंवा कनेक्शन जीवनचक्रातील कृतीतून नोंद पुन्हा तयार करते। बहुतेक रनबुक थेट टेबलवरच थांबतात, म्हणून हटवणे एक मिनिट काम करत असल्यासारखे वाटते आणि नंतर अयशस्वी होते। मालक ओळखा, तो बदला, आणि पुन्हा कनेक्शनवर सिद्ध करा।

मार्ग कोणी स्थापित केला

दुरुस्तीपासून नाही, संभाव्य स्रोतांच्या यादीपासून सुरुवात करा। VPN प्रोफाइल स्वतःचे मार्ग घेऊन येऊ शकते, सर्व्हर कनेक्ट होताना ते push करू शकतो, नेटवर्क मॅनेजर प्रोफाइल ते घोषित करू शकते, बूट युनिट किंवा स्क्रिप्ट ते जोडू शकते, आणि IPsec अंमलबजावणी त्यांनी वाटाघाटी केलेल्या ट्रॅफिक सिलेक्टरसाठी मार्ग स्थापित करतात। धोरणात्मक राउटिंग नियम ट्रॅफिक पूर्णपणे दुसऱ्या टेबलमध्ये पाठवू शकतात।

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

संपादित करण्यापूर्वी टेबल वाचा

जतन केलेल्या फाइलऐवजी कर्नलचे स्वतःचे दृश्य पाहा। प्रोटोकॉल स्तंभ प्रत्येक नोंद कोणी स्थापित केली हे दाखवतो:

ip route show
ip route show table all
ip rule show

प्रोटोकॉल फील्ड, मेट्रिक आणि टेबल क्रमांक तुम्हाला सांगतात की तुम्ही स्थिर नोंद, कर्नलने तयार केलेली नोंद किंवा डीमनने जोडलेली गोष्ट पाहत आहात। नियमांची यादी महत्त्वाची आहे कारण शोध मुख्य टेबल पूर्णपणे सोडू शकतो, ज्यामुळे तिथले संपादन तुम्ही डीबग करत असलेल्या अॅप्लिकेशनला अदृश्य होते। ओळ डावीकडून उजवीकडे वाचा: गंतव्य, गेटवे, डिव्हाइस, प्रोटोकॉल आणि मेट्रिक।

मग कर्नलला विचारा की तो प्रत्यक्षात कोणता मार्ग वापरेल। संरक्षित पत्ता सार्वजनिक पत्त्यापेक्षा चांगली तपासणी आहे:

ip route get 10.20.5.7

लक्षण नाही, मालक बदला

मालक माहीत झाल्यावर, बदल त्या मालकाचा असतो। क्लायंट प्रोफाइलमधून मार्ग काढा, सर्व्हरवरील push केलेला मार्ग दुरुस्त करा, किंवा मेट्रिकने जिंकणारा स्पर्धक कायमचा मार्ग जोडण्याऐवजी नेटवर्क मॅनेजर कनेक्शन संपादित करा। एकमेकांशी लढणारे दोन नियम असे टेबल तयार करतात जे नंतर कोणीही समजावून सांगू शकत नाही।

एंडपॉइंट अपवाद ठेवा। VPN सर्व्हरचा स्वतःचा सार्वजनिक पत्ता भौतिक गेटवेमधून पाठवणारा होस्ट मार्ग बाहेरील टनेल पॅकेट्स वाहत ठेवतो; तो हटवला तर टनेल स्वतःला वाहून नेण्याचा प्रयत्न करते। स्प्लिट-टनेल प्रोफाइलमध्ये टनेल टाळायच्या असलेल्या स्थानिक सबनेटसाठीही तीच काळजी लागू होते।

पुन्हा कनेक्ट करा आणि दोन्ही मार्ग पडताळा

पुन्हा कनेक्ट करा, मग एकाच फेरीत दोन्ही गंतव्ये तपासा। संरक्षित पत्ता आणि वगळलेला एंडपॉइंट वेगवेगळ्या प्रश्नांची उत्तरे देतात:

ip route get 10.20.5.7
ip route get 198.51.100.20

पहिले टनेल इंटरफेसद्वारे आणि दुसरे भौतिक गेटवेमधून सोडवले पाहिजे। दोन्ही टनेलमधून सोडवले गेल्यास अपवाद गहाळ आहे; एकही नसल्यास प्रोफाइल बदल अंमलात आला नाही आणि तुम्ही विचार केल्यापेक्षा वेगळ्या मालकाकडे पाहत आहात।

मार्गाचा उद्देश, त्याचा मालक आणि तो किती काळ जगावा हे लिहून ठेवा। तीच नोंद पुढच्या व्यक्तीला तोच हटणे आणि पुन्हा कनेक्ट करण्याचा चक्र पुन्हा करण्यापासून थांबवते।

संबंधित लेख