Android ஹாட்ஸ்பாட் போர்ட் ஃபார்வர்டிங்: மூன்று நுழைவு புள்ளிகள்

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

சேவை உண்மையில் இயங்கும் இடத்திலிருந்து தொடங்குங்கள்

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

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

பிழைத்திருத்தம் செய்யக்கூடிய பில்டில் adb shell /proc/net/tcp வழியாக சாக்கெட்டுகளைப் பட்டியலிடலாம், ஆனால் பெரும்பாலானவர்களுக்குப் பயன்பாட்டின் சொந்த நிலையே நேர்மையான மூலம். நீங்கள் எதிர்பார்க்காத முகவரியில் பயன்பாடு திறந்த சாக்கெட்டைச் சோதிக்கும் பொறியிலிருந்தும் இது தவிர்க்கிறது.

முதல் நுழைவு புள்ளி: ஹாட்ஸ்பாட்டில் உள்ள மற்ற சாதனம்

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

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

சேவை தொலைபேசியுடன் இணைக்கப்பட்ட மடிக்கணினியில் இயங்கினால், தொலைபேசியின் ஹாட்ஸ்பாட் முகவரி இலக்கே அல்ல. ஹாட்ஸ்பாட் இடைமுகத்தில் மடிக்கணினியின் முகவரியும், மடிக்கணினியில் கேட்பவரும் தேவை, தொலைபேசி இனி ஃபார்வர்டிங்கைத் தவிர எதற்கும் உரிமையாளர் அல்ல.

இரண்டாவது நுழைவு புள்ளி: கேரியர் பாதை

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

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

மூன்றாவது நுழைவு புள்ளி: VPN வெளியேற்றம்

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

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

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

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

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

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

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