VPN-এ Azure প্রাইভেট DNS: রিজলভার এন্ডপয়েন্ট নাকি ফরওয়ার্ডার
দুটি ডিজাইনই টানেলের উপর দিয়ে প্রাইভেট জোনের উত্তর দেয়। ম্যানেজড ইনবাউন্ড এন্ডপয়েন্টের সঙ্গে ফরওয়ার্ডার VM তুলনা করুন, তারপর যেকোনো ক্ষেত্রেই থাকা প্রয়োজনীয় পথটি যাচাই করুন।
অন-প্রিমাইজের একটি সার্ভার প্রাইভেট ঠিকানায় একটি Azure VM-এ পৌঁছায়, তবুও তার প্রাইভেট হোস্টনেম রিজলভ করতে পারে না, ফলে মানুষ ভাঙা টানেল খুঁজতে শুরু করে। টানেল ঠিকই আছে। যেটি নেই তা হল একটি DNS সীমানা: অন-প্রিমাইজের দিকে কেউ জানে না যে নির্দিষ্ট একটি Azure প্রাইভেট জোনের উত্তর VNet-এর ভিতরের রিজলভারকে দিতে হবে। দুটি ডিজাইন এই ফাঁক পূরণ করে, আর তারা আলাদা হয় আপনি শেষ পর্যন্ত কী পরিচালনা করেন তার ভিত্তিতে, কোয়েরি কাজ করে কি না তার ভিত্তিতে নয়।
টানেল কোয়েরি বহন করে, জোনের জ্ঞান নয়
সাইট-টু-সাইট সংযোগ প্যাকেটকে দুই নেটওয়ার্কের মধ্যে পথ দেয়। এটি অন-প্রিমাইজ DNS সার্ভারকে বলে না কোন নেমস্পেস Azure-এর এবং কোন ঠিকানায় উত্তর দিতে হবে, তাই কোয়েরি হয় ইন্টারনেটে গিয়ে খালি ফিরে আসে, নয়তো লোকাল রিজলভার কখনো ছাড়ে না।
সমাধানের দুটি অর্ধ আছে যা সহজেই আলাদা করা যায়। এক অর্ধ হল VNet-এর ভিতরের রিজলভার যা টানেল দিয়ে আসা কোয়েরি গ্রহণ করে। অন্য অর্ধ হল অন-প্রিমাইজের দিকে শর্তসাপেক্ষ ফরওয়ার্ডার যা ঠিক একটি নেমস্পেস সেই রিজলভারে পাঠায়। কোনো অর্ধ একা কাজ করে না।
এই আলোচনার বাকি অংশের জন্য ধরে নিন জোনটি cloud.corp.example, এবং প্রতিটি ঠিকানাকে উদাহরণস্বরূপ গণ্য করুন।
বিকল্প A: ম্যানেজড ইনবাউন্ড এন্ডপয়েন্ট
Azure DNS Private Resolver একটি ইনবাউন্ড এন্ডপয়েন্ট দেয় যা VNet-এর বাইরে থেকে DNS কোয়েরি গ্রহণ করে। আপনি এটি একটি নির্দিষ্ট ডেলিগেটেড সাবনেটে স্থাপন করেন, প্রাইভেট জোনটি সেই VNet-এ লিঙ্ক করেন, এবং সার্ভিস যে ইনবাউন্ড ঠিকানা দেয় তা নোট করেন।
এরপর অন-প্রিমাইজ DNS সার্ভারে ঠিক নেমস্পেসটির জন্য সেই ঠিকানার দিকে একটি শর্তসাপেক্ষ ফরওয়ার্ডার তৈরি করেন:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft-এর হাইব্রিড DNS পদ্ধতি জোন লিঙ্ক ও ফরওয়ার্ডার ধাপ দুটিই নথিভুক্ত করে। ম্যানেজড পথে আপনার প্যাচ করার মতো কোনো DNS সফটওয়্যার থাকে না, এবং রিসোর্সের জীবনকাল জুড়ে এন্ডপয়েন্ট ঠিকানা স্থিতিশীল থাকে।
এর বিনিময়ে এখন একটি রিজলভার রিসোর্স, তার সাবনেট ডেলিগেশন ও তার খরচ আপনার হাতে, যা কোয়েরির পরিমাণ খুব কম হলেও বাস্তব।
বিকল্প B: VNet-এর ভিতরে ফরওয়ার্ডার VM
পুরোনো ডিজাইন VNet-এর একটি সাধারণ VM-এ DNS সফটওয়্যার চালায়: Windows DNS, BIND বা dnsmasq, প্রাইভেট জোনটি হয় লোকালি হোস্ট করা হয়, নয়তো 168.63.129.16-এ Azure-প্রদত্ত রিজলভারে ফরওয়ার্ড করা হয়। অন-প্রিমাইজের শর্তসাপেক্ষ ফরওয়ার্ডার সেই VM-এর প্রাইভেট ঠিকানার দিকে নির্দেশ করে।
যেসব দল ইতিমধ্যে DNS সার্ভার চালায় তাদের কাছে এই বিকল্প পরিচিত, এবং এটি লগিং বা স্প্লিট-হরাইজন উত্তরের মতো অতিরিক্ত লজিক বহন করতে পারে। এটি একটি 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 |
যে সারিই সিদ্ধান্ত দিক, অন-প্রিমাইজের ফরওয়ার্ডার নিয়ম একই দেখায়। এই অংশটিই দুই ডিজাইনেই থাকতে হবে, এবং কেউ যখন জানায় যে Azure-এর ভিতর থেকে রিজলিউশন কাজ করে কিন্তু অফিস থেকে করে না, তখন এই অংশটিই সবচেয়ে বেশি অনুপস্থিত থাকে।
পথটি ক্রমে যাচাই করুন
নিশ্চিত করুন জোনটি রিজলভার ধারণকারী VNet-এ লিঙ্ক করা, এবং অন-প্রিমাইজ ফরওয়ার্ডার প্যারেন্ট ডোমেইন নয় নেমস্পেসের নাম বলে। corp.example-এর ফরওয়ার্ডার cloud.corp.example-এর সঙ্গে মিলবে না, যদি রিজলভার নিজেই ডেলিগেট না করে, এবং এই অমিল একটি পরিষ্কার নেতিবাচক উত্তর দেয় যা অনুপস্থিত রেকর্ডের মতো দেখায়।
তারপর যাচাই করুন কোয়েরি এন্ডপয়েন্টে পৌঁছায়: অন-প্রিমাইজ উৎসের রিজলভার ঠিকানায় পথ ও ফেরার পথ দরকার, এবং যেখানে নীতি অনুমতি দেয় সেখানে UDP ও TCP দুটোই পোর্ট 53 খোলা থাকা উচিত। NSG অনুপস্থিত জোন রেকর্ড দিতে পারে না, আর সঠিক জোন কখনো না আসা কোয়েরির উত্তর দিতে পারে না।
ডায়াগনোস করার সময় অনুরোধকৃত FQDN রিজলভারের পাশে রাখুন এবং টাইমআউটকে নেতিবাচক উত্তর থেকে আলাদা করুন। টাইমআউট পথ বা নীতির সমস্যা। নেতিবাচক উত্তর মানে কোয়েরি পৌঁছেছে এবং নেমস্পেস মেলেনি। কাজের ক্রম: জোন লিঙ্ক করুন, শর্তসাপেক্ষ ফরওয়ার্ডার যোগ করুন, দুই দিকেই পোর্ট 53 খুলুন, অন-প্রিমাইজ থেকে একটি নাম পরীক্ষা করুন, তারপরেই অ্যাপ্লিকেশনের নিজস্ব অনুমোদন দেখুন।