ایک 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 اس نیٹ ورک سے ناقابل رسائی ہے جو آپ اسے ٹھیک کرنے کے لیے استعمال کریں گے۔