۵ سرویس شبکه که پیش از یک سرور رسانه‌ای ارزش میزبانی شخصی دارند

وقتی برای آزمایشگاه خانگی‌ام به سخت‌افزار جدیدی دست پیدا می‌کنم، معمولاً اولین چیزی که می‌خواهم بسازم یک سرور رسانه‌ای است. Plex، Kodi یا Jellyfin نوید نتیجه‌ای فوری را می‌دهند، زیرا می‌توانم برنامه‌ای را باز کنم و تماشای مجموعه رسانه‌ای خودم را آغاز کنم. متأسفانه مواردی مانند گزارش‌های DNS، فهرست دستگاه‌ها و نمودارهای زمان فعالیت به‌مراتب هیجان‌انگیز نیستند.

بااین‌حال، پیش از پر کردن یک دیسک دیگر با فایل‌های رسانه‌ای، یک ماشین مجازی تازه با Ubuntu ۲۶.۰۴ ایجاد کردم و از خودم پرسیدم ابتدا برای بهبود شبکه‌ام چه کاری باید انجام دهم. پنج سرویس نصب کردم که DNS، شناسایی دستگاه‌ها، دسترس‌پذیری، عملکرد اینترنت و دسترسی به داشبوردهای محلی را پوشش می‌دادند — این سرویس‌ها هر دستگاه و هر برنامه خودمیزبانی‌شده‌ای را که بعداً اضافه کنم، از جمله سرور رسانه‌ای، بهبود خواهند داد.

پنج وظیفه متفاوت شبکه را به یک VM سپردم

هر سرویس پیش از پخش نخستین فیلم، مشکلی را حل کرد

یک VM نه‌چندان قدرتمند مبتنی بر Ubuntu Linux راه‌اندازی کردم، نشانی IP آن را ۱۹۲.۱۶۸.۱.۱۲۶ قرار دادم و 6GB حافظه vRAM و یک vDisk با ظرفیت 20GB به آن اختصاص دادم. ایده این بود که به‌جای ایجاد یک VM جداگانه برای هر وظیفه، از همین سرور واحد با Docker Compose مستقرشده روی آن استفاده کنم:

• AdGuard Home کنترل و فیلتر DNS و رکوردهای DNS محلی موردنیازم در آینده را مدیریت می‌کند.
• Uptime Kuma دستگاه‌ها و اتصال اینترنت من را از نظر بروز اختلال زیر نظر می‌گیرد.
• NetAlertX شبکه LAN را اسکن می‌کند و فهرستی از دستگاه‌های متصل می‌سازد.
• Speedtest Tracker به‌طور دوره‌ای آزمایش‌های سرعت را اجرا و نتایج را ثبت می‌کند.
• Nginx Proxy Manager نشانی ۱۹۲.۱۶۸.۱.۱۲۶ و شماره پورت‌ها را با نام‌های محلی خوانا جایگزین می‌کند.

فقط AdGuard Home و NetAlertX از شبکه میزبان استفاده کردند، زیرا برای کار کردن به دسترسی مستقیم به رابط‌های شبکه VM نیاز داشتند. کانتینرهای دیگر یک شبکه Docker را به‌اشتراک گذاشتند. هر پنج سرویس به‌راحتی روی همان یک VM جای گرفتند، اما هرکدام به پرسشی متفاوت پاسخ می‌دادند و وظایف جداگانه‌ای انجام می‌دادند. آن‌ها در کنار هم مجموعه‌ابزار کوچک شبکه‌ای را ساختند که سرور رسانه‌ای جدیدم را امکان‌پذیر کرد.

AdGuard Home یک خط‌مشی DNS واحد برای کل شبکه‌ام فراهم کرد

فیلتر کردن تبلیغات مفید بود، اما دلیل انتخاب من گزارش کوئری‌ها و بازنویسی‌های محلی بود

AdGuard Home به‌طور گسترده به‌عنوان مسدودکننده تبلیغات در سراسر شبکه شناخته می‌شود و این وظیفه را واقعاً خوب انجام می‌دهد. من یک قانون کنترل‌شده برای ads.test اضافه کردم، آن را از لپ‌تاپ Windows خود فراخوانی کردم و مسدود شدن درخواست را دیدم. با وجود مفید بودن این قابلیت، فیلتر تبلیغات دلیل اصلی من برای استفاده از آن نبود.

