Android-இன் ஒற்றை VPN விதி ஹோஸ்ட் செய்யப்பட்ட SSH சேவையகத்தைத் தடுக்காது

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

ஒற்றை VPN விதி உண்மையில் எதைக் கட்டுப்படுத்துகிறது

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

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

கேட்பான் ஒரு இலக்கு, சுரங்கப்பாதையின் பகுதி அல்ல

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

பிணைப்பு விதிகள் சாதாரண SSH உள்ளமைவு: கேட்கும் முகவரி மற்றும் துறை, யார் அங்கீகாரம் பெறலாம் என்பது. Android-இல் அந்த அமைப்புகள் பயன்பாட்டின் சொந்த உள்ளமைவில் உள்ளன, பயன்பாட்டின் செயல்முறையின் உரிமையாளருக்கு சிறப்புத் துறைகளைப் பயன்படுத்த அனுமதி இல்லாமல் இருக்கலாம், எனவே root ஆக துறை 22 ஐப் பிணைக்கும் பணியகப் பழக்கம் மாற்றமின்றி மாற்றப்படாது.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

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

பதில் பாதைதான் பொதுவாக உடையும் இடம்

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

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

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

VPN-ஐத் தவிர்ப்பது உள்வரும் சேவையைச் சரிசெய்யாது

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

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

முதலில் சேவையின் முகவரியை முடிவு செய்யுங்கள்: தொலைபேசியின் LAN முகவரி, அதன் சுரங்கப்பாதை முகவரி, அல்லது வேண்டுமென்றே அனுப்பப்பட்ட இறுதிப்புள்ளி. ஒவ்வொன்றுக்கும் அதன் சொந்த அணுகல் மற்றும் வெளிப்பாட்டு ஒப்பந்தம் உள்ளது, அவற்றைக் கலப்பதே சிறிய அணுகல் சிக்கலை நிரந்தரத் துளையாக மாற்றும் வழி.

ஒரு நேரத்தில் ஒரு திசையைக் கண்டறியுங்கள்

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

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

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

பிழைத்திருத்தத்தின்போது ஹோஸ்ட் விசைச் சரிபார்ப்பையும் கணக்குக் கட்டுப்பாடுகளையும் அப்படியே வைத்திருங்கள். கேட்பானையும் அனுமதிக்கப்பட்ட பயனர்களையும் கட்டுப்படுத்துவதே அணுகக்கூடிய சேவையகத்தை ஏற்கத்தக்கதாக்குகிறது; இணைப்பு வேலை செய்ய அவற்றைத் தளர்த்துவது ஒரு சிக்கலை மோசமான ஒன்றுடன் மாற்றுகிறது. உங்கள் Android செயலாக்கம் அதே உள்ளமைவுப் பெயர்களைப் பின்பற்றினால் OpenSSH சேவையகக் குறிப்பு கேட்கும் மற்றும் அணுகல் கட்டுப்பாடுகளை உள்ளடக்குகிறது.