OpenVPN বাড়িতে কাজ করে কিন্তু একটি নেটওয়ার্কে কাজ করে না: UDP নাকি TCP?

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

কোন ধাপে ব্যর্থ হলো তা বলে দেয় কোন তুলনাটি গুরুত্বপূর্ণ

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

পুনরায় চেষ্টা করার সময় ক্যাপচার করুন, পরে নয়। ক্লায়েন্টে tcpdump -ni any udp port 1194 দেখায় আদৌ কোনো উত্তর ফেরত আসে কি না। আপনি যে সার্ভার নিয়ন্ত্রণ করেন তার WAN ইন্টারফেসে এটি পুনরাবৃত্তি করুন, যা প্রকাশ করে ওই প্যাকেটগুলো আদৌ দূর প্রান্তে পৌঁছায় কি না।

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

UDP ফিল্টারিং বনাম বন্ধ পোর্ট

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

পোর্ট 443-এ একটি TCP প্রোফাইল সাধারণ সমাধান, কারণ এটি সাধারণ HTTPS প্রবাহের মতো এবং বেশিরভাগ ক্যাপ্টিভ পোর্টাল ও এগ্রেস ফিল্টার পেরিয়ে যায়। দুটি শর্ত পূরণ হতে হবে। সার্ভারকে proto tcp-server দিয়ে শুনতে হবে এবং ক্লায়েন্টকে proto tcp-client দিয়ে মিলতে হবে, আর অপারেটরকে সেই বিকল্প এন্ডপয়েন্ট প্রকাশ করতে হবে। কাজ করা UDP প্রোফাইল পুনর্লিখন করে TCP 443 দাবি করা কিছুই অর্জন করে না যখন অন্য প্রান্তে কেউ শুনছে না।

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

পুরোনো প্রোটোকল এই অক্ষে খারাপভাবে তুলনীয়। PPTP-এর TCP 1723 এবং GRE দরকার, আর GRE হলো IP প্রোটোকল 47, পোর্ট নয়, তাই কোনো সাধারণ পোর্ট ফরওয়ার্ড তা প্রকাশ করে না।

যখন সুইচই প্যাকেট ফেলে দিচ্ছে

একটি ম্যানেজড সুইচ ইচ্ছাকৃতভাবে টানেল ফেলে দিতে পারে। কিছু HPE ও Aruba মডেল তাদের উন্নত নিরাপত্তা বিভাগে UDP ফ্লাড সুরক্ষা নিয়ন্ত্রণ দেয়, মাঝে মাঝে Prevent UDP Blat Attack লেবেলযুক্ত। সেই নিয়ন্ত্রণ সক্রিয় হলে সুইচের পিছনের সার্ভার কিছুই উত্তর দেয় না এবং প্রতিটি ক্লায়েন্ট একইভাবে সময় শেষে বন্ধ হয়। এটি সরিয়ে চলমান কনফিগারেশন সংরক্ষণ করাই পুরো মেরামত, তবে কেবল সুইচটি সত্যিই পথে আছে তা নিশ্চিত করার পরে।

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

প্রোফাইল বদলানোর আগে ক্লায়েন্ট ও সার্ভারের মধ্যে প্রতিটি ডিভাইস লিখে রাখুন। ভুল স্তরে প্রয়োগ করা সমাধান পরের নেটওয়ার্ক পর্যন্ত সঠিক দেখায়। ওই তালিকা পরবর্তী প্রকৌশলীকে পুরো তদন্ত পুনরাবৃত্তি না করেই কোথায় দেখতে হবে তা বলে দেয়।

একটি ঠিকানা ওভারল্যাপ যা DNS ব্যর্থতার মতো দেখায়

10.0.0.0/8-এর ভিতরে নম্বরযুক্ত একটি অ্যাক্সেস নেটওয়ার্ক টানেল পুলের সঙ্গে ওভারল্যাপ করতে পারে, এবং রিজলভার সাধারণত ওই পুলের ভিতরেই থাকে। ল্যাপটপ যখন Wi-Fi-তে /8 মাস্কসহ 10.184.178.50-এর মতো ঠিকানা পায়, তখন প্রতিটি 10.x গন্তব্য সংজ্ঞা অনুযায়ী স্থানীয়। 10.4.0.1-এর প্যাকেট তখন LAN-এ যায়, টানেল চালু থাকে, এবং নাম সমাধান ব্যর্থ হয়।

ip addr এক নজরে ওভারল্যাপ প্রকাশ করে, আর ip route get 10.4.0.1 দেখায় প্যাকেটটি সত্যিই কোথায় পৌঁছে দেওয়া হবে। দৃশ্যমান লক্ষণটি রিজলভার ব্যর্থতা হওয়ায় এটি প্রায়শই DNS পরিবর্তনের কয়েক দফা পেরিয়ে টিকে থাকে।

পুলটি পুনঃনম্বর করুন বা ওই অ্যাক্সেস নেটওয়ার্ককে পরিধির বাইরে রাখুন। কোনো ক্লায়েন্ট-সাইড সেটিং ওভারল্যাপ থেকে পুনরুদ্ধার করে না।

TCP ফলব্যাক ও পথ-সংস্কারের মধ্যে সিদ্ধান্ত

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

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