بیشتر علاقه‌مند بودم از AdGuard به‌عنوان نقطه کنترل DNS شبکه استفاده کنم. گزارش کوئری نشان می‌داد کدام دستگاه هر دامنه را درخواست کرده است و ورودی‌های نام‌گذاری‌شده کلاینت‌ها، نشانی‌های ناشناس و کسل‌کننده را با برچسب‌های مفیدی مانند «لپ‌تاپ Windows» و «سرور NetworkOps» جایگزین می‌کردند.

قابلیت بازنویسی DNS آن همچنین به من اجازه داد رکوردهای محلی مانند dns.home ایجاد کنم که به زیربنای نام‌گذاری تمام سرویس‌هایی تبدیل شد که روی VM ایجاد کردم:

• dns.home (AdGuard)
• devices.home (NetAlertX)
• status.home (Kuma Uptime)
• speed.home (Speedtest tracker)
• proxy.home (Nginx Proxy Manager)

البته، این کار به این معنا بود که یک نقطه مرکزی خرابی ایجاد کرده‌ام و همین موضوع سرویس بعدی را نیز به همان اندازه مهم می‌کرد.

اگر شبکه شما از IPv6 استفاده می‌کند، AdGuard Home را برای هر دو خانواده نشانی پیکربندی کنید. در غیر این صورت، کلاینت‌ها با استفاده از تحلیل‌گر IPv6 روتر شما کوئری ارسال می‌کنند و جست‌وجوها را دور می‌زنند. افزودن نشانی ULA سرور AdGuard به‌عنوان سرور DNS مربوط به IPv6 این مشکل رایج را برطرف می‌کند.

Uptime Kuma باعث شد همه قطعی‌ها یکسان به نظر نرسند

یک مانیتور قرمز به من می‌گفت که آیا DNS، روتر یا یکی از کانتینرها از کار افتاده است

Uptime Kuma یک ابزار ساده پایش زمان فعالیت است و برای مشخص کردن دقیق نقاط خرابی، راهکاری بسیار بهتر از این است که صرفاً فرض کنیم کل شبکه از کار افتاده است. پنج مانیتور ایجاد کردم که تمام سرویس‌های روی VM را پوشش می‌دادند؛ به‌علاوه، یک پینگ به روتر Starlink Mini و یک جست‌وجوی DNS از طریق AdGuard Home نیز اضافه کردم.

پس از افزودن هر سرویس، داشبوردی پر از مانیتورهای سبز داشتم که بسیار اطمینان‌بخش به نظر می‌رسید. اما می‌خواستم مطمئن شوم Kuma واقعاً می‌تواند یک خرابی را تشخیص دهد، بنابراین عمداً کانتینر NetAlertX را متوقف کردم:

docker compose stop netalertx

مانیتور ابتدا زرد و سپس قرمز شد و رویداد در تاریخچهٔ آن ثبت شد. پس از راه‌اندازی دوبارهٔ کانتینر با دستور docker compose start netalertx، Kuma بازیابی را تشخیص داد و مانیتور دوباره سبز شد.

Kuma همچنان ماشین مجازی را با تمام چیزهایی که زیر نظر دارد به اشتراک می‌گذارد. اگر کل ماشین مجازی از دسترس خارج شود، مانیتور آن نیز از کار می‌افتد و عملاً نمی‌تواند هشداری ارسال کند. بااین‌حال، تا زمانی که میزبان در دسترس باشد، همچنان می‌تواند خرابی DNS را از مشکل روتر یا کانتینر تشخیص دهد.

NetAlertX به من نشان داد واقعاً چه دستگاه‌هایی متصل بودند

دستگاه‌های ناآشنا لزوماً نفوذگر نبودند

پیش از نصب NetAlertX، فهرست قابل‌اعتمادی از موجودی شبکه‌ام نداشتم. فهرست کلاینت‌های روتر فقط دستگاه‌هایی را نشان می‌دهد که در هر لحظه متصل‌اند و معمولاً آن‌ها را با نام‌های مبهمی نمایش می‌دهد که به‌جز یک آدرس IP و MAC، اطلاعات چندانی ارائه نمی‌کنند.

