ESXi গেস্ট VPN: রাউটিং না ব্রিজিং — পোর্ট গ্রুপের আগে সিদ্ধান্ত নিন
রাউটেড TUN-এর ফিরতি রুট লাগে; ব্রিজড TAP-এর লাগে লেয়ার 2 পৌঁছানো ও আরও প্রশস্ত পোর্ট-গ্রুপ নীতি। promiscuous মোড বাড়ানোর আগে ভূমিকা স্থির করুন।
প্যাকেট রাউট করুন বা Ethernet ডোমেইন বাড়ান: পোর্ট গ্রুপের পরিবর্তন সেই সিদ্ধান্তের পরের ধাপ। একটি প্রাইভেট ঠিকানা ধারণ করা অ্যাপ্লিকেশন থেকে ফলাফল একই রকম দেখাতে পারে, অথচ হাইপারভাইজারের প্রয়োজনীয়তা সম্পূর্ণ আলাদা। এজন্যই আগে পোর্ট গ্রুপ প্রশস্ত করা হয় আর ডিজাইনের প্রশ্নের উত্তর আসে পরে, সাধারণত একটি ব্রডকাস্ট স্টর্মের পর। এই যাচাইগুলো ক্রমে করুন এবং প্রয়োজনটা অস্পষ্ট থাকতেই থামুন, কারণ কোনো পোর্ট-গ্রুপ সেটিং এমন ডিজাইন ঠিক করে না যা কখনো বাছাইই করা হয়নি।
সিদ্ধান্তটি সেবার মালিকের; হাইপারভাইজার কনফিগারেশনের কাজ তা বাস্তবায়ন করা, দৈবক্রমে তা নির্ধারণ করা নয়।
দূরের প্রান্তের আসলে কী দরকার তা যাচাই করুন
রিমোট ক্লায়েন্টদের যে সেবাগুলোতে পৌঁছাতে হবে এবং যে প্রোটোকল ব্যবহার করে তা তালিকাভুক্ত করুন। তালিকাটি যদি পরিচিত প্রিফিক্সে কয়েকটি TCP সেবা হয়, রাউটিংই যথেষ্ট। যদি সত্যিই লেয়ার 2 সংলগ্নতা দরকার হয় — ব্রডকাস্ট-নির্ভর আবিষ্কার, নন-IP প্রোটোকল, এমন ডিভাইস যা গেটওয়ে মানে না — রাউটিং তা নকল করতে পারে না এবং তা আগেই বলা উচিত। ওই তালিকার নন-IP এন্ট্রি সম্পর্কে সৎ থাকুন, কারণ সেখানেই রাউটিং ডিজাইন এক সপ্তাহ পরে চুপচাপ ব্যর্থ হয়।
তারপর ক্লায়েন্ট পুল যাচাই করুন। রাউটেড ডিজাইনে একটি ঠিকানা-পরিসর আর দূরের প্রান্তে স্পষ্ট ফিরতি রুট লাগে; ব্রিজড ডিজাইনে সম্প্রসারিত Ethernet ডোমেইনের হাতে ঠিকানা বণ্টন ও বিচ্ছিন্নতা থাকতে হয়। যা-ই বাছুন, এই VM-এর বাইরের কাউকে তা মেনে নিতে হবে।
প্রতিটি ডিজাইন ভার্চুয়াল নেটওয়ার্কের কাছে কী চায়
দুই ডিজাইন ভার্চুয়াল নেটওয়ার্ককে কী সহ্য করতে হবে তাতে আলাদা, আর টেবিলটিই তা দেখার সবচেয়ে ছোট পথ:
| ডিজাইন | গেস্ট-পাশের ভূমিকা | ভার্চুয়াল নেটওয়ার্ককে কী মানতে হবে | ভুল বাছলে ব্যর্থতার ধরন |
|---|---|---|---|
| রাউটেড TUN | আলাদা প্রিফিক্সের মধ্যে রাউটার | রাউটেড ক্লায়েন্ট পুল এবং দূরের প্রান্তে ফিরতি পথ | ক্লায়েন্টরা গেটওয়েতে পৌঁছায় কিন্তু তার পেছনের সেবায় কখনো পৌঁছায় না |
| ব্রিজড TAP | যে ক্লায়েন্টরা যোগ দেয় তাদের জন্য লেয়ার 2 ব্রিজ | অতিরিক্ত Ethernet পরিচয়, ব্রডকাস্ট ট্র্যাফিক ও VLAN নিয়ম | vSwitch ফ্রেম ফেলে দেয়, বা ডিজাইনে এমন promiscuous মোড লাগে যা কেউ অনুমোদন করেনি |
রাউটিং ব্রডকাস্ট ডোমেইনকে যেখানে আছে সেখানেই রাখে এবং কোন সেবা গেটওয়ে পেরোবে তা সীমিত করার স্বাভাবিক জায়গা দেয়। ব্রিজিং সীমানা সরায়: ক্লায়েন্টরা সম্প্রসারিত Ethernet ডোমেইনের অংশীদার হয়, আর ঠিকানা বণ্টন, বিচ্ছিন্নতা ও যেকোনো লেয়ার 2 নীতি এখন তাদের উপর প্রযোজ্য। বাছাই করা সারিটি পরিবর্তন-রেকর্ডে লিখুন। “রাউটেড TUN, ক্লায়েন্ট পুল 10.90.0.0/24, কোর-এ ফিরতি রুট” — এমন একটি বাক্য পরের ইঞ্জিনিয়ারকে পোর্ট-গ্রুপ সেটিংস থেকে ডিজাইন নিয়ে আবার বিতর্ক করতে দেবে না।
কার ফ্রেম কে দেখতে পাবে
পোর্ট গ্রুপে হাত দেওয়ার আগে প্ল্যাটফর্ম মালিককে একটি প্রশ্ন করুন: ডিজাইনটি কি এই VM-কে অন্য অংশীদারদের ঠিকানার ফ্রেম পেতে বাধ্য করে? উত্তর না হলে এই অংশের কিছুই প্রযোজ্য নয়, কারণ রাউটেড TUN-এর ওই দৃশ্যমানতা কখনো লাগে না। উত্তর হ্যাঁ হলে, Broadcom-এর promiscuous মোড নির্দেশিকা হলো মূল পাঠ: এটি বলে VM vSwitch-এর কতটা বেশি দেখতে পারে এবং সেই নীতিকে একটি পোর্ট গ্রুপে সীমাবদ্ধ রাখার পরামর্শ দেয়।
এটিকে অনুমতিপত্র নয়, প্রয়োজন-যাচাই হিসেবে ধরুন। ব্রিজিংয়ের প্রয়োজন লিখিত হলে একটি নির্দিষ্ট সংযুক্তির জন্য সেটিং চালু করুন, আর বাকি সব জায়গায় বন্ধ রাখুন। অন্য ব্রিজের উদাহরণ থেকে কপি করা প্রশস্ত VLAN ট্রাঙ্ক হলো সেই অংশ যা সরাতে কেউ মনে রাখে না, আর একক-VLAN ডিজাইন একক-VLAN-ই থাকা উচিত।
কোন পোর্ট গ্রুপ বদলাল এবং কেন, তা ডিজাইন-সারি লেখার একই জায়গায় লিখুন। এই জোড়াটিই পরের অডিট সম্ভব করে।
গেস্টের অবজেক্টগুলো স্পষ্ট রাখুন
Linux-এর ভেতরে ব্রিজ সদস্যপদ ও ঠিকানা-মালিকানা আলাদা অবজেক্ট, আর এ দুটো গুলিয়ে ফেললে বিভ্রান্তিকর আধা-কাজ করা অবস্থা তৈরি হয়। ঠিকানা দিন ব্রিজ ইন্টারফেসে বা রাউটেড টানেলে, একই পথের দুই পাশে নয়, এবং সদস্য পোর্টগুলো IP কনফিগারেশনমুক্ত রাখুন।
একটি সাবনেটকে স্বাধীনভাবে রাউটেড TUN-এ এবং অসম্পর্কিত Ethernet ইন্টারফেসে বসানো এড়িয়ে চলুন। ওই কনফিগারেশন তৈরি করে একই প্রিফিক্সে দুটি পথ, অপ্রতিসম উত্তর, এবং flapping নিয়ে এমন সাপোর্ট থ্রেড যা কোনো পথের কথাই বলে না। গেস্ট যদি কনটেইনার বা স্থানীয় হাইপারভাইজারও হোস্ট করে, তবে দেখুন তারা ইতিমধ্যে একই uplink-এ ব্রিজ করছে কি না। একটি NIC-এ দুটি ব্রিজ একটি ডিজাইন, পরিবর্তন-উইন্ডোর মধ্যে আবিষ্কার করার মতো দুর্ঘটনা নয়।
ping দিয়ে নয়, প্যাকেট-পথ দিয়ে নিশ্চিত করুন
শুধু পৌঁছানো নয়, প্রকৃত পথ যাচাই করুন। ক্লায়েন্ট থেকে নিশ্চিত করুন কোন সোর্স ঠিকানা দূরের সেবায় পৌঁছায়, তারপর নিশ্চিত করুন উত্তর একই পথে ফেরে। গেস্টে নির্দিষ্ট ফ্লোর জন্য ফরওয়ার্ডিং কাউন্টার দেখুন, আর পোর্ট গ্রুপে নিশ্চিত করুন বাছাই করা ডিজাইনের প্রয়োজনের বাইরে অতিরিক্ত দৃশ্যমানতা চালু হয়নি।
শেষে ব্যর্থতার দিক পরীক্ষা করুন। টানেল থামান বা ক্লায়েন্ট বিচ্ছিন্ন করুন এবং দেখুন ট্র্যাফিক চুপচাপ এমন রাউটেড পথে ফিরে যাচ্ছে কি না যা আপনি অব্যবহৃত ভেবেছিলেন, কারণ সেই ফিরে যাওয়াই ব্রিজড ডিজাইনকে চুপচাপ অনিচ্ছাকৃত রাউটারে পরিণত করে।