اوپن‌دبلیوآرتی را به اوپی‌ان‌سنس ترجیح می‌دهم، اما این روتر لینوکسی قدیمی برای بیشتر شبکه‌ها مناسب‌تر است

هرگاه شبکه‌ام به روتر تازه‌ای نیاز دارد، معمولاً پیش از OPNsense سراغ OpenWrt می‌روم. هر دو روتر مرزی بسیار توانمندی هستند، به‌ویژه وقتی در قالب ماشین مجازی به کار گرفته شوند. بااین‌حال، همین که شمار رابط‌ها، VLANها و قواعد بالا می‌رود، ناچار می‌شوم نقشه توپولوژی را بکشم تا به یاد بیاورم کدام شبکه‌ها به یکدیگر دسترسی دارند.

وقتی تمام نیازم یک روتر آزمایشگاهی است، این میزان پیچیدگی واقعاً زیاده‌روی به نظر می‌رسد.

ناحیه‌های رنگی قرمز (RED)، سبز (GREEN)، نارنجی (ORANGE) و آبی (BLUE) در IPFire، راه ساده‌تری برای تجسم این مرزها پیش رویم گذاشتند. مینی‌پی‌سی ZOTAC بی‌استفاده‌ام دو درگاه اترنت و یک کارت وای‌فای Intel داشت؛ بنابراین هر شبکه رابط فیزیکی ویژه خودش را گرفت و کار با کل این چیدمان بسیار آسان‌تر شد.

زوتک مرزی واقعی و ملموس برای شبکه‌ام ساخت

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

مینی‌پی‌سی کوچک ZOTAC من، پس از تلاش ناموفقم برای تبدیل آن به یک هایپروایزر، گوشه‌ای افتاده بود و خاک می‌خورد. با IPFire سرانجام کاری پیدا کرد که هم با سخت‌افزارش جور بود و هم، راستش را بخواهید، با پردازنده نسبتاً معمولی Celeron آن.

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

IPFire هنگام راه‌اندازی اولیه از من خواست چیدمان شبکه را انتخاب کنم و من ترکیب سبز و قرمز (GREEN + RED) را برگزیدم. اینجا بود که منطق رنگ‌ها واقعاً برایم جا افتاد. هر رنگ نه‌تنها نماینده نوعی شبکه، بلکه نشان‌دهنده وظیفه‌ای مشخص است. به‌این‌ترتیب، پیش از آنکه حتی یک قاعده دیوار آتش بنویسم، نقشه‌ای کاربردی از شبکه در اختیار داشتم.

IPFire هنگام راه‌اندازی همچنین می‌پرسد هر رابط شبکه را می‌خواهم به کدام رنگ اختصاص دهم و آداپتورهای موجود را با نشانی MAC آن‌ها فهرست می‌کند.

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

در نهایت، شبکه قرمز را به کارت شبکه سمت چپ و شبکه سبز را به کارت سمت راست اختصاص دادم. قرمز را طوری تنظیم کردم که مانند هر دستگاه دیگری در شبکه محلی، نشانی خود را از راه DHCP و از روتر مرزی‌ام بگیرد. برای سبز نشانی ثابت 10.77.50.1 را تعیین کردم و کارساز DHCP در IPFire را نیز فعال کردم تا نشانی‌های آزمایشگاه را از 10.77.50.100 تا 199 واگذار کند.

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

آزمایشگاهم تا نوشتن قاعده درست واقعاً جدا نبود

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

لپ‌تاپ متصل به شبکه سبز نشانی گرفته بود، DNS کار می‌کرد و وب‌سایت‌ها باز می‌شدند. سپس یکی از دستگاه‌های شبکه محلی خانه‌ام را پینگ کردم و با کمال تعجب دیدم که با یک پاسخ پژواک ICMP دوستانه جوابم را داد. معلوم شد تنظیمات پیش‌فرض دیوار آتش IPFire هنوز به آزمایش‌هایم اجازه می‌داد سری هم به همسایه بزنند.

توضیح ماجرا ساده بود: GREEN می‌توانست ترافیک را از مسیر RED عبور دهد و شبکهٔ خانگی من نیز در همان سمتِ بالادست قرار داشت. اختصاص‌دادن یک زیرشبکهٔ متفاوت به آزمایشگاه برای دور نگه‌داشتن ترافیک آن از دیگر بخش‌های شبکه‌ام کافی نبود.

خوشبختانه، ساختن قواعد دیوارهٔ آتش در IPFire بسیار آسان است. قاعده‌ای از نوع DROP ساختم که 192.168.1.0/24 را در همهٔ پروتکل‌ها هدف می‌گرفت. با قراردادن مبدأ روی «شبکه‌های استاندارد ← GREEN»، قاعده در بخش «دسترسی هدایت‌شدهٔ دیوارهٔ آتش» قرار گرفت؛ همان جایی که ترافیک عبوری از مسیریاب باید مدیریت می‌شد. پس از ذخیره و اعمال قاعده، آزمایش‌های قبلی را تکرار کردم:

1. دستگاه موجود در شبکهٔ خانگی دیگر به پینگ پاسخ نداد.
2. نشانی 1.1.1.1 همچنان پاسخ می‌داد و نشان می‌داد این قاعده دسترسی به اینترنت عمومی را مختل نکرده است.

این دقیقاً همان مرزی بود که نیاز داشتم. آزمایشگاه می‌توانست از اتصال اینترنت من استفاده کند، بی‌آنکه به همه‌چیز در شبکهٔ بالادست دسترسی آزاد داشته باشد.

هنگام ساختن قواعد دیوارهٔ آتش در IPFire، برای پالایش ترافیک کارخواه‌های یک شبکه، آن را از بخش «شبکه‌های استاندارد» انتخاب کنید. گزینهٔ «دیوارهٔ آتش» که نامی به‌طرز آزاردهنده مشابه دارد، در واقع به نشانی رابط خود IPFire اشاره می‌کند.

BLUE کارت وای‌فای اضافه را به آزمایشگاهی دوم تبدیل کرد

با کنارگذاشتن انتخاب خودکار کانال، نقطهٔ دسترسی به کار افتاد

کارت Intel Wireless ۳۱۶۵ در دستگاه ZOTAC راهی در اختیارم گذاشت تا گوشی‌ها و دیگر دستگاه‌های آزمایشی بی‌سیم را وارد آزمایشگاه کنم. ابتدا قابلیت‌های آن را بررسی کردم تا مطمئن شوم از حالت نقطهٔ دسترسی پشتیبانی می‌کند:

iw list | grep -A 12 'Supported interface modes'

این سخت‌افزار افزون بر حالت نقطهٔ دسترسی، از حالت پایش و کارخواه P2P نیز پشتیبانی می‌کرد.

در راه‌اندازی کنسولی، نوع شبکه را به GREEN + RED + BLUE تغییر دادم و سازوارگر بی‌سیم را به BLUE اختصاص دادم. نشانی 10.77.60.1/24 را به رابط BLUE دادم و DHCP را برای بازهٔ نشانی‌های 10.77.60.100 تا 199 فعال کردم. سپس افزونهٔ نقطهٔ دسترسی hostapd را از راه مدیر بستهٔ IPFire نصب کردم.

صفحهٔ تازهٔ پیکربندی بی‌سیم به من اجازه می‌داد نام شبکه را IPFire-Lab-Blue بگذارم، کد کشور را تعیین کنم و حالت بی‌سیم IEEE ۸۰۲.11an/gn ۲۰ MHz را برگزینم. باند را روی ۵ GHz با انتخاب خودکار کانال تنظیم کردم، تغییرات را ذخیره کردم و نقطهٔ دسترسی بی‌سیم را به راه انداختم.

برای حدود ۱۰ ثانیهٔ دل‌انگیز، وضعیت سرویس «در حال اجرا» بود؛ اما پیش از آنکه گوشی‌ام حتی بتواند پیدایش کند، متوقف شد. ناچار شدم گزارش‌ها را زیرورو کنم تا بفهمم چرا نقطهٔ دسترسی پس از راه‌اندازی پیوسته از کار می‌افتد:

grep -iE 'hostapd|blue0|iwlwifi' /var/log/messages | tail -n 60

علت این شکست به‌شکلی باورنکردنی جالب بود. سامانهٔ انتخاب خودکار کانال تشخیص داده بود که کانال ۵۲ در باند ۵ GHz بهترین جای ممکن برای پخش سیگنال است.

برخی سامانه‌های راداری نظامی، کنترل ترافیک هوایی و هواشناسی نیز از کانال ۵۲ استفاده می‌کنند. بنابراین، نقطهٔ دسترسی باید پیش از آغاز پخش، یک دقیقه برای شناسایی این سامانه‌ها صبر کند؛ فرایندی که «انتخاب پویای بسامد» یا DFS نام دارد.

همین تأخیر باعث می‌شد hostapd راه‌اندازی را نیمه‌کاره رها کند و سرویس از کار بیفتد. با تغییر باند به ۲.۴ GHz و انتخاب یک کانال ثابت، شبکه بی‌درنگ به راه افتاد. گوشی‌ام متصل شد و الگوی رنگی IPFire نیز یک مرز سودمند دیگر به دست آورد.

از BLUE به GREEN فقط یک در را باز کردم

پیشخوان محلی روی گوشی باز شد، اما باقی آزمایشگاه سیمی بسته ماند

