සයිට්-සයිට් VPN සඳහා සටහන් කළ යුත්තේ කුමක්ද: සෙලෙක්ටර් සහ විෂය පථය
සෙලෙක්ටර් සටහනක් කියන්නේ එක් එක් පැත්තට පෙනෙන දේ ය. සකසන ලද ප්‍රොෆික්ස්, එකඟ වූ සබැඳුම්, පරිවර්තනය සහ සේවා හිමිකාරිත්වය යන සියල්ල එහි ඇතුළත් වේ.
ටනලය සක්‍රීය වී මාස හයකට පසු නව උපජාලයක් ප්‍රතිපත්තිය සමඟ නොගැළපෙන අතර, හවුල් තැටියේ ඇති එකම ලේඛනය කියන්නේ කාර්යාල VPN යන්න පමණි. සෙලෙක්ටර් සටහනක් වළක්වන්නේ එවැනි අසාර්ථකත්වයක් ය, එය නිශ්චිත ය: ලිපින කට්ටලය වෙනස් විය, නමුත් ලේඛන වෙනස් නොවීය. සටහන නිවැරදිව ලිවීම යනු ලිපින කට්ටල කිහිපයකින් ඔබ විස්තර කරන්නේ කුමක්දැයි දැනගැනීම, සහ ඔබ සකසා ඇති දෙය නොව, අනෙක් පැත්ත ඇත්තටම බලාත්මක කරන දෙය සටහන් කිරීම ය.
සකසා ඇත්තේ එකඟ වූ දෙය නොවේ
ප්‍රතිපත්ති පාදක IPsec ටනලයක එක් එක් පැත්ත ට්‍රැෆික් සෙලෙක්ටර් යෝජනා කරයි: දරු සබැඳුම සඳහා මූලාශ්‍ර සහ ගමනාන්ත පරාස. පිළිතුරු දෙන පැත්තට එම යෝජනාව පටු කිරීමට අවසර ඇත, එබැවින් ස්ථාපිත සබැඳුම වින්‍යාසයේ ලැයිස්තුගත කර ඇති ප්‍රමාණයට වඩා අඩුවක් ආවරණය කළ හැක. වින්‍යාසය පිටපත් කරන සටහනක් විස්තර කරන්නේ අභිප්‍රායක් මිස වර්තමාන ආරක්ෂණ විෂය පථය නොවේ. දෙක නිහඬව ඈත් වේ, ටනල තත්ත්ව පිටුවේ එය පෙන්වන කිසිවක් නැත.
ඔබ නිරීක්ෂණය කළ දිනය සමඟ තීරු දෙකම තබා ගන්න. සකසන ලද සෙලෙක්ටරය යනු ඔබ අදහස් කළ දෙය ය; එකඟ වූ එක යනු කර්නලය දැන් බලාත්මක කරන දෙය ය. ඒවා වෙනස් වන විට, එම වෙනස මාර්ගගත කිරීමේ දෝෂයකට වඩා බොහෝ විට අනපේක්ෂිත අසාර්ථකත්වයක් පැහැදිලි කරයි.
එක් සබැඳුමක් සකසන ලද සෑම යුගලයක්ම නියෝජනය නොකරයි. සෙලෙක්ටර් සංයෝජන කිහිපයක් සහිත ටනලයකට අවසානයේ දරු සබැඳුම් කිහිපයක් තිබිය හැක, ඒවායින් එකක් පමණක් ලැයිස්තුගත කරන සටහනක් අසම්පූර්ණ ලැයිස්තුවකි. සාරාංශ කරනවාට වඩා ඒවා එකින් එක ගණන් කරන්න.
මාර්ග පාදක ටනල වෙනස් ලෙස තෝරයි
මාර්ග පාදක අතුරුමුහුණතක් සමඟ මාර්ගගත කිරීමේ වගුව ටනලයට ඇතුළු වන්නේ කුමක්ද යන්න තීරණය කරයි, සෙලෙක්ටර් හිතාමතා පළල් විය හැක. එය නොසැලකිල්ලක් නොව වලංගු නිර්මාණයක් ය, සටහන එය එසේම විස්තර කළ යුතු ය. මාර්ගය, එය යොමු වන අතුරුමුහුණත, සහ කුමන සේවා ළඟා විය හැකිද යන්න සීමා කරන ෆයර්වෝල් ප්‍රතිපත්තිය ලියන්න. ආරක්ෂණ විෂය පථය හිතාමතා පළල් ය, පටු කිරීම සේවා විෂය පථය කරයි.
ප්‍රතිපත්ති පාදක අච්චුවක් මාර්ග පාදක ටනලයකට පිටපත් කිරීමෙන් යෙදවීම භාවිත නොකරන යාන්ත්‍රණයක් විස්තර කරන ලේඛනයක් නිපදවයි. ඊළඟ ඉංජිනේරුවා එහි කිසිදා නොතිබිය යුතු සෙලෙක්ටර් සොයයි, ටනලය වැරදි ලෙස වින්‍යාස කර ඇතැයි නිගමනය කරයි, ඇත්තටම එය නරක ලෙස සටහන් කර තිබුණා පමණි.
පරිවර්තනය එකම වගුවට අයත් වේ
NAT මගින් අනෙක් පැත්තට වෙනස් පරාසයක් ඉදිරිපත් කරන විට, මුල් සහ පරිවර්තිත ප්‍රොෆික්ස් එකට සටහන් කරන්න. සෙලෙක්ටර් සහ ප්‍රවේශ නීති ඒවා සමඟ ගැළපෙන අදියර සටහන් කරන්න, මන්ද අනුපිළිවෙල තීරණය කරන්නේ ඈත පැත්තට ඔබ ලියූ ලිපිනය කිසිදා පෙනේද යන්න ය. පරාස දෙකෙන් එකක් පමණක් ඇති වගුවක් වගුවක් නොමැති වීමට වඩා නරක ය, එය සම්පූර්ණ ලෙස පෙනේ.
NAT වෙනසකට පසු වැඩ කරන ටනලයක් බිඳ දමන විස්තරය මෙය ය: සෙලෙක්ටරය තවමත් මුල් ප්‍රොෆික්සය සමඟ ගැළපේ, අනෙක් පැත්තට දැන් පරිවර්තිත එකක් ලැබේ, එහි ආපසු මාර්ගය තවදුරටත් නොපවතින ලිපිනයකට යොමු වේ. ඒවා ගැළපීම නවත්වන මොහොතේ කිසිවක් දෝෂයක් සටහන් නොකරයි.
පෞද්ගලික DNS එකම තැනට අයත් වේ. අදාළ අඩවියෙන් භාවිත කළ නොහැකි ලිපිනයකට විසඳෙන නමක් යනු සහාය ටිකට්පතක් සමඟ ලේඛන දෝෂයකි, එය ටනලයට දොස් පැවරේ.
සේවා අවශ්‍යතාව අමුණන්න
ආරක්ෂිත පරාසයක් යනු අවසර ලැයිස්තුවක් නොවේ. කුමන සේවා කුමන මූලාශ්‍රයකින් ළඟා විය යුතුද, ඒවා පිටුපස ඇති යෙදුමේ හිමිකරු කවුද යන්න ලියන්න. එම ක්ෂේත්‍ර දෙක වෙනස් ප්‍රශ්නවලට පිළිතුරු දෙයි, ඒවා මිශ්‍ර කිරීම නිසා ආරක්ෂක සමාලෝචනයක් අවසානයේ ප්‍රවේශය ගැන නොව මාර්ගගත කිරීම ගැන තර්ක කරයි.
ඉන්පසු මෙම නියමය නඩත්තු කරන ජාල පරිපාලකයා නම් කරන්න. හිමිකරු නොමැති සෙලෙක්ටර් ලැයිස්තුවක් නිහඬව පැරණි වේ, රාත්‍රී දෙකට ටනලය බිඳෙන විට පැරණි සහ වැරදි අතර වෙනසක් දැකිය නොහැක. වෙනස හිතාමතා සිදු වූ බව තහවුරු කළ හැකි පුද්ගලයා ද හිමිකරු ය.
සටහන පරීක්ෂණ සැලැස්මක් බවට පත් කරන්න
අවශ්‍ය සෑම මාර්ගයක් සඳහා නියෝජිත මූලාශ්‍ර සහ ගමනාන්ත සත්කාරකයක් තෝරා, අපේක්ෂිත මාර්ගය, සේවාව සහ පිළිතුරු ගේට්වේ සටහන් කරන්න. එය ලේඛනය විස්තරයක් නොව පරීක්ෂණ සැලැස්මක් බවට පත් කරයි. පහත විධානයෙන් සක්‍රීය සබැඳුම කියවා, ඔබ සටහන් කළ එකඟ පේළිය සමඟ සසඳන්න.
swanctl --list-sasපේළි පහක ලදකයක් සාමාන්‍යයෙන් සටහන අවංකව තබා ගැනීමට ප්‍රමාණවත් ය. පහත අනුවාදය කැපීමකින් තොරව වෙනස්කම් ටිකට්පතකට ගැළපේ:
sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netopsගේට්වේ දක්වා පමණක් පිංග් කිරීම පිළිගැනීමේ පරීක්ෂණය නොවේ. එය කිසිදා සංක්‍රාන්ති මාර්ගය භාවිත නොකරයි, එබැවින් යැවෙන සෑම ප්‍රවාහයක්ම අසාර්ථක වන විටත් එය සමත් විය හැක. එක් පැත්තක සත්කාරකයක සිට අනෙක් පැත්තේ සේවාවකට පරීක්ෂා කර පිළිතුර ටනලය හරහා පැමිණෙන බව තහවුරු කරන්න. පිංග් පමණක් සමත් වුවහොත්, වළක්වා ගැනීමට ලියූ එම යැවීමේ ගැටලුව සටහන දැන් සොයාගෙන ඇත. යැවීම පිළිබඳ strongSwan ලේඛනය Linux සමානයෙකු මත සෙලෙක්ටර්, මාර්ග සහ යැවීම අන්තර්ක්‍රියා කරන ආකාරය පැහැදිලි කරයි.