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 ට සේවාලාභී උපජාලයට ළඟා වන ආකාරය දැනගත යුතු අතර, එහි ෆයර්වෝලය ටියුනල් ට්‍රැෆික් අවසර දිය යුතුය. නොගැළපීම වසා දැමීමට එකතු කරන පෙරනිමි මාර්ගය සාමාන්‍යයෙන් සැබෑ පරතරය සඟවා සතියකට පසු වෙනත් දෙයක් කඩයි.