রাউটারের VPN কাজ করছে, কিন্তু LAN ক্লায়েন্টের ইন্টারনেট নেই

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

ব্যর্থতা LAN হোস্ট থেকে পড়ুন

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

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

স্থানীয় ট্রাফিক ও ফরওয়ার্ড করা ট্রাফিক আলাদা

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

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

ফেরার পথও থাকতে হবে

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

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

ক্লায়েন্ট DNS একই পর্যালোচনার অংশ। রাউটারের রিজলভার উত্তর দিতে পারে, অথচ ভিন্ন সার্ভারে নির্দেশিত ক্লায়েন্ট কিছুই পায় না।

একটি অনুমোদিত ও একটি প্রত্যাখ্যাত প্রবাহ যাচাই করুন

সংশোধনের পর রাউটারের চলমান সেশনের বদলে ক্লায়েন্ট থেকে নতুন সংযোগ পরীক্ষা করুন। তারপর নিশ্চিত করুন যে টানেল ব্যবহার করা উচিত নয় এমন সেগমেন্ট এখনও সেটি ব্যবহার করছে না।

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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