در سرور جدید، دستورهای iptables را می‌زنیم و می‌بینیم پشت صحنه nftables کار می‌کند. امشب یک ruleset سادهٔ nft را می‌خوانیم و فرق rule موقت و دائمی firewalld را تمرین می‌کنیم.

این جلسه بخشی از دورهٔ لینوکس ۳۰۳ در ۴۰ شب است.

محیط تمرین: Ubuntu Clone برای nftables؛ Rocky Clone جدا برای firewalld؛ کنسول مستقل؛ بدون مدیر فایروال هم‌زمان.

جایگاه در دوره: هدف‌های 334.3 آزمون 303-300.

لایهٔ کرنل و مدیر policy#

nftables ابزار و مدل تازه‌تر netfilter دارد؛ firewalld یک daemon مدیریت policy با zone و service است و می‌تواند از backend nftables استفاده کند. کار کردن مستقیم با nft در کنار daemon فعال، ممکن است با reload بعدی تداخل کند. این جلسه مکمل عملیِ آگاهی nftables در آزمون است؛ firewalld هدف مستقل ۳۰۳ نیست.

از Snapshot پایه شروع کن؛ rulesetهای جلسات قبلی را روی این VM نگه ندار. ابتدا sudo nft list ruleset را ثبت کن. برای تمرین تازه، فایل ~/lpic303/host.nft:

table inet lpic303 {
    chain input {
        type filter hook input priority 0; policy drop;
        iifname "lo" accept
        ct state established,related accept
        ct state invalid drop
        ip protocol icmp accept
        meta l4proto ipv6-icmp accept
        ip saddr 192.168.56.20 tcp dport 22 accept
        ip6 saddr fd30:303::20 tcp dport 22 accept
        limit rate 3/minute counter log prefix "LPIC303 nft drop "
    }
}

جدول inet هر دو خانواده را می‌بیند؛ ruleهای دارای ip و ip6 را همچنان آگاهانه تعریف می‌کنیم. این فایل فقط INPUT میزبان را محدود می‌کند و policy روتر کامل نیست.

sudo nft -c -f ~/lpic303/host.nft
sudo nft -f ~/lpic303/host.nft
sudo nft list table inet lpic303

-c syntax و قابلیت بارگذاری را بررسی می‌کند؛ موفقیت آن اثبات ورود شبکه نیست. از client مجاز و یک VM دیگر اتصال تازه بزن. اگر table از قبل وجود دارد، دستور را کور تکرار نکن؛ وضع موجود و عملیات replacement را بررسی کن. برای برگشت، از کنسول فقط sudo nft delete table inet lpic303 را اجرا کن؛ flush ruleset تمام policyها را پاک می‌کند و راه برگشت محدود ما نیست.

zone و ماندگاری در firewalld#

در Rocky جدا:

sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --zone=public --add-service=https --timeout=5m
sudo firewall-cmd --zone=public --query-service=https
sudo firewall-cmd --permanent --zone=public --query-service=https

اگر کارت lab در public نیست، نام zone فعال همان کارت را جایگزین کن. HTTPS باید در runtime حاضر باشد و لزوماً در permanent نباشد؛ پس از timeout مجوز موقت برداشته می‌شود. service یک تعریف پورت و پروتکل دارد؛ داشتن نام https سرور TLS را نصب نمی‌کند.

برای تغییر دائمی بازبینی‌شده از --permanent --add-service=https استفاده کن؛ قبل از reload بدان تمام تغییرهای runtimeِ ذخیره‌نشده چه می‌شوند. --runtime-to-permanent همهٔ runtime را منتقل می‌کند و برای پذیرش یک تغییر کوچک ممکن است زیادی گسترده باشد. rich rule می‌تواند مبدأ را محدود کند؛ مجوز عمومی هم‌زمان باید بازبینی شود تا محدودیت دور زده نشود.

تمرین: چرا query runtime و permanent پاسخ‌های متفاوت دارند؟ پاسخ را با دو وضعیت ذخیره‌شده و فعال توضیح بده. منابع: نمونهٔ nftables و firewalld؛ بازکردن service .