VPN জুড়ে DHCP: ব্রডকাস্ট বহন করবেন, নাকি রিলে করবেন?

সুড়ঙ্গের ওপারে থাকা নতুন ল্যাপটপ কোনো ঠিকানা পায় না, অথচ একই ল্যাপটপ সদর দপ্তরে কাজ করে। সাধারণত প্রথম অনুমান হয় যে সুড়ঙ্গটি DHCP আটকে দিচ্ছে। বেশি ক্ষেত্রে ব্রডকাস্টের কখনোই কোনো পথ ছিল না: কনফিগার না করা ক্লায়েন্ট 255.255.255.255-এ পাঠায়, আর সাধারণ IP রাউটার সেই প্যাকেট এগিয়ে দেয় না। সুড়ঙ্গটি ঠিক তাই করছে যা একটি রাউটেড সুড়ঙ্গ করে।

দুটি নকশা এটি বদলাতে পারে, এবং তারা সমতুল্য নয়। একটি ব্রডকাস্ট বহন করে; অন্যটি অনুরোধটি রিলে করে।

ব্রডকাস্ট কখনো রাউটার অতিক্রম করে না

ঠিকানাহীন একটি DHCPv4 ক্লায়েন্ট 0.0.0.0 থেকে সীমিত ব্রডকাস্ট ঠিকানায় UDP পোর্ট 67 ও 68-এ পাঠায়। সেই প্যাকেট নকশা অনুযায়ীই তার লিংকে থেকে যায়। যে রাউটার এটি এগিয়ে দিত, সে তার সেবা দেওয়া প্রতিটি সেগমেন্ট প্লাবিত করত।

তাই একটি রাউটেড সাইট-টু-সাইট সুড়ঙ্গ রিলেকে একটি সার্ভারের সঙ্গে যুক্ত করে। এটি ক্লায়েন্টের ব্রডকাস্ট ডোমেইন বাড়ায় না, এবং কোনো ফায়ারওয়াল নিয়মই এটিকে তাই করাতে পারবে না।

ব্রিজ করা সুড়ঙ্গ আসলে কী বাড়ায়

সচেতনভাবে ব্রিজ করা VPN তার সমর্থিত টপোলজিতে Ethernet ব্রডকাস্ট বহন করতে পারে, এবং তখন DHCP স্থানীয় ট্রাফিক হিসেবে পার হতে পারে। এটি বাস্তব একটি বিকল্প, তবে এটি 2 স্তরের নকশা-সিদ্ধান্ত। আপনি ব্রডকাস্টের সঙ্গে সঙ্গে ব্যর্থতার ডোমেইন ও প্রবেশসীমাও বাড়াচ্ছেন।

ব্রিজিং আরও বদলে দেয় একটি ব্রডকাস্ট ঝড়, একটি ARP স্ক্যান বা একটি দুষ্ট DHCP সার্ভার কী পর্যন্ত পৌঁছাতে পারে। আপনি যদি দূরবর্তী অফিসটিকে একই সুইচে না লাগাতেন, তবে কেবল ঠিকানা বিতরণের জন্য সুড়ঙ্গটি ব্রিজ করবেন না। চালু করার আগে সেই বিস্ফোরণ-ব্যাসার্ধ পরীক্ষা করুন।

এটি একটি ঠিকানা জোগানোর চেয়ে বড় সিদ্ধান্ত, এবং এটি সচেতনভাবেই নেওয়া উচিত।

বরং অনুরোধটি রিলে করুন

সাধারণ উত্তর হলো ক্লায়েন্টের স্থানীয় নেটওয়ার্কে একটি রিলে। এটি ব্রডকাস্ট গ্রহণ করে, সেটিকে unicast অনুরোধে রূপান্তর করে, এবং নিজের ঠিকানা গেটওয়ে-ঠিকানা ক্ষেত্রে বসায়। সার্ভার সেই রিলে ঠিকানায় উত্তর দেয়।

একটি দৃষ্টান্তমূলক দূরবর্তী অফিসের জন্য, রিলে অফিসের LAN-এ থাকে এবং সার্ভারে পৌঁছানো হয় সাইট VPN দিয়ে। সেই অফিসের স্কোপ, রিলে ও সার্ভারের পরিচয়, এবং সম্পূর্ণ ফেরত-পথ কনফিগার করুন। সুড়ঙ্গ দিয়ে UDP 67 অনুমোদন করা সার্ভারকে বলে না কোন পুল ব্যবহার করতে হবে।

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

DHCP-কে ARP থেকে এবং সুড়ঙ্গ-ঠিকানাকরণ থেকে আলাদা রাখুন

DHCP চলে UDP/IP-এর ওপরে। Ethernet-এ একটি হোস্ট ARP ব্যবহার করে যাচাইও করতে পারে কোনো প্রার্থী ঠিকানা ইতিমধ্যে ব্যবহৃত কি না। সেই দ্বন্দ্ব-যাচাই আলাদা একটি লিংক-স্থানীয় কাজ, DHCP বার্তার পরিবহন নয়। DHCP মূলত ARP — এ কথা ভুল; দুটি কখনোই সম্পর্কিত নয় — এ কথা অতিরিক্ত বিস্তৃত।

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

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