ඔබේ VPN පූලය LAN හි DHCP පරාසය නොවේ: එය බිඳෙන්නේ ඇයි

කාර්යාලයේ DHCP සේවාදායකය භාවිතා කරන එකම පරාසයෙන් VPN සේවාදායකයන්ට ලිපින ලබා දීම පෙළඹවීම ඇති කෙටි මාර්ගයයි, කෙසේ වෙතත් සියල්ල එකම ජාලයක් යන උපකල්පනයෙන්. එය එසේ නොවේ. රවුට් කළ ටනලයක් කෙළවර දෙකක් අතර unicast පැකට් ගෙන යයි, නමුත් LAN පූලය පවතින්නේ භෞතික කොටසක broadcast ඉල්ලීම්වලට පිළිතුරු දීමටය. එම අංක නැවත භාවිත කිරීමෙන් බෙදාහරින්නන් දෙදෙනෙකු එකම ලිපින අවකාශයකට වගකිව යුතු වන අතර නැවත පැමිණෙන මාර්ගය නිර්වචනය නොකළ ලෙස තබයි.

බෙදාහරින්නන් දෙදෙනෙක්, එකම ලිපින අවකාශයක්

LAN හි DHCP සේවාදායකය දන්නවා තමන් කුමන ලිපින කුමන MAC ලිපිනයට බදු දුන්නාද කියා, සහ ARP මගින් ඒවා ආරක්ෂා කරයි. VPN සේවාදායකයට තමන්ගේම පූලයක් ඇති අතර ඒ බදු ගැන කිසිවක් නොදනී. දෙදෙනාම වැරදි නොවේ; ඔවුන් එකිනෙකාට හඳුන්වා දී නැත.

VPN සේවාදායකය LAN පූලයෙන් දෙන ලිපිනයක් දැනටමත් මුද්‍රණ යන්ත්‍රයකට අයත් විය හැක. දැන් උපාංග දෙකක් එකම පූර්වාංගයේ එකම ලිපිනයක් ඉල්ලා සිටී, සහ ස්විචයේ යැවීම් වගුව කවුරුන් පිළිතුරු දෙන්නේද යන්න තීරණය කරයි.

මිනිසුන් මුලින්ම මුහුණ දෙන දෝෂය මෙයයි: සාර්ථකව සම්බන්ධ වී පසුව වැරදි යන්ත්‍රයට ළඟා වන සේවාදායකයෙක්, නැතහොත් නිවැරදි එකට කලින් කලට ළඟා වන සේවාදායකයෙක්.

රවුටරය VPN ලිපින බෙදා නොදෙන්නේ ඇයි

DHCP සොයාගැනීම broadcast එකක් වන අතර broadcast රවුට් කළ මායිමක නතර වේ. සැලසුම ටනලය පාලම් නොකරන්නේ නම් හෝ ගැළපෙන අධිකාරියක් සහිත DHCP රිලේක් නොකරන්නේ නම්, සේවාදායකයාගේ ඉල්ලීම කිසිදා LAN සේවාදායකයට ළඟා නොවේ.

එබැවින් VPN සේවාදායකය ලිපිනය තමන්ම නියම කරයි: සේවාදායක වින්‍යාසයේ පූලයක්, WireGuard සැකසුමක එක් එක් සහකරුට ලිපිනයක්, නැතහොත් IKEv2 යෙදවීමක සත්‍යාපන ස්ථරය තල්ලු කරන ලිපිනයක්. මෙම ක්‍රියාවලි LAN හි බදු දත්ත සමුදායෙන් ස්වාධීන වන අතර, එබැවින්ම ඒවාට තමන්ගේම පරාසයක් අවශ්‍ය වේ.

එම තර්කයම පැහැදිලි කරන්නේ DHCP විෂය පථය වෙනස් කිරීමෙන් කිසිදා ලිපිනයක් නොලබන VPN සේවාදායකයා අලුත්වැඩියා නොවන්නේ ඇයි කියාය. සේවාදායකයා LAN සේවාදායකයෙන් අසන්නේ නැත, විෂය පථය සංස්කරණය කිරීමෙන් කොපමණ වුවද ඔහු අසන්නට සැලැස්විය නොහැක.

අතිච්ඡාදනය මන්දගාමී ජාලයක් ලෙස නොව ගැටුමක් ලෙස දිස් වේ

