VPN-এ অভ্যন্তরীণ নাম ব্যর্থ, অথচ পাবলিক সাইট খোলে

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

দুটি উপসর্গ, একটিমাত্র ত্রুটি নয়

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

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

দুটি পর্যবেক্ষণই সময়ের টীকাসহ লিখে রাখুন, তারপর নিচের চারটি পরীক্ষা ক্রমানুসারে করুন।

প্রশ্নটি কোন অ্যাডাপ্টারের রিজলভারে যায়

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

বাইন্ডিং ক্রম কেবল প্রথমার্ধ। ক্লায়েন্টকে আরও জানতে হয় কোন নামগুলো ওই অ্যাডাপ্টারের, আর সেটি ক্রমের প্রশ্ন নয়, সাফিক্সের প্রশ্ন।

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

ছোট নামের রুটের আগে সাফিক্স দরকার

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

কাজ করা মেশিনের সাফিক্সটি DNS ট্যাবে VPN অ্যাডাপ্টারের IPv4 বৈশিষ্ট্যে কপি করুন, তারপর আবার সংযোগ দিন। Linux-এ সমতুল্য হলো টানেল লিংকের সার্চ ডোমেইন, যা systemd-resolved বিশ্বব্যাপী নয়, প্রতি লিংকে দেখায়।

নোটে দুটি সেটিং আলাদা রাখুন। সাফিক্স বদলায় কী জিজ্ঞাসা করা হচ্ছে; রিজলভার ঠিকানা বদলায় কাকে জিজ্ঞাসা করা হচ্ছে। একটি ঠিক করে অন্যটি ভুল রাখলে ফলাফল এলোমেলো দেখায়।

আগে রিজলভারকে জিজ্ঞাসা করুন, তারপর নামকে

অফিস রিজলভারে সরাসরি কোয়েরি নামের সমস্যাকে পথের সমস্যা থেকে আলাদা করে, কারণ এটি ক্লায়েন্টের রিজলভার নির্বাচনকে সম্পূর্ণ এড়িয়ে যায়।

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

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

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

Linux-এ যে VPN ক্লায়েন্ট /etc/resolv.conf পুনর্লিখন করে, সে স্থানীয় রিজলভারগুলোকে সম্পূর্ণ প্রতিস্থাপন করে। vpnc তা থামাতে DNSUpdate no প্রকাশ করে, আর systemd-resolved কেবল তালিকাভুক্ত ডোমেইনগুলো টানেল লিংকে পাঠাতে পারে। দুই পদ্ধতিই পাবলিক নাম স্থানীয় রিজলভারে রাখে আর অভ্যন্তরীণ নাম অফিসে পাঠায়।

লিক একটি নিয়ম, চেকবক্স নয়

নাম সমাধান হলো পোর্ট 53-এ একটি UDP বিনিময়, তাই যে টানেল ওয়েব ট্রাফিক বহন করে কিন্তু UDP নয়, সে কোয়েরিটিকে ফিজিক্যাল পথে রেখে দেয়। পাবলিক নাম সমাধান হওয়ার সময় ফিজিক্যাল নেটওয়ার্ক কার্ডে ক্যাপচার করে এটি প্রমাণ করুন। ওই ইন্টারফেসে পাঠযোগ্য রূপে কোয়েরি দেখা গেলে বোঝায় টানেল সেটি বহন করছে না।

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

কোয়েরিটি ওই ইন্টারফেসে পাঠযোগ্য রূপে দেখা গেলে টানেল সেটি বহন করছে না। সমাধান হলো এমন নিয়ম যা কেবল VPN যে রিজলভার পুশ করেছে তার কাছে পোর্ট 53 অনুমোদন করে আর অন্য গন্তব্য ফেলে দেয়, সঙ্গে এমন ক্লায়েন্ট কনফিগারেশন যা পুশ করা অপশনটি নিঃশব্দে ফেলে না।

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

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