LAN সার্ভারে VPN ক্লায়েন্ট: উত্তরগুলো কেন ভুল পথে যায়

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

উত্তর একটি নতুন প্যাকেট, পথের উল্টো যাত্রা নয়

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

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

বাকিটা পড়ার সময় দুটি সাবনেট মনে রাখুন। একটি হলো VPN অ্যাড্রেস পুল যেখান থেকে দূরবর্তী ক্লায়েন্টরা আসে, এই উদাহরণে 10.64.0.0/24। অন্যটি হলো LAN যা কাজ করতে থাকতে হবে, 172.16.24.0/24, যার রাউটার 172.16.24.1। বাগ হলো তাদের মধ্যকার ট্রাফিক ডিফল্ট রুট দিয়ে নির্ধারিত হচ্ছে।

ক্যাপচার ও লুকআপ দিয়ে এটি প্রমাণ করুন

কিছু বদলানোর আগে নিশ্চিত করুন উত্তর কোন ডিভাইস ব্যবহার করবে। লুকআপ ক্যাপচারের চেয়ে দ্রুত এবং প্যাকেট তৈরি হওয়ার সময় কার্নেল যে প্রশ্নের উত্তর দেবে ঠিক সেই প্রশ্নেরই উত্তর দেয়।

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

উত্তরটি দুটি ভাগে পড়ুন। যদি এটি dev tun0 নাম দেয়, হোস্ট উত্তরটি এনক্যাপসুলেট করে প্রোভাইডারের কাছে দেবে, এবং LAN ক্লায়েন্ট তা কখনোই দেখবে না। যদি এটি dev eth0 নাম দেয় কিন্তু ক্লায়েন্ট এখনও টাইমআউট পায়, রুট ইতিমধ্যে ঠিক আছে এবং প্যাকেট পরে ফেলে দেওয়া হচ্ছে, যা ভিন্ন সমস্যা ও ভিন্ন সমাধান।

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

টানেলকে ছাড়িয়ে যাওয়া সবচেয়ে সংকীর্ণ রুট ইনস্টল করুন

প্রিফিক্স দৈর্ঘ্যই নির্ধারক, মেট্রিক নয়, তাই LAN রাউটার দিয়ে ক্লায়েন্ট পুলের রুট VPN ক্লায়েন্ট যে কোনো ডিফল্ট ইনস্টল করুক তার চেয়ে জেতে। মেট্রিক সার্জারির দরকার নেই, আর ডিফল্ট ঠিক যেখানে ক্লায়েন্ট রেখেছে সেখানেই থাকতে পারে।

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

দ্বিতীয় add-এর বদলে replace ব্যবহার করুন, কারণ যে ক্লায়েন্ট আবার সংযুক্ত হবে সে ইতিমধ্যে নিজের এন্ট্রি ইনস্টল করে থাকবে এবং দ্বিতীয় add একটি বিদ্যমান-রুট ত্রুটিতে ব্যর্থ হয় যা অনুমতি সমস্যার মতো শোনায়। Windows হোস্টে সমতুল্য হলো route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, যেখানে -p রিবুটের পরেও এন্ট্রি রাখে, কারণ টানেল আবার উঠলে ক্লায়েন্ট টেবিলটি পুনর্নির্মাণ করতে পারে। আধুনিক Windows হোস্টে সমর্থিত সমতুল্য হলো New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, আর পুরোনো route কমান্ডটি লিগ্যাসি রূপে ধরে রাখা হয়েছে।

একটি বিবরণ ঠিক করে এটি সঠিক না কেবল বিশ্বাসযোগ্য: নেক্সট হপকে অবশ্যই সেই রাউটার হতে হবে যা ক্লায়েন্টদের ফেরার পথের প্রকৃত মালিক। এমন ঠিকানার দিকে রুট দেখানো যা নিজেই টানেল দিয়ে পৌঁছায়, একটি লুপ তৈরি করে যা পরিষ্কার ব্যর্থতার বদলে মাঝেমধ্যে ক্ষতি হিসেবে দেখা দেয়। লাইনটি প্রয়োগ করার আগে নিশ্চিত করুন নেক্সট হপ LAN সাবনেটে আছে।

পুনঃসংযোগের পরেও উত্তর ধরে রাখুন

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

স্টেটফুল ফায়ারওয়াল সঠিক রুটকেও হারাতে পারে। ক্যাপচার এখন দেখালে উত্তর eth0 দিয়ে বেরোচ্ছে অথচ ক্লায়েন্ট এখনও টাইমআউট পায়, তবে দেখুন হোস্ট পাঠানোর আগেই প্যাকেটটি ফেলে দিচ্ছে কি না। কঠোর রিভার্স-পাথ ফিল্টারিং এবং net.ipv4.conf.all.rp_filter-কে 1 সেট করা, এমন প্যাকেট ফেলে দেয় যার উৎস যে ইন্টারফেস দিয়ে এসেছে সেখান দিয়েই ফেরত রাউট হতো না, এবং এটিই ঠিক সেই অসমমিতিক কেস যা আপনি এইমাত্র তৈরি করে পরে ঠিক করেছেন, আর conntrack স্টেট ফরওয়ার্ড করা পোর্টের জন্য একই কথা বলে।

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