LAN ঠিকানার VPN ক্লায়েন্ট LAN-এ থাকে না
VPN ক্লায়েন্টকে LAN ঠিকানা দিলে তাকে ওই লিংকে বসানো হয় না। স্থানীয় হোস্ট প্রতিবেশী খোঁজে, তাই গেটওয়েকে উত্তর দিতে হয়, নইলে উত্তর কখনো পৌঁছায় না।
ক্লায়েন্ট সংযুক্ত হয়, 10.50.0.200 পায়, এবং দুটি নম্বর একই /24-এ থাকা সত্ত্বেও 10.50.0.20-তে সার্ভারে পৌঁছাতে পারে না। এই কনফিগারেশনের পেছনের বিশ্বাস হলো LAN প্রিফিক্সের একটি ঠিকানা ক্লায়েন্টকে LAN-এর অংশ করে দেয়। তা করে না। ক্লায়েন্ট পয়েন্ট-টু-পয়েন্ট লিংকে আছে, সার্ভার গন্তব্যকে স্থানীয় মনে করে, আর অনুপস্থিত অংশটি এমন প্রতিবেশী-উত্তর যা কেউ পাঠাচ্ছে না।
কিংবদন্তি: একই প্রিফিক্স মানে একই সেগমেন্ট
একটি ঠিকানা প্রিফিক্স হোস্টকে বলে কোন গন্তব্যে সে সরাসরি পৌঁছাতে পারে আর কোনটির জন্য রাউটার দরকার। এটি হোস্টকে বলে না গন্তব্যটি ভৌতভাবে কীভাবে যুক্ত, এবং গন্তব্য লিংক-স্তরের অনুরোধের উত্তর দিতে পারবে তার কোনো নিশ্চয়তাও দেয় না। এগুলো আলাদা প্রশ্ন, যার উত্তর হোস্টের আলাদা টেবিল দেয়। মাস্ক প্রথমটির উত্তর দেয় আর প্রতিবেশী টেবিল দ্বিতীয়টির, এবং কেবল প্রথমটিই VPN-এর দিক থেকে আপনার নিয়ন্ত্রণে।
সার্ভার যখন 10.50.0.200-তে পাঠায়, সে গন্তব্যকে নিজের মাস্কের সাথে তুলনা করে, ঠিকানাটিকে on-link মনে করে, এবং যে হার্ডওয়্যার ঠিকানা এটির মালিক সেই ঠিকানা স্থানীয় সেগমেন্টের কাছে চায়। সেই অনুরোধ Ethernet ইন্টারফেস দিয়ে বেরিয়ে যায়, আর VPN ক্লায়েন্ট সেখানে নেই তা শোনার জন্য।
ক্লায়েন্টের কনফিগারেশনে কিছুই নিজের দিক থেকে এটি ঠিক করতে পারে না। উত্তরের পথ নির্ভর করে LAN-এ থাকা কোনো ডিভাইস ক্লায়েন্টের হয়ে উত্তর দিচ্ছে কি না, অথবা ক্লায়েন্টের এমন ঠিকানা আছে কি না যা সার্ভার স্থানীয় মনে করে না।
স্থানীয় হোস্ট আসলে ঠিকানাটি দিয়ে কী করে
আচরণটি সহজে লক্ষ্য করা যায় এবং কিছু বদলানোর আগে লক্ষ্য করা উচিত। ক্লায়েন্টে পৌঁছানোর চেষ্টার পর LAN হোস্টের প্রতিবেশী টেবিলে দেখুন: অসম্পূর্ণ বা ব্যর্থ এন্ট্রিই এক লাইনে পুরো রোগনির্ণয়। সেই লাইনটি আপনাকে এটিও বলে যে ত্রুটিটি সেগমেন্টের স্থানীয়, টানেলের ভেতরে কোথাও নয়।
ip neigh show 10.50.0.200 ip route get 10.50.0.200 arping -I eth0 -c 3 10.50.0.200
রুট অনুসন্ধান Ethernet ইন্টারফেস দিয়ে গন্তব্যকে on-link হিসেবে দেখাবে, এবং সমস্যাটি ঠিক সেটাই। VPN সেশন চালু থাকা অবস্থায় প্রতিবেশী এন্ট্রি অসম্পূর্ণ থাকলে আপনি নিশ্চিত করেছেন যে অনুপস্থিত অংশটি লিংক-স্তরের রিজলিউশন, রাউটিং বা ফায়ারওয়াল নীতি নয়।
অন্য সাবনেটের হোস্ট থেকে একই পরীক্ষা চালান এবং তুলনা করুন। যে হোস্ট রাউটারের মাধ্যমে ক্লায়েন্টে পৌঁছায় তার প্রতিবেশী এন্ট্রি একেবারেই দরকার নেই, আর এই পার্থক্যটি ছোট আকারে নকশার সিদ্ধান্ত।
Proxy ARP কীভাবে পরবর্তী হপ জোগায়
Proxy ARP গেটওয়েকে এমন একটি গন্তব্যের হয়ে লিংক-স্তরের অনুরোধের উত্তর দিতে দেয় যেখানে সে অন্য ইন্টারফেস দিয়ে পৌঁছাতে পারে। LAN হোস্ট একটি হার্ডওয়্যার ঠিকানা পায়, ফ্রেমটি গেটওয়েতে পাঠায়, এবং গেটওয়ে প্যাকেটটি VPN সেশনে পাঠিয়ে দেয়। হোস্টের দৃষ্টিতে ক্লায়েন্ট সহজভাবে গেটওয়ের পেছনে থাকা বলে মনে হয়। ক্লায়েন্টের কনফিগারেশনে কিছুই বদলায় না।
MikroTik-এর RouterOS ARP ডকুমেন্টেশন সংযুক্ত LAN-এর ঠিকানা ক্ষেত্র ধার করা dial-in ক্লায়েন্টের জন্য এই ব্যবহার বর্ণনা করে। প্রক্রিয়াটি প্রতিবেশী রিজলিউশনের একটি মেরামত, এবং এটি কাজ করে কারণ গেটওয়ে সত্যিই দুই পথেই আছে।
এটি ক্লায়েন্টকে LAN-এ ব্রিজ করার সমান নয়। গেটওয়েকে এখনও প্যাকেটটি সঠিক সক্রিয় সেশনে পাঠাতে হয়, এবং তার রাউটিং ও ফায়ারওয়াল নীতিকে এখনও সেবাটি অনুমোদন করতে হয়। Proxy ARP বদলায় কে প্রতিবেশী অনুরোধের উত্তর দেয়, কে কথা বলার অনুমতি পায় তা নয়।
প্ল্যাটফর্মের মোডের নাম মন দিয়ে পড়ুন। RouterOS proxy-arp থেকে local-proxy-arp আলাদা করে, এবং দ্বিতীয়টি একই ইন্টারফেসে ঢোকা ও বেরোনো ট্রাফিক সামলায়। এগুলো বিনিময়যোগ্য বানান নয়, আর দুটোই না বুঝে চালু করা কোনো শর্টকাট নয়।
Proxy ARP আপনাকে যা দেয় না
এটি broadcast বা multicast ডিসকভারি দেয় না। যে ক্লায়েন্টকে broadcast দিয়ে সেবা খুঁজতে হয় সে এখনও ব্যর্থ হবে, কারণ গেটওয়ে unicast সেশনে পাঠায় এবং ক্লায়েন্টকে LAN-এর broadcast ডোমেইনের সদস্য করে না। broadcast-নির্ভর ডিসকভারি প্রোটোকল ধার করা ঠিকানার নকশায় „একটির জন্য কাজ করে, অন্যের জন্য নয়“ ধরনের প্রতিবেদনের সাধারণ উৎস।
এটি ঠিকানাটি সংরক্ষণ করে না। ধার করা নম্বরটি যদি DHCP পুল বা স্ট্যাটিক বরাদ্দেও থাকে, দুটি ডিভাইস একই ঠিকানা পেতে পারে এবং ফলাফল নির্ভর করে সময়ের উপর। সফল লগইন কোনো সংরক্ষণ নয়।
আর এটি LAN-এর মালিকের সাথে সমন্বয়ের প্রয়োজন মেটায় না। যে Proxy ARP এন্ট্রি ঠিকানা পরিকল্পনার মালিককে অবাক করে, তা শান্ত এক সপ্তাহের অপেক্ষায় থাকা সাপোর্ট ঘটনা।
আলাদা রাউটেড পুলের সাথে তুলনা
বিকল্প হলো VPN ক্লায়েন্টদের নিজেদের প্রিফিক্স দেওয়া এবং LAN হোস্টদের সেখানে রাউট করতে দেওয়া। তখন সার্ভার তার গেটওয়েতে off-link উত্তর পাঠায়, গেটওয়ে প্রিফিক্সটি VPN এন্ডপয়েন্টে রাউট করে, এবং LAN সেগমেন্টে প্রতিবেশী রিজলিউশনের একেবারেই দরকার নেই। এটি ধার করা ঠিকানা যোগ proxy উত্তরের চেয়ে কম চলমান অংশ।
এই নকশা নিয়ে ভাবা সহজ এবং অডিট করাও সহজ, কারণ ক্লায়েন্ট পরিসর LAN পরিসর থেকে দৃশ্যত আলাদা। এতে লাগে একটি রুট, একটি ফিরতি পথ ও একটি অ্যাক্সেস নিয়ম — proxy ARP নকশার কম স্পষ্ট জায়গায় যেসব জিনিস লাগে সেগুলোই।
মডেল দুটির মধ্যে সচেতনভাবে বেছে নিন, দৈবক্রমে নয়। Proxy ARP একটি নির্দিষ্ট সম্পর্ক মেরামত করে; রাউটেড পুল সেই মেরামতের প্রয়োজনই রাখে না। আপনি কোনটি বেছেছেন এবং কেন তা লিখে রাখুন, তাহলে পরের ব্যক্তিকে ব্যর্থ প্রতিবেশী এন্ট্রি থেকে তা নতুন করে আবিষ্কার করতে হবে না।