VPN இன் DNS ஒவ்வொரு தேடலையும் எடுக்கிறது: NetworkManager இல் dns-priority சரிசெய்யுங்கள்

அலுவலக VPN உடன் இணையுங்கள், திடீரென்று ஒவ்வொரு பெயர் தேடலும் நிறுவன ரிசால்வருக்குச் செல்கிறது. பொது பெயர்கள் இன்னும் தீர்க்கப்படுகின்றன, எனவே உள்ளூர் அச்சுப்பொறியின் பெயர் தோல்வியடையும் வரை அல்லது split-horizon பதிவு அலுவலக முகவரியைத் திருப்பித் தரும் வரை எதுவும் உடைந்ததாகத் தெரியவில்லை. சில Fedora அமைப்புகளில் எதிர்மாறாக நடக்கிறது: சுரங்கப்பாதை ஏறிய பிறகும் ISP ரிசால்வர் பதிலளிக்கிறது. இரண்டும் ஒரே கேள்வி — இந்த வினவலின் உரிமையாளர் எந்த ரிசால்வர் — மேலும் NetworkManager அமைப்புகளில் பதில் ஒவ்வொரு இணைப்பின் DNS பண்புகளில் வாழ்கிறது.

இரண்டு இணைப்புகள், ஒரு வெற்றி பெறும் ரிசால்வர்

ஒவ்வொரு இணைப்பும் ஒரு DNS முன்னுரிமையை அறிவிக்கிறது. சாதாரண இணைப்புகள் இயல்பாக 50, VPN இணைப்புகள் 0, குறைந்த மதிப்பு வெல்லும். இந்த இயல்புநிலையே VPN இணைப்பு தான் கோரும் ஒவ்வொரு களத்திற்கும் கம்பி இணைப்பை அமைதியாக மிஞ்சுவதற்குக் காரணம்: யாரும் தேர்ந்தெடுக்காமலேயே பூஜ்யம் ஐம்பதை வெல்கிறது.

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

முன்னுரிமை வரிசையைத் தீர்மானிக்கிறது, தேடல் பட்டியல் உரிமையைத் தீர்மானிக்கிறது

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

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

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

பின்னர் முன்னுரிமையைத் தெளிவாக்கி மீண்டும் செயல்படுத்துங்கள்:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

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

பிரிப்பை systemd-resolved வைத்திருக்கட்டும்

இயல்புநிலை dnsmasq செருகுநிரல் வினவல்களை ஒரு உள்ளூர் ரிசால்வருக்குள் கொட்டுகிறது, எனவே இணைப்பு வாரியான பிரிப்பு கரடுமுரடாகவே உள்ளது. systemd-resolved ஒவ்வொரு இணைப்பிற்கும் பிரிப்பை வெளிப்படுத்துகிறது, resolvectl query பதிலளித்த இணைப்பைப் பெயரிடுகிறது.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

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

DNS வடிவமைப்பை சுரங்கப்பாதை வகைக்கு ஏற்றுங்கள்

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

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

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

ஒவ்வொரு இணைப்பிலும் சரிபார்க்கவும், மீண்டும் இணைந்த பிறகு மீண்டும் சரிபார்க்கவும்

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

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