UFW را ساختند تا دیوار آتش با سه فرمان تنظیم شود، و در این کار کامیاب است. اما مشکل جای دیگری است: ufw status نیت‌ها را نشان می‌دهد نه نتیجه‌ها. قاعده‌ای می‌تواند در فهرست باشد و مطلقاً چیزی را نبندد — به سه دلیل گوناگون، که همه‌شان روی سرورهای واقعی مرتب پیش می‌آیند.

آغازی که شما را بیرون قفل نمی‌کند

ترتیب فرمان‌ها مهم است. نخست SSH را مجاز کنید، سپس فعال کنید:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

ufw enable پیش از مجازکردن SSH نشست خودتان را می‌بُرد، و از آن پس تنها کنسول ارائه‌دهنده می‌ماند. اگر سرور از پیش تنظیم شده و مطمئن نیستید، اتصال دومی را باز نگه دارید — از ویرایشی ناموفق جان به در می‌برد.

وضعیت مفصل را ببینید؛ وضعیت کوتاه سیاست پیش‌فرض را پنهان می‌کند:

sudo ufw status verbose

خطای نخست: قاعده هست و پورت به روی جهان باز است

رایج‌ترین سطر در پیکربندی دیگران:

sudo ufw allow 3306

MySQL این‌گونه «تا از خانه وصل شوم» باز می‌شود — و به روی تمام اینترنت باز می‌شود. دو صورت درست هست و هر دو بهترند:

sudo ufw allow from 203.0.113.25 to any port 3306

یا، مطمئن‌تر، سرویس را اصلاً بیرون نفرستید: bind-address = 127.0.0.1 در پیکربندی MySQL، و دسترسی بیرونی از راه تونل SSH. دیوار آتش خط دوم است؛ خط نخست آن است که سرویس روی نشانی عمومی گوش ندهد. قاعده‌ای در UFW ممکن است به‌خطا حذف شود، حال آنکه bind-address خودبه‌خود تغییر نمی‌کند.

خطای دوم: IPv6

قاعده‌ای مانند ufw allow from 203.0.113.25 تنها به IPv4 مربوط است. اگر سرور نشانی IPv6 داشته باشد — و بیشتر VPSها دارند و فعال است — سرویس از راه آن دسترس‌پذیر می‌ماند. ارائه‌دهنده نشانی داده، شما به یادش ندارید، و پویشگر به یاد دارد.

بررسی کنید که پالایش v6 اصلاً فعال است (IPV6=yes در /etc/default/ufw) و سرویس بی‌نیاز روی :: گوش نمی‌دهد:

ss -tulpn | grep ':::'

قواعدی که نشانی را صریح نام می‌برند باید برای هر نسخه پروتکل جداگانه نوشته شوند.

خطای سوم: Docker

آزارنده‌ترین. Docker پورت‌ها را با افزودن قواعد خودش به زنجیره‌های iptables پیش از آن‌هایی که UFW می‌نویسد منتشر می‌کند. در نتیجه ظرفی که با -p 5432:5432 اجرا شده از اینترنت دسترس‌پذیر است هرچند UFW Status: active و سیاست deny incoming گزارش می‌دهد. دیوار آتش خراب نیست — نوبتش به‌سادگی نمی‌رسد.

درمان در UFW نیست بلکه در شیوه انتشار پورت است:

ports:
  - "127.0.0.1:5432:5432"

بستن به نشانی محلی ساده‌ترین و مطمئن‌ترین راه‌حل است. تنها آنچه واقعاً به بازدیدکنندگان خدمت می‌دهد باید بیرون را بنگرد: معمولاً پورت‌های ۸۰ و ۴۴۳ یک پروکسی معکوس.

ترتیب قواعد

UFW نخستین قاعده همخوان را اعمال می‌کند و همان‌جا می‌ایستد. پس منعی که پس از یک اجازه افزوده شود کار نخواهد کرد: نوبتش هرگز نمی‌رسد. به شماره‌گذاری نگاه کنید و آنجا که لازم است درج کنید:

sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.0/24
sudo ufw delete 7

قواعد بر پایه شماره حذف می‌شوند، اما شماره‌ها پس از هر حذف جابه‌جا می‌شوند — یکی‌یکی حذف کنید و فهرست را دوباره بخوانید.

بررسی از بیرون

فرمان‌های محلی نشان می‌دهند چه چیزی تنظیم شده. آنچه واقعاً از کار درآمده تنها از ماشینی دیگر دیده می‌شود:

nmap -Pn -p- 203.0.113.25
nc -zv 203.0.113.25 3306

هر سرور دیگر یا رایانه خانگی شما به کار می‌آید. این تنها بررسی‌ای است که دروغ نمی‌گوید، و ارزش دارد پس از هر بازپیکربندی چشمگیر اجرا شود — به‌ویژه پس از نصب چیزی که «خودش شبکه را تنظیم می‌کند»: Docker، پنل‌های کنترل، VPN.

گزارش‌ها

UFW به‌صورت پیش‌فرض تقریباً چیزی نمی‌نویسد. با این فعال می‌شود:

sudo ufw logging low

ثبت‌ها به /var/log/ufw.log می‌روند — اما تنها اگر rsyslog در سامانه باشد. روی Debian 12 و Ubuntu 24.04 ممکن است نباشد، و آن‌گاه همه‌چیز به ژورنال systemd می‌رود:

sudo journalctl -k | grep -i '\[UFW'

/var/log/ufw.log تهی به‌خودی‌خود هیچ معنایی ندارد — نخست در ژورنال بنگرید.

از دیوار آتش چه انتظاری داشته باشیم

UFW آنچه را نباید دسترس‌پذیر باشد می‌بندد. محتوای درخواست‌ها به آنچه باز است را بازرسی نمی‌کند: پورت ۴۴۳ برای همه باز است، و هر چه به سایت برسد بی‌مانع می‌رسد. این کار ابزارهای دیگر است — دیوار آتش برنامه در سطح برنامه، و IDS در سطح ترافیک. کار دیوار آتش فروتنانه‌تر و مهم‌تر است: اینکه فهرست پورت‌های باز با آنچه درباره‌اش باور دارید همخوان باشد. شکل این فهرست همراه قواعد فعال در یک صفحه را نمایش پایین نشان می‌دهد.