Windows-এ OpenVPN সংযুক্ত হওয়ার পর DNS কেন কাজ করা বন্ধ করে

ping-এ রিজলভার এখনও উত্তর দেয়, অথচ পোর্ট 53 কোথাও পৌঁছায় না। block-outside-dns ফিল্টার করছে কি না দেখুন, তারপর টানেল যে রিজলভারে পৌঁছাতে পারে তা দিন।

অফিসের রিজলভারে "OpenVPN" সংযুক্ত হওয়ার পরেও ping-এর উত্তর আসে, কিন্তু প্রতিটি নাম অনুসন্ধান ব্যর্থ হয়। ঠিকানাটি পৌঁছানোর যোগ্য, পোর্টটি নয়, আর Windows অ্যাডাপ্টারভিত্তিকভাবে DNS ফিল্টার করতে পারে জানলে এই সমন্বয় বোধগম্য হয়। প্রোফাইলে block-outside-dns থাকলে সেই ফিল্টারই প্রথম সন্দেহভাজন, আর রুট টেবিল খোঁজার ভুল জায়গা। নিচের দুটি পরীক্ষা সেকেন্ডের মধ্যে স্তরগুলো আলাদা করে।

পৌঁছানো যায় এমন ঠিকানা, মৃত পোর্ট

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

ping <resolver-ip>
nslookup <name> <resolver-ip>

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

বিকল্পটি ফিল্টারিং প্ল্যাটফর্মের একটি নিয়ম

OpenVPN-এর রেফারেন্স block-outside-dns-কে Windows Filtering Platform-এর একটি নিষেধাজ্ঞা হিসেবে বর্ণনা করে যা টানেলের বাইরের অ্যাডাপ্টারে অ্যাপ্লিকেশনকে DNS-এ পৌঁছাতে বাধা দেয়। এটি TCP ও UDP পোর্ট 53 কভার করে। ফিল্টারটি সাধারণ ফায়ারওয়াল নিয়মের তালিকায় নয়, WFP-তে থাকে, তাই অন্য জায়গায় অনুমতির নিয়ম যোগ করলে ফলাফল বদলাবে না। এ কারণেই DNS অনুমোদনের সাধারণ পরামর্শ বারবার ব্যর্থ হয়।

সেটিংটি আমদানি করা প্রোফাইল বা সার্ভার থেকে আসতে পারে, আর আপনি শেষ যে ফাইলটি সম্পাদনা করেছেন তা "ক্লায়েন্ট কী লোড করেছে তার প্রমাণ নয়"। কার্যকর কনফিগারেশন ও সংযোগ লগ একসাথে পড়ুন। বিকল্পটি Windows-নির্দিষ্টও, এবং এটিকে বহনযোগ্য ভাবলে এমন পরামর্শ আসে যা প্রযোজ্য নয়।

আরও নিয়ম যোগ না করে যে ক্লায়েন্ট কম্পোনেন্ট এই নিষেধাজ্ঞার মালিক তাকে খুঁজুন। মালিকই সেই জিনিস যা এটি সত্যিই সরাতে পারে।

ফিল্টার রিজলভার নয়

টানেলের বাইরের ট্রাফিক ব্লক করা তার ভিতরে কাজ করা রিজলভার ইনস্টল করে না। বিকল্পটি একটি পথ সরিয়ে টানেলের DNS কনফিগারেশন প্রোফাইল যিনি বানিয়েছেন তার হাতে ছেড়ে দেয়। যে প্রোফাইল কখনও রিজলভার পাঠায়নি তার এখন একেবারেই নেই।

তিনটি যাচাই ক্রমে করুন। প্রথমে, ব্যর্থ অ্যাপ্লিকেশনটি আসলে কোন রিজলভার ব্যবহার করে। দ্বিতীয়তে, ক্লায়েন্ট VPN DNS সেটিং প্রয়োগ করেছে কি না। তৃতীয়তে, কোন ইন্টারফেস সেই রিজলভারে ট্রাফিক বহন করে।

  1. ব্যবহৃত রিজলভার: Resolve-DnsName -Server <resolver-ip> <name> কে ipconfig /all-তে তালিকাভুক্ত DNS সার্ভারগুলোর সাথে তুলনা করুন।
  2. VPN DNS প্রয়োগ: একই ipconfig /all আউটপুটে টানেল অ্যাডাপ্টারের DNS এন্ট্রি দেখুন।
  3. ব্যবহৃত ইন্টারফেস: Find-NetRoute -RemoteIPAddress <resolver-ip> সেই গন্তব্যের আউটগোয়িং ইন্টারফেসের নাম দেয়।

এই নীতির অধীনে LAN রিজলভার ডিজাইন অনুযায়ী অপ্রাপ্য হয়ে যায়, এমনকি অন্য LAN ট্রাফিক চললেও। এটাই বিকল্পটি তার কাজ করছে। ডিজাইনে VPN DNS দরকার হলে রিজলভার নিবন্ধন ও টানেল পথ ঠিক করুন; লোকাল ব্যতিক্রমসহ split DNS দরকার হলে কনফিগারেশনের মালিককে সমর্থিত উপায়ে সেই ব্যতিক্রমগুলো প্রকাশ করতে হবে।

বিকল্পটি যা কভার করে না

পোর্ট 53 নাম রিজলভের সম্পূর্ণটা নয়। DNS over HTTPS ও DNS over TLS ভিন্ন ট্রান্সপোর্ট ব্যবহার করে, আর কিছু অ্যাপ্লিকেশন সিস্টেম সেটিং নির্বিশেষে নিজের রিজলভার লজিক চালায়। তাই ব্রাউজার নাম রিজলভ করতে পারে, কমান্ড লাইন পারে না।

এই পার্থক্যকে বিরোধিতা নয়, রোগনির্ণয় হিসেবে নিন। সিস্টেম রিজলভার নষ্ট বলে সিদ্ধান্ত নেওয়ার আগে দুটো তুলনা করুন।

লিখে রাখার সময় উপসংহারটি সংকীর্ণ রাখুন। এই বিকল্পটি একটি প্ল্যাটফর্মে একটি ট্রান্সপোর্ট সীমিত করে, আর রিজলভিং পথের বাকিটা নিজের মালিকসহ আলাদা ডিজাইন প্রশ্ন।

সংযোগ বিচ্ছিন্নের আগে ও পরে অবস্থা যাচাই করুন

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

ipconfig /displaydns
nslookup <name> <resolver-ip>

ক্লায়েন্ট সার্ভিস বা মেশিন পুনরায় চালু করলে সাধারণত পুরোনো ফিল্টার মুছে যায়। এটি রোগনির্ণয় নিশ্চিত করে, তবে স্থায়ী সমাধান প্রমাণ করে না। যা দেখেছেন তা লিখে রাখুন, কারণ বিচ্ছিন্নতা কাটিয়ে ওঠা ফিল্টার আবার তা করবে, আর সেই রেকর্ডই বাগ রিপোর্টের যৌক্তিকতা।

এই যাচাইগুলোর পরেই রিজলভার বদলানো বা ফায়ারওয়াল নীতি পুনর্গঠন অর্থবহ। দুটোই প্রমাণ যতটা সমর্থন করে তার চেয়ে বড় পরিবর্তন।

সম্পর্কিত নিবন্ধ