LAN রাউটার ও VPN ক্লায়েন্ট: দুটি ডিভাইস, দুটি রুট টেবিল

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

কোনো রুটে হাত দেওয়ার আগে দুটি হপ আঁকুন

একটি উদাহরণস্বরূপ বিন্যাস নিন: LAN হোস্ট 192.168.50.0/24, সাধারণ রাউটার 192.168.50.1, একটি নিবেদিত ক্লায়েন্ট 192.168.50.15 এবং একটি দূরবর্তী LAN 10.60.0.0/24 যা শুধু ওই ক্লায়েন্টের রাখা টানেল দিয়েই পৌঁছানো যায়। দুটি প্রাইভেট রেঞ্জের কোনোটিই অন্যটির সঙ্গে ওভারল্যাপ করে না, আর টানেলের নিজস্ব ঠিকানা পরিকল্পনা আছে।

দুটি প্রাইভেট রেঞ্জই গুরুত্বপূর্ণ, কারণ তারা ঠিক করে দেয় কোন ডিভাইস উত্তর দিতে পারবে। দূরবর্তী পক্ষ দেখবে প্যাকেটটি ক্লায়েন্টের টানেল ঠিকানা থেকে আসছে, আর তার উত্তরকে 192.168.50.0/24-এ ফেরার পথ খুঁজতে হবে। শুধু বাইরের দিকটি কনফিগার করা থাকলে অনুরোধ কাজ করতে পারে, অথচ উত্তর উধাও হয়।

ধাপ 1: রাউটারকে টানেলের দিকে নয়, ক্লায়েন্টের দিকে নির্দেশ করুন

LAN রাউটারে এমন একটি গন্তব্য রুট যোগ করুন যার পরবর্তী হপ ক্লায়েন্টের LAN ঠিকানা:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

ওই রেকর্ডটি বলে “এটি সেই মেশিনে পৌঁছাও যা টানেল করতে পারে”। এটি টানেল কীভাবে তৈরি হয় তা নিয়ে কিছু বলে না, এবং এটি ক্লায়েন্টের নিজের রুটের বিকল্প নয়। ম্যানেজড রাউটারে সমতুল্যটি ডিভাইসের স্ট্যাটিক-রুট পাতায় থাকে; Linux রাউটারে এটি LAN-এর মালিক ইন্টারফেস কনফিগারেশনে থাকে, আপনার বন্ধ করে দেওয়া শেলে নয়।

দ্বিতীয় কমান্ডের উত্তর দেখুন। যদি এটি ক্লায়েন্টকে gateway এবং LAN ইন্টারফেসকে device হিসেবে দেখায়, তবে প্রথম হপ ঠিক আছে এবং বাকি কাজ অন্য মেশিনে।

ধাপ 2: ক্লায়েন্টকে টানেলের দিকের নিজস্ব রুট দিন

ক্লায়েন্ট এখন 10.60.0.0/24-এর জন্য একটি প্যাকেট পায় এবং নিজের টেবিল দেখে। যদি তার টানেল কনফিগারেশন ওই প্রিফিক্সের জন্য রুট ইনস্টল করে থাকে, প্যাকেটটি এনক্রিপ্টেড অবস্থায় চলতে থাকে। যদি না করে থাকে, প্যাকেটটি সাধারণ ডিফল্টের সঙ্গে মেলে এবং 192.168.50.1-এ ফিরে যায়, যা এটি আবার ক্লায়েন্টের কাছে পাঠায়।

কিছু যোগ করার আগে দেখুন:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

