VPN-এর জন্য ভাড়া লাইন? আগে প্রয়োজনটি অনুবাদ করুন

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

পণ্যের নাম নয়, প্রয়োজনটি অনুবাদ করুন

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

এই পার্থক্যই পুরো কারণ যে একটি লাইনের প্রয়োজন বৈধ হতে পারে এবং তবুও VPN-এর প্রয়োজন নয়। শুধু সিরিয়াল ইন্টারফেসযুক্ত একটি গেটওয়ে সত্যিই সিরিয়াল হ্যান্ডঅফ চায়, এবং এটি প্রোটোকলের নয়, হার্ডওয়্যারের সীমাবদ্ধতা। অ্যাপ্লায়েন্স বদলান, সীমাবদ্ধতা অদৃশ্য হয়। প্রতিটি প্রয়োজন "গেটওয়ের X দরকার কারণ Y" আকারে লিখুন, এবং যে লাইন সম্পূর্ণ করা যায় না তা প্রত্যাখ্যান করুন।

গতি বলার আগে হ্যান্ডঅফের নাম দিন

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

কানেক্টর, গতি নেগোসিয়েশন এবং মিডিয়া কনভার্টার বা রাউটার কে সরবরাহ করে তা নিশ্চিত করুন। তারপর নিশ্চিত করুন আপনার দায়িত্ব কোথায় শেষ, কারণ সীমানা বিন্দুই ঠিক করে 03:00-এ লিংক পড়ে গেলে কে কী স্পর্শ করতে পারবে। সেই সীমা লাইন শনাক্তকারীর পাশে রেকর্ডে লিখুন। এই একটিই লাইন যা একটি সহায়তা কলকে এক ঘণ্টার ট্রান্সফারের বদলে পাঁচ মিনিটের কথোপকথনে বদলে দেয়।

ip -br link show
ethtool eth0 | head -20
sudo lshw -class network -short

শুধু ঠিকানা নয়, IP সরবরাহ নিশ্চিত করুন

পরিষেবাটি আসলে কোন ঠিকানা বা প্রিফিক্স সরবরাহ করে এবং তা স্থির কি না জিজ্ঞাসা করুন। যে লাইন গতিশীল ঠিকানা দেয় তা সাইট-থেকে-সাইট গেটওয়ের জন্য অনুপযুক্ত, কারণ পিয়ার কনফিগারেশনকে আপনার অনির্ধারিত পরিবর্তন সহ্য করতে হবে। প্রিফিক্সের দৈর্ঘ্যও নিশ্চিত করুন, কারণ একটি ঠিকানা আর রাউটেড /29 আলাদা পণ্য।

তারপর জিজ্ঞাসা করুন আপনার কাছে পৌঁছানোর আগে কিছু ঠিকানাটি অনুবাদ করে কি না। প্রদানকারীর দিকের NAT বা পরিষেবার সামনে ক্যারিয়ার-গ্রেড NAT আগত সেশন ভেঙে দেয়, তাই দূরবর্তী সাইট থেকে IPsec গ্রহণ করতে চাওয়া গেটওয়ে পৌঁছানো যায় না। গতি এর ক্ষতিপূরণ দেয় না: আপনার নিয়ন্ত্রণে নেই এমন অনুবাদকের পেছনের দ্রুত লিংকও এমন পোর্টে আগত সংযোগ নিতে পারে না যা কেউ ফরোয়ার্ড করে না।

রাউটার ও DNS কার মালিকানায় তা লিখুন। প্রদানকারী রাউটার দিলে আপনি তার ফার্মওয়্যার, তার NAT আচরণ এবং ডিফল্ট রুট সম্পর্কে তার ধারণা উত্তরাধিকারী হন, আর পরবর্তী প্রতিটি পরিবর্তন টিকিটের মধ্য দিয়ে যায়। আপনার নেটওয়ার্কের বাইরের কাউকে সেই পোর্টে আগত সংযোগের চেষ্টা করতে দিন যা আপনার কাছে পৌঁছানো উচিত, কারণ এটিই একমাত্র পরীক্ষা যা অনুবাদের গল্প প্রমাণ করে।

ip -br addr
ip route get 198.51.100.10
traceroute -n 198.51.100.10

উভয় দিকে কাজের চাপ থেকে ক্যাপাসিটি নির্ধারণ করুন

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

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

পরিচালনামূলক প্রতিশ্রুতি নির্ধারণ করুন

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

সহায়তার সীমাও লিখুন। প্রদানকারীর দায়িত্ব যদি এমন হ্যান্ডঅফে শেষ হয় যা আপনার নিজের রাউটার সমাপ্ত করে, তাহলে প্রতিটি ঘটনার প্রথম ঘণ্টা যায় ত্রুটির মালিক কে তা ঠিক করতে, আর কোনো SLA ঘড়ি তা ঢাকে না।

লিখিত শর্তের বিপরীতে লাইন যাচাই করুন

পরিষেবা চালু হলে আপনি আসলে যে বৈশিষ্ট্যের জন্য চুক্তি করেছেন তা মাপুন, ইনস্টলার যা প্রদর্শন করেছে তা নয়। প্রকৃত পথে থ্রুপুট, লেটেন্সি ও ক্ষতি হলো প্রমাণ, এবং তা এমন সময়ে ও স্থান থেকে ধারণ করতে হবে যা আপনি নাম দিতে পারেন। ব্যস্ত সময়েও পরিমাপ পুনরাবৃত্তি করুন, কেবল হস্তান্তরের সময় নয়। শান্ত দিনে 10:00-এ চালানো একটি গ্রহণযোগ্যতা পরীক্ষা 15:00-এর লিংক সম্পর্কে আপনাকে খুব কম বলে।

iperf3 -c speed.example.net -t 30 -P 4
mtr -n --report -c 50 198.51.100.10
curl -sS -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' https://speed.example.net/

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

পরিশেষে, সরবরাহ করা হয়েছে তার বিপরীতে চারটি গেট আবার পড়ুন। হ্যান্ডঅফ, IP সরবরাহ, ক্যাপাসিটি ও সহায়তার শর্ত—প্রতিটির রেকর্ডে একটি লাইন আছে, আর প্রতিটি লাইনের পাশে একটি নাম আছে।