හෙයර්පින් NAT: ඇතුළතින් VPN අන්ත ලක්ෂ්‍යය අසාර්ථක වන්නේ ඇයි

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

පැකට්ටුව පිටතට ගොස් නැවත ඇතුළට එයි

පැකට්ටුව අනුගමනය කරන්න. සේවාදායකය පොදු නාමය විසඳයි, පොදු ලිපිනයට සම්බන්ධ වේ, සහ රවුටරයේ ගමනාන්ත NAT ගමනාන්තය අභ්‍යන්තර සේවාදායකයට නැවත ලියයි. සේවාදායකයේ පිළිතුර සේවාදායකයේ LAN ලිපිනයට යොමු කර ඇත, එබැවින් එය මූලාශ්‍රය නැවත පරිවර්තනය කරන NAT නියමය කිසිදා නොපසුකරමින් රවුටරයේ LAN අතුරුමුහුණත හරහා ආපසු යයි.

දැන් සේවාදායකය කිසිදා යමක් නොයැවූ ලිපිනයකින් පැකට්ටුවක් ලබා එය ඉවත දමයි. එම අසමමිතියම සම්පූර්ණ දෝෂයයි.

RFC 4787 මෙම අවස්ථාවේදී NAT වෙතින් අපේක්ෂිත හැසිරීම විස්තර කරයි, සහ කෙටි අනුවාදය නම් සිද්ධාන්තයෙන් නිර්ණය කර ඇති තැනක පවා එය ප්‍රායෝගිකව අත්‍යවශ්‍ය නොවන බවයි. සමහර රවුටර මෙම සැකසුම NAT loopback ලෙස හඳුන්වන අතර, තවත් ඒවා හෙයර්පින් NAT හෝ NAT reflection ලෙස හඳුන්වයි, සමහරක් කිසිවක් නොපෙන්වයි. එය නොමැති රවුටරයක් වැරදි ලෙස වින්‍යාස කර නැත; එය සාමාන්‍ය දෙය කරමින් සිටින අතර නිවැරදි කිරීම වෙනත් තැනකට අයත් වේ. දේශීය පරීක්ෂණයක් අසාර්ථක වූ නිසා පොදු යොමු කිරීමේ නියමය වැරදි යැයි නිගමනය නොකරන්න.

පරීක්ෂාව 1: මාර්ග දෙක වෙන වෙනම පරීක්ෂා කරන්න

LAN පිටතින් සැබෑ පරිශීලකයෙකු භාවිතා කරන එම පැතිකඩ සමඟ සම්බන්ධ වී සැසිය ස්ථාපිත වන බව තහවුරු කරන්න. ඇතුළතින් එම පැතිකඩ සමඟ පොදු ලිපිනයට සම්බන්ධ වී නිශ්චිත දෝෂය සහ වේලාව සටහන් කරන්න.

නිශ්චිත දේශීය පරීක්ෂණයක් සත්කාරක නාමය තබා ගෙන ලිපිනය පමණක් ප්‍රතිස්ථාපනය කරයි: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ නිවැරදි සේවාදායක නාමය ඉදිරිපත් කරමින් ඉල්ලීම පොදු ලිපිනයට යවයි. මෙය නාම විභේදන ගැටලුව පරිවර්තන ගැටලුවෙන් වෙන් කරයි, එම නාමයම කැෆේ එකකින් වැඩ කරන විට ඒවා පහසුවෙන් ව්‍යාකූල වේ. සේවාදායකය TCP සම්බන්ධතාවයේදී අසාර්ථක වේද නැතහොත් පසුව TLS හිදී දැයි සටහන් කරන්න, මන්ද පළමුවැන්න පරිවර්තනයට සහ දෙවැන්න අනන්‍යතාවයට යොමු කරයි.

පරීක්ෂාව 2: සේවාදායකය දකින දේ කියවන්න

වඩාත් ප්‍රයෝජනවත් නිරීක්ෂණය සේවාදායකයේ දෘෂ්ටිකෝණයයි. VPN සත්කාරකයේ සේවාදායකයේ LAN ලිපිනයට සහ රවුටරයේ LAN ලිපිනයට පෙරහන් කළ ග්‍රහණයක් ධාවනය කර, පසුව දේශීය උත්සාහය නැවත කරන්න. කිසිවක් නොපැමිණියේ නම්, පැකට්ටුව පරිවර්තනයෙන් බේරුණේ නැත.

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

