hostapd و OpenVPN روی یک Pi: مسیر پیش‌فرض از آن کیست؟

تلفن‌ها به نقطه دسترسی متصل می‌شوند، آدرسی می‌گیرند و سپس به محض بالا آمدن تونل به هیچ جا نمی‌رسند. 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 می‌آید، پس تا وقتی این را می‌خوانید نمی‌تواند با سرور واقعی برخورد کند.

جلوگیری کنید از اینکه تونل مسیر سرور خودش را برباید

کلاینت OpenVPN که redirect-gateway را می‌پذیرد مسیر پیش‌فرض را تصاحب می‌کند و آن را به داخل تونل می‌فرستد. این درست است وقتی هر کلاینت نقطه دسترسی باید از 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 را در همان تصمیم نگه دارید؛ مسیر IPv4 سالم در کنار مسیر IPv6 خراب هنوز در مرورگر نیمه‌خراب خوانده می‌شود.

از یک کلاینت تأیید کنید، سپس پاک بازگردانید

به این ترتیب از تلفن یا لپ‌تاپ روی نقطه دسترسی آزمایش کنید: یک اجاره از 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 باید دستگاه زیرلایه را نام ببرد و ping -c 3 -I br0 203.0.113.10 باید پاسخ دهد اگر سرور ICMP را مجاز بداند. اگر دو گام اول کلاینت بگذرند و سومی شکست بخورد، خطا در هدایت یا NAT است. اگر گام دوم شکست بخورد، پل یا DHCP هنوز ناقص است.

بازگردانی یک ویرایش فایل و دو فرمان است: بلوک را حذف کنید، dhcpcd را دوباره راه‌اندازی کنید و مسیر پیش‌فرض را صریحاً با ip route replace default via 192.168.50.1 dev br0 جایگزین کنید. این کار را پیش از بسته شدن پنجره نگهداری انجام دهید نه پس از آن، چون Pi که مسیر پیش‌فرضش را از دست داده از شبکه‌ای که برای تعمیرش استفاده می‌کردید در دسترس نیست.