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 ला क्लायंट सबनेटपर्यंत कसे पोहोचायचे हे माहीत असणे आवश्यक आहे, आणि त्याच्या फायरवॉलने टनेल रहदारीला परवानगी द्यायला हवी। विसंगती झाकण्यासाठी जोडलेला डीफॉल्ट मार्ग सहसा खरी तफावत लपवतो आणि आठवड्यानंतर दुसरे काहीतरी तोडतो।