فضای آموزشی عملیاتیِ بدون آدم با تابلوی nftables، تغییر اتمیک و مسیر برگشت زمان‌دار

WIUNIX ACADEMY

تغییر اتمیک nftables؛ برگشت زمان‌دار رو قبل از قطع دسترسی تمرین کن

در دو فضای شبکهٔ جدا، یک تغییر معتبر ولی اشتباه رو اعمال می‌کنیم و با timer مستقل و فایل برگشتِ همان جدول ارتباط رو برمی‌گردونیم؛ بدون تغییر فایروال میزبان.

پیشرفته40 دقیقه مطالعهبه‌روزرسانی
محیطت رو انتخاب کن

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخهٔ سرورت رو انتخاب کن تا مراحل، دستورها و راه‌حل‌های همون محیط رو ببینی.

Ubuntu 26.10بررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

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

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

تنظیم مقادیر برای محیط من8 مقدار قابل‌تغییر

از اینجا شروع کن

آخر این آموزش چی خواهیم داشت؟

در دو فضای شبکهٔ جدا، یک تغییر معتبر ولی اشتباه رو اعمال می‌کنیم و با timer مستقل و فایل برگشتِ همان جدول ارتباط رو برمی‌گردونیم؛ بدون تغییر فایروال میزبان.

سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده

مسیرهای مستند اوبونتو ۲۶٫۱۰ و LTSهای ۲۶٫۰۴ و ۲۴٫۰۴، دبیان ۱۳ و ۱۲، RHEL/راکی/آلما ۱۰ و ۹ و آرچ/مانجارو غلتان در ۲۰۲۶-۱۱-۰۵ بررسی شده‌اند. نام بسته، مسیر ماندگاری و مالکیت مدیر فایروال فرق می‌کنه. همهٔ تغییرها فقط برای ماشین مجازی قابل‌حذف و namespaceهای تازه‌اند؛ اجرای واقعی روی همهٔ سیستم‌ها ادعا نمی‌شه.

قبل از شروع

  • ماشین مجازی آزمایشی قابل‌حذف با systemd به‌عنوان پردازش شمارهٔ یک، namespace شبکه و دسترسی root مجاز؛ کنسول میزبان باید در دسترس باشه.
  • ابزارهای nft، ip، ping، flock و systemd-run و ویرایشگر sudoedit؛ آماده‌سازی بسته فقط در تغییر مصوب محیط آزمایشه.
  • نام‌های کاملاً تازه و یک پوشهٔ خالیِ ساخته‌نشده؛ هیچ سرویس، رابط یا فایروال عملیاتی نباید هدف باشه.

قطع دسترسی رو تمرین کنیم، بدون دست‌زدن به فایروال میزبان

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

فقط روی ماشین مجازی آزمایشیِ قابل‌حذف با دسترسی root مجاز، systemd و پشتیبانی namespace کار کن. دو فضای شبکهٔ تازه با یک جفت رابط مجازی veth به هم وصل می‌شن؛ نه مسیر پیش‌فرض می‌گیرن، نه NAT و نه رابطی به شبکهٔ میزبان. هر دستور تغییردهندهٔ nft داخل فضای سرور و فقط روی جدول انحصاری همین تمرین اجرا می‌شه. فایروال میزبان و قانون SSH بیرون از آزمایش می‌مونن.

موضوع این راهنما تراکنش تغییر فایروال و برگشت زمان‌دار است. مشکل دسترسی Docker/UFW، بن Fail2ban و تصمیم‌های CrowdSec در راهنماهای جدا بررسی می‌شن. این نمونه نه سیاست آمادهٔ فایروال عملیاتی است و نه دستور مهاجرت میزبان مدیریت‌شده به nftables خام.

نام‌های تازه و فرصت برگشت رو انتخاب کن

فرم مقادیر نمونه رو باز کن و برای دو فضای شبکه، جدول، timer و پوشهٔ شواهد نام تازه بذار. آدرس‌های اولیه از محدودهٔ مستندسازی هستن و فقط در یک شبکهٔ /30 جدا استفاده می‌شن. قبل از کپی، مقدارها رو اعمال کن؛ نام دو فضا باید فرق داشته باشه و دو IP هم باید آدرس میزبانِ متفاوت در همان /30 باشن.

این مقدارهای عمومی فقط برای همین زبان و محیط در همین تب می‌مونن؛ رمز و اطلاعات خصوصی جاشون اینجا نیست. تا اعمال یا بازنشانی تغییرها و رفع مقدار نامعتبر، کپی دستورها متوقف می‌شه. زمان برگشت 90 ثانیه است، اما تضمین مهلت بازیابی نیست؛ تأخیر مدیر سرویس، مشکل کرنل یا شکست بازگردانی می‌تونه دیرترش کنه یا اصلاً مانع برگشت بشه. کنسول ماشین مجازی رو در دسترس نگه دار.

01

قدم بعدی

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

اوبونتو/دبیان از بسته‌های nftables، iproute2، iputils-ping و util-linux استفاده می‌کنن. سرویس بومی معمولاً /etc/nftables.conf رو می‌خونه؛ واحد و drop-in واقعی رو ببین. برای این تمرین فعال، متوقف یا دوباره راه‌اندازیش نکن. دبیان ۱۲ در LTS است؛ پوشش بسته و معماری رو جدا بررسی کن.

bash

ترمینال ماشین مجازی آزمایشی قابل‌حذف

cat /etc/os-release
uname -r
cat /proc/1/comm
dpkg-query -W nftables iproute2 iputils-ping util-linux coreutils systemd sudo
sudo sh -c 'command -v nft ip ping flock systemd-run systemctl journalctl sudo sudoedit'
sudo nft --version
systemd --version
از کجا بفهمم درست انجام شده؟

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

