SSH ඉදිරියට යැවීම සැබවින්ම ගෙන යන්නේ කුමන යෙදුම් ගමනාගමනයද?

ටර්මිනලය සම්බන්ධ වේ, විධාන දර්ශකය දිස්වේ, සහ SSH ප්‍රවේශය ක්‍රියා කරන බව සියල්ලෝ එකඟ වෙති. පසුව ලැප්ටොප් එකේ ඇති දත්ත සමුදාය සේවාලාභියාට තවමත් පෞද්ගලික සත්කාරකයට ළඟා විය නොහැක, සහ සැසියට දොස් පවරනු ලැබේ. ගොඩනගා ඇත්තේ ෂෙල් එකක් වන අතර එය SSH ලබා දිය හැකි සම්පූර්ණයෙන්ම වෙනස් අතුරුමුහුණත් හතරෙන් එකකි. පළමුව අතුරුමුහුණත නම් කරන්න, පසුව යෙදුම එය සැබවින්ම භාවිත කරන්නේදැයි පරීක්ෂා කරන්න. අනුපිළිවෙල වැදගත් වේ, මන්ද සෑම අතුරුමුහුණතක්ම තමන්ගේම ආකාරයෙන් අසාර්ථක වේ.

කිසිවක් සසඳීමට පෙර අතුරුමුහුණත නම් කරන්න

OpenSSH සේවාලාභී අත්පොත පහසුවෙන් ව්‍යාකූල කළ හැකි යාන්ත්‍රණ හතරක් වෙන් කරයි. ෂෙල් එකක් හෝ දුරස්ථ විධානයක් SSH සත්කාරකයේ ක්‍රියාත්මක වේ. දේශීය ඉදිරියට යැවීම සේවාලාභියා මත සවන් දෙන සොකට් එකක් විවෘත කර ඊළඟ සම්බන්ධතාවය දුරස්ථ පැත්තෙන් සිදු කරයි. දුරස්ථ ඉදිරියට යැවීම ප්‍රතිවිරුද්ධ ලෙස ක්‍රියා කර සේවාදායක පැත්තේ සවන් දෙයි. ගතික ඉදිරියට යැවීම එය භාවිත කරන ආකාරය දන්නා වැඩසටහන් සඳහා SOCKS අන්තිම ලක්ෂ්‍යයක් ලබා දෙයි.

• ෂෙල්: වැඩසටහන දුරස්ථ යන්ත්‍රයේ ක්‍රියා කරයි, දේශීයව කිසිවක් සවන් නොදෙයි.
• දේශීය ඉදිරියට යැවීම: ඔබේ ලැප්ටොප් එකට වරායක් ඇත, දුරස්ථ සත්කාරකය පිටතට යන සම්බන්ධතාවය සිදු කරයි.
• දුරස්ථ ඉදිරියට යැවීම: දුරස්ථ පැත්තට වරායක් ඇත, ගමනාගමනය ඔබ දෙසට ආපසු එයි.
• ගතික: සේවාලාභියා මත SOCKS ප්‍රතිනිධියක්, ප්‍රතිනිධිය තේරුම් ගන්නා යෙදුම් පමණක් භාවිත කරයි.

මේවායින් කිසිවක් මාර්ගයක් ස්ථාපනය නොකරයි. ප්‍රතිනිධි සැකසුම් නොසලකා හරින, හෝ UDP කතා කරන, හෝ නම් තමන්ම විසඳන වැඩසටහනක්, සක්‍රීය SSH සැසියකින් බලපෑමට ලක් නොවේ. මෙය SSH හි දෝෂයක් නොවේ; මෙය ඔබ තෝරාගත් අතුරුමුහුණතේ විෂය පථයයි.

දේශීය, දුරස්ථ සහ ගතික ඉදිරියට යැවීම් සවන් දෙන්නේ කවුරුන්ද යන්නෙන් වෙනස් වේ

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

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

පළමු විධානය ලැප්ටොප් එකේ 5432 වරාය බැඳ බැස්ටියන් එකෙන් දිස්වන ආකාරයට දත්ත සමුදායට ඉදිරියට යවයි. දෙවැන්න 1080 වරායේ SOCKS ප්‍රතිනිධියක් සාදයි. තෙවැනි විධානය සැබවින්ම සවන් දෙන ක්‍රියාවලීන් තහවුරු කරයි, සහ වරාය ගැටුමක් නිසා නිහඬව අසාර්ථක වීම වෙනුවට ඉදිරියට යැවීම පවතින බවට එය එකම සාක්ෂියයි.