ازآنجاکه ماشین مجازی از طریق یک آداپتور اترنت پل‌شده به LAN دسترسی داشت، ابتدا باید تأیید می‌کردم که شناسایی ARP می‌تواند فراتر از هایپروایزر را ببیند:

sudo arp-scan --interface=ens33 192.168.1.0/24

این دستور فهرستی از دستگاه‌هایی را برمی‌گرداند که در حال حاضر از طریق زیرشبکه متصل‌اند:

192.168.1.1     74:24:x   (Unknown)
192.168.1.83    66:27:x   (Unknown: locally administered)
192.168.1.120   90:ca:x   (Unknown)
192.168.1.134   de:cf:x   (Unknown: locally administered)
192.168.1.245   14:13:x   (Unknown)

پس از اطمینان از کارکرد شناسایی ARP، مقدار SCAN_SUBNETS در NetAlertX را روی ['۱۹۲.۱۶۸.۱.۰/۲۴ –interface=ens33'] تنظیم کردم. سپس NetAlertX یک فهرست موجودی پایدار ایجاد کرد که شامل موارد زیر بود:

• آدرس‌های IP
• آدرس‌های MAC
• سازندگان
• اولین و جدیدترین زمان‌های مشاهده
• وضعیت‌های آنلاین و آفلاین
• رویدادهای دستگاه جدید

تا جایی که می‌دانم، NetAlertX یک سامانهٔ تشخیص یا پیشگیری از نفوذ نیست. یک دستگاه ناآشنا قطعاً می‌تواند موضوعی برای بررسی در اختیارم بگذارد، اما ثابت نمی‌کند که فردی متخاصم وارد شبکه شده است. ارزش واقعی آن بیشتر در جایگزین‌کردن فهرست موقت کلاینت‌ها با چیزی است که بیشتر شبیه تاریخچه و گزارش رویدادهاست.

Speedtest Tracker به نتایج منفرد زمینه داد

عملکرد اینترنت من به یک خط زمانی نیاز داشت، نه یک آزمایش دلگرم‌کننده

هدف این سرویس، کسب شناخت دربارهٔ ساعت‌هایی از روز بود که برای پخش جریانی و دانلود رسانه مناسب‌ترند؛ زمانی که سرانجام سرور رسانه را راه‌اندازی می‌کردم.

یک آزمایش معمولی سرعت بیشتر شبیه عکس لحظه‌ای است؛ به‌خاطر سپردن نتایج خوب آسان و فراموش‌کردن نتایج بد حتی آسان‌تر است. Speedtest Tracker این بررسی‌های گاه‌به‌گاه را با یک اجرای زمان‌بندی‌شده در هر دو ساعت جایگزین می‌کند.

هر نتیجه، سرعت دانلود و آپلود، پینگ، جیتر، ازدست‌رفتن بسته‌ها، اطلاعات ISP و سرور آزمایش انتخاب‌شده را نگه می‌دارد. پیکربندی Compose من برای این کار، هم زمان‌بندی و هم سرور آزمایش را ثابت نگه می‌داشت:

SPEEDTEST_SCHEDULE: "17 */2 * * *"
SPEEDTEST_SERVERS: "55297"

زمان‌بندی در دقیقهٔ ۱۷ یک ساعت در میان اجرا می‌شد تا از بازه‌های بدیهی «ابتدای ساعت» که معمولاً سرورهای مقصد زیر بار شدید قرار می‌گیرند، دوری شود. سرور ملبورن Superloop با ID ۵۵۲۹۷ را ثابت کردم تا انتخاب مقصد متفاوتی از Ookla نتواند مقایسهٔ اجراها را مخدوش کند.

Nginx Proxy Manager باعث شد این مجموعه مانند یک سیستم یکپارچه به نظر برسد

سرانجام نام‌های خوانا جایگزین فهرست روبه‌رشد پورت‌ها شدند