02

قدم بعدی

نصب اختیاری ابزار روی ماشین مجازی قابل‌حذف

اگر ابزارها موجودن رد شو. تغییر مخزن رسمی و اثرش روی واحدهای بسته رو بررسی کن. برای این تمرین مدیر فایروال رو عوض نکن و سرویس فایروال میزبان رو فعال نکن.

bash

ترمینال ماشین مجازی آزمایشی قابل‌حذف

sudo apt-get update
sudo apt-get install nftables iproute2 iputils-ping util-linux coreutils sudo
sudo sh -c 'command -v nft ip ping flock systemd-run sudoedit'
از کجا بفهمم درست انجام شده؟

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

03

قدم بعدی

قبل از تغییر، صاحب قانون‌های میزبان رو پیدا کنیم

اول مدیرهای فعال و نصب‌شده رو ببین. nft دستور بارگذاری قانون در کرنله و لزوماً daemon مستقلی نداره؛ غیرفعال‌بودن سرویس nftables به معنی خالی‌بودن فایروال نیست. firewalld، UFW، Docker، Fail2ban، CrowdSec یا اتوماسیون محلی ممکنه بخش‌های مختلف رو بسازن و بعداً دوباره عوض کنن. قانون‌ها می‌تونن آدرس خصوصی داشته باشن؛ محلی بررسی کن و خروجی رو عمومی نکن.

اتصال‌های NetworkManager می‌تونن zone فایروال firewalld رو تعیین کنن. برای این تمرین اتصال، zone یا تنظیم موقت و دائمی رو عوض نکن. accept در یک زنجیره هم مجوز قطعی عبور از کل فایروال نیست؛ زنجیرهٔ مرتبط دیگری هنوز می‌تونه بسته رو رد کنه. به‌جای رقابت با مدیر فعلی، روش مدیریتش رو حفظ کن.

bash

ترمینال ماشین مجازی آزمایشی قابل‌حذف

systemctl show nftables.service firewalld.service ufw.service docker.service NetworkManager.service fail2ban.service crowdsec.service -p Id -p LoadState -p ActiveState
sudo nft -n list ruleset
systemctl cat nftables.service
از کجا بفهمم درست انجام شده؟

مدیر قانون‌ها و رفتار واحد نصب‌شده رو شناختی؛ چیزی متوقف، خالی یا دوباره تنظیم نشده.

04

قدم بعدی

دو فضای شبکهٔ تازه و اتصال خصوصی‌شون رو بسازیم

بررسی اول روی نام موجود یا پوشهٔ شواهد موجود متوقف می‌شه. بعد دو فضای شبکه می‌سازیم. جفت veth از همان اول داخل این فضاها با نام‌های محلی ثابت nfta0 و nftb0 ساخته می‌شه؛ هیچ رابط میزبان رو جابه‌جا نمی‌کنیم. آدرس‌ها در همان /30 مستقیم می‌مونن و تنظیم forwarding تغییر نمی‌کنه.

هر تغییر روی خطا متوقف می‌شه، ولی مجموع این مراحل تراکنش نیست؛ شکست یک خط بعدی می‌تونه پوشهٔ خالی یا یک فضای شبکه باقی بذاره. فقط همان نام‌ها رو بررسی کن و بعد از فهمیدن علت از بخش جمع‌کردن تمرین کمک بگیر؛ همهٔ namespaceها رو حذف نکن. قبل از بارگذاری فایروال، اولین ping باید جواب بده.

bash

ترمینال ماشین مجازی آزمایشی قابل‌حذف

sudo test ! -e '/var/lib/academy-nft-rollback-lab' || exit 1
sudo test ! -e '/run/netns/academy-nft-server' || exit 1
sudo test ! -e '/run/netns/academy-nft-client' || exit 1
test "$(systemctl show -p LoadState --value 'academy-nft-rollback.timer')" = not-found || exit 1
test "$(systemctl show -p LoadState --value 'academy-nft-rollback.service')" = not-found || exit 1
test "$(systemctl show -p LoadState --value 'academy-nft-rollback-rehearsal.timer')" = not-found || exit 1
test "$(systemctl show -p LoadState --value 'academy-nft-rollback-rehearsal.service')" = not-found || exit 1
sudo mkdir -m 0700 -- '/var/lib/academy-nft-rollback-lab' || exit 1
sudo ip netns add 'academy-nft-server' || exit 1
sudo ip netns add 'academy-nft-client' || exit 1
sudo ip -n 'academy-nft-server' link add nfta0 type veth peer name nftb0 netns 'academy-nft-client' || exit 1
sudo ip -n 'academy-nft-server' address add '192.0.2.1/30' dev nfta0 || exit 1
sudo ip -n 'academy-nft-client' address add '192.0.2.2/30' dev nftb0 || exit 1
sudo ip -n 'academy-nft-server' link set lo up || exit 1
sudo ip -n 'academy-nft-client' link set lo up || exit 1
sudo ip -n 'academy-nft-server' link set nfta0 up || exit 1
sudo ip -n 'academy-nft-client' link set nftb0 up || exit 1
sudo ip netns exec 'academy-nft-client' ping -c 2 -W 2 '192.0.2.1' || exit 1
از کجا بفهمم درست انجام شده؟

دو فضای جدا قبل از فایروال با ICMP به هم می‌رسن؛ رابط میزبان و مسیر پیش‌فرض تغییری نکرده.

همهٔ آموزش‌های آکادمی ↗