රුට් කළ OpenVPN උමඟක් හරහා නම් සෙවීම් ඇයි අසාර්ථක වන්නේ
රුට් කළ TUN උමඟක් ගෙන යන්නේ unicast IP පමණි, එබැවින් broadcast නම් විමසුමට එයට ඇතුළට මාර්ගයක් කිසිදා නොතිබුණි. පාලම මායිම ඉවත් කරයි; DNS තල්ලු කිරීම ලාභදායී නිවැරදි කිරීමයි.
සත්කාරකය ping වලට ලිපිනයෙන් පිළිතුරු දෙන නමුත් නමින් සිදු කරන සෑම සෙවීමක්ම අසාර්ථක වේ. උමඟ ක්‍රියාත්මක වන අතර මාර්ගය ද පවතී, එබැවින් ස්වාභාවික නිගමනය වන්නේ VPN වැරදි ලෙස වින්‍යාස කර ඇති බවයි. වඩාත් ප්‍රයෝජනවත් නිගමනය නම් එම සෙවීම කිසිදා රුට් කළ නොහැකි වූ බවයි: රුට් කළ උමඟක් unicast IP ගෙන යන අතර, එම විමසුම අනෙක් පැත්තේ නොමැති කොටසක් සොයමින් තිබූ broadcast එකක් විය. ස්තරවල නොගැළපීම පෙනෙන්නට පටන් ගත් විට, නිවැරදි කිරීම් තමන්ම පිරිවැය අනුව පෙළගැසෙයි.
මිථ්‍යාව: නම් අසාර්ථක වන නිසා උමඟ කැඩී ඇත
රෝග ලක්ෂණය විශ්වාසදායක වන්නේ නම් ස්තරයට ඉහළින් ඇති සියල්ල ක්‍රියාත්මක වන නිසාය. ලිපින රුට් වේ, අතුරුමුහුණත ක්‍රියාත්මකය, සහ සහකරු ping වලට පිළිතුරු දෙයි. අසාර්ථක වූයේ ලක්ෂ්‍යයේ සිට ලක්ෂ්‍යයට සබැඳියක් හරහා කිසිදා මාර්ගයක් නොතිබූ සොයාගැනීමේ යාන්ත්‍රණයයි, එය කැඩුණු උමඟකින් වෙනස් ප්‍රකාශයකි. මෙම ප්‍රකාශ දෙක වෙන් කිරීම රෝග විනිශ්චයේ විශාල කොටසයි.
එය උමඟේ දෝෂයක් ලෙස සැලකීම උපකාර කළ නොහැකි පැතිකඩ සංස්කරණවලට යොමු කරයි. විකල්ප එකතු කිරීම, සංකේතනය මාරු කිරීම හෝ සේවාදායකය නැවත ස්ථාපනය කිරීම broadcast එක තිබූ තැනම තබයි.
නිවැරදි කිරීම නම් කිරීමට පෙර අසාර්ථක වූ යාන්ත්‍රණය නම් කරන්න. broadcast භාවිතා කරන සෙවීමකට කොටසක් අවශ්‍ය වන අතර, විසඳන්නෙකු භාවිතා කරන සෙවීමකට ඇසීමට ලිපිනයක් අවශ්‍ය වේ.
TUN ගෙන යන දේ සහ නොගෙන යන දේ
TUN උපාංගය IP අතුරුමුහුණතකි, එයම එය රුට් කළ හැකි එකක් කරයි. OpenVPN සේවාදායකයාට ලිපිනයක් සහ මාර්ග කට්ටලයක් ලබා දෙන අතර, ඉන් පසු සේවාදායකයා සහකරුට දත්තග්‍රෑම් යවයි. එම ආකෘතියේ කිසිවක් සෑම සත්කාරකයක්ම සෑම රාමුවක්ම අසන බෙදාගත් සබැඳියක් නොසාදයි.
සොයාගැනීමේ ගමනාගමනය එම ආකෘතියට කිසිසේත් නොගැළපේ. පැරණි Windows නම් විමසුම්, SSDP නිවේදන සහ mDNS ඉල්ලීම් එක් ගමනාන්තයකට වෙනුවට කොටසක සියල්ලන්ට යවනු ලැබේ. රුට් කළ සබැඳියකට යැවීමට «සියල්ලන්» නොමැත. එම එක් එක් යාන්ත්‍රණය බෙදාගත් මාධ්‍යයක් උපකල්පනය කරයි.
එබැවින් උමඟ සෞඛ්‍ය සම්පන්න විය හැකි අතරම සොයාගැනීම සම්පූර්ණයෙන් අසාර්ථක විය හැක. යමෙකු VPN බිම වැටී ඇති බව වාර්තා කරන විට රැඳී සිටිය යුතු වාක්‍යය එයයි.
පාලම ක්‍රියා කරන්නේ මායිම ඉවත් කිරීමෙන්
TAP උපාංගය රාමු ගෙන යන අතර, පාලමක් එය සැබෑ LAN කොටසකට සම්බන්ධ කරයි. එවිට සේවාදායකයාට එම කොටසේ ලිපිනයක් ඇති අතර එහි broadcast ගමනාගමනය අසයි. එබැවින් පාලම නම් ගැටලුව සුව කරන බව පෙනේ. එය සේවාදායකයා ලිපිනකරණය සඳහා එම කොටස මත යැපෙන්නට ද තබයි.
සුවය රුට් මායිම ඉවත් කිරීමයි, උමඟ තුළ නම්කරණයේ නව හැකියාවක් නොවේ. කොටස broadcast කරන සියල්ල දැන් සබැඳිය ද පසු කරයි.
කුඩා විද්‍යාගාරයකට මෙය සාධාරණ හුවමාරුවකි. විසිරුණු කාර්ය මණ්ඩලයකට මෙය කලාතුරකින් වේ.
DNS සහ WINS තල්ලු කිරීම වඩාත් පටු නිවැරදි කිරීමයි
සේවාදායකයාට ඇසීමට නිශ්චිත ස්ථානයක් දෙන්න. dhcp-option DNS සහ dhcp-option DOMAIN අභ්‍යන්තර නම් කලාපය දන්නා සේවාදායකයකට යොමු කරයි, සහ තවමත් NetBIOS මත රඳා පවතින Windows සේවාදායකයාට එලෙසම WINS සේවාදායකයක් ලැබිය හැක. උමඟ රුට් වී පවතින අතර කොටස එහි ස්ථානයේම පවතී.
කොන්දේසි දෙකක් එය ක්‍රියාත්මක වේද යන්න තීරණය කරයි. සඳහන් කළ සේවාදායකය කලාපය සඳහා පිළිතුරු දිය යුතු අතර, විමසුම උමඟ හරහා අවසර ලැබිය යුතුය.
විසඳන්නා සේවාදායකයේම shell එකෙන් නොව සේවාදායකයාගෙන් පරීක්ෂා කරන්න. ස්ථානීයව ක්‍රියාත්මක වන විසඳන්නෙකු උමඟ ගෙන යන දේ ගැන කිසිවක් නොකියයි.
කුමන ස්තරය අසාර්ථක වුණාදැයි සොයා ගන්න
මුලින්ම ලිපිනයට ping කරන්න, පසුව නම විසඳා කුමන සේවාදායකය පිළිතුරු දුන්නේ ද කියවන්න. කලාපය සත්කාරක නොකරන සේවාදායකයක ඍණාත්මක පිළිතුර, යන්ත්‍රයෙන් කිසිදා පිටවී නොගිය විමසුමකට වඩා වෙනස් ලෙස පෙනේ. විසඳෙන නමුත් සම්බන්ධතා ප්‍රතික්ෂේප කරන නමක් සම්පූර්ණයෙන්ම තුන්වන ගැටලුවකි.
Multicast එම බිත්තිය පිටුපසම ඇත. 224.0.0.251 වැනි කණ්ඩායමක් පෙරනිමියෙන් රුට් කළ උමඟක් හරහා යවනු නොලැබේ, සහ multicast තේරුම් ගන්නා මාර්ගයක් හෝ LAN හි පරාවර්තකයක් නොමැතිව කණ්ඩායම සඳහා මාර්ගය ප්‍රමාණවත් නොවේ.