Android ගෙදර IPsec VPN වෙත සම්බන්ධ වන අතර Windows නොවන්නේ ඇයි

දුරකථනය කිසිදු පැමිණිල්ලක් නොමැතිව රවුටරයේ VPN වෙත එක් වන අතර, එකම Wi-Fi ජාලයේ ඇති ලැප්ටොප් එයට නොහැක. එකම පිවිසුම් තොරතුරු, එකම සේවාදායකය, එකම මොහොත. වෙනස මුරපදය නොව, ප්‍රොටොකොල සහායයි: රවුටරය එක් මෙහෙයුම් පද්ධතියක් ක්‍රියාත්මක කරන පැතිකඩක් ඉදිරිපත් කරයි, අනෙක් පද්ධතිය කිසිදා කළේ නැත.

පළමුව පැතිකඩ හඳුනා ගන්න, පසුව එය එක් එක් සේවාලාභියා ඇත්තටම කතා කරන දෙය සමඟ සසඳන්න.

එක මෙනුවක්, ප්‍රොටොකොල තුනක්

එක IPsec මාතෘකාවක් යටතේ, පාරිභෝගික උපාංග සඳහා වන ෆර්ම්වෙයර් තරමක් වෙනස් උමං තුනක් සඟවා තැබිය හැක. පළමුවැන්න XAUTH සමඟ IKEv1 ය: පොදු කණ්ඩායම් රහසක්, ඉන්පසු ඊට උඩින් පරිශීලක නාමයක් සහ මුරපදයක්. දෙවැන්න L2TP/IPsec වන අතර, එහි PPP පොදු යතුරකින් ආරක්ෂා කරන ලද IPsec ප්‍රවාහනයක් තුළ ක්‍රියා කරයි. තෙවැන්න IKEv2 වන අතර, සහතික හෝ EAP මගින් සත්‍යාපනය කෙරේ.

ලේබලය නොව ක්ෂේත්‍ර කියවන්න. කණ්ඩායම් රහසක් සහ පරිශීලක ලැයිස්තුවක් යනු IKEv1 XAUTH ය. පොදු යතුරක් සහ PPP ගිණුමක් යනු L2TP/IPsec ය. කණ්ඩායම් රහසක් නොමැති සේවාදායක සහතිකයක් යනු IKEv2 ය.

දුරකථනය සහ ලැප්ටොප් අතර සහාය පරතරය

Android තුළම IKEv1 XAUTH PSK සේවාලාභියෙක් ඇත, එබැවින් වෙනත් කිසිවක් නොදෙන රවුටරයක් සමඟ දුරකථනය සාර්ථක වේ. Windows එසේ නොවේ: එහි මුල් සේවාලාභියා L2TP/IPsec සහ IKEv2 හසුරුවයි, සක්‍රීය කිරීමට IKEv1 XAUTH විකල්පයක් නැත. රහස නැවත ඇතුළත් කිරීමෙන් ප්‍රයෝජනයක් නැත, මන්ද නොමැති කොටස ප්‍රොටොකොලය මිස පිවිසුම් තොරතුරු නොවේ.

Apple පැත්ත චලනය වන ඉලක්කයකි. නව macOS සහ iOS නිකුතු IKEv2 දෙසට යොමු වේ, පැරණි Cisco-විලාස පැතිකඩ සමහර ගොඩනැගීම්වල දිගටම පවතී, සහ උත්ශ්‍රේණියක් පසුගිය මාසයේ වැඩ කළ දේ ඉවත් කිරීමට හෝ තද කිරීමට හැක. ඊයේ සම්බන්ධ වී අද නොවන Mac එකක්, රවුටරයේ වෙනසක් නොමැතිව, සාමාන්‍යයෙන් මෙයයි.

වෙනත් ආකාරයෙන් නිවැරදි පැතිකඩ බිඳ දමන සැකසුම් දෙකක්