පරීක්ෂාව 3: පිටත මාර්ගය නොස්පර්ශ කර නිවැරදි කරන්න

සහාය දක්වන ආකාර තුනක් ඇත, බලපෑමේ අරය වැඩිවන අනුපිළිවෙලින්. වඩාත් පටු වන්නේ බෙදුණු DNS ය: අභ්‍යන්තර වාර්තාවක් ප්‍රකාශයට පත් කරන්න, එවිට එම සේවාදායක නාමය LAN හි සේවාදායකයන්ට අභ්‍යන්තර ලිපිනයට විසඳෙන අතර එය පොදු මාර්ගය සම්පූර්ණයෙන් මග හරියි. ඊළඟට රවුටරයේ ලේඛනගත loopback හෝ reflection විකල්පය තිබේ නම් සක්‍රීය කර එය මෙම සේවාවට පමණක් යෙදීමයි. වඩාත් පුළුල් වන්නේ රවුටරයේ source-NAT නියමය වන අතර එය LAN සිට එන ගමනාගමනය සේවාදායකයට නැවත ලියා පිළිතුර රවුටරය හරහා ආපසු එන ලෙස සලසයි; Linux රවුටරයක එය සේවාදායකයේ ලිපිනයට සහ තොටුපළට ගැළපෙන MASQUERADE නියමය POSTROUTING වේ. තුනම පිටත මාර්ගය ස්පර්ශ නොකර තබන අතර ආරක්ෂා කළ යුතු ගුණාංගය එයයි.

දේශීය මාර්ගය පිටත මාර්ගයට සමාන කිරීම සඳහා අදාළ නොවන තොටුපළ යොමු කිරීම පුළුල් නොකරන්න, සහ ගැටලුව මඟ හැරීමට සේවාව වෙනත් තොටුපළකට ගෙන නොයන්න. දෙකම පිටත ලෝකයට ළඟා විය හැකි දේ වෙනස් කරන්නේ ඇතුළත ලෝකයට පමණක් පෙනෙන දෙයක් නිවැරදි කිරීමටයි.

බෙදුණු DNS හි සඳහන් කිරීමට වටිනා උගුලක් ඇත. සත්කාරක නාමයක් අත්තනෝමතික IP එකකින් ප්‍රතිස්ථාපනය කිරීම සේවාදායකය තහවුරු කරන දේ වෙනස් කරයි, එබැවින් අභ්‍යන්තර වාර්තාව තවමත් සහතිකයේ නාමයට ගැළපිය යුතුය.

පරීක්ෂාව 4: පසුව මාර්ග දෙකම තහවුරු කරන්න

LAN පිටතින් පිටත උත්සාහය නැවත කරන්න, එම පැතිකඩ සමඟ ඇතුළත උත්සාහය නැවත කරන්න, සහ සේවාදායක ලොගය එක් සාර්ථකත්වයක් සහ එක් නිහඬතාවක් නොව වෙන වෙනම සාර්ථක සැසි දෙකක් පෙන්වන බව තහවුරු කරන්න. පසුව අනෙකුත් සේවාදායකයන් තවමත් ශ්‍රාවකයාට ළඟා වන බව සහ පෞද්ගලික සම්පත් සඳහා මාර්ග වෙනස් නොවී ඇති බව පරීක්ෂා කරන්න.

වාර්තාව කෙටිව තබන්න: කුමන සේවාදායකය කුමන ලිපිනය භාවිතා කළේද, සේවාදායකය දුටු දේ, සහ නිවැරදි කිරීම් තුනෙන් කුමක් යොදන ලද්දේද යන්න. RFC 4787 හි හෙයර්පිනිං අවශ්‍යතා මෙහි NAT වෙතින් අපේක්ෂා කරන දේ සඳහා යොමුව වන අතර, මෙම විශේෂාංගය නොමැති රවුටරයක් සාමාන්‍ය ලෙස හැසිරෙන්නේ ඇයිද යන්න පැහැදිලි කරයි. පිටත ලෝකයට ප්‍රතිනිෂ්පාදනය කළ නොහැකි දේශීය අසාර්ථකත්වයක් ප්‍රතිවිරුද්ධය ඔප්පු වන තෙක් පරිවර්තන ප්‍රශ්නයකි, එබැවින් එය එලෙසම පරීක්ෂා කරන්න.