একই রাউটারের পেছনে কেন কেবল একটি VPN ক্লায়েন্ট সংযুক্ত হয়

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

ক্লায়েন্ট স্পর্শ করার আগে গেটওয়ে লগ পড়ুন

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

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

কিছু বদলানোর আগে ফলাফলটি লিখে রাখুন, কারণ লগের তিনটি ফলাফল তিনটি আলাদা মেরামতে নিয়ে যায়। তিনটির মধ্যে কোনটি দেখেছেন তা লেখা একটি টীকা ক্লায়েন্টের ত্রুটির স্ক্রিনশটের চেয়ে বেশি মূল্যবান।

রাউটার GRE ও NAT-T নিয়ে কী করে

PPTP হলো চিরাচরিত অপরাধী: কন্ট্রোল চ্যানেল TCP 1723, আর ডেটা পথ GRE, অর্থাৎ IP প্রোটোকল 47। অনেক গ্রাহক-রাউটার একটি PPTP হেল্পার নিয়ে আসে যা কেবল একটি কন্ট্রোল সংযোগ অনুসরণ করে, তাই একই NAT-এর পেছনে দ্বিতীয় ক্লায়েন্ট তার কন্ট্রোল চ্যানেল খুলে কোনো ডেটা পথই পায় না। 47 নম্বরের TCP পোর্ট ফরওয়ার্ড করলে GRE-র জন্য কিছুই হয় না, কারণ GRE একটি প্রোটোকল নম্বর, পোর্ট নয়।

L2TP IPsec-এর ওপর নকশা অনুযায়ী ভিন্নভাবে আচরণ করে: IKE UDP 500 ব্যবহার করে, NAT ট্রাভার্সাল সুরক্ষিত পেলোডকে UDP 4500-এ সরায়, আর এনক্যাপসুলেশনটি থাকে ঠিক যাতে একটি ঠিকানার পেছনে থাকা কয়েকটি ক্লায়েন্ট একই গেটওয়েতে পৌঁছাতে পারে। এই নকশা কোনো গেটওয়ে বা মাঝখানের বক্সকে প্রতি-ঠিকানা সেশন-সীমা আরোপ করা থেকে বিরত করে না, আর সোফা থেকে দুই ব্যর্থতাই একই রকম দেখায়। SoftEther-এর নিজস্ব প্রোটোকলে একই শ্রেণির সমস্যা আছে, যেখানে কাজ করা পাস-থ্রু ছাড়া রাউটার LAN থেকে প্রথম ক্লায়েন্টকে ঢোকার সুযোগ দেয় আর দ্বিতীয়টিকে ফেলে দেয়। রাউটারের ALG বা পাস-থ্রু সুইচ দুই অবস্থাতেই পরীক্ষা করুন, কারণ পুরোনো ক্লায়েন্টের জন্য লেখা হেল্পার বর্তমান ক্লায়েন্টের পাঠানো প্যাকেট নষ্ট করতে পারে।

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

পরিবহন-সীমার মতো দেখতে পরিচয়-সীমা

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

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

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

লগ এন্ট্রির সাথে মেরামত মিলিয়ে নিন

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

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

দুটি জীবন্ত সেশন যাচাই

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

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