क्या Pi गेटवे का होस्टनाम स्थिर रूट अपने आप अपडेट करता है?

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

DNS उत्तर और रूट अलग-अलग वस्तुएँ हैं

मान लें कि आपका Pi vpn-gw.lan पर उत्तर देता है और 10.44.0.0/16 को एक टनल में फ़ॉरवर्ड करता है। 192.168.30.0/24 पर मौजूद क्लाइंट एक स्थिर रूट से वहाँ पहुँचते हैं। जब Pi का पता 192.168.30.4 से 192.168.30.11 पर चला गया, रिकॉर्ड अपने TTL के भीतर साथ चला और रूट नहीं।

दोनों दृष्टिकोण ऐसे असहमत हैं जिसे चूकना आसान है, क्योंकि अलग-अलग पूछने पर दोनों विश्वसनीय लगते हैं:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

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

कमांड खत्म होने के बाद तालिका में क्या बचता है

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

इसीलिए ip route add 10.44.0.0/16 via vpn-gw.lan काम करता हुआ लग सकता है। उपकरण कमांड चलते समय नाम हल करता है, परिणामी पता लिखता है, और नाम को पूरी तरह भूल जाता है। बाद में ip route show 10.44.0.0/16 चलाएँ और आपको शब्दशः पता वापस मिलेगा।

टनल को दोष देने से पहले यह व्यवहार जानने योग्य है।

वे उपकरण जो आपके लिए नाम हल करते हैं, और कब

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

प्रबंधित सेटअप काम को बाँटते हैं। एक DHCP आरक्षण या स्थिर लीज़ Pi को एक पते पर रखता है, और DNS रिकॉर्ड बस लीज़ का अनुसरण करता है। किसी को चलते लक्ष्य को ट्रैक करने की ज़रूरत नहीं है, क्योंकि लक्ष्य चलता नहीं है।

निगरानी किया गया अपडेटर दूसरा वैध पैटर्न है, और उसे एक मालिक चाहिए।

पता पिन करें या अपडेटर खुद चलाएँ

छोटे LAN के लिए DHCP सर्वर पर आरक्षण सबसे सस्ता उपाय है। गतिशील पूल के बाहर एक पता चुनें, उसे Pi के MAC पते से बाँधें, और अगले लीज़ नवीनीकरण के बाद ip -4 addr show dev eth0 से उसकी पुष्टि करें। फिर क्लाइंट का अगला हॉप एक बार उस पते की ओर इंगित करें। अब आपके पास एक स्थिर गेटवे और उसका वर्णन करने वाला रिकॉर्ड है, और संबंध वास्तव में जिस क्रम में काम करता है वही यही है।

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

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

अंतिम कमांड स्वीकृति परीक्षण है, क्योंकि यह वह गेटवे छापता है जिसे कर्नेल वास्तव में उपयोग करेगा। यदि छपा हुआ पता अभी भी पुराना है, तो स्क्रिप्ट गलत नेटवर्क नेमस्पेस में चली या उसमें अनुमति नहीं थी, और DNS पक्ष अप्रासंगिक है।

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