خبر و ترفند روز

خبر و ترفند های روز را اینجا بخوانید!

چطور Starlink و اینترنت موبایل را به یک اتصال پشتیبان خانگی تبدیل کردم

صفحه Software در OpenWRT با بسته‌های USB نصب‌شده برای شناسایی مودم.
با OpenWRT و MWAN3 می‌توان اینترنت Starlink و مودم 4G را پشت یک روتر واحد قرار داد تا هنگام قطعی، همه دستگاه‌های خانه بدون تغییر Wi‑Fi، Gateway یا DNS به مسیر پشتیبان بروند.

داشتن اینترنت پشتیبان تا وقتی فقط برای یک لپ‌تاپ یا گوشی باشد، معمولاً با روشن کردن hotspot حل می‌شود. اما وقتی کل خانه، تلویزیون‌ها، گوشی‌ها، لپ‌تاپ‌ها و سرویس‌های داخلی به یک شبکه ثابت وابسته‌اند، جابه‌جایی دستی بین اتصال اصلی و اینترنت موبایل هم وقت‌گیر است و هم اعصاب‌خردکن. نویسنده MakeUseOf برای همین مشکل، Starlink و مودم 4G قدیمی خود را پشت یک روتر OpenWRT واحد قرار داد تا شبکه خانه همیشه یک مسیر دوم برای خروج داشته باشد.

صفحه Software در OpenWRT با بسته‌های USB نصب‌شده برای شناسایی مودم.

در این تجربه، Starlink اتصال اصلی بود؛ سریع‌تر، پایدارتر و مناسب‌تر برای کارهایی مثل تماس ویدیویی. با این حال، آنتن و تجهیزات Starlink به برق و شرایط آب‌وهوایی وابسته‌اند و در محیطی با قطعی برق، طوفان و گرمای شدید نمی‌توان همیشه روی آن حساب کرد. راه‌حل این بود که مودم USB 4G کنار گذاشته نشود، بلکه به عنوان مسیر WAN دوم وارد روتر مرزی شبکه شود.

ترمینال OpenWRT با خروجی log مربوط به اتصال مودم USB.

OpenWRT نقش پلیس ترافیک بین دو اتصال را گرفت

اتصال پشتیبان باید در لبه شبکه باشد، نه کنار آن

روتر OpenWRT این setup به صورت یک ماشین مجازی اجرا می‌شد و درست در لبه LAN قرار داشت؛ یعنی همه درخواست‌های شبکه از آن عبور می‌کردند. اتصال Starlink روی رابط eth1 به عنوان WAN اصلی بود و مودم USB 4G هم مستقیم به ماشین مجازی ESXi پاس داده شد تا روی eth2 در دسترس OpenWRT قرار بگیرد.

مزیت این چینش این است که از دید بقیه دستگاه‌های خانه تقریباً هیچ چیز عوض نمی‌شود. همان gateway، همان IP و همان DNS که قبلاً از OpenWRT می‌گرفتند باقی می‌ماند؛ فقط روتر پشت صحنه تصمیم می‌گیرد ترافیک از Starlink خارج شود یا از مودم 4G.

اتصال مودم USB البته کاملاً plug-and-play نبود. برای اینکه OpenWRT بتواند دستگاه Ethernet over USB را تشخیص دهد، چند بسته و درایور USB نصب شد:

apk update
apk add usbids usbutils kmod-usb-common kmod-usb-core  kmod-usb-net kmod-usb-net-cdc-ether kmod-usb-net-cdc-ncm kmod-usb-net-rndis libusb-1.0-0

همین بسته‌ها را می‌توان از رابط وب LuCI هم نصب کرد: مسیر System > Software را باز کنید و هر بسته را جداگانه جست‌وجو و نصب کنید. در این مجموعه، usbutils و usbids به شناسایی مودم کمک می‌کنند، بسته‌های kmod-usb-net پشتیبانی از پروتکل‌هایی مثل CDC Ethernet، CDC NCM و RNDIS را اضافه می‌کنند و libusb ارتباط با دستگاه USB را ممکن می‌کند.

