OpenVPN ক্লায়েন্ট সার্ভারে পৌঁছায় কিন্তু LAN হোস্টে নয়: চেকলিস্ট

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

প্রথম ধাপ: ক্লায়েন্টের রাউটিং সিদ্ধান্ত দেখুন

সার্ভারে হাত দেওয়ার আগে প্রমাণ করুন যে ক্লায়েন্ট প্যাকেটটি টানেলে পাঠায়। পুরো টেবিল পড়ার বদলে কার্নেলকে জিজ্ঞাসা করুন একটি নির্দিষ্ট LAN হোস্টের জন্য সে কোন ইন্টারফেস ব্যবহার করবে:

ip route get 192.168.50.10

যদি উত্তর আপনার ফিজিক্যাল অ্যাডাপ্টার আর অফিস গেটওয়ের নাম বলে, তবে সার্ভার পাশে কোনো পরিবর্তনই সাহায্য করতে পারে না। OpenVPN রুট দেয় কেবল তখনই যখন সার্ভার সেগুলো পুশ করে, তাই সার্ভার কনফিগারেশনে push "route 192.168.50.0 255.255.255.0" খুঁজুন, আর পরে ক্লায়েন্টটি আবার সংযুক্ত করুন। বেশিরভাগ ক্লায়েন্ট পুশ করা রুট সংযোগের সময় প্রয়োগ করে, প্রোফাইল রিলোড করার সময় নয়।

Windows-এ একই প্রশ্নের ভিন্ন কমান্ড আছে। Find-NetRoute -RemoteIPAddress 192.168.50.10 সেই ইন্টারফেস ও পরবর্তী হপ প্রিন্ট করে যা স্ট্যাক বেছে নিত, আর route print -4 দেখায় পুশ করা প্রিফিক্স আদৌ আছে কি না।

দ্বিতীয় ধাপ: সার্ভার প্যাকেটটি ফরওয়ার্ড করবে তা নিশ্চিত করুন

যদি ক্লায়েন্ট রুট ঠিক থাকে, প্যাকেট সার্ভারে পৌঁছায় এবং সার্ভারকে তা ফরওয়ার্ড করতে সম্মত হতে হয়। কার্নেল সুইচটি প্রথম গেট, এবং sysctl net.ipv4.ip_forward-কে 1 ফেরত দিতে হবে। echo 1 > /proc/sys/net/ipv4/ip_forward দিয়ে এটি সেট করা পরের রিবুট পর্যন্ত কাজ করে, আর ঠিক এজন্য একই অভিযোগ সপ্তাহ পরে ফিরে আসে।

এটি এমন জায়গায় লিখুন যা রিস্টার্টের পরে টিকে থাকে:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

দ্বিতীয় গেট হলো ফিল্টার টেবিল। Docker ইনস্টল করা হোস্টে প্রায়ই FORWARD নীতিটি DROP থাকে, এবং টানেল সেই সিদ্ধান্ত উত্তরাধিকারসূত্রে পায়। iptables -L FORWARD -v -n নীতি ও প্যাকেট কাউন্টার দুটোই দেখায়; যদি নীতি DROP হয়, ফরওয়ার্ডিংয়ের জন্য টানেল-থেকে-LAN দিকে একটি স্পষ্ট অনুমতি দরকার এবং উত্তরের জন্য আরেকটি।

তৃতীয় ধাপ: প্যাকেটকে LAN-এ অনুসরণ করুন এবং উত্তর খুঁজুন

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

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

যে অনুরোধগুলো tun0-এ এবং আবার eth0-এ 10.8.0.x সোর্স নিয়ে দেখা যায়, তারপর নীরবতা নামে, তার মানে প্যাকেট এসেছে আর উত্তর অন্য কোথাও গেছে। LAN হোস্ট তার ডিফল্ট গেটওয়েতে উত্তর দেয়, সেই গেটওয়ের VPN পুলের জন্য কোনো রুট নেই, আর উত্তরটি LAN রাউটারে মারা যায়। সার্ভার থেকে LAN হোস্টে ping করলে এই পথ সম্পর্কে কিছুই প্রমাণ হয় না, কারণ সেই ট্র্যাফিক কখনো টানেল পার হয় না।

চতুর্থ ধাপ: ট্রান্সলেশন আর রিটার্ন রুটের মধ্যে বেছে নিন

দুটি মেরামত গর্তটি বন্ধ করে, আর এই পছন্দের পরিণতি ping কাজ করে কি না তার বাইরেও যায়। সোর্স ট্রান্সলেশন সার্ভারকে দৃশ্যত প্রেরক করে তোলে:

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

নিয়মটি পুল আর LAN ইন্টারফেসে সীমাবদ্ধ করুন, তারপর এটি স্থায়ী করুন, নইলে পরের ফায়ারওয়াল রিলোড আপনার সমাধানটি চুপচাপ মুছে দেবে। মূল্য হলো পরিচয়: LAN লগ ও অ্যাক্সেস নিয়মে প্রতিটি ক্লায়েন্ট VPN সার্ভারের মতো দেখায়, আর per-client policy becomes guesswork।

LAN রাউটারে VPN সার্ভারের দিকে নির্দেশ করা 10.8.0.0/24-এর একটি স্ট্যাটিক রুট ক্লায়েন্ট ঠিকানা দৃশ্যমান রাখে এবং সেই রাউটারটি আপনার হলে এটি দীর্ঘমেয়াদে ভালো উত্তর। অনেক সাইট কিছুদিন দুটোই চালায়, তাৎক্ষণিক মেরামতের জন্য NAT আর ফায়ারওয়াল নীতি লেখা হয়ে গেলে রুটটি। যদি সার্ভারটি পুলের বদলে সাইট-টু-সাইট পিয়ার হয়, তবে সার্ভার পাশেও দূরবর্তী সাবনেটের জন্য iroute দরকার, নইলে পিয়ার রুট থাকে কিন্তু ক্লায়েন্ট ট্র্যাফিক কখনো তার সাথে যুক্ত হয় না।

পঞ্চম ধাপ: ক্লায়েন্ট থেকে যাচাই করুন এবং কী বদলাল তা লিখে রাখুন

লুপটি সার্ভার থেকে নয়, ক্লায়েন্ট থেকে বন্ধ করুন। LAN হোস্টে একটি বাস্তব সেবায় সংযোগ করুন, তারপর iptables -t nat -L POSTROUTING -v -n দিয়ে নিশ্চিত করুন যে ট্রান্সলেশন কাউন্টার নড়েছে, কারণ শূন্য প্যাকেটের নিয়ম হলো এমন নিয়ম যা কখনো মেলেনি। ফেরার দিকটি ট্র্যাক হচ্ছে—এমন প্রমাণ দরকার হলে conntrack -L -s 10.8.0.5 প্রবাহ ও তার অবস্থা দেখায়।

সার্ভার কনফিগে একটি নোট রেখে দিন: কোন সাবনেট, কোন ইন্টারফেস, কোন নিয়ম, আর LAN রাউটার ফেরার রুট বহন করে কি না। পরেরবার যখন কোনো ক্লায়েন্ট আপগ্রেড পুশ করা রুট মুছে দেয়, সেই নোট একটি আগুন-নেভানো সেশনকে এক লাইনের সমাধানে বদলে দেয়।