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 சரியான வடிவம். எதுவும் அதன் தொலை முடிவுப் புள்ளியிலிருந்து அடையக்கூடிய அனைத்தையும் வழங்கவில்லை.