VPN இயக்கத்தில் இருக்கும்போது இரண்டாவது தனிப்பட்ட பாதையில் SSH

ஒரு இயந்திரம் VPN வழியாக மற்றொன்றை அடைகிறது, இப்போது ஒருவர் அதே ஷெல்லை வழங்குநரின் தனிப்பட்ட வலையமைப்பில் விரும்புகிறார். பாதை உள்ளது, பிங் வெற்றிபெறுகிறது, இருந்தும் SSH மறுக்கிறது. வழக்கமான காரணம், டீமன் புதிய முகவரியில் ஒருபோதும் கேட்கவில்லை, எனவே இணைக்க எதுவும் இல்லை. இது firewall சிக்கலாகும் முன் முகவரி-பிணைப்பு சிக்கல்.

புதிய பாதை புதிய கேட்பானை ஏன் உருவாக்குவதில்லை

கேட்கும் சாக்கெட்டை ஏற்றுக்கொள்ளும் முகவரிகளைப் பெயரிடும் செயல்முறை உருவாக்குகிறது. பாதை பாக்கெட்டுகள் எங்கு செல்ல வேண்டும் என்பதை மட்டும் சொல்கிறது; அது இலக்கில் கேட்பானை உருவாக்குவதில்லை. sshd ஒரு ListenAddress உடன் அமைக்கப்பட்டிருந்தால், இடைமுகம் இயக்கத்தில் இருந்தாலும் வேறு எந்த உள்ளூர் முகவரிக்கும் இணைப்புகள் நிராகரிக்கப்படும். போர்ட்டை வைத்திருக்கும் சாக்கெட் அலகுக்கும் இது பொருந்தும், அதனால் முதல் சரிபார்ப்பு எப்போதும் உண்மையில் எது கேட்கிறது என்பதே.

இரண்டு பாதைகளையும் இடைமுகப் பெயரால் அல்ல, இலக்கு முகவரியால் ஒப்பிடுங்கள். வாடிக்கையாளர் ஒரு முகவரியுடன் இணைகிறார், எந்த firewall விதியும் முக்கியமாகும் முன் அந்த முகவரி பிணைக்கப்பட்டிருக்க வேண்டும்.

முகவரிகள் மற்றும் கேட்பான்களைப் பட்டியலிடுங்கள்

எதையும் திருத்தும் முன், ஹோஸ்ட்டில் உள்ள முகவரிகள் மற்றும் இப்போது உள்ள சாக்கெட்டுகளைப் பதிவு செய்யுங்கள்.

ip -br addr
ss -ltnp | grep ':22'

முகவரிப் பட்டியல் எந்த தனிப்பட்ட முகவரி உண்மையானது மற்றும் எந்த இடைமுகத்தில் உள்ளது என்பதைக் காட்டுகிறது, சாக்கெட் பட்டியல் அதற்கு ஏதேனும் பிணைக்கப்பட்டுள்ளதா என்பதைக் காட்டுகிறது. 0.0.0.0:22 இல் கேட்கும் கேட்பான் ஏற்கனவே ஒவ்வொரு முகவரியையும் ஏற்றுக்கொள்கிறது, எனவே புதிய பிணைப்பு எதையும் சேர்ப்பதில்லை. ஒரு குறிப்பிட்ட முகவரியில் கேட்கும் கேட்பான் மறுப்பை உடனடியாக விளக்குகிறது. போர்ட் டீமனுக்கு அல்ல, சாக்கெட் அலகுக்கு சொந்தமானது என்றால், டீமன் உள்ளமைவு முழுக் கதை அல்ல.

பிணைப்பைச் சேர்த்து பழையதை வைத்திருங்கள்

OpenSSH பல ListenAddress உள்ளீடுகளை ஏற்றுக்கொள்கிறது, எனவே தனிப்பட்ட பாதை சேர்க்கப்படும்போது VPN பாதை தொடரலாம். கோப்பை மீண்டும் ஏற்றும் முன் சோதிக்கவும்.

sshd -t
systemctl reload sshd

தோல்வியடைந்த உள்ளமைவு சோதனை இயங்கும் டீமனைத் தொடாமல் விடுகிறது, நீங்கள் திருத்தும் பாதை வழியாக இணைந்திருக்கும்போது அதுவே உங்களுக்குத் தேவை. இருக்கும் உள்ளீட்டை வைத்து, புதிய உள்ளூர் முகவரியைச் சேர்த்து, தற்போதைய அமர்வைத் துண்டிக்காமல் சேவை மீண்டும் ஏற்றப்படுவதை உறுதிசெய்யுங்கள். சாக்கெட்-செயல்படுத்தப்பட்ட நிறுவல்களில் முகவரியை சாக்கெட் அலகில் சேர்த்து அந்த அலகை மீண்டும் ஏற்றுங்கள். பின்னர் கேட்பான் பட்டியலை மீண்டும் படியுங்கள், ஏனெனில் ஒருபோதும் தோன்றாத பிணைப்பு என்பது தவறான கூறு திருத்தப்பட்டது என்பதாகும்.

பழைய அமர்வை மூடும் முன் புதிய அமர்வைச் சரிபார்க்கவும்

அசல் அமர்வு இன்னும் திறந்திருக்கும்போது புதிய முகவரியுடன் இணைந்து, எந்த முகவரி மற்றும் சாவி பயன்படுத்தப்பட்டது என்பதைப் பார்க்க விரிவான வெளியீட்டைப் பயன்படுத்துங்கள். சோதனை இரண்டு முறை வெற்றிபெறும் வரை அசல் அமர்வைத் திறந்து வைத்திருங்கள்.

ssh -v [email protected]

இலக்கு முகவரி மற்றும் வழங்கப்பட்ட ஹோஸ்ட் சாவிக்கான பிழைத்திருத்த வரிகளைப் படியுங்கள். வலையமைப்பு தனிப்பட்டது என்று விவரிக்கப்பட்டதால் அறியாத சாவியை ஏற்பதற்குப் பதிலாக, நீங்கள் ஏற்கனவே நம்பும் மதிப்புடன் ஹோஸ்ட் சாவியின் கைரேகையை உறுதிசெய்யுங்கள். புதிய இலக்குக்கு அதன் சொந்த known_hosts உள்ளீடு தேவை, அது எதிர்பார்க்கப்படுகிறது. தனிப்பட்ட பாதை வேலை செய்த பிறகே பழைய நிர்வாக அமர்வை மூட வேண்டும்.

SSH போக்குவரத்தைப் பாதுகாக்கிறது, ஆனால் தனியாக அது இரண்டு வலையமைப்புகளைச் சமமாக்காது. தனிப்பட்ட கடப்பின் நம்பிக்கை தரவுடன் பொருந்துகிறதா என்பதை அதை நம்புவதற்கு முன் முடிவு செய்யுங்கள்.