কেন DHCP রিজার্ভেশন আপনার VPN সার্ভারের জন্য স্থির IP নয়

আমি একটি হোম VPN বক্স Wi-Fi থেকে Ethernet-এ সরালাম, আর তার “স্থায়ী” ঠিকানা সেই সন্ধ্যাতেই বদলে গেল। রাউটারে কিছুই নষ্ট ছিল না। রিজার্ভেশনটি ওয়্যারলেস অ্যাডাপ্টারের সঙ্গে মিলছিল, আর সেই অ্যাডাপ্টার আর পথে ছিল না।

একই ভুল ধারণার আরেকটি অর্ধেক আছে। LAN ঠিকানা ঠিক করলে আপনার বন্ধুরা যে ঠিকানায় সংযোগ করে তাতে কিছুই হয় না, আর VPN ক্লায়েন্টদের যে প্রাইভেট পুল দেয় তার সঙ্গে এর কোনো সম্পর্ক নেই। তিনটি ঠিকানা, তিনটি আলাদা ব্যর্থতার ধরন, আর তাদের একটিই রিজার্ভেশনের কাজ।

রিজার্ভেশন ক্লায়েন্টের সঙ্গে মেলে, ডিভাইসের সঙ্গে নয়

DHCPv4-এ রিজার্ভেশন ক্লায়েন্টের হার্ডওয়্যার ঠিকানার উপর নির্ভর করে; DHCPv6-এ তা নির্ভর করে একটি DUID-এর উপর যা ক্লায়েন্টের রাখার কথা। হোস্টনেম ফিল্ডটি মানুষের জন্য একটি লেবেল। রাউটার আসলে অনুরোধে যে শনাক্তকারী আসে তার সঙ্গে তুলনা করে।

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

OpenWrt রূপটি পরিষ্কারভাবে দেখায়। /etc/config/dhcp-এ একটি config host ব্লক একটি নাম, একটি MAC এবং একটি ঠিকানা একসঙ্গে বাঁধে, এবং স্থির লিজের ডকুমেন্টেশন ব্যাখ্যা করে যে এন্ট্রিটি পুলের সঙ্গে কীভাবে কাজ করে। অন্য রাউটারগুলো একই তিনটি ফিল্ড ভিন্ন লেবেলের আড়ালে লুকায়।

যেখানে মিলটি নিঃশব্দে ভেঙে যায়

হার্ডওয়্যার বদলানো সাধারণ ঘটনা। NIC বদলান, বা মেশিনটি Ethernet ও Wi-Fi-এর মধ্যে সরান, আর রাউটার যে ঠিকানা দেখে সেটিও তার সঙ্গে বদলায়। পুরোনো রিজার্ভেশন তালিকায় থেকে যায়, এখনো সঠিক দেখাতে থাকে।

পুনঃইনস্টল দ্বিতীয় ঘটনা, এবং এটি IPv6-এ সবচেয়ে বেশি আঘাত করে। নতুন ইনস্টল একটি নতুন DUID তৈরি করতে পারে যখন পুরোনো IPv4 লিজ এখনো বৈধ, তাই v4 ঠিকানাটি কিছু সময় টিকে থাকে আর v6 এন্ট্রিটি কোনো দৃশ্যমান সম্পাদনা ছাড়াই প্রযোজ্য হওয়া বন্ধ করে।

তৃতীয়টি হলো পিন করা ক্লায়েন্ট শনাক্তকারী। বেশ কিছু DHCP ক্লায়েন্ট MAC ব্যবহারের বদলে একটি শনাক্তকারী স্ট্রিং সেট করতে দেয়। কোনো আপগ্রেড বা কনফিগ পুনর্লিখন সেই সেটিংটি ফেলে দিলে মিলটি হারিয়ে যায়, যদিও মেশিনটি সরেনি।

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

হোস্টের পাশের কনফিগারেশন এবং তার মূল্য

হোস্টেই ঠিকানা সেট করলে মেলানোর প্রশ্নটি সম্পূর্ণ মুছে যায়। DHCP উত্তর দিক বা না দিক, ইন্টারফেসটি সেই ঠিকানা নিয়েই উঠে, আর রাউটার রিবুটের পরেও পৌঁছানো যায় এমন মেশিন থেকে আপনি এটাই চান।

