পিয়ারড VNet-এ রিজলভার থাকলে Azure P2S DNS ব্যর্থ হয়

VM-এ পিং করুন, উত্তর আসে; তার নাম জিজ্ঞাসা করুন, ক্লায়েন্ট বলে হোস্ট অজানা। যখন রিজলভার VPN গেটওয়ে ধারণকারী নেটওয়ার্কের বদলে একটি পিয়ারড ভার্চুয়াল নেটওয়ার্কে থাকে, তখন এই জোড়া ফলাফল প্রত্যাশিত, এবং রিজলভার ট্রাবলশুটিংয়ের কোনো পরিমাণই তা বদলায় না। যা অনুপস্থিত তা হলো একটি রাউটিং চুক্তি, যা পিয়ারিং ডিফল্টভাবে আটকে রাখে। দুটি টোপোলজি কাগজে প্রায় অভিন্ন দেখায়, আর কাজ করা ও ভাঙা অবস্থার মধ্যের ফারাক হলো সঠিক দিকে বসানো এক জোড়া পিয়ারিং সুইচ।

ভাবুন একটি ল্যাপটপ VNet2-এর একটি গেটওয়েতে টানেল করছে, আর DNS পরিবেশনকারী ডোমেইন কন্ট্রোলার বসে আছে VNet1-এ।

দুটি টোপোলজি, একটি পার্থক্য

রিজলভারটি গেটওয়ের নিজের ভার্চুয়াল নেটওয়ার্কের ভিতরে রাখুন, টানেল ওঠার মুহূর্তেই নাম রিজলভ হবে। কোনো পিয়ারিং সেটিং সেই লুকআপে অংশ নেয় না।

একই রিজলভারকে পিয়ারিংয়ের ওপারে সরান, ক্লায়েন্ট তখনও VM থেকে উত্তর পায়, অথচ নাম অজানা থাকে। সার্টিফিকেট, টানেল ও ক্লায়েন্ট অপরিবর্তিত। শুধু যা সরেছে তা হলো রিজলভার কোথায় থাকে। পিয়ারিং তাকে ওই ঠিকানায় একটি রুট দিয়েছে, গেটওয়েকে সেখানে ট্রাফিক বহনের অধিকার নয়।

পক্ষ A: গেটওয়ে মালিকের উপর গেটওয়ে ট্রানজিট অনুমোদন করুন

পিয়ারিং দুটি ভার্চুয়াল নেটওয়ার্ককে যুক্ত করে, কিন্তু এই যুক্তি গেটওয়ে দিয়ে আসা ট্রাফিকের জন্য ট্রানজিটিভ নয়, আর পয়েন্ট-টু-সাইট অনুরোধ ঠিক সেইভাবেই আসে। তাই VNet2-এর গেটওয়ের VNet1-এ লুকআপ হস্তান্তরের অধিকার নেই, যতক্ষণ ডিজাইন তা অনুমোদন না করে। অনুমোদনটি গেটওয়ে ধারণকারী নেটওয়ার্কের মালিকানাধীন পিয়ারিংয়ের একটি সুইচ।

VNet2 থেকে VNet1-এর দিকে পিয়ারিংয়ে Allow gateway transit সেট করুন। এই বৈশিষ্ট্যটি গেটওয়ে রিসোর্সের নয়, পিয়ারিং অবজেক্টের, তাই পিয়ারিং ব্লেডেই তা পড়ুন ও বদলান। পক্ষ A-এর পুরোটাই এটুকু।

পক্ষ B: পিয়ারে রিমোট গেটওয়ে ব্যবহার করুন

অন্য অর্ধেকটি আয়নার প্রতিচ্ছবি: VNet1 থেকে VNet2-এর দিকে পিয়ারিংয়ে Use remote gateways চালু করুন। একই ফ্ল্যাগ দুই প্রান্তে বা কেবল এক প্রান্তে চালু করলে অর্ধগঠিত পথ ও মূল উপসর্গ অপরিবর্তিত থাকে। কেবল VPN গেটওয়েওয়ালা নেটওয়ার্কই ট্রানজিট অনুমোদন করে, আর পিয়ার হলো যে পক্ষ তা ব্যবহার করে।

সর্বশেষ খোলা পোর্টাল ব্লেডে ভরসা না করে দুই নেটওয়ার্কে দুই বৈশিষ্ট্যই পড়ুন।

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