مطلب مرتبط:   Nextbase در مقابل Garmin: چه کسی بهترین داش‌کم‌ها را می‌سازد؟

برای اطمینان از اینکه OpenWRT مودم و رابط تازه را می‌بیند، این دستورها اجرا شدند:

lsusb
ip link show eth2
logread | grep -Ei 'usb|rndis|cdc|ncm|eth2'

بعد از شناسایی مودم، یک رابط DHCP جدید با نام wanb ساخته شد، به eth2 وصل شد و به قانون فایروال WAN موجود در OpenWRT اضافه شد. وقتی روتر از مودم 4G آدرس IP گرفت، رابط LuCI هر دو اتصال Starlink و 4G را هم‌زمان فعال نشان می‌داد.

خروجی دستور lsusb در OpenWRT که شناسایی مودم USB را نشان می‌دهد.

OpenWRT باید می‌فهمید چه زمانی Starlink واقعاً از کار افتاده است

WAN دوم وقتی مفید است که روتر خرابی WAN اول را تشخیص دهد

در ابتدا نویسنده تصور می‌کرد route metric برای انتخاب مسیر کافی است. متریک‌ها به این شکل تنظیم شدند:

  • wan: 20
  • wanb: 10

این روش وقتی کابل eth1 فیزیکی جدا می‌شد جواب می‌داد، اما در خرابی‌های واقعی کافی نبود. ممکن است لینک Ethernet تا دیش Starlink، سرویس‌های upstream یا routeهای ظاهری هنوز برقرار باشند، اما اینترنت واقعی از آن مسیر عبور نکند. در چنین حالتی جدول route فکر می‌کند جاده هنوز باز است، در حالی که عملاً به مقصد نمی‌رسد.

راه‌حل بهتر استفاده از مدیر MultiWAN در OpenWRT یعنی MWAN3 بود. نصب آن با این دستور انجام شد:

apk add mwan3 luci-app-mwan3

سپس سرویس فعال و ری‌استارت شد:

/etc/init.d/mwan3 enable
/etc/init.d/mwan3 restart

در LuCI، هر دو رابط wan و wanb به عنوان monitored interface فعال شدند. برای جلوگیری از خطای مثبت کاذب، چند tracking address مثل 1.1.1.1 و 9.9.9.9 انتخاب شد تا اگر فقط یک سرور پاسخ نداد، failover بی‌دلیل فعال نشود.

بعد از آن، MWAN3 سیاستی با ترتیب درست ساخت: عضو wan_m1_w3 با metric ۱ و عضو wanb_m2_w2 با metric ۲. این policy به default_rule_v4 وصل شد تا Starlink همیشه انتخاب اول باشد و 4G فقط هنگام خرابی مسیر اصلی وارد عمل شود.

مطلب مرتبط:   پارازیت سیگنال چیست و چه کاری می توانید در مورد آن انجام دهید؟

برای بررسی وضعیت MWAN3 و رابط‌ها از SSH هم می‌توان این دستورها را اجرا کرد:

mwan3 status
ubus call network.interface.wan status
ubus call network.interface.wanb status

نکته مهم این است که این setup برای failover است، نه load balancing. یعنی ترافیک عادی روی Starlink می‌ماند و فقط وقتی MWAN3 تشخیص دهد Starlink در دسترس نیست، مسیر 4G جایگزین می‌شود.

صفحه Interfaces در OpenWRT با رابط wanb برای مودم USB Ethernet.

اولین تست واقعی failover بسیار ساده بود

Starlink قطع شد و روتر خودش 4G را انتخاب کرد

برای آزمایش، یک کامپیوتر ویندوزی روی subnet شبکه داخلی 192.168.24.0 استفاده شد؛ همان شبکه‌ای که رابط LAN روتر OpenWRT روی آن بود. در یک پنجره PowerShell، ping پیوسته اجرا شد تا زمان دقیق قطع و برگشت اتصال دیده شود:

ping 1.1.1.1 -t

