একটি Pi-তে hostapd ও OpenVPN: ডিফল্ট রুট কার?

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

কিছু সম্পাদনার আগে ইন্টারফেসগুলো তালিকাভুক্ত করুন

পরিচিত বিন্যাসটি ওয়্যারলেস রেডিও ও তারযুক্ত পোর্টকে br0-এর ভেতরে রাখে, ব্রিজের বিরুদ্ধে hostapd চালায় এবং dnsmasq থেকে লিজ দেয়, আর একটি OpenVPN ক্লায়েন্ট tun0 তৈরি করে। তখন তিনটি আলাদা প্রয়োজন একটির মতো দেখায়: অ্যাক্সেস পয়েন্ট ক্লায়েন্টদের গেটওয়ে হিসেবে Pi দরকার, Pi-এর সার্ভারে পৌঁছাতে ইন্টারনেটে রুট দরকার, এবং ব্রিজের দরকার এমন গেটওয়ে ঠিকানা যা ওই ক্লায়েন্টরা ব্যবহার করতে পারে।

পরিবর্তনের আগে বর্তমান অবস্থা পড়ুন, কারণ এই চারটি কমান্ড ইন্টারফেস সমস্যাকে রাউটিং সমস্যা থেকে আলাদা করে।

ip -br addr
ip route show
ip link show master br0
bridge link show

যদি br0 একটি ঠিকানা বহন করে কিন্তু ডিফল্ট রুট না থাকে, ক্লায়েন্টরা Pi পর্যন্ত পৌঁছায় আর তার পরে কিছুই নয়। যদি টানেল বন্ধ থাকা অবস্থায় ডিফল্ট রুট tun0-এর দিকে থাকে, Pi-এর একেবারেই কোনো কার্যকর পথ থাকে না, আর ক্লায়েন্টের লক্ষণ হুবহু একই দেখায়। উভয় ক্ষেত্রেই ফোন থেকে একই রকম দেখায়, তাই রুট টেবিল সরাসরি পড়তে হয়।

ব্রিজকে তার নিজের ডিফল্ট রুট দিন

Raspberry Pi OS প্রায়ই ব্রিজকে ডিফল্ট রুট ছাড়া রেখে দেয়, যখন ইন্টারফেস ফাইল লেখার পরে ব্রিজের উদ্ভব হয়। স্ট্যানজাটি /etc/dhcpcd.conf-এ থাকা উচিত, এবং এটি Pi-কে নয়, আপস্ট্রিম রাউটারকে নাম দেবে।

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

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

systemctl restart dhcpcd-এর পরে ip route show default একবার br0 দেখাবে এবং তারযুক্ত পোর্ট থেকে কোনো নকল থাকবে না। টেবিল নয়, লুকআপ নিশ্চিত করুন, কারণ একটি পুরোনো এন্ট্রি বিজয়ী এন্ট্রির পাশে বসে থাকতে পারে: ip -4 route get 203.0.113.10-কে br0 নাম দিতে হবে। ওই ঠিকানাটি TEST-NET-3 ডকুমেন্টেশন রেঞ্জ থেকে আসে, তাই আপনি এটি পড়ার সময় এটি কোনো বাস্তব সার্ভারের সাথে সংঘর্ষ করতে পারে না।

টানেলকে তার নিজের সার্ভারের পথ ছিনতাই করা থেকে থামান

redirect-gateway গ্রহণ করা একটি OpenVPN ক্লায়েন্ট ডিফল্ট রুট দখল করে টানেলের ভেতরে নিয়ে যায়। এটি ঠিক যখন প্রতিটি অ্যাক্সেস পয়েন্ট ক্লায়েন্টের VPN ব্যবহার করা উচিত, আর ভুল যখন কেবল কিছু গন্তব্যের উচিত। যেভাবেই হোক, সার্ভারের সাথে Pi-এর নিজের সংযোগ যে টানেলটি এখনো তৈরি হচ্ছে তার ভেতরে যাওয়া উচিত নয়। OpenVPN ডিফল্ট পুনঃনির্দেশ করার সময় মূল গেটওয়ে দিয়ে রিমোটে একটি হোস্ট রুট যোগ করে, এবং এটিই ঠিক সেই আচরণ যা পরিবহনকে জীবিত রাখে; ওই রুট না থাকলে, টানেল প্রতিষ্ঠিত হওয়ার সাথে সাথেই ভেঙে পড়ে।

