কেন একটি LAN হোস্ট OpenVPN ক্লায়েন্টের ঠিকানার জন্য ARP পাঠায়

LAN হোস্ট এবং VPN ক্লায়েন্টের মধ্যে পৌঁছানোর সমস্যাগুলো প্রায়ই ঠিকানা পরিকল্পনারই কাছে ফিরে আসে। ওই হোস্টকে 10.0.100.0/22-এ একটি ইন্টারফেস দিন এবং এটি 10.0.100.0 থেকে 10.0.103.255 পর্যন্ত প্রতিটি ঠিকানাকে সরাসরি সংযুক্ত মনে করবে, যার মধ্যে 10.0.101.0/24-এ চুপচাপ রাখা ক্লায়েন্ট পুলও আছে। উত্তর কখনো রাউটারের কাছে যায় না, কারণ হোস্টের দৃষ্টিকোণ থেকে কোনো রাউটার জড়িত থাকে না। প্যাকেটটি প্রতিবেশীকে সম্বোধন করা এবং তারে চাওয়া হয়।

এই ব্যবস্থাটি প্রতিবেদনের একটি সম্পূর্ণ পরিবারের পেছনে রয়েছে: টানেল চালু আছে, সার্ভারের একটি রুট আছে, এবং LAN হোস্ট তবুও ক্লায়েন্টে পৌঁছাতে পারে না।

যে /22 /24-কে গিলে ফেলে

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

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

সরাসরি সংযোগ মানে ARP, রাউটিং নয়

/22 ইন্টারফেসযুক্ত হোস্ট যখন 10.0.101.25-তে পাঠায়, কার্নেল গন্তব্যের সঙ্গে ইন্টারফেসের প্রিফিক্স তুলনা করে এবং মিল পায়। প্যাকেটটি রাউটেড প্যাকেটের বদলে প্রতিবেশী অনুসন্ধান হয়ে যায়, এবং ইথারনেটে প্রতিবেশী অনুসন্ধান সেই ঠিকানার জন্য ARP অনুরোধ। যদি ঠিকানাটি রাউটেড গেটওয়ের পেছনের VPN ক্লায়েন্টের হয়, LAN-এর কোনো হোস্ট এর মালিক নয়, তাই অনুরোধটি উত্তরহীন থেকে যায় এবং প্যাকেটগুলো ফেলে দেওয়া হয়। টানেল দোষী নয়, এবং ক্লায়েন্ট ট্রাফিক কখনো দেখে না।

তাই ব্যর্থতাটি অসামঞ্জস্যপূর্ণ এবং মাঝে মাঝে বিরতিহীন দেখায়। VPN হোস্ট প্রায়ই LAN-এ পৌঁছায় কারণ এর নিজস্ব রুট সঠিক দিকে নির্দেশ করে, অথচ LAN হোস্ট উত্তর দিতে পারে না, এবং পুরনো ARP এন্ট্রি ক্যাশ করা যেকোনো কিছু লক্ষণটিকে ঝিকমিক করে রাখে।

TUN, TAP এবং প্রত্যেকে কী বহন করে

TUN ডিভাইস IP প্যাকেট বহন করে, এবং TAP ডিভাইস ইথারনেট ফ্রেম বহন করে। রাউটেড TUN লিংককে IP অ্যাক্সেস দিতে ARP বহন করতে হয় না, এবং ঠিক তাই উপরের উত্তরহীন অনুরোধটি প্রত্যাশিত, নষ্ট নয়। TAP ইচ্ছাকৃত ব্রিজের সঙ্গে সম্প্রচার ডোমেইন বাড়াতে পারে এবং ARP চালাতে পারে, তবে এটি ক্লায়েন্ট কী দেখতে পারে তা বদলে দেয়, একই ফ্রেমিং সমর্থনকারী প্রান্তবিন্দু দাবি করে, এবং এটি ওভারল্যাপিং প্রিফিক্সের মেরামত নয় বরং নেটওয়ার্ক মডেলের পুনঃনকশা। ঠিকানা পরিকল্পনার ভুলের চিকিৎসায় রাউটেড স্থাপনা TAP-এ নেওয়া ছোট সমস্যাকে বড় সমস্যার সঙ্গে বদলায়।

সিদ্ধান্তে পৌঁছানোর আগে লিখে রাখুন ARP অনুরোধ কোথায় দেখা দিয়েছিল এবং কোন সিস্টেম পাঠিয়েছিল। প্রেরক আপনাকে বলে সে গন্তব্য সম্পর্কে কী ভাবে, টানেল কী করে তা নয়।

এমন পুল ডিজাইন করুন যা ওভারল্যাপ করতে পারে না

প্রতিটি সংযুক্ত প্রিফিক্স এবং প্রতিটি ঘোষিত সাইট প্রিফিক্সের বাইরে পুল বেছে নিন, তারপর যে রুটগুলো এটি উভয় দিকেই পৌঁছানোর যোগ্য করে যোগ করুন। পরিকল্পনার অব্যবহৃত অংশে 10.8.0.0/24-এর মতো পরিসর ভাবা সহজ, এবং যে LAN-কে সেখানে পৌঁছাতে হবে সে VPN সার্ভারের দিকে নির্দেশ করা স্ট্যাটিক রুট পায়। বরাদ্দ, ঘোষিত রুট, অনুমোদিত উৎস ঠিকানা এবং ফায়ারওয়াল নিয়ম একসঙ্গে পরিবর্তন করুন, কারণ এগুলো চারটি সেটিং নয় বরং একটি নকশা বর্ণনা করে।

সার্ভারে Source NAT পুলটিকে LAN থেকে রাউটযোগ্য ঠিকানার পেছনে লুকাতে পারে, এবং এটি বৈধ মাইগ্রেশন সরঞ্জাম। এটি উৎসও পুনর্লিখন করে, তাই LAN সংযোগগুলোকে পৃথক ক্লায়েন্টের সঙ্গে যুক্ত করার এবং প্রতি-ক্লায়েন্ট নিয়ম প্রয়োগ করার ক্ষমতা হারায়।

গ্রহণের জন্য আসল ক্লায়েন্টের প্রকৃত বরাদ্দকৃত ঠিকানা এবং LAN হোস্ট থেকে একটি আসল অ্যাপ্লিকেশন অনুরোধ ব্যবহার করুন, তারপর নিশ্চিত করুন যে উত্তর তারের বদলে পরিকল্পিত গেটওয়ে অনুসরণ করে।