Android always-on VPN: எண்ட்பாயிண்ட் பெயர் முதலில் எவ்வாறு தீர்க்கப்படுகிறது
டனல் இருப்பதற்கு முன்பே Android போக்குவரத்தைத் தடுக்கிறது, இருந்தாலும் கிளையண்ட் தன் எண்ட்பாயிண்ட்டைத் தீர்க்க வேண்டும். இதோ வரிசையும் சிக்கும் இடமும்.
தொலைபேசி மீண்டும் துவங்குகிறது, always-on செயலில் உள்ளது, «VPN இல்லாமல் இணைப்புகளைத் தடு» இயக்கத்தில் உள்ளது, ஆனால் டனல் ஒருபோதும் வராது. எதுவும் தவறாக அமைக்கப்படவில்லை: தடை அதன் வேலையைச் செய்கிறது, கிளையண்ட் தானே தன் எண்ட்பாயிண்ட்டை அடைய முயல்வதும் அதற்கு உட்பட்டதே. எண்ட்பாயிண்ட் பெயர் டனல் இருப்பதற்கு முன்பே தீர்க்கப்பட வேண்டும், மற்ற எல்லா பயன்பாடுகளுக்கும் அனுமதி இல்லாதபோது வலையத்துடன் பேச அனுமதிக்கப்பட்ட கிளையண்டால். எந்தக் கூறு இதைச் செய்கிறது, எந்த வரிசையில் என்பதைப் புரிந்துகொள்வதே இந்த மர்மத்தை அமைப்புக் கேள்வியாக மாற்றுகிறது.
VPN பில்டர் உண்மையில் கேட்பது என்ன
Android VPN பயன்பாடு தளத்திற்கு சேவையக முகவரியை வழங்குவதில்லை. அது ஒரு உள்ளூர் இடைமுகத்தை உருவாக்குகிறது: டனலுக்கான முகவரிகள் மற்றும் பாதைகள், அதன் உள்ளே பயன்பாடுகள் பயன்படுத்த வேண்டிய தீர்விகைகள், பின்னர் establish() ஒரு கோப்பு விவரிப்பியைத் திருப்பித் தருகிறது, அதை பயன்பாடு மூல IP பொதிகளாகப் படித்து எழுதுகிறது. தொலை எண்ட்பாயிண்ட் அந்த பில்டரில் சற்றும் தெரிவதில்லை.
இதுவே முக்கிய கட்டமைப்பு உண்மை. தளம் tun இடைமுகத்தை உருவாக்கி அதில் கொள்கையைச் செயல்படுத்துகிறது; பயன்பாடு பயனர் இடத்தில் போக்குவரத்தைச் செயல்படுத்துகிறது, அதாவது எண்ட்பாயிண்ட் பெயரைத் தீர்ப்பதும் மறையாக்கப்பட்ட இணைப்பைத் திறப்பதும் பயன்பாடே செய்கிறது. எனவே ஹோஸ்ட் பெயர் வடிவில் எண்ட்பாயிண்ட் சாத்தியம் — தளம் பெயர்களை ஆதரிப்பதால் அல்ல, தளம் எண்ட்பாயிண்ட்டை ஒருபோதும் பார்ப்பதில்லை என்பதால்.
பில்டரின் ஒரு புலம் மட்டும் முகவரிகளைப் பெறுகிறது: DNS சேவையகங்கள். அவை எண்ணியல் தீர்விகை முகவரிகளாக இருக்க வேண்டும், பொதுவாக இயக்குநர் டனல் வழியாகக் கேட்க விரும்புவன. அந்தப் புலம் டனல் எழுந்த பிறகு பயன்பாடுகள் வினவல்களை எங்கே அனுப்புகின்றன என்பதை விவரிக்கிறது. கிளையண்ட் எண்ட்பாயிண்ட்டை எவ்வாறு கண்டுபிடிக்கிறது என்பதைப் பற்றி எதுவும் கூறவில்லை, இவை இரண்டையும் ஒரே அமைப்பாகக் கருதுவதிலிருந்தே குழப்பம் தொடங்குகிறது.
ஒன்றல்ல, இரண்டு DNS கேள்விகள்
முதல் கேள்வி: டனல் எழுந்த பிறகு பயன்பாடுகள் வினவல்களை எங்கே அனுப்புகின்றன? பதில் டனலுக்குள் உள்ள தீர்விகை முகவரி, tun இடைமுகம் வழியாக அடையக்கூடியது, மற்றும் அமைப்பின்படி எண்ணியல்.
இரண்டாம் கேள்வி: அந்த டனல் இருப்பதற்கு முன்பு கிளையண்ட் தன் சொந்த எண்ட்பாயிண்ட்டை எவ்வாறு கண்டுபிடிக்கிறது? அந்தத் தேடல் டனலுக்கு வெளியே, அடிப்படை வலையத்தில், கிளையண்டின் செயல்முறையில் நடக்கிறது. அது பெயரைப் பயன்படுத்தலாம், VPN இல்லாமல் சாதனம் அடையக்கூடிய தீர்விகையைப் பயன்படுத்த வேண்டும்.
| Stage | Who resolves | Path | Failure looks like |
|---|---|---|---|
| Endpoint lookup | The VPN app | Underlying network, protected socket | Never connects; no tunnel interface traffic |
| Peer authentication | Client and server | Tunnel transport | Connects then drops; certificate or key error |
| Private name lookup | Apps via the tunnel | Resolver inside the tun | Tunnel up, internal sites do not resolve |
மூன்று நிலைகள், மூன்று வேறுபட்ட அறிகுறிகள். «இணைக்க முடியவில்லை» எனும் ஒரே பிழைச் செய்தி அவற்றை ஒன்றாக்கிவிடுகிறது, அதனால்தான் அந்தப் புலம் படிக்கப்படுவதற்கு முன்பே நடக்கும் சிக்கலைச் சரிசெய்ய மக்கள் DNS சேவையகப் புலத்தைத் திருத்தத் தொடங்குகிறார்கள்.
bootstrap ஏன் சிக்கலாம்
always-on இல் தடை இயக்கத்தில் இருந்தால் VPN உள்ளே இல்லாத போக்குவரத்து நிராகரிக்கப்படும், VPN வைத்திருக்கும் பயன்பாட்டின் போக்குவரத்தும் அடங்கும். வெளியேறும் வழி தெளிவானது: பயன்பாடு ஒரு சாக்கெட்டில் protect() அழைக்கிறது, அது அதை அடிப்படை வலையத்துடன் பிணைக்கிறது, எனவே அது டனலைத் தவிர்த்து வெளியேற அனுமதிக்கப்படுகிறது. ஒவ்வொரு VPN கிளையண்டும் தன் சொந்த போக்குவரத்திற்கு இதைச் செய்ய வேண்டும், இல்லையேல் ஒருபோதும் சேவையகத்தை அடையாது.
இப்போது எண்ட்பாயிண்ட் பெயரை அறிந்த ஒரே தீர்விகையே டனலுக்குள் இருக்கும் ஒரு பயன்பாட்டைக் கவனியுங்கள். பெயரைத் தீர்க்க கிளையண்டிற்கு டனல் தேவை, டனலைக் கட்ட பெயர் தேவை. இது உண்மையான வட்டச் சார்பு, எந்தக் கிளையண்ட் அமைப்பும் இதைத் தீர்க்காது. இது வடிவமைப்புப் பிழை, பிழை அல்ல.
நேரம் அதே சார்பை மென்மையான வடிவங்களில் வெளிப்படுத்துகிறது. துவக்கத்தில், முதல் திறப்புக்கு முன்பு, சாதனத்திற்கு இன்னும் பயன்படுத்தக்கூடிய வலையம் இல்லாமல் இருக்கலாம்; captive portal இல் வலையம் உள்ளது ஆனால் போர்ட்டலைத் தவிர அனைத்தையும் தடுக்கிறது; Wi-Fi இலிருந்து மொபைலுக்கு மாறும்போது பாதுகாக்கப்பட்ட சாக்கெட்டின் அடிப்படை வலையம் மாறுகிறது, கிளையண்ட் அதைக் கவனித்து மீண்டும் தீர்க்க வேண்டும். இவை ஒவ்வொன்றும் bootstrap நிகழ்வு, ஒவ்வொன்றும் இரவு 3 மணிக்குக் கண்டுபிடிப்பதை விட வேண்டுமென்றே சோதிக்கத் தகுந்தது.
பதிலை நிலைநிறுத்துவது ஏன் தீர்வல்ல
கவர்ச்சிகரமான சுருக்குவழி என்பது பெயரை ஒருமுறை தீர்த்து வரும் முகவரியை எண்ணியல் புலத்தில் ஒட்டுவது, அல்லது தனிப்பயன் கட்டுமானத்தில் கடினமாகக் குறியிடுவது. அது வேலை செய்வது போல் தெரிகிறது, பெயரை ஒரு புகைப்படமாக மாற்றுகிறது. இயக்குநர் எண்ட்பாயிண்ட்டை நகர்த்தும்போது — இடமாற்றம், anycast மாற்றம், புதிய பிராந்திய முகவரி — கிளையண்ட் பழையதையே அழைத்துக்கொண்டிருக்கும், UI இல் எதுவும் காரணத்தை விளக்காது.
DNS பதிவுகளுக்கு ஆயுட்காலம் இருப்பது பதில்கள் மாறக்கூடும் என்பதற்காகவே; தற்காலிகச் சேமிப்பு அந்த ஆயுட்காலத்தை அடிப்படையாகக் கொண்டது, நிரந்தரமாக அல்ல. பதிலை நிலைநிறுத்துவது பெயரை முகவரியை விடச் சிறந்ததாக்கும் பொறிமுறையைத் தூக்கி எறிகிறது, அதே நேரத்தில் பெயரைப் பயன்படுத்திய செயல்பாட்டுச் செலவைத் தக்கவைக்கிறது.
நிலைநிறுத்தல் பொதுவாக இரண்டாவது மோசமான பழக்கத்துடன் சேர்ந்து வருகிறது: இணைப்பு இப்போது வேறு விதமாகத் தோல்வியடைவதால் அடையாளச் சரிபார்ப்பைத் தளர்த்துவது. சேவையக அடையாளச் சரிபார்ப்பு bootstrap சிக்கலின் பகுதி அல்ல, அதைப் பலவீனப்படுத்துவது DNS அசௌகரியத்தை இடையூறு ஆபத்துடன் மாற்றுகிறது.
மீள்துவக்கத்தைத் தாங்கும் வடிவமைப்புகள்
நீடித்த அமைப்பு கவர்ச்சியற்றது. பாதுகாக்கப்பட்ட சாக்கெட்டுகளைச் சரியாகச் செயல்படுத்தி தன் எண்ட்பாயிண்ட்டை அடிப்படை வலையத்தில் தீர்க்கும் கிளையண்டைப் பயன்படுத்துங்கள், அதற்குப் பொதுவில் அல்லது டனலுக்கு முன் அடையக்கூடிய தீர்விகை வழியாகத் தீர்க்கப்படும் எண்ட்பாயிண்ட் பெயரைக் கொடுங்கள். தடையை இயக்கத்தில் வைத்திருங்கள்; DNS வேலை செய்ய முழுவதுமாக அணைப்பது அந்தப் பயன்பாடு இருப்பதற்கான பண்பை நீக்கிவிடும்.
எண்ட்பாயிண்ட் தனிப்பட்டதாக இருக்க வேண்டிய இடத்தில், தளம் பயன்படுத்தக்கூடிய தெளிவான bootstrap பாதையை வழங்குங்கள் — டனல் இல்லாமல் அடையக்கூடிய தீர்விகை, அல்லது இயக்குநர் பராமரிக்கும் நிர்வாக இணைப்பு — அந்த விதிவிலக்கைக் குறுகலாக வைத்து, பயனர் நிலைமாற்றிக்கு அல்ல, கொள்கைக்கு உரியதாக்குங்கள். Android VpnService ஆவணங்கள் பாதுகாப்பு மற்றும் வாழ்க்கைச் சுழற்சி பற்றி தளம் என்ன உத்தரவாதம் அளிக்கிறது என்பதற்கான குறிப்பு, மேலும் VpnService.Builder குறிப்பு DNS புலம் எண்ணியல் முகவரிகளைப் பெறுகிறது என்பதை உறுதிப்படுத்துகிறது.
பின்னர் மீள்துவக்கத்திற்குப் பின் புதிய இணைப்பில் மூன்று நிலைகளையும் வரிசையாகச் சரிபார்க்கவும்: எண்ட்பாயிண்ட் பெயர் தீர்க்கப்படுகிறது, டனல் நிறுவப்பட்டு இணை உறுதிப்படுத்தப்படுகிறது, தனிப்பட்ட பெயர் டனலின் தீர்விகை வழியாகத் தீர்க்கப்படுகிறது. முதல் நிலை தோல்வியுற்றால் பின்னால் எதுவும் வேலை செய்யாது, திருத்தம் bootstrap பாதைக்கு உரியது — ஒருபோதும் தீர்விகை புலத்திற்கு அல்ல.
- எண்ட்பாயிண்ட் தீர்த்தல் பயன்பாட்டிற்குள், டனலுக்கு வெளியே, பாதுகாக்கப்பட்ட சாக்கெட்டில் நடக்கிறது.
- பில்டரின் DNS புலம் டனலுக்குள் உள்ள பயன்பாடுகளுக்கானது, கிளையண்டின் சொந்த எண்ட்பாயிண்ட்டிற்கு அல்ல.
- டனல் வழியாக மட்டுமே அடையக்கூடிய தீர்விகை சிக்கல், மெதுவான துவக்கம் அல்ல.
- மீள்துவக்கத்திற்குப் பின் எண்ட்பாயிண்ட், அங்கீகாரம், தனிப்பட்ட தேடலைத் தனித்தனியாகச் சோதிக்கவும்.