সংযোগের আগে ও পরে ওই পরিবহন পথের একটি দ্রুত তুলনা দশ সেকেন্ডের মূল্য। ip -4 route get 203.0.113.10 উভয় অবস্থাতেই আন্ডারলে ডিভাইসের নাম দেবে, কেবল মেট্রিক বদলাবে। যদি টানেল ওঠার পরে এটি tun0 নাম দেয়, তবে হোস্ট রুট কখনোই ইনস্টল হয়নি আর পরের পুনঃসংযোগ ব্যর্থ হবে।

যখন কেবল নির্বাচিত প্রিফিক্সগুলো টানেল পার হবে, route-nopull ব্যবহার করুন এবং যে রুটগুলো চান হাতে যোগ করুন, অথবা সার্ভার থেকে আরও সরু সেট পাঠান। ওই নকশায় ব্রিজ ডিফল্ট রুট রাখে, আর DNS পরের সিদ্ধান্ত হয়: dnsmasq-এর হোম রিজলভারে ফরওয়ার্ডিং কেবল সেই নামগুলোর জন্য অর্থবহ যেগুলো সত্যিই সেখানে থাকে।

ফরওয়ার্ডিং ও NAT-এর সিদ্ধান্ত নিন

পূর্ণ টানেলে Pi-তে ফরওয়ার্ডিং সক্রিয় থাকা দরকার এবং অ্যাক্সেস পয়েন্ট সাবনেট রাউট করতে ইচ্ছুক একটি দূরপার্শ্বের গেটওয়ে দরকার। অন্য কিছুর আগে ফরওয়ার্ডিং পরীক্ষা করুন, কারণ শূন্য প্রতিটি রুট পরিবর্তনকে অপ্রাসঙ্গিক করে দেয়।

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT নিয়মটি সেই শর্টকাট যা কাজ করে যখন সার্ভার অ্যাক্সেস পয়েন্ট প্রিফিক্স গ্রহণ করবে না, তবে তার দাম হলো দূরপার্শ্বের লগে প্রতিটি ক্লায়েন্ট Pi-এর টানেল ঠিকানা হিসেবে দেখা যাবে। NAT ছাড়া প্রিফিক্স রাউট করলে ঠিকানাগুলো দৃশ্যমান থাকে এবং এটি হোম পাশে 192.168.50.0/24-এর জন্য একটি ফেরত রুটের উপর নির্ভর করে।

ফায়ারওয়াল নিয়মের পাশে সিদ্ধান্তটি লিখে রাখুন, কারণ নকশায় অদৃশ্য NAT নিয়ম ছয় মাস পরে অব্যাখ্যেয় হয়ে যায়। IPv6-কে একই সিদ্ধান্তে রাখুন; ভাঙা IPv6 পথের পাশে কার্যকর IPv4 পথ ব্রাউজারে এখনো অর্ধভাঙা হিসেবেই পড়া যায়।

ক্লায়েন্ট থেকে যাচাই করুন, তারপর পরিষ্কারভাবে রোলব্যাক করুন

অ্যাক্সেস পয়েন্টের একটি ফোন বা ল্যাপটপ থেকে এই ক্রমে পরীক্ষা করুন: dnsmasq থেকে লিজ, ব্রিজ ঠিকানায় ping, তারপর টানেলের দূরপার্শ্বে একটি গন্তব্য। প্রতিটি ধাপ একটি স্তর আলাদা করে, একটি মাত্র অকেজো ব্যর্থতা তৈরি করার বদলে।

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

তারপর নিশ্চিত করুন Pi-এর এখনো নিজের বেরোনোর পথ আছে: ip route get 203.0.113.10-কে আন্ডারলে ডিভাইসের নাম দিতে হবে, আর সার্ভার ICMP অনুমোদন করলে ping -c 3 -I br0 203.0.113.10-কে উত্তর দিতে হবে। প্রথম দুটি ক্লায়েন্ট ধাপ পাস করলে আর তৃতীয়টি ব্যর্থ হলে, ত্রুটি ফরওয়ার্ডিং বা NAT-এ। দ্বিতীয় ধাপ ব্যর্থ হলে, ব্রিজ বা DHCP এখনো অসম্পূর্ণ।

রোলব্যাক হলো একটি ফাইল সম্পাদনা ও দুটি কমান্ড: স্ট্যানজা সরান, dhcpcd পুনরায় চালু করুন, এবং ডিফল্ট রুট স্পষ্টভাবে ip route replace default via 192.168.50.1 dev br0 দিয়ে প্রতিস্থাপন করুন। রক্ষণাবেক্ষণ উইন্ডো বন্ধ হওয়ার পরে নয়, আগেই এটি করুন, কারণ ডিফল্ট রুট হারানো Pi সেই নেটওয়ার্ক থেকেই পৌঁছানো যায় না যা আপনি মেরামতের জন্য ব্যবহার করতেন।