VPN क्लाइंट आपका जोड़ा हुआ रूट हटा देता है? पॉलिसी टेबल का उपयोग करें

लैब प्रिंटर के लिए एक /24 दो ip route show कॉल के बीच गायब हो जाता है, और क्लाइंट लॉग सिर्फ यह कहता है कि नेटवर्क बदल गया। कमांड, प्रीफ़िक्स या आपके विशेषाधिकारों में कुछ भी गलत नहीं था। होस्ट के रूटिंग मॉडल का स्वामित्व रखने वाला कॉर्पोरेट क्लाइंट, जब भी कोई और उसे संपादित करता है, उस मॉडल को फिर से लागू करता है, इसलिए आपकी जोड़ी गई प्रविष्टि घुसपैठिए के रूप में हटा दी जाती है। उसी टेबल में उससे लड़ना हारी हुई स्थिति है। समाधान यह है कि उस टेबल के लिए प्रतिस्पर्धा पूरी तरह छोड़ दें और अपवाद को वहाँ रखें जहाँ मॉनिटर कभी नहीं देखता।

मॉनिटर गुम रूट की व्याख्या करता है

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

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

ऊपर दिया गया प्रीफ़िक्स और इंटरफ़ेस प्लेसहोल्डर हैं। किसी दूसरी मशीन पर काम करने वाले उदाहरण से इंटरफ़ेस का नाम कॉपी करना इस प्रदर्शन के कुछ भी न देने का सबसे आम कारण है।

दूसरी टेबल मॉनिटर के लिए अदृश्य है

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

यह सौदा रखरखाव है। दो वस्तुएँ अलग-अलग हो सकती हैं, और सूची में नियम की स्थिति उतनी ही मायने रखती है जितना उस टेबल के अंदर का रूट जिसे वह चुनता है।

अपवाद बनाएँ और फिर उसे जिताएँ

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

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get उस रूट को हल करता है जो कर्नेल उपयोग करेगा, जिसमें डिवाइस और स्रोत पता शामिल है। यह टेबल पहचानकर्ता नहीं छापता, इसलिए इसे ip rule show के साथ जोड़ें जब आपको यह पुष्टि करनी हो कि कौन-सी टेबल जीती। साथ में वे एकमात्र महत्वपूर्ण सवाल का जवाब देते हैं: क्या उस पते तक का ट्रैफ़िक वहीं से निकलता है जहाँ आप चाहते थे?

उसी विचार के अन्य रूप

गंतव्यों में सोचना बंद करते ही पैटर्न सामान्य हो जाता है। टनल के डिफ़ॉल्ट रूट रखते हुए भी स्थानीय सबनेट पहुँच योग्य रह सकता है। LAN से जुड़े SSH सर्वर के उत्तर टनल में गायब होने के बजाय उसी इंटरफ़ेस से बाहर जा सकते हैं जिस पर वे आए थे। और इंटरफ़ेस-आधारित नियम वायरलेस इंटरफ़ेस पर आने वाली हर चीज़ को टनल में धकेल सकता है, जबकि होस्ट स्वयं जो ट्रैफ़िक पैदा करता है वह Ethernet पर रहता है:

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

वह अंतिम मामला गंतव्य के बजाय आने वाले इंटरफ़ेस से मेल खाता है, जो अलग नियम प्रकार और अलग मानसिक मॉडल है। फ़ॉरवर्ड किए गए ट्रैफ़िक के लिए net.ipv4.ip_forward सक्षम होना भी ज़रूरी है, और दूर के छोर को स्रोत श्रेणी को वापस रूट करना या उसका अनुवाद करना होगा; एक मशीन पर नियम कभी पथ का दूसरा आधा हिस्सा नहीं बनाता।

नियम को एकबारगी मानें

नियम और टेबल रूट मेमोरी में रहते हैं। फिर से कनेक्ट होने के बाद टनल डिवाइस का नाम बदल सकता है, आवंटित पता खिसक सकता है, और पुराना मान रखने वाला नियम चुपचाप मेल खाना बंद कर देता है। पूरा बदलाव उसी एक स्क्रिप्ट से दोबारा लागू करें जो उसका स्वामी है, फिर अपवाद पर भरोसा करने से पहले ip rule show, वर्तमान डिवाइस नाम और नए ip route get को किसी वास्तविक गंतव्य के सामने फिर से जाँचें।

कितनी भी सावधानी हो, दो सीमाएँ बनी रहती हैं। क्लाइंट अब भी अपने स्वयं के फ़िल्टर नियमों और रिज़ॉल्वर कॉन्फ़िगरेशन को नियंत्रित करता है, और रूटिंग अपवाद दोनों में से किसी को भी अधिलंघन नहीं करता। यदि क्लाइंट आपका पॉलिसी नियम भी हटा देता है, तो समर्थित रास्ते उसकी अपनी स्प्लिट-टनल पॉलिसी या ऐसा क्लाइंट हैं जो आपको रूट प्रबंधित करने देता है, जैसे OpenConnect; मॉनिटर को चुप कराने के लिए विक्रेता की बाइनरी को पैच करना एक अखंडता जाँच के साथ जुड़ी रखरखाव प्रतिबद्धता है।

टेबल नंबर, प्राथमिकता और गंतव्य को स्क्रिप्ट के बगल में एक नोट में लिखें। वरना अगला व्यक्ति ऐसा नियम पाएगा जो टनल से आगे निकल जाता है और उसके पास यह जानने का कोई तरीका नहीं होगा कि क्यों।