একটি TAP সার্ভার নাকি কয়েকটি? ব্রিজে OpenVPN ক্লায়েন্ট

একাধিক TAP ক্লায়েন্টের জন্য প্রতিটির আলাদা সার্ভার প্রসেস, আলাদা UDP পোর্ট এবং হোস্টে আলাদা TAP ডিভাইস লাগে না। ইথারনেট মোডে একটি OpenVPN সার্ভার অনেক প্রমাণিত ক্লায়েন্ট গ্রহণ করে তাদের একটিমাত্র ব্রিজে যুক্ত করতে পারে, এবং স্তর 2-এর একটি সেগমেন্ট বাড়ানোর এটাই নথিভুক্ত পদ্ধতি। এক-প্রসেস ডিজাইনটিই ম্যানুয়ালে নথিভুক্ত, এবং সাধারণত এটাই সঠিক ডিফল্ট।

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

দুটি স্থাপত্য, দুটি সেটিং নয়

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

ব্রিজড TAP স্থাপনা ক্লায়েন্টদের একটি ইথারনেট সেগমেন্টের সদস্য করে তোলে। তারা ব্রডকাস্ট দেখে, ARP দিয়ে একে অন্যকে রিজলভ করতে পারে, এবং আলাদা থাকতে রাউটিংয়ের বদলে ব্রিজ ও ফায়ারওয়াল নীতির উপর নির্ভর করে। ক্লায়েন্টদের যদি একই সুইচে প্লাগ করা আছে বলে দেখাতে হয়, তখন এটি কাজে লাগে।

তাই তুলনাটি ক্লায়েন্টদের কোথায় পৌঁছাতে হবে তা নিয়ে, পারফরম্যান্স নিয়ে নয়। আগে স্তর বেছে নিন, তারপর ঠিক করুন কতগুলো প্রসেস তাতে সেবা দেবে।

server-bridge হেল্পার কী করে

server-bridge হেল্পারটি বহু-ক্লায়েন্ট ইথারনেট মোড কনফিগার করে। এর ঠিকানা-পুল রূপটি গেটওয়ে, নেটমাস্ক এবং ব্রিজড সাবনেটের ভিতরে একটি নির্দিষ্ট রেঞ্জ নেয়, যেমন 192.168.50.1 গেটওয়ে এবং 192.168.50.160 থেকে 192.168.50.199 পর্যন্ত পুল।

সেই রেঞ্জ অন্য যেকোনো DHCP বা স্ট্যাটিক অ্যাসাইনমেন্টের বাইরে রাখুন। হেল্পার সেখান থেকেই ঠিকানা বরাদ্দ করে, কিন্তু একই সেগমেন্টের অন্য বরাদ্দকারীর সঙ্গে সমন্বয় করে না, আর দুটি ওভারল্যাপিং পুল ডুপ্লিকেট ঠিকানা তৈরি করে যা এলোমেলো সংযোগ-ব্যর্থতার মতো দেখায়। সংরক্ষিত রেঞ্জটি সাইটের ঠিকানা-পরিকল্পনায় লিখুন যাতে পরের ব্যক্তি তা আবার ব্যবহার না করে। সার্ভার কনফিগারেশনে একটি মন্তব্য সেই রেকর্ডের দুর্বল বিকল্প।

যেসব স্থাপনায় বাইরের সার্ভার ঠিকানা দেয়, তাদের জন্য DHCP-প্রক্সি রূপ আছে। এর নিজস্ব পূর্বশর্ত আছে, আর দুটি রূপ মেশালে ঠিক যে দ্বন্দ্বটি ডকুমেন্টেশন সতর্ক করে তা-ই তৈরি হয়। ব্রিজড সাবনেটের জন্য একটি বরাদ্দকারী বেছে নিন।

বিচ্ছিন্নতা প্রসেসের সংখ্যা থেকে আসে না

একই অনিয়ন্ত্রিত ব্রিজে যুক্ত আটটি OpenVPN প্রসেসও একটি ব্রডকাস্ট ডোমেইনই ভাগ করে। ক্লায়েন্টরা ব্রিজের ওপারে একে অন্যের জন্য ARP করতে পারে, আর শ্রোতার সংখ্যা এতে কিছুই বদলায়নি।

যদি প্রয়োজন হয় যে ক্লায়েন্ট গোষ্ঠীগুলো স্তর 2-এ একে অন্যকে দেখবে না, তবে ডিজাইনে আলাদা ব্রিজ বা VLAN সংযুক্তি এবং তার সঙ্গে সংশ্লিষ্ট অ্যাক্সেস নিয়ম দরকার। এটি নেটওয়ার্ক ডিজাইনের সিদ্ধান্ত, আর একটি সার্ভার প্রসেস বা আটটি জড়িত থাকুক, সিদ্ধান্ত একই। ব্রিজ ফিল্টারিং কিছু ট্রাফিক সীমিত করতে পারে, কিন্তু আলাদা ব্রডকাস্ট ডোমেইন তৈরি করে না। এটিকে সেগমেন্টেশনের সম্পূরক হিসেবে দেখুন, তার বিকল্প হিসেবে নয়।

যদি প্রয়োজন শুধু এই হয় যে ক্লায়েন্টরা নির্দিষ্ট IP সেবায় পৌঁছাবে, তবে রাউটেড TUN ডিজাইন সাধারণত ব্রিজিং প্লাস ফিল্টারিংয়ের চেয়ে সরল। প্রতিটি ক্লায়েন্ট নিজের লিংক পায়, আর নীতি ব্রিজের অভ্যন্তরে নয়, রাউটিং ও ফায়ারওয়াল নিয়মে থাকে।

কখন একাধিক প্রসেস তবুও সঠিক

আলাদা প্রসেস পরিচালনগত প্রয়োজনে ন্যায্য হতে পারে: ভিন্ন প্রমাণীকরণ ব্যাকএন্ড, ভিন্ন সার্টিফিকেট কর্তৃপক্ষ, আলাদা আপগ্রেড চক্র, বা অসঙ্গত বিকল্প-সেট। এগুলো বাস্তব কারণ এবং ক্লায়েন্ট সংখ্যা থেকে স্বাধীন।

একাধিক ব্যবহার করলে প্রতিটিকে নিজস্ব শ্রোতা ও ডিভাইস-মালিকানা দিন এবং ঠিকানা রেঞ্জগুলো সমন্বয় করুন। একই ব্রিজে একই পুল নিজের বলে মনে করা দুটি সার্ভার শেষে একই ঠিকানা দিতে শুরু করবে।

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

ডায়াগ্রামে ভরসা করার আগে চলমান হোস্ট থেকে ব্রিজ ও সার্ভার মোড পড়ুন। যে কনফিগারেশনটি গুরুত্বপূর্ণ তা হলো কার্নেল ও ডেমন আসলে যা লোড করেছে, এবং সেটিই একজন পর্যালোচক যাচাই করতে পারেন।