සහාය දක්වන සැලසුමක් නොමැතිව එකම පූර්වාංගය බෙදා ගන්නා ජාල දෙකක් ද්විත්ව අයිතියට වඩා වෙනස් ගැටලුවක් වන අතර ඒවා බොහෝ විට ව්‍යාකූල වේ. VPN පූලය වෙනම පූර්වාංගයක් නම්, මාර්ගයක් රථවාහන වැරදි පැත්තට යවන විට පමණක් අතිච්ඡාදනය වැදගත් වේ. පූලය LAN පූර්වාංගය තුළ නම්, ගැටුම ක්ෂණික හා දේශීය වේ.

ප්‍රායෝගිකව ඔබට වැරදි උපාංගයෙන් ARP පිළිතුරු, මැදින් නැවත සැකසෙන සම්බන්ධතා, සහ තමන්ගේම ලිපිනය වෙනත් අයෙකු ඉල්ලා සිටින සේවාදායකයෙක් දකිනු ඇත. මේ කිසිවක් රවුට් කිරීමේ ගැටලුවක් ලෙස නොපෙනෙන බැවින් නිවැරදි කිරීම වැරදි ස්ථරයට යෙදේ. ද්විත්ව බද්දක් තහවුරු කිරීම පහසුය, එය සමඟ ජීවත් වීම කරදරයකි. එය නැවත ආරම්භ කිරීම්වලිනුත් ඉතිරි වේ, මන්ද බෙදාහරින්නන් දෙදෙනාම එකම ලිපිනය ඉල්ලා සිටී.

නැවත පැමිණෙන මාර්ගය වෙනම ගැටලුවකි

පිරිසිදු හා වෙනම පූලයක් සමඟ වුවද, LAN සත්කාරකයන් දැනගත යුතුයි සේවාදායකයෙකුට පිළිතුරු දෙන්නේ කෙසේද කියා. ඔවුන්ගේ පෙරනිමි ගේට්වේ රවුටරයයි, රවුටරයට පූලය සඳහා VPN සේවාදායකයට යොමු වන මාර්ගයක් අවශ්‍ය වේ, සැලසුම ඒ වෙනුවට සේවාදායකයාගේ රථවාහන පරිවර්තනය නොකරන්නේ නම්.

කිසිවක් වෙනස් කිරීමට පෙර මාර්ගය දිශා දෙකෙන්ම කියවන්න. ගේට්වේ එකේදී කර්නලය සේවාදායක ලිපිනයට භාවිත කරන අතුරුමුහුණත කුමක්දැයි අසන්න; සේවාදායකයාගේදී LAN ලිපිනයට භාවිත කරන මාර්ගය කුමක්දැයි අසන්න.

මෙම විධාන ගේට්වේ එකේ යැවීම් තීරණය සහ අනුපිටපතක් හෙළිදරව් කරන අසල්වැසි සටහන් පෙන්වයි:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

පළමු විධානය ටනලයේ අතුරුමුහුණත සමඟ පිළිතුරු දෙන්නේ නම්, නැවත පැමිණෙන මාර්ගය පවතී. එය LAN අතුරුමුහුණත සමඟ පිළිතුරු දෙන්නේ නම්, රවුටරය සිතන්නේ සේවාදායකයා කම්බියේ සිටින බවයි, සහ ඔහු සඳහා ARP කිරීමට උත්සාහ කරයි.

පාලම් සැලසුම් ඇත, නමුත් ඒවා තෝරා ගත යුතුය

ටනලයක් LAN වෙත පාලම් කිරීම සැබෑ සැලසුමකි, සේවාදායකයන්ට broadcast ලැබිය යුතු විට හෝ එක් කොටසක් උපකල්පනය කරන ප්‍රොටොකෝල මගින් ඔවුන් සොයා ගත යුතු විට භාවිත කෙරේ. එයට සේවාදායකයට එම පාලම් හැසිරීම සහ ඒ සමඟ එන ලිපින හැසිරවීම තිබිය යුතුය.

ක්‍රියා නොකරන දෙය නම් අංක පිටපත් කර ප්‍රතිඵලය අනුකරණය කිරීමයි. පාලමක් නොමැති හවුල් පූලයක් ඔබට සොයාගැනීමක් නොමැතිව ගැටුම ලබා දෙයි, එය දෙවිධියේම නරකම දෙයයි.

යෙදුමට සැබවින්ම කොටස අවශ්‍ය නොවන්නේ නම් වෙනම පූලයක් සමඟ තුන්වන ස්ථරය තෝරන්න, සහ පූලය ලේඛනගත කරන්න, එවිට ඊළඟ පරිපාලකයා පිළිවෙල සඳහා DHCP පරාසය නැවත භාවිත නොකරනු ඇත.