iPhone இல் WireGuard DNS: டொமைன் ஒரு தேடல் பின்னொட்டு மட்டுமே

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

DNS வரி எதில் பிரிக்கப்படுகிறது

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

DNS = 10.24.8.53, lab.internal.example

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

Apple இன் இரண்டு புலங்கள், இரண்டு வெவ்வேறு வேலைகள்

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

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

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

ஒவ்வொரு பெயரும் ஏன் இன்னும் சுரங்கப் பகுப்பியை அடைகிறது

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

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

பிரிக்கப்பட்ட DNS உண்மையில் என்ன தேவைப்படும்

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

நிர்வகிக்கப்பட்ட Apple சாதனங்களில் இது பொதுவாக டொமைன் சார்ந்த DNS அமைப்புகளைச் சுமக்கும் அமைப்புச் சுயவிவரம் மூலம் வழங்கப்படுகிறது. இது WireGuard அமைப்புக் கோப்பிலிருந்து வேறுபட்ட பொறிமுறை, வாடிக்கையாளர் சுயவிவரத்தை மதித்தால் மட்டுமே இரண்டும் சேர்ந்து இருக்க முடியும். இரண்டு தயாரிப்புகளும் ஒரே மாதிரி நடந்துகொள்கின்றன என்று கருதுவதற்கு முன், உங்கள் வாடிக்கையாளர் அந்தப் புலத்தை உண்மையில் என்ன அழைக்கிறது என்று பாருங்கள். Mac இல் wg-quick ஸ்கிரிப்டும் iPhone இல் WireGuard பயன்பாடும் ஒத்த வரிகளைப் படித்து அவற்றை வெவ்வேறு அடுக்குகள் வழியாக நிறுவுகின்றன.

நிறுவப்பட்ட அமைப்புகளைப் படியுங்கள், கட்டமைப்பை அல்ல

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

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

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