AWS Client VPN DNS: সাবনেট নয়, VPC রিজলভার ব্যবহার করুন

এন্ডপয়েন্টটি 10.0.8.0/24-এ আছে, তাই রিজলভার হতে হবে 10.0.8.2। এই যুক্তিটাই আমি সবচেয়ে বেশি শুনি, আর এটি দুইবার ভুল। Route 53 Resolver প্রাইমারি VPC IPv4 রেঞ্জ প্লাস দুই-তে উত্তর দেয়, যা 10.0.0.0/16 VPC-এর জন্য 10.0.0.2, এন্ডপয়েন্ট কোন সাবনেট ব্যবহার করুক না কেন। দ্বিতীয় ভুলটি আরও নীরব: এন্ডপয়েন্টে সঠিক ঠিকানা বসানো মানে এই নয় যে ক্লায়েন্টের অপারেটিং সিস্টেম কখনো এটিকে কিছু জিজ্ঞেস করে। দুটি ভুলই একই লক্ষণ দেয়: কিছু ক্লায়েন্টে নাম রেজলিউশন কাজ করে, অন্যদের ক্ষেত্রে ব্যর্থ হয়।

ভ্রান্ত ধারণা শুরু হয় সাবনেট অ্যাসোসিয়েশন থেকে

অ্যাসোসিয়েশন হলো ক্লায়েন্ট সংযোগের জন্য ইলাস্টিক নেটওয়ার্ক ইন্টারফেসগুলো কোথায় থাকে তা নিয়ে, কোন রিজলভার ঠিকানা আছে তা নিয়ে নয়। এন্ডপয়েন্টের সাবনেটগুলো ক্লায়েন্টকে VPC-এর ভেতরে একটি ঠিকানা দেয়, এবং তাদের প্রত্যেকে নিজস্ব রিজলভার বহন করে না।

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

প্রাইমারি VPC রেঞ্জ থেকে ঠিকানা হিসাব করুন

VPC-এর প্রাইমারি IPv4 CIDR নিন এবং নেটওয়ার্ক ঠিকানার সাথে দুই যোগ করুন। 10.0.0.0/16 দেয় 10.0.0.2, 172.31.0.0/16 দেয় 172.31.0.2, এবং সেকেন্ডারি রেঞ্জযুক্ত VPC রিজলভারকে প্রাইমারি রেঞ্জেই রাখে। ওই VPC-এর ভেতরের 10.0.8.0/24 সাবনেট এটি সরায় না। এন্ডপয়েন্ট স্পর্শ করার আগে VPC ID-এর পাশে ঠিকানাটি লিখে রাখুন, কারণ সংখ্যাটি VPC-এর বৈশিষ্ট্য, সংযোগের নয়।

VPC লিংক-লোকাল ঠিকানা 169.254.169.253-এও উত্তর দেয়। এই ঠিকানাটি VPC-এর ভেতর থেকে পৌঁছানো যায়, কিন্তু টানেলের অপর প্রান্তের ল্যাপটপের জন্য এটি সাধারণ রাউটেড গন্তব্য নয়।

তাই দুটি বৈধ রিজলভার ঠিকানা আছে, এবং কোনোটিই সাবনেট প্লাস দুই নয়।

এন্ডপয়েন্ট সেটিং কী করে আর কী করে না

Client VPN এন্ডপয়েন্টে DNS সার্ভার ফিল্ড আছে, আর যেখানে কনসোল VPC রিজলভার অপশন দেয় সেখানে একই ধারণা পূরণ করে। এগুলো সেট করলে সংযোগ স্থাপনের সময় সার্ভিস ক্লায়েন্টকে যা দেয় তা বদলায়। এটি কোনো আনম্যানেজড OpenVPN ক্লায়েন্ট ওই মান দিয়ে কী করে তা বদলায় না, কারণ ক্লায়েন্টকে এখনো সেটি অপারেটিং সিস্টেমে প্রয়োগ করতে হয়। এই ফাঁক থেকেই «আমার Mac-এ কাজ করে কিন্তু Linux বক্সে করে না» আসে।

Linux-এ রিজলভার ইন্টিগ্রেশন কানেকশন ম্যানেজারের মালিকানাধীন, ব্যবহারকারীর নয়। /etc/resolv.conf হাতে সম্পাদনা করলে প্রমাণ হয় ঠিকানাটি এক সেশনের জন্য কাজ করে, তারপর পুনঃসংযোগে হারিয়ে যায় — তাই অনেক ঠিক করা কেস পরদিন সকালে ফিরে আসে।

সংযোগের পর ক্লায়েন্টে সক্রিয় রিজলভার দেখুন, এন্ডপয়েন্টের কনফিগারেশন পাতা নয়।

স্প্লিট টানেলিং সঠিক রিজলভারকেও হারাতে পারে

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

ওভারল্যাপিং লোকাল রেঞ্জ একই ফলাফল আরও খারাপভাবে দেয়: কোয়েরির উত্তর আসে, শুধু ভুল সার্ভার থেকে।

Amazon DNS ঠিকানার জন্য সিকিউরিটি গ্রুপ খুলবেন না

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

আপনার ডিজাইনে দুটোই থাকলে কোনো নিয়ম সম্পাদনার আগে দেখুন ক্লায়েন্ট আসলে কোনটির দিকে নির্দেশিত।

পথ যাচাই করুন, তারপর অন্য কিছু মাপুন

একটি পাবলিক নাম রিজলভ করুন, VPC-এর সাথে অ্যাসোসিয়েটেড প্রাইভেট হোস্টেড জোনে নিবন্ধিত একটি প্রাইভেট নাম রিজলভ করুন, এবং দুটির মাঝে ক্লায়েন্টের সক্রিয় রিজলভার পড়ুন। এই ক্রমটি «রিজলভার ঠিকানা ভুল» থেকে «জোন অ্যাসোসিয়েটেড নয়» থেকে «ক্লায়েন্ট সেটিং উপেক্ষা করেছে» আলাদা করে। প্রতিটির আলাদা সমাধান, আর কোনোটিই থ্রুপুট সমস্যা নয়।

সফল লুকআপ ধারাবাহিক ট্রান্সফার গতির সম্পর্কে কিছুই বলে না, তাই রিপোর্ট করার সময় এই দুটি আলোচনা আলাদা রাখুন।