در پنجره‌ای دیگر، اسکریپت کوتاهی هر پنج ثانیه IP عمومی را بررسی می‌کرد:

while ($true) {
    $time = Get-Date -Format "HH:mm:ss"

    try {
        $ip = Invoke-RestMethod "https://api.ipify.org" -TimeoutSec 3
        "$time  $ip"
    }
    catch {
        "$time  OFFLINE"
    }

    Start-Sleep 5
}

وقتی IPهای Starlink چند بار در خروجی دیده شدند، نویسنده از طریق SSH وارد OpenWRT شد و عمداً رابط WAN اصلی را پایین آورد:

ifdown wan

ping برای مدت کوتاهی دچار وقفه شد تا MWAN3 به آستانه failure برسد. سپس wan را offline علامت زد و زیر policy مربوط به wan_wanb، مسیر wanb را انتخاب کرد. بعد از آن، اسکریپت PowerShell IP عمومی اپراتور موبایل را گزارش می‌کرد.

برای بازگرداندن Starlink هم ifup wan اجرا شد. MWAN3 دوباره منتظر چند بررسی موفق ماند، لینک را سالم تشخیص داد و ترافیک تازه را به اتصال اصلی برگرداند. طبق تجربه منبع، در هر بار خاموش و روشن کردن رابط WAN، قطعی بیشتر از حدود یک ثانیه طول نکشید.

مطلب مرتبط:   Claude Artifact در مقابل Canvas ChatGPT: گزینه بهتر چیست؟
افزودن رابط eth2 مربوط به اینترنت USB به ناحیه فایروال WAN در OpenWRT.

این اتصال بی‌نقص نیست، اما بهتر از بازسازی دستی شبکه است

4G کندتر است، اما وقتی گزینه دیگر قطع کامل اینترنت باشد ارزش دارد

این روش اینترنت bonded نمی‌سازد؛ یعنی سرعت دانلود Starlink و 4G با هم جمع نمی‌شود. همچنین تماس ویدیویی فعال، VPN یا دانلود در حال اجرا ممکن است هنگام تغییر IP عمومی قطع شود. با این حال، لپ‌تاپ‌ها، گوشی‌ها، تلویزیون‌ها و دستگاه‌های خانه روی همان LAN باقی می‌مانند و فقط با یک وقفه کوتاه مسیر خروجی‌شان عوض می‌شود.

در setup منبع، سروری که OpenWRT و مودم 4G روی آن قرار داشتند به UPS وصل بود، اما آنتن Starlink به دلیل فاصله از خانه چنین پشتیبانی‌ای نداشت. مدار برق هم هنگام طوفان قطع می‌شد و گرمای تابستان از دمای کاری قابل تحمل آنتن Starlink بالاتر می‌رفت. بنابراین حتی این failover هم در blackout کامل یا خاموشی switchها و access pointها بی‌اثر می‌شود.

با وجود این محدودیت‌ها، تفاوت اصلی در خودکار شدن کار است. hotspot فقط یک دستگاه را نجات می‌دهد و نیاز به دخالت دستی دارد؛ اما OpenWRT هر چیزی را که هنوز برق دارد بدون تغییر SSID، gateway یا DNS روی 4G می‌برد و وقتی Starlink برگشت، شبکه را به مسیر اصلی برمی‌گرداند.

مودم 4G لازم نیست سرعت Starlink را تکرار کند. کافی است کارهای ضروری و ارتباطات پایه را تا برگشت اتصال اصلی زنده نگه دارد. نتیجه این است که کاربر هنوز قطع شدن Starlink را حس می‌کند، مخصوصاً هنگام تماس ویدیویی؛ اما دیگر لازم نیست کار را متوقف کند، مودم را پیدا کند، همه چیز را دوباره وصل کند و شبکه خانه را دور قطعی اینترنت از نو بسازد.

منبع: این مطلب یک بومی‌سازی و بازنویسی تحریریه‌ای بر اساس مقاله‌ای از MakeUseOf است: مشاهده مقاله اصلی.