ගතික ඉදිරියට යැවීමට තමන්ගේම අනතුරු ඇඟවීමක් ලැබිය යුතුය: එය SOCKS ගරු කරන යෙදුම් පමණක් ආවරණය කරයි. බ්‍රවුසරයක් එය වෙත යොමු කළ හැක, විධාන රේඛා මෙවලමකට එය භාවිත කරන ලෙස පැවසිය හැක, නමුත් තමන්ගේම සම්බන්ධතා තට්ටුවක් ඇති දත්ත සමුදාය ධාවකයකට සාමාන්‍යයෙන් නොහැක. යන්ත්‍රයේ සෑම වැඩසටහනක්ම දැන් ටනලය භාවිත කරන බව උපකල්පනය කිරීම මෙම මුළු ක්ෂේත්‍රයේම වඩාත් පොදු වැරැද්දයි.

ටනල්-උපාංග මාදිලිය එකම සැබෑ ජාල ව්‍යතිරේකයයි

OpenSSH -w ටනල්-උපාංග ඉදිරියට යැවීමද අනුග්‍රහය දක්වයි, එය TCP සවන් දෙන්නෙකු වෙනුවට ලක්ෂ්‍යයේ සිට ලක්ෂ්‍යයට අතුරුමුහුණතක් යවයි. එය සැබෑ ජාල ටනලයක් වන අතර එය හිතාමතා වින්‍යාස කරනු ලැබේ, ෂෙල් එකක් විවෘත කිරීමේ අතුරු ඵලයක් නොවේ.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

එයට දෙකෙළවරේම ඇති අනුරූප අතුරුමුහුණත අංක, සේවාදායකයේ නිවැරදි වින්‍යාසය සහ උපාංගය සෑදීමට සේවාලාභියාට ප්‍රමාණවත් වරප්‍රසාද අවශ්‍ය වේ. එයට ලිපින සහ මාර්ගගත කිරීමේ සැලැස්මක්ද අවශ්‍ය වේ, මන්ද නිරුවත් අතුරුමුහුණතක් කුමන ගමනාන්ත එය භාවිත කළ යුතුද යන්න පිළිබඳ ප්‍රතිපත්තියක් රැගෙන නොයයි.

එසේ වුවත් ටනලය දුරස්ථ සත්කාරකයේ අවසන් වේ. SSH ප්‍රවාහනය ලබා දුන් කුමන ආරක්ෂාවක් වුවත් එය එහිදී අවසන් වේ, සහ ඊළඟ සම්බන්ධතාවය වෙනම පිම්මකි. VPN ද්වාරයටද එම හැඩයේ මායිමක් ඇත, එබැවින් සසඳීම කුමන මෙවලම ශක්තිමත්ද යන්න ගැන නොව විෂය පථය සහ අවසානය ගැන විය යුතුය. එම මායිම හයියෙන් නම් කිරීම ටනලයක් «සියල්ල සංකේතනය කරයිද» යන වාදයද අවසන් කරයි, මන්ද එය පැහැදිලිවම එසේ නොකරයි.

ඔබේ යෙදුම ඔබ ගොඩනගා ඇති අතුරුමුහුණත භාවිත කරන්නේදැයි පරීක්ෂා කරන්න

සත්‍යාපනය සැසිය සඳහා නොව සෑම යෙදුමක් සඳහාම වේ. ක්‍රියා කරන ඉදිරියට යැවීමක් වරාය බැඳී ඇති බවත් දුර පැත්තට අමතන්නට හැකි බවත් සාධනය කරයි; ඔබට වැදගත් වැඩසටහන එය හරහා සම්බන්ධ වූ බව සාධනය නොකරයි.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

පළමු විධානය සත්කාරක නාමය දුරස්ථව විසඳමින් SOCKS අන්තිම ලක්ෂ්‍යය හරහා ඉල්ලීමක් යවයි, දෙවැන්න TLS තවමත් අවශ්‍ය වන අතර ඉදිරියට යවන ලද දත්ත සමුදාය වරාය අභ්‍යාස කරයි. ඉදිරියට යැවීම නතර කර ඇති තත්වයේදී එම පරීක්ෂණම ධාවනය කර ඒවා අසාර්ථක වන බව තහවුරු කරන්න, මන්ද දෙපැත්තෙන්ම සමත් වන පරීක්ෂණයක් කිසිදාක ටනලය භාවිත කර නැත.

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