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 ക്ലയന്റ് സബ്നെറ്റിൽ എങ്ങനെ എത്തണം എന്ന് അറിയണം, അതിന്റെ ഫയർവാൾ ടണൽ ട്രാഫിക് അനുവദിക്കണം. പൊരുത്തക്കേട് മറയ്ക്കാൻ ചേർക്കുന്ന ഡിഫോൾട്ട് റൂട്ട് സാധാരണയായി യഥാർത്ഥ വിടവ് മറയ്ക്കുകയും ഒരാഴ്ച കഴിഞ്ഞ് മറ്റെന്തെങ്കിലും തകർക്കുകയും ചെയ്യുന്നു.