TCP রিসেট মানে আপনার VPN ব্লক হচ্ছে না

ক্লায়েন্ট লগে “সংযোগ রিসেট, পুনরায় চালু হচ্ছে” দেখা যায়, আর সিদ্ধান্ত প্রমাণের আগেই এসে পড়ে। কেউ ঠিক করে নেয় নেটওয়ার্ক VPN ব্লক করছে, বা সার্টিফিকেট ভুল, বা নির্দিষ্ট কোনো দেশ হস্তক্ষেপ করছে। রিসেট হলো একটি TCP প্যাকেট যা একটি সংযোগ শেষ করে, এবং লগের লাইনটি শুধু লিখে রাখে যে আপনার ক্লায়েন্ট এমন একটি পেয়েছে। এটি পাঠানো ডিভাইসটির নাম বলে না, পাঠানোর কারণও বলে না।

রিসেট একটি প্যাকেট, রায় নয়

TCP রিসেট প্রক্রিয়াকরণ নির্ধারণ করে: RST ফ্ল্যাগযুক্ত সেগমেন্ট সংযোগটি সঙ্গে সঙ্গে শেষ করে। প্রাপক দরকষাকষি করে না, আবার চেষ্টা করে না, কারণও জিজ্ঞেস করে না। সে রিসেট জানায় এবং এগিয়ে যায়।

ক্লায়েন্ট শুধু এটুকুই জানে। RST সার্ভার, প্রক্সি, ফায়ারওয়াল বা অবস্থা হারানো লোড ব্যালান্সার থেকে আসতে পারে।

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

কোন সংযোগটি রিসেট হয়েছে তা নিশ্চিত করুন

প্রথমে দেখুন সক্রিয় প্রোফাইলটি সত্যিই TCP ব্যবহার করে কি না। UDP টানেলে রিসেট অর্থহীন, আর HTTP প্রক্সির লগ VPN-এর নিজের চেয়ে ভিন্ন TCP অংশ সম্পর্কে হতে পারে।

গন্তব্য, পোর্ট, চেষ্টার সময় এবং ক্লায়েন্ট যে ধাপে পৌঁছেছিল তা লিখুন।

ধাপটিই সবচেয়ে কাজের ক্ষেত্র। TLS হ্যান্ডশেকের সময় রিসেট একগুচ্ছ সন্দেহভাজনের দিকে ইঙ্গিত করে; প্রমাণীকরণের পরে রিসেট অন্য একগুচ্ছের দিকে। ধাপ ছাড়া সব তত্ত্বই খাপ খায়।

পথের দুই প্রান্ত মিলিয়ে দেখুন

আপনি যদি সার্ভার পরিচালনা করেন, একই চেষ্টার জন্য তার ঘটনাগুলো মিলিয়ে দেখুন। এটি সংযোগ গ্রহণ করেছিল? ইচ্ছাকৃতভাবে বন্ধ করেছিল? কোনো উত্তর একটি সীমানা ছেড়ে পরের সীমানায় পৌঁছায়নি?

সম্ভব হলে ক্লায়েন্টে ও সার্ভারে ক্যাপচার করুন। যে রিসেট ক্লায়েন্টে দেখা যায় কিন্তু সার্ভারে দেখা যায় না, তা সার্ভারে জন্মায়নি।

দুই দিকেই RST সেগমেন্ট খেয়াল করুন:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

নিয়ন্ত্রিত তুলনা দিয়ে সংকুচিত করুন

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

এটি এখনো নির্দিষ্ট কোনো মধ্যবর্তী ডিভাইস চিহ্নিত করে না। এটি পরিধিকে একটি রুটে সংকুচিত করে, যা একটি কাজের ও সৎ ফলাফল।

“এই পথ ব্যর্থ হয়” আর “এই নামযুক্ত পক্ষ এর কারণ” — এই পার্থক্যটি ধরে রাখুন। প্রথমটি পরীক্ষাযোগ্য; দ্বিতীয়টি সাধারণত একটি ক্লায়েন্ট থেকে নয়।

বিশ্বাসের সেটিংস না বদলে সমাধান যাচাই করুন

TLS যাচাই বন্ধ করবেন না, শংসাপত্র নতুন করে তৈরি করবেন না, আর এক লাইন রিসেটের ভিত্তিতে ব্লকিং নীতি ঘোষণা করবেন না। এর প্রত্যেকটি পরীক্ষাধীন সিস্টেম বদলে দেয় এবং পরের তুলনাটিকে অর্থহীন করে তোলে।

চিহ্নিত উপাদানটি তার মালিকের মাধ্যমে ঠিক করুন, তারপর একই প্রোফাইল ও একই পর্যবেক্ষণ পুনরাবৃত্তি করুন:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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