Synology හි L2TP/IPsec පිටුව Enable SHA2-256 compatible mode (96 bit) යනුවෙන් ලේබල් කළ සලකුණු කොටුවක් ලබා දෙයි. iOS 14 සහ macOS Big Sur සිට Apple සේවාලාභීන් එම කපා දැමූ ප්‍රකාරය ප්‍රතික්ෂේප කරයි, එබැවින් ඔවුන් සඳහා එය ඉවත් කළ යුතුය. එය සක්‍රීයව තැබුවහොත්, උමඟ සත්‍යාපනය වී පසුව බිඳ වැටේ; එය නරක පිවිසුම් තොරතුරු ලෙස පෙනේ, නමුත් එසේ නොවේ. නිෂ්පාදකයා මෙම ස්විචය ලේඛනගත කරයි, සහ මෙය වැදගත් වීම ආරම්භ වන සුපුරුදු මොහොත මෙහෙයුම් පද්ධති උත්ශ්‍රේණියයි.

Windows සහතික වෙන වෙනම ගබඩා දෙකක තබා ගනී, IKEv2 කියවන්නේ යන්ත්‍රයේ එක පමණි. සේවාලාභී සහතිකය එහි පෞද්ගලික යතුර සමඟ පරිගණක ගිණුමට ආයාත කරන්න; ඔබේම පරිශීලක ගිණුම යටතේ ගොනු කරන සහතිකයක් කළමනාකරණ කොන්සෝලයේ පෙනෙන නමුත් IKEv2 සේවාව වෙත කිසිදා ළඟා නොවේ. EAP-TLS යනු පරිශීලක සහතිකයක් භාවිත කළ හැකි එකම අවස්ථාවයි, එහිදීත් අත්සන් කරන CA යන්ත්‍රය විසින් විශ්වාස කළ යුතුය. මෙය වැරදි කිරීම සත්‍යාපන අසාර්ථකත්වයක් ලෙස පෙනේ, නොමැති සහතිකයක් ඉල්ලන විමසුමක් ලෙස නොවේ.

රවුටරය එලෙසම පවතින විට

XAUTH PSK පමණක් කතා කරන රවුටරයක් ඉදිරියට මාර්ග තුනක් ඉතිරි කරයි: නිෂ්පාදකයාගේ සේවාලාභියා, පැතිකඩ තවමත් ක්‍රියාත්මක කරන තෙවන පාර්ශ්ව සේවාලාභියෙක්, හෝ උමං අන්තය IKEv2 කතා කරන දෙයකට ගෙන යාම. උදාහරණයක් ලෙස AVM එහි රවුටර සඳහා Windows සේවාලාභී මෘදුකාංගයක් සහ අපනයනය කළ වින්‍යාස ගොනුවක් ප්‍රකාශයට පත් කරයි. එම මාර්ගයට සහාය ඇත, එය එක් එක් ලැප්ටොප් එකේ නිෂ්පාදක මෙවලමක් ස්ථාපනය කිරීම අදහස් කරයි.

ලැප්ටොප් ඔබේ නොවන විට නැවත ගොඩනැගීමට, සහාය අලංකාරයට වඩා වැදගත් වේ.

ආරක්ෂක පිරිවැය ද සලකා බලන්න. එක් කණ්ඩායම් රහසක් සෑම පරිශීලකයෙකුම ආවරණය කරයි, එබැවින් එය දරන ඕනෑම අයෙකු සේවාදායකයා ලෙස පෙනී සිටිය හැකි අතර සේවාලාභියා ලබා දෙන පරිශීලක නාමය සහ මුරපදය අල්ලා ගත හැක. සහතික සමඟ IKEv2 ලබා ගත හැකි තැන, එම සංක්‍රමණය ඕනෑම සේවාලාභී විසඳුමකට වඩා වටී.

පිටතින් ඇතුළට රෝග විනිශ්චය කරන්න

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

ක්‍රියාකාරී දුරකථන පැතිකඩ පාලකය ලෙස තබා ගන්න. ෆර්ම්වෙයර් යාවත්කාලීනයකින් පසු බිඳෙන්නේ ලැප්ටොප් පමණක් නම්, සේවාදායක පැත්ත පෙර පරිදිම හැසිරේ. දෙකම බිඳේ නම්, කිසිදු සේවාලාභියෙකු ස්පර්ශ කිරීමට පෙර සහතිකය හෝ සවන් දෙන පෝර්ටය දෙස බලන්න.