প্রতিটি টেবিলে প্রিফিক্স রুট না থাকাই আপনার খোঁজা ফলাফল। এটি টানেলের নিজের কনফিগারেশনের মাধ্যমে যোগ করুন, যাতে পরের পুনঃসংযোগে এটি আবার ইনস্টল হয়; হাতে করা ip route add সেশনের সঙ্গে হারিয়ে যায় এবং সবচেয়ে অসুবিধাজনক সময়ে ত্রুটি ফিরিয়ে আনে। পরবর্তী হপ হলো টানেল ইন্টারফেস বা VPN যে ঠিকানাটি পিয়ার হিসেবে দেয়, ক্লায়েন্টের ওপর নির্ভর করে, আর পিয়ার ঠিকানাটি পুরোনো নোট থেকে নয়, বর্তমান প্রোফাইল থেকে আসা উচিত।

লুপটি, যখন ঘটে, বাস্তবে অসীম নয়: প্রতিটি পাসে TTL কমে এবং প্যাকেটটি সময়-অতিক্রান্ত বার্তা নিয়ে মারা যায়। তাই বারবার traceroute একটি চক্রের ইঙ্গিত দিতে পারে, অথচ যে ক্লায়েন্ট কেবল ফরওয়ার্ড করছে না সে একই প্যাকেট নীরবে ফেলে দেয়।

ধাপ 3: ফরওয়ার্ডিং অনুমোদন করুন এবং ফেরতের পথ বেছে নিন

গ্রহণ ও ফরওয়ার্ডিং ভিন্ন অনুমতি। ক্লায়েন্টে net.ipv4.ip_forward=1 কার্নেল স্তরে ট্রানজিট অনুমোদন করে, আর ফায়ারওয়াল নিয়মকে এখনও LAN ইন্টারফেস ও টানেলের মধ্যে তা অনুমোদন করতে হবে। যে নিয়ম ক্লায়েন্টের নিজের ম্যানেজমেন্ট পাতায় প্রবেশ অনুমোদন করে, তা দূরবর্তী LAN-এ ট্রানজিট অনুমোদন করবে না, এবং একই হোস্ট স্থানীয়ভাবে ping-এর উত্তর দিলে এই পার্থক্যটি সহজেই চোখ এড়ায়।

দূরবর্তী পক্ষের আয়নার মতো সমস্যা আছে। তাকে জানতে হবে যে 192.168.50.0/24 এই প্রমাণিত ক্লায়েন্টের মাধ্যমে পৌঁছানো যায়। OpenVPN এর সঙ্গে সাধারণত বোঝায় সার্ভার কনফিগারেশনের পাঠানো প্রতি-ক্লায়েন্ট রুট, বা সার্ভারে ক্লায়েন্ট-নির্দিষ্ট ফাইল যা ক্লায়েন্টের পেছনের LAN ঘোষণা করে। এটি ছাড়া দূরবর্তী LAN হয় উত্তরটি ফেলে দেয়, নয়তো নিজের ডিফল্ট গেটওয়েতে পাঠায়, যা হলো ইন্টারনেট।

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

ধাপ 4: দুই সিদ্ধান্তই স্থায়ী করুন, তারপর আসল পথ পরীক্ষা করুন

প্রতিটি রুটের একটি মালিক আছে, আর মালিক হলো সেই কনফিগারেশন যা বুটে বা পুনঃসংযোগে আবার তৈরি হয়। রাউটারে এটি স্ট্যাটিক রুট এন্ট্রি হতে পারে; ক্লায়েন্টে এটি VPN প্রোফাইল, NetworkManager বা systemd-networkd হতে পারে। টানেল পুনঃসংযোগ করে ও ক্লায়েন্ট রিবুট করে যাচাই করুন, তারপর সম্পাদনায় ভরসা না করে টেবিলটি আবার পড়ুন।

টানেলের বাইরের সংযোগ বহনকারী ডিফল্ট রুটটি অক্ষত রাখুন। সেটআপ “সরল” করতে এটি প্রতিস্থাপন করলে কোনো ভেতরের ট্রাফিক ব্যবহার করার আগেই এনক্রিপ্টেড পথ ভেঙে যায়, আর লক্ষণ হলো এমন টানেল যা পরিবর্তনের পর কখনোই আবার প্রতিষ্ঠিত হয় না।

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