பொது DNS வேலை செய்வது Active Directory கிடைக்கும் என்று அர்த்தமல்ல

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

கட்டுக்கதை: பெயர்கள் தீர்க்கப்படுகின்றன, எனவே DNS முடிந்தது

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

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

டொமைன் கிளையண்ட் உண்மையில் என்ன கேட்கிறது, வரிசையாக

corp.example போன்ற டொமைனுக்கு பொது இருப்பிட வினவல் _ldap._tcp.dc._msdcs.corp.example ஆகும். SRV பதில்கள் வேட்பாளர் கட்டுப்படுத்திகளையும் அவற்றின் துறைமுகங்களையும் பெயரிடுகின்றன, பின்னர் இணைப்பைத் திறக்கும் முன் அந்த ஹோஸ்ட் பெயர்களுக்கான முகவரிப் பதிவுகள் கிளையண்டிற்குத் தேவை. தளத்தை அறிந்த கண்டறிதல் தளத்தின் துணை டொமைனின் கீழ் வினவல்களைச் சேர்க்கிறது, பதில்கள் எந்தக் கட்டுப்படுத்திகள் விரும்பத்தக்கவை என்பதைத் தீர்மானிக்கின்றன, எது கட்டாயம் என்பதை அல்ல.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

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

பொது தீர்வி பதிலளித்தும் உள்நுழைவு ஏன் உடைகிறது

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

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

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

சுரங்கப்பாதையின் DNS மற்றும் அதன் வழித்தடங்களை ஒத்திசைவாக வைத்திருங்கள்

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

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

கண்டறிதல் அழைப்பு மற்றும் ஒரு நேரடி செயல்பாட்டுடன் ஏற்றுக்கொள்ளுங்கள்

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

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

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