আপনার VPN পুল LAN-এর DHCP রেঞ্জ নয়: কেন এটি ভেঙে পড়ে

প্রলোভনজনক শর্টকাট হলো অফিসের DHCP সার্ভার যে রেঞ্জ ব্যবহার করে, ঠিক সেই রেঞ্জ থেকেই VPN ক্লায়েন্টদের ঠিকানা দেওয়া, এই ধারণায় যে সবকিছু যেকোনোভাবেই একটি নেটওয়ার্ক। কিন্তু তা নয়। একটি রাউটেড টানেল দুই প্রান্তের মধ্যে unicast প্যাকেট বহন করে, অন্যদিকে LAN পুল বিদ্যমান থাকে ভৌত সেগমেন্টে broadcast অনুরোধের উত্তর দেওয়ার জন্য। একই নম্বর পুনরায় ব্যবহার করলে দুইটি বরাদ্দকারী একই ঠিকানা-ক্ষেত্রের দায়িত্বে চলে আসে এবং রিটার্ন পাথ অনির্ধারিত থেকে যায়।

দুই বরাদ্দকারী, এক ঠিকানা-ক্ষেত্র

LAN DHCP সার্ভার জানে সে কোন ঠিকানাগুলো লিজ দিয়েছে এবং কোন MAC ঠিকানায়, এবং ARP দিয়ে সেগুলো রক্ষা করে। VPN সার্ভারের নিজের পুল আছে এবং সেই লিজগুলোর কোনো জ্ঞান নেই। কোনোটিই ভুল নয়; তাদের কেবল পরস্পরের সঙ্গে পরিচয় করানো হয়নি।

VPN সার্ভার যে LAN পুল থেকে ঠিকানা দেয়, তা ইতিমধ্যেই কোনো প্রিন্টারের হতে পারে। এখন দুইটি ডিভাইস একই প্রিফিক্সে একটি ঠিকানার দাবি করে, এবং সুইচের ফরওয়ার্ডিং টেবিল নির্ধারণ করে কোনটি উত্তর দেবে।

এই ব্যর্থতারই মুখোমুখি মানুষ প্রথমে পড়ে: এমন ক্লায়েন্ট যা সফলভাবে সংযুক্ত হয় এবং পরে ভুল মেশিনে পৌঁছায়, অথবা থেমে থেমে সঠিকটিতে পৌঁছায়।

কেন রাউটার VPN ঠিকানা বিতরণ করে না

DHCP ডিসকভারি একটি broadcast, এবং broadcast রাউটেড সীমানায় থেমে যায়। যদি নকশাটি টানেলটি ব্রিজ না করে বা সামঞ্জস্যপূর্ণ কর্তৃত্বসহ DHCP রিলে না চালায়, তবে ক্লায়েন্টের অনুরোধ কখনোই LAN সার্ভারে পৌঁছায় না।

তাই VPN সার্ভার নিজেই ঠিকানাটি নির্ধারণ করে: সার্ভার কনফিগারেশনে একটি পুল, WireGuard সেটআপে প্রতি পিয়ারের জন্য একটি ঠিকানা, অথবা IKEv2 স্থাপনায় প্রমাণীকরণ স্তর যে ঠিকানা ঠেলে দেয়। এই প্রক্রিয়াগুলো LAN লিজ ডেটাবেসের থেকে স্বাধীন, আর ঠিক সেই কারণেই তাদের নিজস্ব রেঞ্জ দরকার।

একই যুক্তি ব্যাখ্যা করে কেন DHCP স্কোপ বদলালে এমন VPN ক্লায়েন্ট ঠিক হয় না যে কখনো ঠিকানা পায় না। ক্লায়েন্ট LAN সার্ভারকে জিজ্ঞাসা করছে না, এবং স্কোপ সম্পাদনার কোনো পরিমাণই তাকে জিজ্ঞাসা করাতে পারে না।

ওভারল্যাপ ধীর নেটওয়ার্ক নয়, দ্বন্দ্ব হিসেবে দেখা দেয়

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

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

রিটার্ন পাথ আলাদা সমস্যা

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

কিছু বদলানোর আগে পথটি দুই দিকেই পড়ুন। গেটওয়েতে জিজ্ঞাসা করুন কার্নেল ক্লায়েন্ট ঠিকানার জন্য কোন ইন্টারফেস ব্যবহার করবে; ক্লায়েন্টে জিজ্ঞাসা করুন LAN ঠিকানার জন্য এটি কোন রুট ব্যবহার করে।

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

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

প্রথম কমান্ড যদি টানেল ইন্টারফেস দিয়ে উত্তর দেয়, রিটার্ন রুট বিদ্যমান। যদি এটি LAN ইন্টারফেস দিয়ে উত্তর দেয়, রাউটার মনে করে ক্লায়েন্ট তারেই আছে এবং এর জন্য ARP করার চেষ্টা করবে।

ব্রিজড নকশা আছে, তবে সেগুলো বেছে নিতে হয়

টানেলকে LAN-এ ব্রিজ করা একটি বাস্তব নকশা, যা ব্যবহৃত হয় যখন ক্লায়েন্টদের broadcast পেতে হয় বা এমন প্রোটোকল দ্বারা আবিষ্কৃত হতে হয় যা এক সেগমেন্ট ধরে নেয়। এতে সার্ভারকে সেই ব্রিজিং আচরণ এবং তার সঙ্গে আসা ঠিকানা পরিচালনার মালিক হতে হয়।

যা কাজ করে না তা হলো নম্বর কপি করে ফলাফল নকল করা। ব্রিজ ছাড়া ভাগ করা পুল আপনাকে আবিষ্কার ছাড়াই দ্বন্দ্ব দেয়, যা দুই ব্যবস্থারই সবচেয়ে খারাপ দিক।

অ্যাপ্লিকেশনটি সত্যিই সেগমেন্ট চাইলে ছাড়া আলাদা পুলসহ তৃতীয় স্তর বেছে নিন, এবং পুলটি নথিভুক্ত করুন যাতে পরবর্তী প্রশাসক পরিচ্ছন্নতার জন্য DHCP রেঞ্জ পুনরায় ব্যবহার না করেন।