VPN সংযোগ হওয়ার পরেই DNS64 উত্তরেরা কেন বদলে যায়?

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

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

একটি সংশ্লেষিত AAAA রেকর্ড আসলে কী নির্দেশ করে

DNS64 রিজলভার কেবল IPv4-যুক্ত একটি নামের AAAA প্রশ্নের উত্তর দেয় IPv4 ঠিকানাটি এমন একটি উপসর্গের ভিতরে এম্বেড করে যা ব্যবহার করার জন্যে এটি কনফিগার করা হয়েছে, আর এই কাজের সুপরিচিত উপসর্গটি হল 64:ff9b::/96 যেমনটি RFC 6147 নথিতে বর্ণিত। অ্যাপ্লিকেশনটির কাছে রেকর্ডটি অন্য যেকোনো AAAA রেকর্ডের মতোই দেখায়, আর এটাই মূল কথা: কেবল IPv6-যুক্ত একটি ক্লায়েন্ট গন্তব্যটির কখনো IPv6 ছিল না জেনেও সংযোগের চেষ্টা করতে পারে। এরপর সেই সংযোগটি পথের কোথাও দুটি পরিবারের মধ্যে অনুবাদ করা একটি NAT64 ফাংশনের উপর নির্ভর করে। সেই অনুবাদক ছাড়া সংশ্লেষিত ঠিকানাটি একটি বিশ্বাসযোগ্য দেখতে গন্তব্য, যা কোথাও পৌঁছায় না।

তাই রেকর্ডটি একসঙ্গে দুটি জিনিস সংকেত করে: মূল IPv4 ঠিকানা এবং অনুবাদক পৌঁছানোযোগ্য এই অনুমান। কেবল প্রথমটিই উত্তরটির ভিতরেই দৃশ্যমান।

তিনটি শর্ত ঠিক করে এটি এখনো কাজ করে কি না

প্রথম শর্তটি হল কোন রিজলভার রেকর্ডটি তৈরি করেছে, কারণ DNS64 কনফিগার না থাকা রিজলভার সেই নামের জন্য কিছুই ফেরায় না এবং অ্যাপ্লিকেশনটি ভিন্নভাবে ব্যর্থ হয়। দ্বিতীয়টি হল আপনার ডিভাইসের সংশ্লেষিত উপসর্গে রুট আছে কি না, কারণ উত্তরটি বৈধ হতে পারে অথচ তার পথ অনুপস্থিত। তৃতীয়টি হল সেই উপসর্গের মালিক অনুবাদকটি আপনার ব্যবহারযোগ্য পথে আছে কি না, কারণ 64:ff9b::/96 অন্যত্র বহন করা একটি টানেল ভিন্ন ফাংশনে পৌঁছায় বা কিছুতেই পৌঁছায় না। তিনটিই টানেলের আগে সত্য থাকতে পারে এবং পরে ব্যর্থ হতে পারে, আর এ কারণেই উপসর্গটি হঠাৎ পতনের মতো দেখায়।

সেই ক্রমেই এগুলি যাচাই করুন। অনুপস্থিত উত্তর আর অনুপস্থিত রুট ব্রাউজারে একই রকম দেখায় আর রিজলভার লগে সম্পূর্ণ আলাদা।

রিজলভার বদলালে উত্তরও বদলায়

একটি VPN ক্লায়েন্ট প্রায়ই নিজের রিজলভার চালু করে বা পুরো প্রশ্নের পথটি নিজের হাতে নেয়, আর সেই রিজলভার হয়তো কিছুই সংশ্লেষ করে না। তখন কেবল IPv4-যুক্ত নামের প্রশ্নে কোনো AAAA রেকর্ড ফেরে না, যা কেবল IPv6-যুক্ত ক্লায়েন্ট এমন একটি নাম হিসেবে ভোগ করে যেখানে পৌঁছানো যায় না। উল্টোটাও ঘটে: যে রিজলভার সত্যিই সংশ্লেষ করে সে আপনাকে এমন উপসর্গ দিতে পারে যা আপনার টানেলযুক্ত পথ বহন করে না।

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

অনুসন্ধান ও পথ আলাদাভাবে পরীক্ষা করুন

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

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

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

প্রতিটি ফলাফলের পাশে রিজলভার, নেটওয়ার্ক প্রসঙ্গ ও ঠিকানা-পরিবার লিখে রাখুন। এই টীকাটিই পরের তুলনায় রিজলভার পরিবর্তনকে রাউটিং পরিবর্তন থেকে আলাদা করতে দেয়।