systemd-networkd के साथ दोबारा कनेक्ट होने पर ip rule को टिकाए रखें

ip rule से एक नीति नियम जोड़ें और वह तब तक काम करता है जब तक लिंक चला न जाए; उस क्षण वह बस नहीं रहता। कुछ भी ज़ोर से विफल नहीं हुआ: कर्नेल की स्थिति बदल गई, और किसी कॉन्फ़िगरेशन मालिक को पता नहीं था कि नियम का होना चाहिए। टिकने वाले और न टिकने वाले नियम के बीच पूरा अंतर यही है। systemd-networkd वाले होस्ट पर समाधान यह है कि नियम को एक मालिक दें, न कि हर दोबारा कनेक्शन के बाद कमांड फिर चलाएँ।

नियम तभी होता है जब कोई उसका मालिक हो

कर्नेल की रूटिंग नीति स्थिति है, कॉन्फ़िगरेशन नहीं। वह चल रहे सिस्टम में रहती है, और जो भी उस इंटरफ़ेस को ढहा देता है जिस पर वह निर्भर है, उसे साथ ले जा सकता है। शेल कमांड उस स्थिति को बदलता है और मंशा का कोई रिकॉर्ड नहीं छोड़ता।

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

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

किसी सेटिंग पर भरोसा करने से पहले संस्करण पढ़ें

मालिकाना व्यवहार networkd.conf की एक सेटिंग से नियंत्रित होता है, और वह सेटिंग पुराने systemd संस्करणों में नहीं है। उसके आसपास डिज़ाइन करने से पहले स्थापित संस्करण जाँचें, क्योंकि पुराना होस्ट उस दस्तावेज़ से अलग व्यवहार करता है जो आप पढ़ रहे हैं।

दो मान मायने रखते हैं। एक तय करता है कि networkd कॉन्फ़िगरेशन में घोषित न किए गए नियम हटाए जाएँ या नहीं, और दूसरा रूट के लिए वही करता है। दोनों नीति की सामग्री नहीं, मालिकाना के बारे में हैं, और दोनों वर्तमान संस्करणों में डिफ़ॉल्ट रूप से कड़ा व्यवहार चुनते हैं। इन्हें वैश्विक रूप से बंद करने पर हर बाहरी नियम जीवित रहता है, जो एक इच्छित VPN नीति घोषित करने से कहीं बड़ा निर्णय है।

systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null

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

नियम और वह तालिका घोषित करें जिसकी ओर वह इशारा करता है

.network फ़ाइल में नियम एक तालिका का नाम देता है, और नाम बस इतना ही करता है। वह उस तालिका के भीतर रूट नहीं बनाता और यह नहीं जाँचता कि वे समझदार हैं या नहीं। रूट के बिना नियम घोषित करने से ऐसी नीति बनती है जो ट्रैफ़िक से मेल खाती है और फिर उसे गिरा देती है।

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

[RoutingPolicyRule]
Family=ipv4
IPProtocol=tcp
SourcePort=443
Table=100
Priority=1000

[Route]
Destination=10.80.0.0/24
Gateway=10.80.0.1
Table=100

फिर दोबारा लोड करें और फ़ाइल के बजाय कर्नेल की स्थिति पढ़ें। साफ़ तरह से पार्स हुआ कॉन्फ़िगरेशन फिर भी ऐसा नियम बना सकता है जिसकी आपने मंशा नहीं की थी, और दोनों दृश्य तभी मेल खाते हैं जब घोषणा पूरी थी।

इंटरफ़ेस के लिए एक ही मालिक चुनें

एक ही टनल पर दो मैनेजर ऐसा संघर्ष पैदा करते हैं जो दोनों में बग जैसा दिखता है। मौजूदा wg-quick सेटअप को networkd में आयात करना जोड़ नहीं, स्थानांतरण है, और दोनों चलाने पर इंटरफ़ेस और उसके नियम दो मालिकों के अधीन रह जाते हैं।

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

मार्क का मालिकाना भी उतनी ही देखभाल माँगता है: अगर कोई नियम फ़ायरवॉल मार्क से मेल खाता है, तो किसी को वह मार्क सेट करना होगा। ऐसे मार्क की ओर इशारा करने वाला नियम जिसे कोई सेट नहीं करता, मृत कॉन्फ़िगरेशन है जो जानबूझकर किया हुआ लगता है।

जीवनचक्र की घटनाओं का अभ्यास करें

कॉन्फ़िगरेशन उतना ही अच्छा है जितना घटनाओं के पार उसका व्यवहार। लिंक नीचे उतारें, ऊपर लाएँ, सेवा फिर चालू करें और पता नवीनीकृत करें। हर एक के बाद नियमों की सूची और तालिका की सामग्री पढ़ें।

sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd

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