Synology-তে OpenVPN হ্যান্ডশেক ব্যর্থ? LAN ফরওয়ার্ড পরীক্ষা করুন

আপনার ল্যাপটপ জানায় যে TLS হ্যান্ডশেক ব্যর্থ হয়েছে, তাই সার্টিফিকেট নতুন করে বানানোর প্রলোভন জাগে। তার আগে আরও সাদামাটা প্রশ্ন করুন: Synology আসলে কোন Ethernet পোর্টে শুনছে? দুই LAN পোর্টের NAS-এ দুইটি ঠিকানা থাকে, আর DSM-এর VPN Server প্যাকেজ তার OpenVPN শ্রোতাকে তাদের একটিতে বাঁধে। রাউটার 1194 অন্য ঠিকানায় ফরওয়ার্ড করলে কোনো প্যাকেটই সেবায় পৌঁছায় না, আর ক্লায়েন্টের দর-কষাকষি করার মতো কিছু থাকে না।

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

শ্রোতা যে ঠিকানায় বাঁধা আছে সেটি খুঁজুন

DSM তার পোর্টগুলোর নাম দেয় LAN 1 আর LAN 2, আর প্রতিটির আলাদা ঠিকানা ও সাবনেট থাকে। VPN Server খুলুন, OpenVPN ট্যাবে উল্লিখিত ইন্টারফেসটি পড়ুন, তারপর Control Panel খুলে DSM-এর সেই একই ইন্টারফেসের IPv4 ঠিকানাটি লিখে নিন। ফরওয়ার্ডকে নাম দিতে হবে এই দুই মান, NAS-এর হোস্টনেম নয়।

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

SSH দিয়ে সকেটটির দিকেই তাকান, কারণ ডেমন আসলে কোথায় বাঁধা পড়েছে তা কেবল এখানেই দেখা যায়, সেটিংস পৃষ্ঠা যা বোঝাতে চায় তা নয়।

sudo netstat -anp | grep 1194

নতুন আরেকটি যোগ না করে বিদ্যমান ফরওয়ার্ডটিই সম্পাদনা করুন

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

external 1194/udp  ->  192.0.2.20:1194/udp

অভ্যন্তরীণ পোর্ট শোনার পোর্টের সমান রাখুন, আর প্রোটোকল সামঞ্জস্যপূর্ণ রাখুন। UDP 1194 ডিফল্ট শ্রোতা, অথচ TCP প্রোফাইলের প্যাকেজের দিকে নিজের শ্রোতা আর রাউটারে মিলতে থাকা ফরওয়ার্ড দরকার। যে সেবা কেবল UDP-তে শোনে তার কাছে TCP ফরওয়ার্ড করলে ত্রুটি নয়, নীরবতা মেলে।

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

প্যাকেট আদৌ পৌঁছায় কি না তা প্রমাণ করুন

প্রথমে NAS-এ ক্যাপচার শুরু করুন, তারপর ক্লায়েন্ট থেকে সংযোগ করুন, আর আউটপুটে উৎস ঠিকানাটি পড়ুন। ব্যর্থতার পরে শুরু করা ক্যাপচার কিছুই দেখায় না আর কিছুই প্রমাণ করে না।

sudo tcpdump -i any -n udp port 1194

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

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

প্যাকেট এলে ফরওয়ার্ডকে দোষ দেওয়া বন্ধ করুন

প্রোফাইলই পরের সন্দেহভাজন, আর স্বাভাবিক কারণটি হলো পুরোনো হওয়া। রপ্তানি করা একটি .ovpn ফাইলে রপ্তানির মুহূর্তের কর্তৃত্ব ও উপাদান থাকে, তাই যে প্যাকেজের সার্টিফিকেট পরে বদলানো হয়েছে সেটি পুরোনো কপি বহন করা ক্লায়েন্টকে প্রত্যাখ্যান করবে।

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

দূরবর্তী ব্যবহারকারী আসলে যে পথে যায় সেটি পরীক্ষা করুন

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

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