হোম VPN সার্ভারের জন্য কি ডায়নামিক DNS দরকার?

লোকেরা আমাকে যে হোম VPN ব্যর্থতার কথা জিজ্ঞেস করে, তার বেশিরভাগই DNS ব্যর্থতা নয়, তবু তারা আগে ডায়নামিক DNS সাবস্ক্রিপশন কেনে। কিছু কনফিগার করার আগে ঠিক করুন হোস্টনেমটাই আসলে ভাঙা অংশ কি না। আপডেটার একটি রেকর্ড নতুন করে লেখে যখন আপনার ISP যে ঠিকানা দিয়েছে তা বদলে যায়; এটি পোর্ট খুলতে পারে না, ক্যারিয়ার NAT ভেদ করতে পারে না, বা চালু WireGuard সেশনকে তার এন্ডপয়েন্ট বদলেছে বুঝতে বাধ্য করতে পারে না। তিনটি শর্ত ঠিক করে ডায়নামিক DNS পুরো সমাধান, নাকি তার এক লাইন মাত্র।

শর্ত এক: আপনার ঠিকানা সত্যিই বদলায়

আবাসিক ঠিকানা সাধারণ কারণেই বদলায়: বিদ্যুৎ চলে যাওয়ার পর মডেম আবার সিঙ্ক হয়, ISP পুল পুনর্বিন্যাস করে, দীর্ঘ বিভ্রাটের পর নতুন লিজ আসে। কিছু লাইনে এগুলো খুব কমই বদলায়, আর আমি একই ঠিকানা এক বছর টিকে থাকতে দেখেছি; ব্যবসায়িক প্ল্যানে প্রায়ই স্থির ঠিকানা থাকে। বারো মাসে কিছু না বদলালে, হাতে সম্পাদনা করা একটি A রেকর্ড মানে একটি কম ডেমন জীবিত রাখতে হবে।

অনুমান না করে মাপুন। রাউটারের স্ট্যাটাস পেজে WAN ঠিকানা পড়ুন, তারপর বাইরের পৃথিবী যা দেখে তার সঙ্গে মিলিয়ে দেখুন। LAN-এর একটি মেশিন থেকে এটি চালান:

curl -fsS https://api.ipify.org; echo

দুটি মান আলাদা হলে, আপনার রাউটারের সামনে কিছু একটা অনুবাদ করছে, আর কোনো হোস্টনেম আপডেট তা সারাবে না। 100.64.0.0/10-এর ভেতরের ঠিকানা হলো ক্যারিয়ার-গ্রেড NAT-এর ভাগ করা রেঞ্জ, আর সঠিকভাবে আপডেট হওয়া নামও বাইরে থেকে টাইম আউট হওয়ার সাধারণ কারণ এটিই।

শর্ত দুই: ক্লায়েন্টরা নামটি আবার খোঁজে

ছোট TTL-ই সেই অংশ যা মানুষ এড়িয়ে যায়। রিকার্সিভ রিজলভার রেকর্ডের TTL মানে, কিন্তু ক্লায়েন্ট স্ট্যাক আলাদাভাবে ক্যাশ করে, আর ইতিমধ্যে চালু টানেল কিছুই নতুন করে রিজলভ করে না। ডিবাগ করার সময় রেকর্ডটি 60-300 সেকেন্ডে রাখুন; এটি পুরনো উত্তর দেওয়ার জানালা ছোট করে, এবং সংযুক্ত সেশন মাইগ্রেট করে না।

OpenVPN প্রতিবার পুনঃসংযোগে লাইনটি remote vpn.example.net 1194 নতুন করে রিজলভ করে, এবং resolv-retry infinite তাকে আবার চেষ্টা করতে থাকে, লুকআপ ব্যর্থ হলে বেরিয়ে না গিয়ে। সার্ভারে float প্রতিষ্ঠিত সেশনকে এমন পিয়ারের অনুসরণ করতে দেয় যার উৎস ঠিকানা বদলেছে। WireGuard আরও সরাসরি: wg-quick up কনফিগারেশন প্রয়োগের সময় Endpoint রিজলভ করে, আর ক্লায়েন্ট টানেল পুনর্নির্মাণের সময় আবার রিজলভ করে, তাই পুরনো ঠিকানার বিরুদ্ধে যে হ্যান্ডশেক এখনও সফল হয়, তা থামা পর্যন্ত সফল থাকতে থাকে।

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