জোড়াটি পাশাপাশি দেখা উল্টো সেটিং ধরার দ্রুততম উপায়। যে পিয়ারিং গেটওয়ের দিকে AllowGatewayTransit false দেখায়, সে প্যাকেট ক্যাপচার ছাড়াই পুরো ব্যর্থতা ব্যাখ্যা করে।

ক্লায়েন্টকে এখনও যা পেতে হবে

রাউটিং প্রয়োজনীয়, যথেষ্ট নয়, কারণ পয়েন্ট-টু-সাইট প্রোফাইলকেও ক্লায়েন্টকে এমন একটি DNS ঠিকানা দিতে হবে যা ট্রানজিট কাজ করার পর উত্তর দেয়। প্ল্যাটফর্ম রিজলভার সেই ঠিকানা নয়: এটি ভার্চুয়াল নেটওয়ার্কে যুক্ত Azure Private DNS জোনের উত্তর দেয়, কিন্তু আপনার নিজের ডিরেক্টরি সার্ভারে হোস্ট করা জোনের জন্য কিছুই না, আর এই ডিপ্লয়মেন্ট ঠিক সেটাই ব্যবহার করে। ক্লায়েন্টকে সেখানে নির্দেশ করুন, পাবলিক নামগুলো আনন্দে রিজলভ হবে, আর অভ্যন্তরীণ হোস্ট অজানা থেকে যাবে।

অন্য কিছু বদলানোর আগে সংযুক্ত ল্যাপটপ থেকে রিজলভারকে জিজ্ঞাসা করুন।

nslookup dc01.corp.example 10.1.0.4

টাইমআউট বলে পথটি এখনও অনুপস্থিত। একটি কর্তৃত্বপূর্ণ উত্তর সমস্যাটিকে ক্লায়েন্টের দিকে ফিরিয়ে দেয়, সাধারণত এমন একটি সাফিক্স যা কখনও যুক্ত হয় না, ফলে ছোট নাম একটি পাবলিক রিজলভারে যায় যা তাদের আনন্দে ব্যর্থ করে।

সাইট-টু-সাইট দিকেও একই চুক্তি তুলনা করুন

এর কিছুই বিশেষভাবে ল্যাপটপের নয়। ক্লায়েন্টের বদলে সাইট-টু-সাইটের একটি শাখা বসান, দুই দিকের শর্তটি ফিরে আসে: শাখাটি সরাসরি গেটওয়ে নেটওয়ার্কে আসে, আর দুই নেটওয়ার্ক দূরের একটি সার্ভিস তখনও পিয়ারিংয়ের পেছনে।

ট্রানজিট দুই পিয়ারিংয়েই অনুমোদন করতে হবে, আর যে সুইচ তা দেয় সেটি ক্লায়েন্ট টাইপে নয়, পিয়ারিংয়ে থাকে।

গেটওয়েকে দোষ দেওয়ার আগে

Windows প্রতিটি অ্যাডাপ্টারের জন্য আলাদা রিজলভার তালিকা রাখে, তাই গেটওয়েকে দোষ দেওয়ার আগে টানেল ইন্টারফেস আসলে কী পেয়েছে তা নিশ্চিত করুন।

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

নেতিবাচক উত্তর ক্যাশে রাউটিং ঠিকের চেয়ে বেশি দিন বাঁচে, আর পুরোনো সাফিক্স তালিকা কোয়েরি পাঠাতে থাকে এমন জায়গায় যেখানে জোন কখনও হোস্ট হয়নি। ফ্লাশ করুন, আবার জিজ্ঞাসা করুন, আর কোন সার্ভার উত্তর দেয় তা লিখে রাখুন।

দুটি ছোট শর্ত ঠিক করে পথটি টিকবে কি না: ঠিকানা স্পেসগুলো ওভারল্যাপ করা যাবে না, আর রিজলভারের সাবনেটের নেটওয়ার্ক সিকিউরিটি গ্রুপকে ক্লায়েন্ট পুল গ্রহণ করতে হবে, যা আরেকটি সোর্স রেঞ্জ মাত্র। VM-এর দিক থেকে এফেক্টিভ-রুট যাচাই আর ক্লায়েন্ট থেকে একটি সরাসরি কোয়েরি দিয়ে এটি প্রমাণ করুন, যাতে জোন সমস্যা, সাফিক্স সমস্যা বা ফিল্টারকে কখনও অনুপস্থিত ট্রানজিট ভুল না করা হয়।