ডুয়াল-স্ট্যাক VPN: অ্যাড্রেস ফ্যামিলি বেছে নেয় ক্লায়েন্ট, আপনি নন

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

নির্বাচন কভারেজের প্রতিশ্রুতি নয়

RFC 6724-এ বর্ণিত ডিফল্ট অ্যাড্রেস সিলেকশন ঠিক করে, একাধিক বিকল্প থাকলে হোস্ট কোন সোর্স-গন্তব্য জোড়াকে প্রাধান্য দেবে। Happy Eyeballs তার ওপরে একটি সংযোগ-কৌশল যোগ করে: এটি দুই ফ্যামিলিতেই চেষ্টা শুরু করে এবং যেটি আগে উত্তর দেয় সেটিই রাখে, ফলে ব্যবহারকারী নষ্ট ফ্যামিলির টাইমআউট পর্যন্ত অপেক্ষা করেন না।

কোনো মেকানিজমই রুট তৈরি করে না। আপনার টানেল যদি কেবল IPv4 বহন করে, AAAA প্রার্থী তবুও একটি বৈধ গন্তব্য, যা ক্লায়েন্ট চেষ্টা করতে পারে; আর ব্যর্থতা ত্রুটি হিসেবে নয়, ধীর লোড হিসেবে দেখা যায়, কারণ ব্রাউজার ফলব্যাক করেছে। ব্যবহারকারী নষ্ট সাইট নয়, ধীর সাইটের কথা জানান, এবং সাপোর্ট টিকিট সেই অস্পষ্টতা উত্তরাধিকারসূত্রে পায়। নির্দিষ্ট ফ্যামিলি দিয়ে এটি পুনরুৎপাদন করুন, প্রতিবেদনটি সুনির্দিষ্ট হয়ে যাবে।

এই ফলব্যাকের কারণেই উপসর্গটি অ্যাপ্লিকেশনভেদে অসঙ্গত। ব্রাউজার বিলম্ব লুকায়; নির্দিষ্ট ফ্যামিলিযুক্ত কমান্ড-লাইন ক্লায়েন্ট আসল ব্যর্থতা তখনই দেখায়।

অনুরোধটি প্রকৃতপক্ষে কোন ফ্যামিলি ব্যবহার করেছে তা খুঁজুন

টানেল দিয়ে নয়, নাম দিয়ে শুরু করুন। দুই ধরনের রেকর্ডই জিজ্ঞাসা করুন এবং কী ফিরে এলো তা লিখে রাখুন:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

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

ফ্যামিলি ও গন্তব্য আপনার নোটে রাখুন। যে টিকিট বলে সাইটটি VPN-এ লোড হয় না, তা কেউ যাচাই করতে পারে না; আর যে টিকিট বলে AAAA ব্যর্থ হয় ও A কাজ করে, তা নির্দিষ্ট একটি রুটের দিকে ইশারা করে।

সেই ফ্যামিলির জন্য রুট পরীক্ষা করুন

ব্যর্থ ফ্যামিলির জন্য কার্নেলকে জিজ্ঞাসা করুন কোন পথ ব্যবহার করবে, এবং তা টানেলের কনফিগার করা অ্যাড্রেসের সঙ্গে মিলিয়ে দেখুন। Linux-এ ip -6 route get গন্তব্যের জন্য যে ইন্টারফেস ও সোর্স বেছে নেওয়া হবে তা দেখায়।

তারপর টানেল নিজেই পরীক্ষা করুন। WireGuard পিয়াররা অনুমোদিত IP-র তালিকা বহন করে, আর 0.0.0.0/0-এর একটি এন্ট্রি IPv6 সম্পর্কে কিছুই বলে না। পিয়ারের তালিকায় IPv6 প্রিফিক্স না থাকলে, AAAA ট্রাফিক টানেলে পাঠানোর কোনো কারণ ক্লায়েন্টের নেই, এবং প্যাকেটটি হোস্ট অন্যথায় যা করত তা দিয়েই বেরিয়ে যায়।

ফায়ারওয়াল নিয়ম ও NAT নীতি প্রতিটি ফ্যামিলির জন্য একই পরীক্ষার দাবিদার। IPv4-এর জন্য লেখা নিয়ম কোনো প্ল্যাটফর্মেই IPv6 কভার করে না, এবং একটি ফ্যামিলি কাজ করা অথচ অন্যটি না করার এটি-ই সবচেয়ে সাধারণ কারণ।

স্ক্রিনশট সহজ করতে IPv6 বন্ধ করবেন না

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

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

টিকিটে কী লিখবেন

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

RFC 6724 অ্যাড্রেস সিলেকশন নিয়মাবলি ব্যাখ্যা করে কেন ক্লায়েন্ট যে প্রার্থীকে প্রাধান্য দিয়েছে তাকেই দিয়েছে, আর RFC 8305 ব্যাখ্যা করে সেই প্রতিযোগিতামূলক আচরণ, যা বিলম্ব লুকিয়েছিল। এদের কোনোটিই আপনার হয়ে প্যাকেট রুট করবে না, আর টানেলকে ঠিক সেই কাজটিই করতে হয়।