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

இரண்டு கேள்விகளுக்கு உரிமையாளர் இரண்டு துணை அமைப்புகள்

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

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

ஒவ்வொரு செயலிக்குமான விலக்கு உண்மையில் என்ன மாற்றுகிறது

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

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

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

தொலைபேசிக்கு டெதர் செய்யப்பட்ட பாக்கெட் எப்படித் தெரிகிறது

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

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

ஹாட்ஸ்பாட் விதிவிலக்குக்கு உண்மையில் என்ன கொள்கை தேவை

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

SourceDestinationIntended path
One authorized hotspot clientOne approved public service addressOrdinary cellular uplink
The same clientAll other covered destinationsShared VPN
The phone's own appsTheir existing destinationsUnchanged phone policy

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

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

பிடிபட்ட ஒரு முகவரி இலக்கு அல்ல

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

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

கீழ்ப் பக்கத்திலிருந்து சரிபார்க்கவும்

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

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

தொடர்புடைய கட்டுரைகள்