VPN পোর্ট খুললে ক্লায়েন্টরা LAN-এ পৌঁছায় না

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

দুটি চেইন, দুটি আলাদা গন্তব্য

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

গোটা কিংবদন্তি এক বাক্যে: শ্রোতাকে অনুমতি দেওয়া তার পিছনের নেটওয়ার্ককে অনুমতি দেওয়ার কথা কিছুই বলে না। এগুলি আলাদা প্রমাণসহ দুটি আলাদা সিদ্ধান্ত, আর দুটিতেই ইন্টারফেসের নাম থাকলেও তারা এক হয় না।

শ্রোতা নিয়ম আসলে কী অনুমতি দেয়

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

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

ক্লায়েন্ট থেকে পরীক্ষা করুন, গেটওয়ে থেকে কখনও নয়

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

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

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

ফরওয়ার্ডিংয়ে একটি নয়, তিনটি জিনিস লাগে

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

তিনটি আউটপুট একসঙ্গে পড়ুন। প্রথমটিতে শূন্য থাকলে বাকি দুটি অপ্রাসঙ্গিক, আর দ্বিতীয়টিতে ডিফল্ট-ড্রপ নীতি ক্লায়েন্টের প্যাকেট ফেলে দেয় যদিও গেটওয়ের নিজের ট্রাফিক চলতে থাকে। তৃতীয় আউটপুট দেখায় শ্রোতা নিয়ম কখনও সমস্যা ছিল না।

ডকুমেন্টেশনে দুটি নিয়মের সেট আলাদা রাখুন

শ্রোতা নিয়ম ও ফরওয়ার্ড করা সেবার নিয়ম আলাদা লাইনে, আলাদা মালিক ও কারণসহ লিখুন। VPN পোর্ট বদলালে বা নতুন সেবা প্রকাশিত হলে সেই পৃথকীকরণ একটি পরিবর্তনকে অন্যটি নিঃশব্দে বিস্তৃত করতে দেয় না।

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

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