VPN ক্লায়েন্টের পেছনের সার্ভার কেন টানেল দিয়ে উত্তর দেয়

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

উত্তর রুট হয়, মনে রাখা হয় না

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

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

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

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

প্রথম কমান্ড দেখায় এখন কোন ডিফল্ট জিতছে। দ্বিতীয়টি জানায় কঠোর ফিল্টারিং বিশ্বব্যাপী নাকি প্রতি ইন্টারফেসে প্রযোজ্য, আর তৃতীয়টি দেখায় ফরোয়ার্ড চেইনের কোনো নিয়ম জড়িত থাকতে পারে কি না।

ফিরতি পথ রাখার তিনটি উপায়

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

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

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

প্রথম দুই কমান্ড পাবলিক ঠিকানা থেকে আসা উত্তরের জন্য বিকল্প পথ তৈরি করে। তৃতীয়টি কার্নেলকে জিজ্ঞাসা করে ঠিক ওই উৎস ও গন্তব্য কোন পথ নেবে, আর এভাবেই নিয়মের কোনো প্রভাব আছে কি না নিশ্চিত করেন।

সোর্স ট্রান্সলেশন তৃতীয় বিকল্প এবং একমাত্র যা সার্ভিসের সামনে ইতিমধ্যে NAT করা রাউটারের সামনে টিকে থাকে। উত্তরকে সেই রাউটারে ফিরতে হয়, আর WAN ইন্টারফেসে মাস্কারেডিং তা অর্জন করে এবং ক্লায়েন্টকে সার্ভিস লগ থেকে লুকায়। সংযোগের পর ডিফল্ট রুট হাতে বদলানো একটি ডায়াগনস্টিক, কারণ পরের বার পুনঃসংযোগে ক্লায়েন্ট টেবিলটি আবার লেখে।

যখন বক্সটি LAN-এর জন্যও রুট করে

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

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

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

কারণগুলো আলাদা করার তিনটি পরীক্ষা

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

আগে রাউটিং প্রশ্নটি ঠিক করুন, তারপর নাম দেখুন। দুটো মিশিয়ে ফেলাই কাজ করা সার্ভারকে ভাঙা রিজলভারের জন্য দোষী বানায়।

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