VPN ক্লায়েন্টরা সার্ভারে পৌঁছায় কিন্তু LAN-এ নয়: কোন সমাধান?

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

প্রথমে নির্ধারণ করুন কোন দিকটি ভাঙা

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

LAN-এর হোস্ট যদি আগেই VPN সার্ভারের দিকে ইঙ্গিত করে, তবে আপনার সমস্যা ফায়ারওয়াল নিয়ম বা MTU সীমা, ফেরার পথ অনুপস্থিত নয়। ফিল্টার ঠিক করতে রুট যোগ করবেন না।

প্রথম প্রশ্ন: আপনি কি দূরের LAN-এর রাউটার সম্পাদনা করতে পারেন?

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

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

যে NAS বা Layer 3 সুইচ সেবাটি হোস্ট করে তারও একই রুট দরকার, যদি না সে সবকিছু এমন রাউটার দিয়ে পাঠায় যার তা আছে। যে ডিভাইস সাবনেট শেষ করে সেটি পরীক্ষা করুন, কেবল ইন্টারনেটমুখীটি নয়। ছোট নেটওয়ার্কে প্রায়ই রাউটিং নিয়ে মতামত থাকা তিনটি ডিভাইস থাকে।

দ্বিতীয় প্রশ্ন: LAN কি ক্লায়েন্ট ঠিকানা দেখা বন্ধ করতে পারে?

রাউটার অন্য কারও হলে VPN সার্ভারে অনুবাদে সহযোগিতার দরকার হয় না। LAN-এর হোস্ট সার্ভারের LAN ঠিকানা দেখে, তাকে উত্তর দেয়, এবং সার্ভার ফিরিয়ে অনুবাদ করে। এজন্য অ্যাপ্লায়েন্স ও NAT-ভিত্তিক রিমোট অ্যাক্সেস ভূমিকা এভাবে আচরণ করে।

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

মূল্য হলো অ্যাট্রিবিউশন: প্রতি ক্লায়েন্টের ঠিকানা LAN-এর লগ থেকে হারিয়ে যায়। তখন LAN-এর হোস্টে যেকোনো অনুমোদিত তালিকাকে পুলের বদলে সার্ভারের নাম নিতে হবে।

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

তৃতীয় প্রশ্ন: সার্ভার কি নিজেই অন্য টানেলের ক্লায়েন্ট?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

তারপর দুই দিক ও দুই আকার যাচাই করুন

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

তারপর আসল ডেটা সরান, কারণ ছোট ping সফল হওয়া অথচ বড় স্থানান্তর আটকে যাওয়া MTU-র লক্ষণ। সেই ত্রুটি রুট ঠিক করার জন্য নিজেকে অভিনন্দন জানানোর ঠিক পরেই দেখা যায়।

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