தனியுரிம DNS பெயர்கள் VPN கிளையண்ட்களில் ஏன் தோல்வியடைகின்றன, எங்கே சரிபார்க்க வேண்டும்

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

எந்தவொரு சுயவிவரத்தையும் திருத்தும் முன் கிளையண்ட் பெயரை எப்படிக் கையாள்கிறது என்பதை உறுதிசெய்யுங்கள். Linux இல் resolvectl query files.corp.example எந்த இணைப்பும் எந்தத் தீர்வியும் பதிலை உருவாக்கியது என்பதைக் காட்டுகிறது. Windows இல் Resolve-DnsName files.corp.example பதிலளித்த சேவையகத்தையும் அது திருப்பிய முகவரியையும் காட்டுகிறது.

எதையும் மாற்றும் முன் பதிலைப் படியுங்கள்

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

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

தீர்வியைச் சுரங்கப்பாதையின் உள்ளிருந்து வழங்குங்கள்

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

OpenVPN முதல் குழுவில் உள்ளது. சேவையகத்தில் push "dhcp-option DNS 10.8.0.53" மற்றும் push "dhcp-option DOMAIN corp.example" கட்டுப்பாட்டு சேனல் வழியாகக் கீழே செல்கின்றன, ஆனால் கிளையண்டின் கட்டமைப்பில் pull இன்னும் இயக்கத்தில் இருந்தால் மட்டுமே. கைமுறையாகத் திருத்தப்பட்டு pull-filter ignore "dhcp-option" ஏந்தும் கிளையண்ட் அவற்றை ஒருபோதும் பார்க்காது, அந்த ஒரு வரியே «சேவையகம் அதைத் தள்ளுகிறது ஆனால் என் மடிக்கணினி ஒப்புக்கொள்ளவில்லை» என்பது போன்ற வியக்கத்தக்க பல நிகழ்வுகளை விளக்குகிறது.

WireGuard இரண்டாவது குழுவில் உள்ளது, ஏனெனில் நெறிமுறையில் விருப்பங்கள் பற்றிய பேச்சுவார்த்தையே இல்லை. தீர்வியும் தேடல் களமும் கிளையண்டின் சொந்த [Interface] தொகுதியில் DNS = 10.8.0.53, corp.example வடிவில் செல்கின்றன. wg-quick அதை resolvconf அல்லது systemd-resolved வழியாகப் பயன்படுத்துகிறது, Windows இல் அதிகாரப்பூர்வ கிளையண்ட் சுரங்கப்பாதை நிற்கும் வரை மட்டுமே இருக்கும் NRPT விதிகளை நிறுவுகிறது: Get-DnsClientNrptPolicy அவற்றைப் பட்டியலிடுகிறது, இது கிளையண்ட் உங்கள் கோப்பை எப்போதாவது பயன்படுத்தியதா எனப் பார்க்க விரைவான வழியாகிறது.

IPsec/IKEv2 இடையில் உள்ளது. strongSwan இன் attr செருகுநிரல் குளத்திலிருந்து எடுக்கப்பட்ட DNS சேவையகத்தைத் திருப்பித் தரலாம், Windows கிளையண்ட் அதை வழக்கமாக ஏற்கிறது, ஆனால் தன் சொந்தப் பெயர் சேவையகத்தைப் பதித்துவிடும் சுயவிவரம் நுழைவாயில் வழங்குவதை எல்லாம் மிஞ்சுகிறது. Linux கிளையண்டில் இணையான கைமுறைப் படி resolvectl dns wg0 10.8.0.53 பின்னர் resolvectl domain wg0 '~corp.example'; இரண்டும் இடைமுகத்துடன் மறைந்துவிடும், இது சுரங்கப்பாதைக்கு எல்லைப்படுத்தப்பட்ட அமைப்புக்கு நீங்கள் விரும்புவது சரியாக அதுவே.

ஒவ்வொரு வினவலையும் விழுங்குவதற்குப் பதிலாகப் பின்னொட்டை எல்லைப்படுத்துங்கள்

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