শর্ত তিন: ভেতরে ঢোকার পথ এখনও খোলা

ডায়নামিক DNS শুধু বদলায় নামটি কোথায় দেখাবে, আর কিছুই না। রাউটারের পোর্ট ফরওয়ার্ড, VPN হোস্টের ফায়ারওয়াল নিয়ম, আর ISP-র ইনবাউন্ড প্যাকেট অনুমোদন—সবই রেকর্ডটি গুরুত্বপূর্ণ হওয়ার আগে থাকতে হবে। ফরওয়ার্ড কোথায় লক্ষ্য করে দেখুন: এটি ইন্টারফেসের বদলে WAN ঠিকানায় পিন করা থাকলে, ঠিকানা বদল নিঃশব্দে ফরওয়ার্ড ভাঙে আর দোষ রেকর্ডের ওপর পড়ে।

বাইরে থেকে পরীক্ষা করুন। Wi-Fi বন্ধ রেখে সেলুলার ডেটায় ফোন সবচেয়ে সস্তা সৎ পরীক্ষা; একই LAN-এর ল্যাপটপ নয়। নামটি যখন আপনার পাবলিক ঠিকানায় রিজলভ করে আর রাউটারে NAT লুপব্যাক নেই, তখন ভেতরের পরীক্ষা ব্যর্থ হয় যদিও রেকর্ড পুরোপুরি সঠিক, আর এটিই বেশিরভাগ মানুষকে কখনও ভুল না হওয়া রেকর্ড সম্পাদনা করতে পাঠায়।

তিনটিই মিললে কী চালাবেন

ছোট হোস্টের জন্য ddclient সবচেয়ে কম অবাক করা আপডেটার। ন্যূনতম কনফিগারেশন প্রোভাইডার যে ঠিকানা দেখে তা প্রকাশ করে, যা ডাবল-NAT ভুল এড়ায়:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

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

প্রতিশ্রুত হওয়ার আগে যাচাই করুন

একটি লুকআপই বলে দেয় বাকি পৃথিবী কী দেখে, আর ছাপে সেই TTL যা বদলের পর অপেক্ষা করতে হবে:

dig +noall +answer vpn.example.net @1.1.1.1

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

এক মিনিটের রোলব্যাক রাখুন: শেষ কার্যকর ঠিকানা আর আগের TTL টুকে রাখুন, যাতে প্রোভাইডারের খারাপ দুপুরে দুটোই হাতে প্রকাশ করতে পারেন।

যখন উত্তর না

শর্ত এক বা তিন ব্যর্থ হলে কনফিগারেশন নয়, সিদ্ধান্ত বদলায়। ক্যারিয়ার NAT-এর পেছনে আপনার বাস্তব বিকল্প হলো ISP-র কাছে পাবলিক ঠিকানা চাওয়া, স্থির ঠিকানার ছোট VPS-এ এন্ট্রি পয়েন্ট সরানো, বা নিজের সাক্ষাৎ রাখে এমন ওভারলে ব্যবহার করা। ঠিকানা স্থির হলে আপডেটার বাদ দিন: একটি A রেকর্ড, IPv6 চালালে একটি AAAA রেকর্ড, একই পোর্ট ফরওয়ার্ড।

ক্লায়েন্ট সংযুক্ত থাকা অবস্থায় ঠিকানা বদলালে সৎ সমাধান ক্লায়েন্টেই থাকে: পুনঃসংযোগ লজিক আর পুনঃচেষ্টার বিরতি, দ্রুততর আপডেটার নয়। দ্বিতীয় প্রোভাইডার যোগ করলে শুধু বিরতিটি ঢাকা পড়ে।

এগিয়ে যাওয়ার আগে ক্রমে চারটি বিষয় নিশ্চিত করুন:

• আপডেটার যে ঠিকানা প্রকাশ করে তা রাউটারের WAN ঠিকানার সঙ্গে মেলে।
• রেকর্ডের TTL এত ছোট যে বদল কয়েক মিনিটেই দেখা যায়।
• পোর্ট ফরওয়ার্ড স্থির ঠিকানায় নয়, ইন্টারফেসে বাঁধা।
• শেষ বদলের পর একটি বাস্তব ক্লায়েন্ট পুনঃসংযুক্ত হয়েছে এবং ট্রাফিক গেছে।

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