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 வாடிக்கையாளர் துணைப்பிணையை எப்படி அடைவது என்பதை அறிய வேண்டும், அதன் ஃபயர்வால் சுரங்கப்பாதைப் போக்குவரத்தை அனுமதிக்க வேண்டும். பொருந்தாமையை மறைக்கச் சேர்க்கப்படும் இயல்புநிலை வழி பொதுவாக உண்மையான இடைவெளியை மறைத்து ஒரு வாரம் கழித்து வேறொன்றை உடைக்கிறது.