تا زمانی که هر چهار سرویس در حال اجرا بودند، مجموعهٔ قابل‌توجهی از پورت‌های اختصاص‌یافته به سرویس‌ها گرد آورده بودم:

• http://192.168.1.126:3000 (AdGuard)
• http://192.168.1.126:3001 (Uptime Kuma)
• http://192.168.1.126:20211 (NetAlertX)
• http://192.168.1.126:8080 (Speedtest Tracker)

خیلی زود مشخص شد که به‌خاطر سپردن اینکه هر پورت کدام سرویس را باز می‌کند، قرار است به‌سرعت بسیار خسته‌کننده شود.

بازنویسی‌های DNS در AdGuard که پیش‌تر انجام شده بودند، همگی نام‌های خوانا را به آدرس IP ماشین مجازی تفکیک می‌کردند. لازم بود Nginx Proxy Manager نام‌های میزبان درخواست‌شده را بخواند و سپس مرورگر را به سرویس متناظر هدایت کند.

در Nginx Proxy Manager، برای هر نام محلی یک Proxy Host ایجاد کردم. هر ورودی صرفاً از HTTP معمولی، دامنهٔ .home آن و نام میزبان یا آدرس و پورت سرویس پشت آن استفاده می‌کرد.

AdGuard Home و NetAlertX از ۱۹۲.۱۶۸.۱.۱۲۶ با پورت‌های ۳۰۰۰ و ۲۰۲۱۱ استفاده می‌کردند، زیرا هر دو کانتینر شبکهٔ میزبان را به اشتراک می‌گذاشتند. Uptime Kuma و Speedtest Tracker از uptime-kuma:۳۰۰۱ و speedtest-tracker:۸۰ استفاده می‌کردند، زیرا هر دو همان شبکه‌ای را به اشتراک می‌گذاشتند که Nginx Proxy Manager روی آن قرار داشت.

پس از ذخیره آن ورودی‌ها، همه درخواست‌ها همچنان به همان ماشین مجازی می‌رسیدند، اما Nginx Proxy Manager با استفاده از دامنه درخواست‌شده، درخواست‌ها را به داشبورد صحیح هدایت می‌کرد.

بخش کاربردی را پیش از بخش سرگرم‌کننده ساختم

اکنون هر سرویس آینده زیرساخت بهتری دارد

اجرای پنج سرویس، در قالب به‌روزرسانی‌ها و نگهداری، دردسر کارهای دستی بیشتری نسبت به نصب یک مدیا سرور ایجاد می‌کند. یک‌جا نگه‌داشتن همه آن‌ها نیز ماشین مجازی را به یک نقطه مرکزی و بزرگ شکست تبدیل می‌کند. اگر میزبان آفلاین شود، تمام سرویس‌های DNS، پایش، شناسایی دستگاه‌ها و ردیابی عملکرد نیز همراه آن از دسترس خارج می‌شوند.

این واقعاً یک نقطه‌ضعف است و باور کنید، به‌هیچ‌وجه به‌اندازه باز کردن کتابخانه فیلم‌ها روی مدیا سرور کاملاً جدیدم رضایت‌بخش نیست.

بااین‌حال، هر سرویس جایگاه خود را دارد. اکنون فیلتر DNS در سراسر شبکه، فهرستی از دستگاه‌ها در دسترس، سوابق قطعی سرویس‌ها و آدرس‌های خوانا نه‌تنها برای این سرویس‌های شبکه، بلکه برای مدیا سرور جدیدم نیز دارم.

وقتی بالاخره فرصت کنم مدیا سرورم را راه‌اندازی کنم، می‌توانم یک نام محلی به آن بدهم، آن را به پایشگر Uptime اضافه کنم و مناسب‌ترین زمان‌ها برای پخش جریانی و دانلود را به‌دقت زیر نظر بگیرم. همچنین دیگر پس از ازکارافتادن چیزی، مجبور نخواهم بود در آخرین لحظه زیرساختی را به آن وصله کنم.

کتابخانه فیلم‌ها می‌تواند کمی بیشتر منتظر بماند. دست‌کم حالا می‌دانم کدام بخش شبکه‌ام مانع بارگذاری همه‌چیز می‌شود.

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