گوشی‌ام به BLUE پیوست و توانست به شبکهٔ محلی من دسترسی پیدا کند. این مسیر برای GREEN بسته بود، اما کارخواه‌های بی‌سیم به قواعد جداگانهٔ خود نیاز داشتند. قاعدهٔ DROP دیگری ساختم که 192.168.1.0/24 را هدف می‌گرفت و این بار مبدأ آن را روی «شبکه‌های استاندارد ← BLUE» گذاشتم. پس از اعمال قاعده، مسیریاب مرزی دیگر به پینگ پاسخ نمی‌داد، درحالی‌که دسترسی به اینترنت بیرونی همچنان برقرار بود.

گام بعدی، آزمودن مرزهایی دقیق‌تر بود. یک ماشین مجازی روی لپ‌تاپم راه انداختم و پیشخوان Homarr را درون یک کانتینر Docker نصب کردم. چون شبکهٔ ماشین مجازی در حالت پل قرار داشت، نشانی 10.77.50.101 را از کارساز DHCP در GREEN دریافت کرد.

اکنون گوشی نمی‌توانست آن را پینگ کند و این مشکلی نداشت؛ اما می‌خواستم بدون آنکه دستگاه‌های بی‌سیم به سراسر زیرشبکه دسترسی پیدا کنند، پیشخوان را در دسترس داشته باشم.

قاعده‌ای از نوع ACCEPT از BLUE به 10.77.50.101 ساختم و دسترسی را به درگاه مقصد ۷۵۷۵ در TCP محدود کردم. با بازکردن http://10.77.50.101 روی گوشی، صفحهٔ ورود پیشخوان نمایان شد؛ اما تلاش برای پینگ‌کردن همان نشانی IP شکست خورد. علتش ساده بود: من فقط ترافیک TCP پیشخوان را مجاز کرده بودم، نه ICMP را.

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

می‌توانستم ببینم دیوار آتش دقیقاً چه می‌کند

جزئیات اتصال و نمودارها، آی‌پی‌فایر را به ابزاری عالی برای آزمایش تبدیل می‌کنند

وقتی مرزبندی‌ها درست کار کردند، می‌خواستم ببینم واقعاً چه داده‌هایی از آن‌ها می‌گذرند. صفحهٔ Connections در IPFire ابزار قدرتمندی برای مشاهدهٔ نشانی مبدأ و مقصد اتصال‌های فعال، همراه با موقعیت جغرافیایی آن‌هاست.

برای آزمودن این قابلیت، سراغ وب‌سایتی رفتم که از مسیر پرپیچ‌وخم یک CDN عبور نمی‌کرد: وب‌سایت دانشگاه غنا به نشانی https://ug.edu.gh. پرچم غنا در خروجی Connections نمایان شد و فرصت مناسبی برای آزمودن یکی از سیاست‌ها به من داد.

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

نمودارهای IPFire نیز نمایی کلی در اختیارم می‌گذارند. نمودارهای جداگانهٔ ترافیک GREEN و BLUE امکان مشاهده و مقایسهٔ فعالیت شبکه‌های سیمی و بی‌سیم را فراهم می‌کنند. نمودار برخوردهای دیوار آتش نیز همهٔ بسته‌های کنارگذاشته‌شده یا ردشده را در گذر زمان نشان می‌دهد و نمودارهای سخت‌افزاری دمای سامانه و مصرف منابع را زیر نظر دارند.

این نماها کمک می‌کنند آزمایش‌های مشخصی را موشکافانه بررسی کنم و نمودارها نیز تمام فعالیت‌های پیرامون آن‌ها را نشان می‌دهند. ظاهرشان هم فوق‌العاده است؛ مزیتی که بی‌تأثیر نیست.

آی‌پی‌فایر با وجود دردسرهایش جای خود را باز کرد

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

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

وب‌سایت www.ipfire.org خطای SERVFAIL برمی‌گرداند، زیرا تحلیلگر DNS مسیریاب مرزی بالادستی نمی‌توانست فرایند DNSSEC را کامل و دامنه را اعتبارسنجی کند. تغییر DNS در IPFire به 1.1.1.1 مشکل را برطرف کرد، اما این همچنان پیچیدگی آزاردهنده‌ای در فرایندی است که در حالت عادی باید نسبتاً سرراست باشد.

با این همه، دستگاه ZOTAC اکنون یک آزمایشگاه سیمی، یک ناحیهٔ بی‌سیم جداگانه، استثناهای مشخص میان آن‌ها و داده‌های بسیار سودمندی در قالب نمودارها برایم فراهم کرده است.

هرگاه به انعطاف‌پذیری نیاز داشته باشم، هنوز هم سراغ OpenWRT می‌روم. بااین‌حال، برای این دستگاه رنگ‌های IPFire به هر رابط نقشی مشخص دادند و فهم قوانین را بسیار آسان‌تر کردند. راه‌اندازی کمی شکیبایی می‌خواست، اما در پایان آزمایشگاهی دارم که آن‌قدر خوب می‌شناسمش که بتوانم با خیال آسوده خرابکاری را در آن آغاز کنم.

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