உள்ளே தனியுரிம பின்னொட்டை மட்டும் அனுப்புங்கள். systemd-resolved இல் ~ உடன் தொடங்கும் களம் வழிமாற்றத்திற்கு மட்டுமே, எனவே ~corp.example என்பது அந்தப் பின்னொட்டின் கீழான வினவல்கள் அந்த இணைப்பின் சேவையகங்களுக்குச் செல்கின்றன, மற்ற அனைத்தும் இயற்பியல் வலையமைப்பையே பயன்படுத்துகின்றன என்பதாகும். Windows இதே வேலையைப் பெயரிடத்திற்கு எல்லைப்படுத்தப்பட்ட NRPT விதிகளால் செய்கிறது, macOS /etc/resolver/ கீழ் கூடுதல் தீர்விக் கோப்பால் செய்கிறது.

பலவழி பெயர்கள் தங்கள் சொந்தப் பதிலுக்குத் தகுதியானவை. .local பெயர்கள் வடிவமைப்பால் link-local (RFC 6762), புள்ளி-க்கு-புள்ளி tun இடைமுகம் அந்தப் பலவழிக் குழுவைச் சுமக்காது, எனவே பொது தீர்வி சேர்த்தால் அவை வெளியிடப்படாது, உள் unicast தீர்வியிடம் அவற்றைப் பற்றிக் கேட்டால் NXDOMAIN திரும்பும். avahi போன்ற பிரதிபலிப்பான் பிரதிபலிப்பு பயன்முறையில் இரு பகுதிகளை இணைக்கலாம், ஆனால் அது சேவையகப் பக்கத்தின் முடிவு, எந்தக் கிளையண்டும் கேட்க முடியாதது. அச்சுப்பொறி அல்லது NAS பெயரால் அணுகத்தக்கதாக இருக்க வேண்டும் என்றால், அதற்குப் பதிலாக உங்கள் மண்டலத்தில் அதற்கு A பதிவு கொடுங்கள்.

பதில் திரும்ப வர முடியும் என்பதை நிரூபியுங்கள்

அடையமுடியாத முகவரியைச் சுட்டும் சரியான பதில், நீங்கள் வழியைச் சரிபார்க்கும் வரை சரியாகத் தீர்விச் சிக்கலைப் போலவே தோன்றும். கர்னலைக் கேளுங்கள் பதில் எங்கே போகும் என: ip route get 10.20.5.20 இடைமுகத்தையும், மிகவும் பயனுள்ளதாக, அது பயன்படுத்தும் மூல முகவரியையும் குறிப்பிடுகிறது.

தீர்வியின் முகவரியையே கவனியுங்கள். DNS = 10.8.0.53 உடன் AllowedIPs = 10.20.0.0/16 உள்ள கிளையண்ட் தன் வினவல்களை இயற்பியல் NIC வழியாக வெளியே அனுப்புகிறது, அங்கே அவை அமைதியாக இறக்கின்றன, ஏனெனில் தீர்வி சுரங்கப்பாதை கோரும் எந்த முன்னொட்டுக்குள்ளும் இல்லை. இந்த முரண்பாடே இந்தத் துறை முழுவதிலும் மிகவும் பொதுவான ஒற்றைக் காரணத் தோல்வி, DNS அமைப்பை அனுமதிக்கப்பட்ட முன்னொட்டுகளுடன் வரி வரியாக ஒப்பிடாத வரை இது கண்ணுக்குத் தெரியாது.

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

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

நுழைவாயிலிலிருந்து அல்ல, கிளையண்டிலிருந்து மீண்டும் சோதியுங்கள்

பயனர் புகார் சொல்லும் பயன்பாட்டின் உள்ளேயே சோதியுங்கள், ஏனெனில் கட்டளை வரியின் தேடல் உலாவியும் அதே வழியை எடுக்கிறது என்பதை நிரூபிக்காது. Chrome இன் பாதுகாப்பான DNS உம் Firefox இன் network.trr.mode உம் கணினித் தீர்வியை முழுமையாகத் தவிர்க்க முடியும், அவ்வாறு செய்யும்போது தனியுரிம பெயர் தோல்வியடையும் அல்லது பொது தீர்விக்குக் கசியும். resolvectl query ஐக் கைமுறையாக இயக்கிய dig @10.8.0.53 files.corp.example உடன் ஒப்பிடுவது இரண்டில் எது நடந்தது என்பதைச் சொல்லும்.

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

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