TCP 443 কি সত্যিই সাহায্য করে? কেবল যদি সার্ভার সেখানে শোনে
TCP প্রোফাইল একটি বিকল্প, ছদ্মবেশ নয়। সার্ভার যে ওই পোর্টে শোনে তা যাচাই করুন, তারপর দ্বৈত TCP-এর খরচ বনাম অপ্রাপ্যতা মিলিয়ে দেখুন।
TCP 443 একটি শর্তযুক্ত বিকল্প, কোনো ফিল্টার পেরিয়ে টানেল পাঠানোর ছদ্মবেশ নয়। এটি কাজ করে যখন অপারেটর ইতিমধ্যে ওই পোর্টে TCP শ্রবণকারী প্রকাশ করে এবং পথটি ঘণ্টার পর ঘণ্টা খোলা থাকা সংযোগ সহ্য করে। এর মধ্যে একটি অনুপস্থিত থাকলে এটি সাধারণত টাইমআউট হিসেবে ব্যর্থ হয়, আর টাইমআউট খুব কমই বলে কোনটি অনুপস্থিত। বদলাবেন কি না তা ঠিক করতে তিনটি প্রশ্ন লাগে, আর তাদের মধ্যে কেবল একটি পোর্ট নম্বর নিয়ে।
পোর্ট নম্বর কোনো পরিবহন প্রতিশ্রুতি নয়
পোর্ট একটি প্রান্তবিন্দুর নাম দেয়; TCP সেটিকে ক্রমবদ্ধ বাইট-প্রবাহে পরিণত করে; OpenVPN ঠিক করে ওই প্রবাহের ভিতরে কী চলাচল করবে। একই নম্বরে থাকা একটি ওয়েব সার্ভার সম্পূর্ণ ভিন্ন অ্যাপ্লিকেশন বিন্যাস ব্যবহার করে, তাই 443 পোর্ট ভাগ করা দুটিকে ফিল্টারের চোখে একরকম দেখায়, তার বেশি কিছু নয়। নম্বরটি ফিল্টার যে ইঙ্গিত পড়ে, তা-ই; প্যাকেটের ভিতরে কী থাকে তা বদলায় এমন কোনো বৈশিষ্ট্য নয়। কেবল একটি পোর্ট ভাগ করে বলে দুটিকে এক বলে ধরে নেওয়া এখানকার বেশিরভাগ বিভ্রান্তির পেছনের ভুল।
মধ্যস্থ বাক্সগুলো কোনো পোর্ট সম্পর্কে খুব কমই সরল অনুমতি-বা-নিষেধ সিদ্ধান্ত নেয়। অনেকেই প্রথম বাইটগুলো পরীক্ষা করে, কেউ গন্তব্য পিন করে, আবার কেউ বেশি সময় খোলা থাকা সংযোগ রিসেট করে। এজন্যই একই প্রোফাইল একটি নেটওয়ার্ক থেকে কাজ করতে পারে আর অন্যটি থেকে টাইমআউট হতে পারে, এবং এজন্যই বিকল্পটিকে প্রতিশ্রুতি হিসেবে বিশ্বাস না করে সমর্থিত বিকল্প হিসেবে পরীক্ষা করা উচিত। ফিল্টার যখন ট্রাফিক দেখে, পোর্ট নম্বর তার দেখা প্রথম জিনিস মাত্র।
প্রোফাইলে হাত দেওয়ার আগে শ্রবণকারী নিশ্চিত করুন
সার্ভারটিকে পোর্টে TCP-এর জন্য কনফিগার করা থাকতে হবে, আর ক্লায়েন্ট প্রোফাইলকে একই পরিবহন চাইতে হবে। UDP প্রোফাইল লিখে TCP চাওয়া শ্রবণকারী তৈরি করে না, আর যে টাইমআউট হয় তা পোর্ট ফেলে দেওয়া ফায়ারওয়াল থেকে আলাদা করা যায় না। অপারেটরের নিজের TCP প্রোফাইল থাকলে সেটি ডাউনলোড করুন, কারণ কিছু সেবা প্রতিটি পরিবহনের জন্য আলাদা প্রান্তবিন্দু ও আলাদা পরিচয় সেটিং প্রকাশ করে। হাতে সম্পাদনা নিয়ন্ত্রিত পরীক্ষার জন্য ঠিক, কিন্তু প্রোভাইডারের অভীষ্ট কনফিগারেশন আন্দাজ করার বাজে উপায়।
এই মিলের দুই দিক কনফিগারেশনে দেখা যায়, আর OpenVPN প্রকল্পের লিংক অপশন নথিতে দুই রূপই আছে। ন্যূনতম জোড়াটি এমন দেখায়:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443তিনটি শর্ত ঠিক করে বিকল্পটি লাভজনক কি না
প্রথম শর্ত হলো অপারেটর আদৌ ওই পরিবহন দেয়; তা না থাকলে বাকি কিছুই গুরুত্বপূর্ণ নয়। দ্বিতীয়টি হলো পথটি দীর্ঘস্থায়ী সেশন ধরে রাখে, কারণ কিছু নেটওয়ার্ক পোর্ট পুরোপুরি ব্লক করার বদলে খোলা থাকা সংযোগ রিসেট করে। তৃতীয়টি হলো বিকল্পটি ইচ্ছাকৃত ব্যতিক্রম, নাকি আপনি যে ত্রুটি সারাননি তা লুকানো কোনো অস্থায়ী ব্যবস্থা।
প্রতিটি শর্তের একটি সস্তা পরীক্ষা আছে। এর যেকোনোটিতে ব্যর্থতা ক্লায়েন্টের দিক থেকে একই দেখায়:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
পরিবহন তুলনা করার আগে ক্যাপটিভ পোর্টালে যেকোনো সাইন-ইন শেষ করুন। যে নেটওয়ার্ক আপনার ডিভাইসকে প্রবেশ করতে দেয়নি সেটি দুই পরিবহনই ব্লক করে, আর তখন তুলনাটি টানেল নয়, পোর্টালকে মাপে। সাইন ইন করুন, সাধারণ ব্রাউজিং কাজ করছে কি না নিশ্চিত করুন, তারপরেই পরীক্ষা শুরু করুন।
আপনি যে খরচ মানছেন: TCP-এর ভিতরে TCP
TCP হারানো সেগমেন্ট আবার পাঠায় এবং তাদের ক্রম রক্ষা করে। যখন এমন অ্যাপ্লিকেশন যা নিজেও TCP ব্যবহার করে TCP টানেলের ভিতরে চলে, তখন দুই পুনরুদ্ধার স্তর একই ক্ষতিতে সাড়া দেয়, আর এই মিথস্ক্রিয়াই ক্ষতিপূর্ণ পথে টানেলকে ধীর অনুভব করায়। লক্ষণটি পরিষ্কার ব্যর্থতা নয়, বরং বিলম্ব ও কম্পন, যা দূর প্রান্তকে দোষারোপ করা সহজ করে তোলে। সিদ্ধান্তে পৌঁছানোর আগে ক্লায়েন্টের দিক থেকে দুই পরিবহনেই মাপুন।
UDP এই নেস্টিং এড়ায়, আর এটাই প্রধান কারণ অপারেটররা এটি পছন্দ করে এবং TCP শুধু বিকল্প হিসেবে দেয়। স্থিতিশীল TCP সংযোগ তবুও অপ্রাপ্য UDP সংযোগের চেয়ে বেশি কাজে আসে, তাই তুলনাটি ভালো বনাম খারাপ বিকল্পের নয়, দুই বাস্তব খরচের মধ্যে। তুলনা করার সময় ডিভাইস ও অ্যাক্সেস নেটওয়ার্ক অপরিবর্তিত রাখুন, নইলে ফলাফল ভুল চলকটিকে বর্ণনা করবে।
কিছু ক্লায়েন্ট বৈশিষ্ট্য কেবল একটি পরিবহনের জন্য নথিভুক্ত, তাই বিকল্প প্রোফাইল আপনি যে আচরণের উপর নির্ভর করতেন তা নীরবে বাদ দিতে পারে। TCP প্রোফাইলকে সরাসরি বদল ভাবার আগে অপশনটির পরিবহন-চাহিদা পড়ুন।
ভিন্ন পরিবহন যে ত্রুটিগুলো ছোঁয় না
মেয়াদোত্তীর্ণ সার্টিফিকেটের এখনও ঘড়ি যাচাই বা নবায়ন দরকার, আর প্রত্যাখ্যাত অ্যাকাউন্টের এখনও সঠিক পরিচয়পত্র দরকার। অপারেটর যে সার্ভার-পরিচয় যাচাই দিয়েছে তা রাখুন, কারণ পরিচিত পোর্ট নম্বর কাউকে প্রমাণিত করে না। যে পোর্ট উত্তর দেয় সে কেবল বলে যে কিছু একটা শুনছে।
টানেল উঠে এলেও গন্তব্যগুলো যদি ব্যর্থ হয়, তবে বাকি সমস্যা সংযোগের পরে রাউটিং বা নাম-সমাধান, পরিবহন নয়। পোর্ট বদলাতে বদলাতে ঘোরার বদলে ওই পথটি অনুসরণ করুন, কারণ এভাবেই একটা বিকেল হারিয়ে যায়। প্রোফাইল বলে কোন পরিবহন চেষ্টা করবেন; কেন UDP পথ ব্যর্থ হলো তা কখনও বলে না।