OpenVPN-এ সংযুক্ত, তবু কিছুই লোড হয় না: ক্লায়েন্ট থেকে বাইরের দিকে

ক্লায়েন্ট উইন্ডোতে Connected লেখা, টানেলের ঠিকানা আছে, তবু ব্রাউজার ঘুরছে। এই সমন্বয়টি স্বাভাবিক, কারণ সফল হ্যান্ডশেক কেবল প্রমাণ করে টানেল তৈরি হয়েছে; এটি বলে না সার্ভার আপনার প্যাকেট ফরোয়ার্ড করবে কি না, তাদের উৎস পুনর্লিখন করবে কি না, বা আপনার DNS কোয়েরির উত্তর দেবে কি না। বেশিরভাগ মানুষ যে ভুলটি করেন তা হলো প্রথমে সার্ভার কনফিগারেশন খোলা। বরং ক্লায়েন্ট থেকে বাইরের দিকে কাজ করুন, কারণ নিচের প্রতিটি ধাপ বলে দেয় পরেরটি আদৌ যাচাই করার মতো কি না।

ক্লায়েন্ট থেকে শুরু করুন, বাইরের দিকে এগোন

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

ব্রাউজার দ্রুত মনে হচ্ছে বলে তৃতীয় পরীক্ষায় ঝাঁপ দেবেন না। একটি ব্যর্থ পেজ লোড একসাথে তিনটি স্তরকেই ঢেকে দেয়, আর সেখান থেকেই শুরু করে মানুষ পরে কাজ করা টানেল নতুন করে বানায়। ব্যর্থ পেজ তিনটির মধ্যে কোনটি ভেঙেছে তা বলে না।

দুটি ক্যাপচার দেখায় প্যাকেট কোথায় থামে

ক্লায়েন্ট থেকে একটি পাবলিক ঠিকানায় ping চলার সময় টানেল ইন্টারফেসে একটি ক্যাপচার এবং ইন্টারনেটে যাওয়ার কথা থাকা আপলিংকে আরেকটি ক্যাপচার নিন। দুটোই একই সময়ে চালান যাতে টাইমস্ট্যাম্প মিলে যায়।

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

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

ip -4 route get 9.9.9.9

সেই আউটপুটের dev ফিল্ড হলো সেই নাম যা পরে NAT নিয়মের দরকার হবে, তাই এটি রেখে দিন।

ফরোয়ার্ডিং হলো কার্নেলের একটি সুইচ আর ফায়ারওয়ালের একটি নীতি

কার্নেলকে আদৌ ফরোয়ার্ড করতে সম্মত হতে হবে। বর্তমান মান পড়ুন, তারপর শুধু চলমান কার্নেলে লেখার বদলে সেটিংটি স্থায়ী করুন:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

ফরোয়ার্ডিং এর অর্ধেক মাত্র। UFW ব্যবহার করা হোস্টে ফরোয়ার্ড নীতি /etc/default/ufw-তে সেট হয় এবং রিলোড কার্যকর হওয়ার আগে তা ACCEPT হতে হবে। ফরোয়ার্ড পথে ডিফল্ট ড্রপ হ্যান্ডশেককে পুরোপুরি সুস্থ রেখে চুপচাপ প্রতিটি প্যাকেট ফেলে দেয় যা টানেল দিয়ে বেরোতে চায় — ঠিক যে উপসর্গ নিয়ে আপনি শুরু করেছিলেন।

যে হোস্টগুলো সরাসরি nftables চালায় তাদের একই প্রশ্ন অন্য বাক্যে আসে। ক্লায়েন্ট পরীক্ষা চলার সময় ফরোয়ার্ড চেইনের কাউন্টার দেখুন, কারণ যে চেইনকে জিজ্ঞাসা করা হয় আর যে চেইন ফেলে দেয়, কনফিগারেশন ফাইলে দুটো একই রকম দেখায়।

NAT নিয়মে প্রকৃত এগ্রেস ইন্টারফেসের নাম দিন

সোর্স অনুবাদ সেই ইন্টারফেসে থাকা উচিত যা সত্যিই হোস্ট ছাড়ে, সার্ভার যে পুল দেয় তার সাথে। সেই নিয়মের দুই অর্ধেকই বাস্তবতা বর্ণনা করতে হবে, এবং কোনোটিই ঐচ্ছিক নয়।

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

চিরাচরিত ব্যর্থতা হলো গাইড থেকে কপি করা একটি নিয়ম যা -o eth0 বলে এমন মেশিনে যার অ্যাডাপ্টার অন্য নামে চলে। নিয়মটি কোনো সতর্কতা ছাড়াই ইনস্টল হয়, কিছুর সাথে মেলে না, আর ক্লায়েন্টের ইন্টারনেট থাকে না। পুল একই ভুলের অন্য অর্ধেক: সার্ভার যদি 10.44.0.0/24 দেয় আর নিয়মটি 10.8.0.0/24 ঢাকে, তবে কিছুই কখনো মিলবে না।

নিয়মের লেখা বিশ্বাস করার বদলে কাউন্টার দেখুন। তালিকাটি প্রতি নিয়মে প্যাকেট জানায়, আর যে নিয়ম কখনো মেলে না তা যতই সঠিক দেখাক, শূন্যেই থাকে। ওই সংখ্যা থেকে কিছু বোঝার আগে এটিকে এক মিনিটের প্রকৃত ক্লায়েন্ট ট্রাফিক দিন:

iptables -t nat -L POSTROUTING -v -n

প্রকৃত ক্লায়েন্ট পরীক্ষার পরে শূন্য প্যাকেট গণনা মানে মিলটি ভুল, টানেল ভাঙা নয়। একবার মিললে নিয়মসমষ্টি সংরক্ষণ করুন যাতে রিবুটেও টিকে থাকে; যে সমাধান কেবল আপনার শেল ইতিহাসে বাস করে তা প্রথম রিস্টার্টেই হারিয়ে যায়।

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

DNS হলো প্রথমটির পিছনে দ্বিতীয় ব্যর্থতা

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

সার্ভার থেকে একটি রিজলভার পুশ করুন যাতে ক্লায়েন্ট জানতে পারে কোথায় জিজ্ঞাসা করতে হবে। দুটি এন্ট্রি ক্লায়েন্টকে ব্যাকআপ দেয় যদি প্রথমটি না পৌঁছায়, আর দুটোই এমন রিজলভার হওয়া উচিত যা টানেল সত্যিই অনুমোদন করে।

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows ক্লায়েন্ট তখনও লোকাল রিজলভারে ফিরে যেতে পারে, আর block-outside-dns ঠিক তা-ই প্রতিরোধ করতে আছে, তবে তার দাম হলো কেবল লোকাল নেটওয়ার্ক যে নামগুলো রিজলভ করতে পারে সেগুলো হারানো। systemd-resolved ব্যবহার করা Linux ক্লায়েন্ট প্রায়ই পুশ করা রিজলভার উপেক্ষা করে যদি না কোনো স্ক্রিপ্ট তা ইনস্টল করে, তাই পুশ উপেক্ষিত হয়েছে বলে সিদ্ধান্তে আসার আগে টানেল ডিভাইসের জন্য resolvectl status দেখুন।

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