resolver peered VNet இல் இருக்கும்போது Azure P2S DNS தோல்வியடைகிறது

VM க்கு ping செய்யுங்கள், அது பதிலளிக்கிறது; அதன் பெயரைக் கேளுங்கள், கிளையண்ட் host தெரியவில்லை என்கிறது. resolver VPN gateway உள்ள வலையமைப்பில் இல்லாமல் peered மெய்நிகர் வலையமைப்பில் இருக்கும்போது, இந்த இரு முடிவுகளும் எதிர்பார்க்கப்பட்டவை, மேலும் resolver பிழைத்திருத்தம் எவ்வளவு செய்தாலும் அதை மாற்றாது. காணாமல் இருப்பது peering இயல்பாகத் தடுத்து வைக்கும் வழித்தட ஒப்பந்தம். இரு இடவியல்கள் காகிதத்தில் கிட்டத்தட்ட ஒரே மாதிரி தெரிகின்றன, வேலை செய்வதற்கும் உடைந்ததற்கும் இடையிலான இடைவெளி சரியான திசையில் வைக்கப்பட்ட ஒரு ஜோடி peering சுவிட்சுகள்.

ஒரு மடிக்கணினி VNet2 இல் உள்ள gateway க்கு டன்னல் செய்கிறது, DNS வழங்கும் domain controller VNet1 இல் அமர்ந்துள்ளது என கற்பனை செய்யுங்கள்.

இரு இடவியல்கள், ஒரு வேறுபாடு

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

அதே resolver ஐ peering இன் மறுபக்கத்திற்கு நகர்த்துங்கள், கிளையண்ட் இன்னும் VM இல் இருந்து பதிலைப் பெறுகிறது, பெயர் தெரியாததாகவே இருக்கிறது. சான்றிதழ், டன்னல் மற்றும் கிளையண்ட் மாறவில்லை. நகர்ந்த ஒரே விஷயம் resolver எங்கு வாழ்கிறது என்பதுதான். peering அதற்கு அந்த முகவரிக்கு ஒரு வழியைக் கொடுத்தது, gateway க்கு அங்கு போக்குவரத்தை எடுத்துச் செல்லும் அதிகாரத்தை அல்ல.

பக்கம் A: gateway உரிமையாளரிடம் gateway இடமாற்றத்தை அனுமதிக்கவும்

peering இரு மெய்நிகர் வலையமைப்புகளை இணைக்கிறது, ஆனால் gateway வழியாக வரும் போக்குவரத்துக்கு இந்த இணைப்பு கடத்தலாகாது, point-to-site கோரிக்கை அப்படியே வருகிறது. எனவே VNet2 இல் உள்ள gateway வடிவமைப்பு அனுமதிக்கும் வரை தேடலை VNet1 க்கு ஒப்படைக்கும் உரிமை அதற்கு இல்லை. அனுமதி என்பது gateway உள்ள வலையமைப்புக்குச் சொந்தமான peering இல் உள்ள சுவிட்ச்.

VNet2 இல் இருந்து VNet1 நோக்கிய peering இல் Allow gateway transit அமைக்கவும். இந்தப் பண்பு gateway வளத்திற்கு அல்ல, peering பொருளுக்கு உரியது, எனவே peering பிளேடில் அதைப் படித்து மாற்றுகிறீர்கள். முழு பக்கம் A இவ்வளவுதான்.

பக்கம் B: இணையில் தொலை gateway களைப் பயன்படுத்தவும்

மறு பாதி கண்ணாடிப் பிம்பம்: VNet1 இல் இருந்து VNet2 க்குத் திரும்பும் peering இல் Use remote gateways ஐ இயக்கவும். அதே கொடியை இரு முனைகளிலும், அல்லது ஒரு முனையில் மட்டும் இயக்கினால் பாதி கட்டப்பட்ட வழியும் அசல் அறிகுறியும் தொடப்படாமல் இருக்கும். VPN gateway உள்ள வலையமைப்பு மட்டுமே இடமாற்றத்தை அனுமதிக்கிறது, இணை என்பது அதைப் பயன்படுத்தும் பக்கம்.

கடைசியாகத் திறந்த போர்ட்டல் பிளேடை நம்புவதற்குப் பதிலாக இரு வலையமைப்புகளிலும் இரு பண்புகளையும் படியுங்கள்.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

ஜோடியை அருகருகே பார்ப்பது தலைகீழான அமைப்பைப் பிடிக்கும் வேகமான வழி. gateway பக்கத்தில் AllowGatewayTransit false எனத் தெரிவிக்கும் peering, packet capture இல்லாமலே முழுத் தோல்வியையும் விளக்குகிறது.

கிளையண்ட் இன்னும் பெற வேண்டியது

வழித்தடம் அவசியம், போதுமானதல்ல, ஏனெனில் point-to-site சுயவிவரம் இடமாற்றம் வேலை செய்தபின் பதிலளிக்கும் DNS முகவரியையும் கிளையண்டுக்கு வழங்க வேண்டும். தளத்தின் resolver அந்த முகவரி அல்ல: மெய்நிகர் வலையமைப்புடன் இணைக்கப்பட்ட Azure Private DNS மண்டலங்களுக்குப் பதிலளிக்கிறது, ஆனால் உங்கள் சொந்த அடைவகச் சேவையகங்களில் ஹோஸ்ட் செய்யப்பட்ட மண்டலத்திற்கு எதுவும் இல்லை, இந்தப் பயன்பாடு அதைத்தான் பயன்படுத்துகிறது. ஒரு கிளையண்டை அங்கு சுட்டுங்கள், பொது பெயர்கள் மகிழ்ச்சியுடன் தீர்க்கப்படும், உள் host தெரியாததாகவே இருக்கும்.

வேறு எதையும் மாற்றுவதற்கு முன் இணைக்கப்பட்ட மடிக்கணினியில் இருந்து resolver ஐக் கேளுங்கள்.

nslookup dc01.corp.example 10.1.0.4

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

தளம்-தளம் பக்கத்தில் அதே ஒப்பந்தத்தை ஒப்பிடுங்கள்

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

இடமாற்றம் இரு peering களிலும் வழங்கப்பட வேண்டும், அதை வழங்கும் சுவிட்ச் கிளையண்ட் வகையில் அல்ல, peering இல் வாழ்கிறது.

gateway ஐக் குறை சொல்வதற்கு முன்

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

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

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

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