VPN வழியாக Azure தனிப்பட்ட DNS: resolver முனை அல்லது forwarder
இரு வடிவமைப்புகளும் சுரங்கப்பாதை வழியாக தனிப்பட்ட மண்டலங்களுக்குப் பதிலளிக்கின்றன. நிர்வகிக்கப்பட்ட உள்வரும் முனையை forwarder VM உடன் ஒப்பிட்டு, பின்னர் இரு சூழலிலும் இருக்க வேண்டிய பாதையைச் சரிபார்க்கவும்.
அக இருப்பிடத்தில் உள்ள சேவையகம் தனிப்பட்ட முகவரியால் Azure VM ஐ அடைகிறது, ஆனால் அதன் தனிப்பட்ட புரவலன் பெயரை இன்னும் தீர்க்க முடியவில்லை, இது மக்களை உடைந்த சுரங்கப்பாதையைத் தேட வைக்கிறது. சுரங்கப்பாதை நலமாக உள்ளது. இல்லாதது ஒரு DNS எல்லை: அக இருப்பிடப் பக்கத்தில் எதற்கும் தெரியாது ஒரு குறிப்பிட்ட Azure தனிப்பட்ட மண்டலத்திற்கு VNet உள்ளே உள்ள resolver பதிலளிக்க வேண்டும் என. இந்த இடைவெளியை இரண்டு வடிவமைப்புகள் நிரப்புகின்றன, அவை இறுதியில் நீங்கள் நிர்வகிப்பதில் வேறுபடுகின்றன, வினவல்கள் வேலை செய்கின்றனவா என்பதில் அல்ல.
சுரங்கப்பாதை வினவல்களை எடுத்துச் செல்கிறது, மண்டல அறிவை அல்ல
தளம்-க்கு-தளம் இணைப்பு பாக்கெட்டுகளுக்கு இரு வலைப்பிணைப்புகளுக்கு இடையே வழியைத் தருகிறது. எந்த பெயரிடம் Azure க்கு சொந்தம் அல்லது எந்த முகவரி பதிலளிக்க வேண்டும் என்பதை அக இருப்பிட DNS சேவையகத்திற்குச் சொல்லவில்லை, எனவே வினவல் ஒன்று இணையத்திற்குச் சென்று காலியாகத் திரும்பும், அல்லது உள்ளூர் resolver ஐ ஒருபோதும் விட்டு வெளியேறாது.
தீர்வுக்கு எளிதாகப் பிரிக்கக்கூடிய இரு பாதிகள் உள்ளன. ஒரு பாதி சுரங்கப்பாதை வழியாக வரும் வினவல்களை ஏற்கும் VNet உள்ளே உள்ள resolver. மற்றொரு பாதி அக இருப்பிடப் பக்கத்தில் உள்ள நிபந்தனை forwarder, அது சரியாக ஒரு பெயரிடத்தை அந்த resolver க்கு அனுப்புகிறது. எந்தப் பாதியும் தனியாக வேலை செய்யாது.
இந்த விளக்கத்தின் மீதமுள்ள பகுதிக்கு மண்டலம் cloud.corp.example என்று கருதுங்கள், ஒவ்வொரு முகவரியையும் எடுத்துக்காட்டாகக் கருதுங்கள்.
விருப்பம் A: நிர்வகிக்கப்பட்ட உள்வரும் முனை
Azure DNS Private Resolver VNet க்கு வெளியே இருந்து வரும் DNS வினவல்களை ஏற்கும் உள்வரும் முனையை வழங்குகிறது. நீங்கள் அதை அர்ப்பணிக்கப்பட்ட ஒப்படைக்கப்பட்ட துணை வலைப்பிணைப்பில் நிறுவி, தனிப்பட்ட மண்டலத்தை அந்த VNet உடன் இணைத்து, சேவை வழங்கும் உள்வரும் முகவரியைக் குறிப்பிடுகிறீர்கள்.
பின்னர் அக இருப்பிட DNS சேவையகத்தில் சரியான பெயரிடத்திற்காக அந்த முகவரியை நோக்கிய நிபந்தனை forwarder ஐ உருவாக்குகிறீர்கள்:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft இன் கலப்பு DNS செயல்முறை மண்டல இணைப்பையும் forwarder படியையும் பதிவு செய்கிறது. நிர்வகிக்கப்பட்ட பாதை இணைக்க DNS மென்பொருளை விட்டுச் செல்லாது, முனை முகவரி வளத்தின் முழு ஆயுளிலும் நிலையாக இருக்கும்.
விலை என்னவென்றால் இப்போது உங்களிடம் resolver வளம், அதன் துணை வலைப்பிணைப்பு ஒப்படைப்பு மற்றும் அதன் செலவு உள்ளன, வினவல் அளவு மிகக் குறைவாக இருந்தாலும் இது உண்மையானது.
விருப்பம் B: VNet உள்ளே forwarder VM
பழைய வடிவமைப்பு VNet இல் உள்ள சாதாரண VM இல் DNS மென்பொருளை இயக்குகிறது: Windows DNS, BIND அல்லது dnsmasq, தனிப்பட்ட மண்டலம் உள்ளூரில் வழங்கப்படுகிறது அல்லது 168.63.129.16 இல் உள்ள Azure resolver க்கு அனுப்பப்படுகிறது. அக இருப்பிட நிபந்தனை forwarder அந்த VM இன் தனிப்பட்ட முகவரியை நோக்குகிறது.
இந்த விருப்பம் ஏற்கனவே DNS சேவையகங்களை இயக்கும் குழுக்களுக்குப் பரிச்சயம், மேலும் பதிவு செய்தல் அல்லது split-horizon பதில்கள் போன்ற கூடுதல் தர்க்கத்தை ஏற்க முடியும். DNS சேவையகத்தின் ஒவ்வொரு செயல்பாட்டுக் கடமையையும் இது மரபாகப் பெறுகிறது: இணைப்பு, கிடைப்பதற்கான இரண்டாவது நிகழ்வு, கண்காணிப்பு, மற்றும் VM மாற்றப்பட்டு அதன் முகவரி மாறும்போது மீள்கட்டுமானப் பாதை.
சாதாரண VNet புரவலன் DNS ப்ராக்ஸி அல்ல, சேவை நிறுவப்பட்டு அந்த வாடிக்கையாளர்களுக்குப் பதிலளிக்க அனுமதி கிடைக்கும் வரை, VM ஐ நகலெடுக்கும்போது மக்கள் தவிர்க்கும் படி அதுவே.
எது உங்கள் செயல்பாட்டிற்குப் பொருந்துகிறது
ஒப்பீடு எந்த வடிவமைப்பு வேகமானது என்பதில் அல்ல. DNS மென்பொருளை நீங்கள் இயக்க விரும்புகிறீர்களா, மற்றும் வினவல் அளவு முனை மற்றும் வினவலுக்கு ஏற்ப கட்டணம் வசூலிக்கும் நிர்வகிக்கப்பட்ட வளத்தை நியாயப்படுத்துகிறதா என்பதில்.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
எந்த வரி முடிவு செய்தாலும், அக இருப்பிட forwarder விதி ஒரே மாதிரியாகத் தெரிகிறது. இந்தப் பகுதி இரு வடிவமைப்புகளிலும் இருக்க வேண்டும், Azure உள்ளேயிருந்து தீர்வு வேலை செய்கிறது ஆனால் அலுவலகத்திலிருந்து இல்லை என்று யாராவது தெரிவிக்கும்போது அதிகம் இல்லாத பகுதி இதுவே.
பாதையை வரிசையாகச் சரிபார்க்கவும்
மண்டலம் resolver உள்ள VNet உடன் இணைக்கப்பட்டுள்ளதா, அக இருப்பிட forwarder பெற்றோர் களம் அல்ல பெயரிடத்தைக் குறிப்பிடுகிறதா என்பதை உறுதிசெய்யுங்கள். corp.example க்கான forwarder, resolver தானே ஒப்படைக்காவிட்டால் cloud.corp.example உடன் பொருந்தாது, இந்தப் பொருந்தாமை காணாமற்போன பதிவு போலத் தெரியும் தூய எதிர்மறை பதிலை உருவாக்குகிறது.
பின்னர் வினவல் முனையை அடைகிறதா எனச் சரிபார்க்கவும்: அக இருப்பிட மூலத்திற்கு resolver முகவரிக்கு வழியும் திரும்பும் வழியும் தேவை, கொள்கை அனுமதிக்கும் இடத்தில் UDP மற்றும் TCP இரண்டிற்கும் போர்ட் 53 திறந்திருக்க வேண்டும். NSG காணாமற்போன மண்டலப் பதிவைத் தர முடியாது, சரியான மண்டலமும் ஒருபோதும் வராத வினவலுக்குப் பதிலளிக்க முடியாது.
கண்டறியும்போது கோரப்பட்ட FQDN ஐ தேர்ந்தெடுத்த resolver அருகில் வைத்திருங்கள், நேரம் முடிவதையும் எதிர்மறை பதிலையும் பிரிக்கவும். நேரம் முடிவது வழி அல்லது கொள்கை சிக்கல். எதிர்மறை பதில் என்பது வினவல் வந்தது, பெயரிடம் பொருந்தவில்லை. வேலை வரிசை: மண்டலத்தை இணைக்கவும், நிபந்தனை forwarder ஐச் சேர்க்கவும், இரு திசைகளிலும் போர்ட் 53 ஐத் திறக்கவும், அக இருப்பிடத்திலிருந்து ஒரு பெயரைச் சோதிக்கவும், பின்னரே பயன்பாட்டின் சொந்த அனுமதியைப் பார்க்கவும்.