মূল্য হলো মালিকানা। এখন উপসর্গ, গেটওয়ে আর রিজলভার আপনাকেই দিতে হবে, আর ঠিকানাটি ডাইনামিক পুলের বাইরে আপনাকেই রাখতে হবে। netplan সহ Ubuntu-তে এটি বহন করে /etc/netplan/01-vpn.yaml:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

NetworkManager ব্যবহারকারীরা nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1 দিয়ে, তারপর nmcli con up "Wired connection 1" দিয়ে একই অবস্থায় পৌঁছান। প্রথম চেষ্টাতেই netplan apply-এর বদলে netplan try দিয়ে netplan প্রয়োগ করুন; ভুল লেখা গেটওয়ে বক্সটিকে নেটওয়ার্ক থেকে নামিয়ে দেয় এবং আপনাকে কনসোল খুঁজতে ছেড়ে দেয়।

তবুও একটি মিলে যাওয়া রিজার্ভেশন রাখুন। এটি বাড়তি নয়। এন্ট্রিটি রাউটারের পাশে ঠিকানাটি লিখে রাখে এবং কেউ পরে পুল বাড়ালে DHCP সার্ভারকে সেই ঠিকানা কোনো অতিথি ডিভাইসকে দিতে বাধা দেয়।

স্থির LAN ঠিকানা কোনো পাবলিক এন্ডপয়েন্ট নয়

পোর্ট ফরওয়ার্ডটি 192.168.50.10-এর দিকে করুন এবং নিয়মটি LAN-এর পাশের প্রতিটি পরিবর্তনেও টিকে থাকে। এটি আপনাকে স্থির ইন্টারনেট ঠিকানা দেয় না। আপনার পাবলিক IP আইএসপির এবং পুনঃসংযোগ বা মডেম বদলে সরে যেতে পারে, ডাইনামিক DNS ঠিক এজন্য।

ক্যারিয়ার-গ্রেড NAT-এর পিছনে ফরওয়ার্ড করার মতো কোনো পাবলিক IPv4-ই নেই, আর কোনো রিজার্ভেশন তা তৈরি করে না। সবার আগে রাউটারের WAN পৃষ্ঠাটি দেখুন: ঠিকানাটি যদি শেয়ার করা রেঞ্জে থাকে, রিজার্ভেশন যতই পরিষ্কার হোক, ইনবাউন্ড ফরওয়ার্ডিং কাজ করতে পারে না।

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

যে ক্রমে ভাঙে সেই ক্রমে পথটি দেখুন

রাউটার দিয়ে শুরু করুন। লিজ টেবিলের এন্ট্রিটি রিজার্ভেশনের লক্ষ্যের সঙ্গে মিলিয়ে দেখুন; সার্ভার যদি পুল ঠিকানা নিয়ে থাকে, শনাক্তকারীটি ভুল, আর হোস্টে ip link show আপনাকে তুলনার মান দেয়।

তারপর হোস্ট। ip -4 addr show eth0 প্রত্যাশিত ঠিকানা ও উপসর্গ দেখানো উচিত। একই ইন্টারফেসে দ্বিতীয় ঠিকানা সাধারণত বোঝায় DHCP এখনো আপনার স্থির কনফিগারেশনের পাশে চলছে।

তারপর ফরওয়ার্ড। গন্তব্যটি এখনো আপনি এইমাত্র যাচাই করা ঠিকানার সমান কিনা নিশ্চিত করুন, আর ss -lntp দিয়ে কিছু শুনছে কিনা নিশ্চিত করুন। বন্ধ পোর্টে নির্দেশিত ফরওয়ার্ড বাইরে থেকে হুবহু ভাঙা ফরওয়ার্ডের মতো দেখায়।

বাইরে থেকে শেষ করুন, Wi-Fi বন্ধ থাকা একটি ফোনে। এই একটি পরীক্ষাই “স্থানীয় ঠিকানাটি ভুল” আর “পাবলিক পৌঁছানো ভাঙা”-এর মধ্যে পার্থক্য করে, এই সেটআপ যে দুটি সমস্যা বারবার গুলিয়ে ফেলে।

তিনটি ঠিকানা লিখে রাখুন — LAN, পাবলিক আর টানেল পুল — এবং কোন সিস্টেম কোনটি মালিক তা টুকে রাখুন। আগামী মাসে কোনো সংযোগ ব্যর্থ হলে একসঙ্গে তিনটিই বদলানোর বদলে কোনটি দেখতে হবে তা আপনি জানবেন।