proto udp নাকি tcp-client: আপনার সার্ভার কোনটি শোনে?

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

নির্বাচিত সংযোগ যে পরিবহন ব্যবহার করে তা পড়ুন

একটি প্রোফাইলে একাধিক remote এন্ট্রি থাকতে পারে, এবং প্রত্যেকটি নিজের পরিবহন উল্লেখ করতে পারে। ক্লায়েন্ট সেগুলো ক্রমানুসারে কাজ করে, তাই আপনি প্রথমে যে লাইনটি দেখেন সেটিই প্রযোজ্য লাইন নাও হতে পারে।

যে এন্ট্রিটি সত্যিই চেষ্টা করা হচ্ছে সেটি খুঁজুন, তারপর তার পরিবহন পড়ুন। ক্রম গুরুত্বপূর্ণ, কারণ ক্লায়েন্ট নিঃশব্দে পরেরটিতে যায় না। কিছু বিল্ড কেবল সময় শেষ হওয়ার পরেই পরের এন্ট্রি চেষ্টা করে, তাই ফাইলের নিচের একটি কার্যকর বিকল্প আপনার প্রত্যাশার চেয়ে কয়েক সেকেন্ড দেরিতে পৌঁছায়। প্রথম লাইন জিতেছে ধরে নেওয়ার বদলে লগে চেষ্টা করা এন্ডপয়েন্টটি দেখুন।

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

grep -nE '^(remote|proto)\b' client.ovpn

UDP ও TCP কোনো গতির সেটিং নয়

UDP কোনো ক্রমবদ্ধ স্ট্রিম না বানিয়ে ডেটাগ্রাম পাঠায়, তাই টানেলের নিজস্ব ট্রাফিক দ্বিতীয় নির্ভরযোগ্য পরিবহনের ভিতরে মোড়া হয় না। TCP আপনাকে এমন নেটওয়ার্কের মধ্য দিয়ে পথ দেয় যা UDP ফেলে দেয় বা ব্লক করে, তবে এর বিনিময়ে নেস্টেড পুনঃপ্রেরণ আসে যা ক্ষতিকর লিংককে আরও খারাপ লাগাতে পারে।

এটি একটি নাগালের বিনিময়, কোনো সর্বজনীন তুলনা নয়। সঠিক পছন্দ হলো যা ক্লায়েন্টের সামনের নেটওয়ার্ক অনুমোদন করে। যে পথ VPN পোর্টে UDP ফেলে দেয় সেটি কখনও দরকষাকষি করবে না, প্রোফাইল যত ভালোভাবেই লেখা হোক। পথ পরীক্ষা করুন, তারপর পরিবহন বাছুন।

শুধু বেঞ্চমার্কের ভিত্তিতে তাদের মধ্যে বাছাই করা ভুল, কারণ উত্তর নির্ভর করে আপনার সামনের নেটওয়ার্ক কী অনুমোদন করে তার উপর। একটি হোটেল বা কর্পোরেট প্রক্সি 443 পোর্টে শুধু বহির্গামী TCP অনুমোদন করতে পারে এবং আর কিছু নয়, তাই প্রদানকারীরা ওই ভ্যারিয়েন্টটি দেয়। পোর্ট নম্বরটি পরিচিত হলেও এটি ওই পোর্টে একটি OpenVPN সংযোগ, HTTPS সেশন নয়।

tcp-client আসলে কী বোঝায়

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

মিলে যাওয়া মানে দুই প্রান্ত পরিবহনে একমত, একই স্ট্রিং ভাগ করে নয়।

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

প্রোফাইল ভুল ধরে নেওয়ার আগে সার্ভারকে জিজ্ঞাসা করুন এটি কী শুনছে। UDP শ্রবণকারী TCP সকেট তালিকায় দেখা যায় না, এবং উল্টোটাও সত্য, তাই সাধারণ দৃশ্যের বদলে প্রোটোকল-নির্দিষ্ট দৃশ্য দেখুন।

যখন প্রোফাইল আমদানি হয় কিন্তু কখনও সংযোগ করে না

সঙ্গে সঙ্গে সময় শেষ হওয়া একটি আমদানি করা প্রোফাইল সাধারণত কোনো প্রমাণীকরণের আগেই ব্যর্থ হয়। প্যাকেটটি কোনো শ্রবণকারী ছাড়া পোর্টে যায়, অথবা নেটওয়ার্ক এটি নিঃশব্দে ফেলে দেয়।

সরলতম উপায়ে পথটি পরীক্ষা করুন: ব্যর্থ ক্লায়েন্টের মতো একই নেটওয়ার্ক থেকে, প্রোফাইল যে পরিবহনের দাবি করে সেটি দিয়ে একই হোস্ট ও পোর্টে সংযোগ করুন।

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

কার্যকর পরিবহনটি লিখে রাখুন

একবার কোনো মিশ্রণ কাজ করলে, সার্ভার, পোর্ট ও প্রোটোকলসহ এটি লিখে রাখুন এবং কোন নেটওয়ার্ক থেকে পরীক্ষা করা হয়েছে তা টুকে রাখুন।

নাহলে পরবর্তী যে ব্যক্তি সময় শেষের সমস্যায় পড়বে সে একই পরীক্ষা উল্টো দিকে করবে, এবং সম্ভবত একটি সার্ভার বদলে দেবে যা ঠিকই ছিল।

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