हटाया गया VPN रूट फिर से कनेक्ट होने पर वापस क्यों आता है

हाथ से हटाया गया रूट अगली बार फिर से कनेक्ट होने पर वापस आ जाता है, और टेबल बिल्कुल पहले जैसी दिखती है। यह रूटिंग बग नहीं है: कुछ चीज़ कॉन्फ़िगरेशन से या कनेक्शन लाइफ़साइकल की किसी क्रिया से एंट्री को फिर से बनाती है। ज़्यादातर रनबुक लाइव टेबल पर ही रुक जाते हैं, इसलिए हटाना एक मिनट तक काम करता दिखता है और फिर विफल हो जाता है। मालिक को पहचानें, उसे बदलें, और फिर से कनेक्ट होकर साबित करें।

रूट किसने इंस्टॉल किया

किसी सुधार से नहीं, संभावित स्रोतों की सूची से शुरू करें। 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

पहला टनल इंटरफ़ेस से और दूसरा भौतिक गेटवे से हल होना चाहिए। अगर दोनों टनल से हल हों, तो अपवाद गायब है; अगर कोई नहीं, तो प्रोफ़ाइल बदलाव लागू नहीं हुआ और आप जिस मालिक को सोच रहे थे उससे अलग देख रहे हैं।

रूट का उद्देश्य, उसका मालिक और वह कितने समय जीवित रहना चाहिए, लिखें। वही नोट अगले व्यक्ति को वही हटाने और फिर से कनेक्ट करने का चक्र दोहराने से रोकता है।