দুটি সাইটের সাইট VPN-এর জন্য কি একই VLAN ID দরকার?
একই VLAN ID রাউটেড সাইট VPN ঠিক করতে পারে না: টানেল IP প্রিফিক্স বহন করে, তাই পৌঁছানো নির্ধারণ করে অ্যাড্রেস প্ল্যান ও সিলেক্টর, সুইচ ট্যাগ নয়।
দুই অফিসে একই VLAN নম্বর থাকলে মনে হয় এটি সাইট-থেকে-সাইট টানেলে সাহায্য করবে, অথচ টানেল যা বহন করে তা এতে বদলায় না। একটি VLAN ID একটি ভবনের ভিতরে একটি Ethernet ব্রডকাস্ট ডোমেইন চিহ্নিত করে; টানেল গেটওয়েগুলোর মধ্যে IP প্যাকেট এগিয়ে দেয়। দুই সাইট সম্পূর্ণ ভিন্ন VLAN নম্বরায়ন ব্যবহার করেও একে অপরের কাছে রুট করতে পারে, আবার দুই সাইট একই VLAN নম্বরায়ন ব্যবহার করেও একে অপরের কাছে পৌঁছাতে পারে না। পৌঁছানো নির্ধারণ করে যে চলকটি, সেটি হলো অ্যাড্রেস প্ল্যান।
মিথ: দুই প্রান্তে একই VLAN ID
এই বিশ্বাসের উৎপত্তি যুক্তিসঙ্গত। এক ভবনের ভিতরে একই VLAN-এর দুই পোর্ট কথা বলতে পারে, আর ভিন্ন VLAN-এর দুই পোর্ট পারে না, তাই VLAN নম্বরই সংযোগ দেওয়ার জিনিস বলে মনে হয়। রাউটেড টানেলের ওপারে ট্যাগের বর্ণনা করার মতো কোনো সাধারণ Ethernet সেগমেন্ট নেই, এবং গেটওয়েগুলো কখনো VLAN লেবেল বিনিময় করে না।
টানেলের দরকার এমন দুটি অ্যাড্রেস স্কোপ যা ওভারল্যাপ করে না, আর এমন নীতি যা তাদের মধ্যে ট্রাফিক অনুমোদন করে। যেকোনো অফিসে VLAN বদলান, টানেল কাজ করতে থাকে, কারণ টানেল কনফিগারেশনে কিছুই এটির উল্লেখ করেনি। এই পরীক্ষাই বিতর্ক নিষ্পত্তি করে: VLAN পুনঃনম্বরায়ন করুন, অ্যাড্রেস অপরিবর্তিত রাখুন, আর টানেল টিকে আছে কি না দেখুন।
উল্টো পরীক্ষাও সমান তথ্যবহ। দুই অফিসকে একই সাবনেট দিন, আর যত বেশি VLAN নম্বর মিলুক না কেন, তাতে কোনো অ্যাড্রেস দ্ব্যর্থহীন হবে না।
টানেল আসলে কী বহন করে
IPsec অ্যাড্রেস, প্রোটোকল ও পোর্টে প্রকাশ করা নীতি অনুযায়ী IP প্যাকেট সুরক্ষিত করে। IPsec আর্কিটেকচার IP স্তরে সেই সিলেক্টরগুলোর বর্ণনা দেয়, যা কোনো সুইচ ট্যাগ বর্ণনা করে তার চেয়ে কয়েক স্তর উপরে। প্যাকেট টানেলে ঢোকার সময়ই তা VLAN ছেড়ে এসেছে; ট্যাগটি স্থানীয় সুইচ খরচ করে ফেলেছে।
পলিসি-ভিত্তিক ও রুট-ভিত্তিক ডিজাইন টানেল বেছে নেওয়ার ধরনে আলাদা, যা বহন করতে পারে তাতে নয়। পলিসি-ভিত্তিক পিয়ার ট্রাফিক সিলেক্টর মেলায় এবং মিলে যাওয়া প্যাকেট টানেলে পাঠায়। রুট-ভিত্তিক পিয়ার টানেল ইন্টারফেসে ট্রাফিক রুট করে এবং সিদ্ধান্ত রাউটিং টেবিলকে ছেড়ে দেয়। দুটোই এখনো সুরক্ষা-পরিসর নিয়ে দরকষাকষি করে, তাই টানেলের দিকে যাওয়া একটি রুট পিয়াররা যে সুরক্ষায় সম্মত হয়েছে তা বাড়ায় না।
এই পার্থক্যই একটি সাধারণ অর্ধ-ব্যর্থতা ব্যাখ্যা করে: রুট আছে, প্যাকেট টানেলে ঢোকে, আর দূরপ্রান্ত সেগুলো ফেলে দেয়, কারণ দরকষাকষি করা সিলেক্টরে ওই প্রিফিক্স কখনোই ছিল না। ইনস্টল করা পলিসি পড়লে দেখা যায় কোন পরিসরটি আসলে কার্যকর হয়েছে।
ip xfrm policy
ip route show
swanctl --list-sasযে ওভারল্যাপ সত্যিই ভাঙে
আলাদা সাবনেটের দুই অফিস টানেল দিয়ে পরিষ্কারভাবে রুট করে, আর তাদের VLAN নম্বরের কোনো তাৎপর্য নেই। একই সাবনেটের দুই অফিস পারে না, কারণ নির্দিষ্ট অ্যাড্রেসের অনুরোধের দুটি সম্ভাব্য অর্থ থাকে এবং রাউটিং টেবিল কেবল একটি বেছে নিতে পারে। একটি সাইট পুনঃনম্বরায়ন করা পরিষ্কার সমাধান, এবং DNS ও ফায়ারওয়াল পরিবর্তন হিসাব করলে এটি সাধারণত বিকল্পগুলোর চেয়ে সস্তা।
| Office | Local VLAN | Subnet | Result |
|---|---|---|---|
| A | 40 | 10.31.0.0/24 | Routes normally |
| B | 55 | 10.62.0.0/24 | Routes normally |
| B after renumber | 40 | 10.31.0.0/24 | Ambiguous, tunnel cannot help |
পুনঃনম্বরায়ন অসম্ভব হলে, ইচ্ছাকৃত ট্রান্সলেশন ডিজাইন প্রতিটি পক্ষকে আলাদা অ্যাড্রেস দৃশ্য দেখাতে পারে। এর অর্থ এক-থেকে-এক ম্যাপিং, মিলে যাওয়া সিলেক্টর, অনূদিত দৃশ্য প্রতিফলিত DNS এন্ট্রি এবং পুনর্লিখন সত্তেও টিকে থাকা রিটার্ন রাউটিং। এটি বাস্তব পরিচালন ব্যয়সহ একটি সমর্থিত ডিজাইন, আর VLAN ID বদলানো এটা করে না।
দুই প্রান্তে একই VLAN নম্বর কখনো কখনো সাধারণ টেমপ্লেটের কাকতালীয় ঘটনা, আর সেই কাকতালীয়কে সচল টানেলের কারণ ভাবলে পরে কিছু ভাঙলে ভুল পরিবর্তন করা হয়।
প্রতিটি স্তরের জন্য একটি কাজ, লিখিতভাবে
স্থানীয় সুইচ ঠিক করে কোন পোর্টগুলো একটি ব্রডকাস্ট ডোমেইন ভাগ করে, আর তার VLAN নম্বরায়ন স্থানীয় হিসাব, যা অন্য কোনো সাইটকে জানতে হয় না। গেটওয়ে পিয়ারকে প্রমাণীকরণ করে এবং দরকষাকষি করা সুরক্ষা-পরিসর প্রয়োগ করে। রাউটিং টেবিল ঠিক করে ডিক্রিপ্ট করা প্যাকেট এরপর কোথায় যাবে, আর অ্যাক্সেস পলিসি ঠিক করে সেই প্যাকেট আদৌ অনুমোদিত হওয়া উচিত ছিল কি না।
এই কাজগুলো আলাদা রাখাই পরিবর্তনকে নিরাপদ করে। এক অফিসে VLAN পুনঃনম্বরায়ন স্থানীয় সুইচ, DHCP স্কোপ এবং সম্ভবত ফায়ারওয়াল জোনে ছোঁয়, আর টানেলে ছোঁয় না। প্রিফিক্স পরিবর্তন টানেল সিলেক্টর, দুই পাশের রুট ও অ্যাক্সেস পলিসিতে ছোঁয়, আর সুইচ ট্যাগে ছোঁয় না।
রিটার্ন রুট, প্রাইভেট DNS ও অ্যাপ্লিকেশন পরিচয়ের প্রয়োজনীয়তা আবার আলাদা কাজ, আর এর কোনোটিই অন্য সাইট থেকে VLAN নম্বর কপি করে আসে না। যে ডিজাইন নথি পৌঁছানোযোগ্য প্রিফিক্স ও অনুমোদিত সেবা তালিকাভুক্ত করে, তা সুইচ প্রতিস্থাপনেও টিকে থাকে; যা VLAN নম্বর তালিকাভুক্ত করে, তা টেকে না।
ট্যাগ টানেলে পৌঁছায় ধরে নেওয়ার আগে ব্রিজ টুল দিয়ে স্থানীয় চিত্র নিশ্চিত করুন।
bridge vlan show
ip -br addr
ip route get 10.62.0.20যখন layer-2 সম্প্রসারণই প্রকৃত প্রয়োজন
কিছু ডিজাইনে সত্যিই সাইটের মধ্যে Ethernet আচরণ দরকার: এমন লিগ্যাসি অ্যাপ্লিকেশন যা ব্রডকাস্ট ডিসকভারির উপর নির্ভর করে, এমন মাইগ্রেশন যা মেশিন সরলেও অ্যাড্রেস ধরে রাখতে হবে, বা এমন প্রোটোকল যা layer-2 ধারণা অন্তর্ভুক্ত করে। এসব ক্ষেত্রে ফ্রেম বহনকারী ওভারলে বা ব্রিজড সেবা দরকার, আর তখন VLAN সদস্যতা, লুপ প্রতিরোধ ও ব্যর্থতা সামলানো প্রান্ত-থেকে-প্রান্ত বিষয় হয়ে ওঠে।
এটি অনেক বড় ব্যর্থতার ক্ষেত্র, আর ফাইল শেয়ার চালু করার চেষ্টার আকস্মিক ফল নয়, সচেতন পছন্দ হওয়া উচিত। সাধারণ ফাইল সার্ভার, ডেটাবেস বা ওয়েব অ্যাপ্লিকেশনের অনুমোদিত IP পথ দরকার, আর তার নিচে টানা ব্রডকাস্ট ডোমেইন না থাকলে সে বেশি ভালো থাকবে।
VPN চুক্তিটি পৌঁছানোযোগ্য প্রিফিক্স ও অনুমোদিত সেবা হিসেবে লিখুন, আর VLAN লেবেল কেবল সেখানেই লিপিবদ্ধ করুন যেখানে স্থানীয় পরিচালনার তা দরকার। তখন প্রতিটি অফিস নিজের সুইচিং পুনঃনম্বরায়ন করতে পারবে, প্রতিটি পরিবর্তনকে টানেল পুনর্র্নকাশে পরিণত না করে।