VPN সংযোগ হয় কিন্তু LAN ডিভাইসে পৌঁছায় না: কী পরীক্ষা করবেন

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

এখন থেকে গেটওয়ের অপর পাশে কিছু পরীক্ষা করুন। ফরওয়ার্ডিং যতই নষ্ট থাকুক, গেটওয়ের নিজের ঠিকানা উত্তর দিতে থাকবে।

গেটওয়ে নিজের স্ট্যাক থেকেই উত্তর দেয়

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

টানেলের মধ্য দিয়ে পৌঁছানো প্রশাসনিক পাতাগুলোও প্রথম শ্রেণিতে পড়ে। সেগুলো টানেল সম্পর্কে প্রমাণ, তার পেছনের নেটওয়ার্ক সম্পর্কে নয়।

প্রবাহটিকে প্রথম যে সীমানা এটি ফেলে দেয় সেখানে অনুসরণ করুন

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

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

ফেরার রুট ও হোস্ট ফায়ারওয়াল আলাদাভাবে ব্যর্থ হয়

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

ক্লায়েন্ট থেকে পাঠিয়ে এবং ফেরা লক্ষ্য করে ফেরার পথটি ইচ্ছাকৃতভাবে পরীক্ষা করুন। একমুখী ক্যাপচার সেকেন্ডের মধ্যে সেই প্রশ্ন নিষ্পত্তি করে যা এক ঘণ্টার অনুমান পারবে না।

ক্লায়েন্টের উৎস ঠিকানা দিয়ে প্রতিটি হপ নিশ্চিত করুন

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

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

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

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