के 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 ले ग्राहक सबनेटमा कसरी पुग्ने जान्नुपर्छ, र यसको फायरवालले सुरुङ ट्राफिकलाई अनुमति दिनुपर्छ। मेल नमिलेको कुरा छोप्न थपिएको पूर्वनिर्धारित रुटले सामान्यतया साँचो खाली ठाउँ लुकाउँछ र एक हप्तापछि अरू केही बिगार्छ।