যে নেটওয়ার্ক শুধু TCP 443 অনুমোদন করে, তারা এমন নেটওয়ার্কের পাশে থাকে যারা UDP সহজে পার করে, এবং একটি সার্ভারকে দুটিকেই সেবা দিতে হয়। proto udp থাকা প্রোফাইল দ্বিতীয় দলকে উত্তর দেয় আর প্রথমটিতে ব্যর্থ হয়, এবং একই কনফিগারেশন বদলে proto tcp বললেও দ্বিতীয় লিসেনার তৈরি হয় না। ডিরেক্টিভটি একটি প্রসেসের জন্য একটি ট্রান্সপোর্ট বেছে নেয়। বাকি সব কিছু সেই সীমাবদ্ধতা থেকেই আসে।

হয় আপনি একাধিক প্রসেস চালান, নয়তো এমন সংস্করণ চালান যা একসাথে কয়েকটি সকেট বাইন্ড করতে পারে।

2.7-এর আগে একটি প্রসেস একটি ট্রান্সপোর্ট বাইন্ড করে

কমিউনিটি সংস্করণ OpenVPN এমন সকেট বাইন্ড করে যা proto বর্ণনা করে, আর ওই ডিরেক্টিভ ইনস্ট্যান্সটির জন্য একটিই ট্রান্সপোর্ট বেছে নেয়। TCP ও UDP আলাদা স্ট্যাক, তাই একই পোর্ট নম্বর দুটোই একসাথে দখল করতে পারে, কিন্তু একটি প্রসেস পারে না। তাই 2.6 লাইন আপনাকে প্রতি ডেমন-এ একটি ট্রান্সপোর্ট দেয়। OpenVPN 2.7 সার্ভারদের জন্য সেই সীমাবদ্ধতা তুলে দিয়েছে, যারা একটি প্রসেসে একাধিক --local দিয়ে কয়েকটি সকেট বাইন্ড করতে পারে।

দুই উত্তর কোনটির ভিত্তিতে নকশা করার আগে সংস্করণ দেখে নিন, কারণ 2.7-এর বিন্যাস নিজস্ব কনফিগারেশন সিনট্যাক্সসহ আলাদা পরিচালন মডেল। 2.6-এর জন্য লেখা গাইড না বললেও দুটি প্রসেস বর্ণনা করে।

দুটি ইনস্ট্যান্স চালানোর তিন উপায়

TAP ইন্টারফেসে প্রতি ট্রান্সপোর্টে একটি ইনস্ট্যান্স চালান এবং হোস্টে দুটি tap ডিভাইস ব্রিজ করুন। দুই ক্লায়েন্ট দল একই ব্রডকাস্ট ডোমেইনে পড়ে, যা একটি ঠিকানা পুলকে তাদের ঢেকে দিতে দেয় এবং ব্রডকাস্ট-নির্ভর প্রোটোকল চালু রাখে। TUN-এ ব্রিজ নেই, তাই সরলতম বিভাজন প্রতিটি ইনস্ট্যান্সকে নিজের সাবনেট দেয় এবং রাউটিং দুই ক্লায়েন্ট দলকে আলাদা রাখে। তৃতীয় বিকল্পটি এক পুল রাখে, প্রতিটি ইনস্ট্যান্সকে একটি learn-address স্ক্রিপ্ট ডাকিয়ে, যা ওই ইনস্ট্যান্সের ডিভাইস দিয়ে ক্লায়েন্টের জন্য /32 রুট বসায়।

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

ArrangementInterfacesAddress poolCost
Bridged TAP pairTwo tap devices joined by a bridgeOne shared poolBroadcast traffic and bridge maintenance
Two TUN subnetsTwo tun devices, no bridgeOne pool per instanceRouting rules and two plans
Shared pool with routesTwo tun devices plus a hookOne pool across bothA script on the data path

দুটি ইনস্ট্যান্স আলাদা রাখুন

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

ইউনিট ও প্রোফাইলের নাম এমন দিন যেন ফাইলের নাম থেকেই ট্রান্সপোর্ট স্পষ্ট হয়. পরের অপারেটরকে কনফিগ খুলে জানতে হবে না কোনটি TCP।

প্রোফাইলকে লিসেনারের সাথে মিলান

proto tcp চালানো সার্ভার proto tcp-client সম্বলিত ক্লায়েন্ট প্রোফাইল আশা করে, আর যে প্রোফাইল এখনো proto udp বহন করে সেই লিসেনারের বিরুদ্ধে ব্যবহারকারী যার বিরুদ্ধে কিছু করতে পারে এমন ত্রুটি ছাড়াই সময় শেষ হয়ে যায়. ডিপ্লয়মেন্ট দুই ট্রান্সপোর্টই দিলে দুটি প্রোফাইল রাখুন এবং এমনভাবে লেবেল দিন যেন সাপোর্ট বুঝতে পারে কোনটি চেষ্টা করা হয়েছিল। শুধু পোর্ট নম্বর ট্রান্সপোর্ট বর্ণনা করে না।

ফায়ারওয়াল নিয়ম একই বিভাজন অনুসরণ করে: UDP 1194-এর নিয়ম TCP 1194 নিয়ে কিছু বলে না, আর এক ঠিকানার নিয়ম অন্য লিসেনারকে ঢাকে না।

আগে সার্ভারের দৃষ্টিভঙ্গি পড়ুন

সার্ভারে ss -lntup দিয়ে শুরু করুন এবং TCP ও UDP দুটি লিসেনারই দেখা যাচ্ছে তা নিশ্চিত করুন। তারপর প্রতিটি ধরনের একটি ক্লায়েন্ট সংযুক্ত করে স্ট্যাটাস আউটপুটে ভিন্ন ঠিকানার দুটি এন্ট্রি দেখুন। সকেট থাকলে কিন্তু কোনো ক্লায়েন্ট না এলে, ডেমন দেখার আগেই পথ বা ফায়ারওয়াল প্যাকেট প্রত্যাখ্যান করছে।

যে সকেট কখনো দেখা যায় না তা কনফিগারেশন বা বাইন্ড সমস্যা, আর যে সকেট দেখা যায় কিন্তু কখনো সংযোগ লগ করে না তা ফিল্টারিং সমস্যা। ক্লায়েন্টের দিক থেকে দুটোই একই রকম দেখায়, তাই সার্ভারের নিজের দৃষ্টিভঙ্গিই আগে। মনে রাখবেন TCP হেড-অব-লাইন ব্লকিং বহন করে, তাই এটি দেওয়া পরিচ্ছন্ন UDP পথ থাকা ক্লায়েন্টদের জন্য উন্নয়ন নয়, বরং পৌঁছানোর ব্যবস্থা।

সম্পর্কিত নিবন্ধ