یک محدوده مقصد را برای هر استخر کلاینت VPN مسدود کنید
یک قاعده nftables می‌تواند یک پیشوند مقصد را برای استخر VPN مجاز رد کند بدون اینکه ترافیک خود دروازه را لمس کند. قلاب و موقعیت را هماهنگ کنید.
یک قاعده می‌تواند استخر VPN مجاز را از یک محدوده مقصد دور نگه دارد بدون اینکه چیزی دیگر از کارهای دروازه را مختل کند. خود قاعده کوتاه است؛ آنچه تعیین می‌کند کار می‌کند یا نه، قلابی است که در آن زندگی می‌کند و جایگاهش در زنجیره. اشتباه در این دو، دیوار آتشی می‌سازد که درست به نظر می‌رسد و ناسازگار رفتار می‌کند. از آنچه بسته هنگام دیدن قاعده انجام می‌دهد شروع کنید.
قاعده در واقع چه چیزی را تطبیق می‌دهد
قاعده سه چیز را همزمان تطبیق می‌دهد: یک رابط ورودی، یک پیشوند مبدأ و یک پیشوند مقصد. هر سه باید درست باشند تا drop اعمال شود، و همین آن را باریک نگه می‌دارد. خواندنش به‌عنوان یک عبارت آسان‌تر از خواندنش به‌عنوان سه سیاست جداگانه است.
تطبیق رابط چیزی است که ترافیک کلاینتِ فوروارد‌شده را از اتصال‌های خود دروازه جدا می‌کند. بدون آن، قاعده‌ای که فقط استخر مبدأ را نام می‌برد بسته‌هایی را هم تحت تأثیر قرار می‌داد که خود دروازه از آن نشانی تولید می‌کند، اگر هرگز چنین کاری بکند. پیشوند مبدأ سیاست را به کلاینت‌های مجاز محدود می‌کند و پیشوند مقصد آن را به یک محدوده. قاعده را به‌عنوان اشتراک، نه فهرست بخوانید.
پیش از هر تغییری سه مقدار را بنویسید: نام رابط تونل، استخری که سرور توزیع می‌کند، و پیشوندی که قصد رد آن را دارید. غلط تایپی در هر یک از آن‌ها قاعده‌ای می‌سازد که تمیز تجزیه می‌شود و از چیزی محافظت نمی‌کند. این سه مقدار را در سابقه تغییر کنار قاعده نگه دارید.
قلاب تعیین می‌کند قاعده بر چه کسی اعمال می‌شود
زنجیره netfilter به یک قلاب متصل است، و قلاب تعیین می‌کند زنجیره اصلاً کدام بسته‌ها را می‌بیند. قلاب forward ترافیکی را می‌بیند که از دروازه مسیریابی می‌شود، و ترافیک کلاینت به مقصد همین است. هر چیز دیگری در زنجیره مخاطب دیگری دارد.
قلاب input ترافیک خطاب‌شده به خود دروازه را می‌بیند، پس قاعده‌ای که آنجا قرار می‌گیرد دسترسی به سرویس‌های خودش را اداره می‌کند نه عبور را. قلاب output ترافیکی را می‌بیند که دروازه تولید می‌کند، که عکس چیزی است که سیاست استخر کلاینت نیاز دارد. نام زنجیره‌ها برچسب‌های دلبخواهی‌اند که نویسنده قواعد آن‌ها را انتخاب کرده، پس قلاب را از نام استنباط نکنید. بررسی کنید زنجیره کجا متصل است پیش از آنکه فرض کنید چه چیزی را می‌تواند تطبیق دهد.
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
خواندن اتصال یک بررسی یک‌خطی است که مانع می‌شود قاعده در زنجیره‌ای بیفتد که هرگز بسته را نمی‌بیند.
قاعده را پیش از پذیرش گسترده قرار دهید
قواعد به ترتیب ارزیابی می‌شوند و اولین رأی برنده است. یک پذیرش گسترده در جایگاه بالاتر زنجیره ارزیابی بسته‌هایی را که تطبیق می‌دهد پایان می‌دهد، پس dropی که بعداً افزوده شود هرگز برای آن‌ها اجرا نمی‌شود. همین قاعده ترتیب، تمام دلیل بی‌اثر بودن قاعده‌ای است که درست به نظر می‌رسد.
قاعده را پیش از پذیرش درج کنید نه در انتها بیفزایید. اگر زنجیره از پیش پذیرش عمومی برای رابط تونل دارد، قاعده جدید باید پیش از آن بیاید وگرنه فقط تزئینی است. ترتیب حاصل را بررسی کنید نه فایلی که ویرایش کردید، چون مجموعه‌قواعدی که از چند فایل ساخته شده ممکن است با هیچ‌یک از آن‌ها یکسان نباشد. سپس با یک بسته آزمایشی از استخر تأیید کنید.
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.confفرمان سوم فایل را بدون اعمال تجزیه می‌کند، که خطاهای نحوی را پیش از تبدیل شدن به قطعی می‌گیرد. با طرح بازگشت اعمال کنید، چون قاعده اشتباه در زنجیره forward می‌تواند تونلی را که رویش کار می‌کنید قطع کند.
جریان‌های موجود به قاعده جدید شما اهمیت نمی‌دهند
یک ورودی conntrack که پیش از وجود قاعده ساخته شده همچنان با پذیرش قبلی تطبیق می‌یابد. به همین دلیل drop جدید گاهی برای اتصال‌های تازه کار می‌کند و برای اتصالی که آزمایش می‌شود هیچ کاری نمی‌کند.
تطبیق وضعیت را در بالای زنجیره بخوانید. اگر پیش از قاعده شما ترافیک established و related را می‌پذیرد، هر جریانی که در جریان است تا بسته شدن ادامه می‌یابد. معمولاً برای قاعده اضطراری همین رفتار را می‌خواهید، و وقتی انتظار قطع فوری دارید گیج‌کننده است. پیش از استقرار تصمیم بگیرید کدام اثر را می‌خواهید. آزمایشی که از اتصال باز استفاده مجدد می‌کند داستان اشتباهی به شما می‌گوید.
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'فرمان اول نشان می‌دهد جریانی وجود دارد یا نه، و دومی نشان می‌دهد آیا قاعده وضعیتِ اولیه همچنان آن را می‌پذیرد. هر دو فقط‌خواندنی و در هنگام رخداد ایمن‌اند.
این قاعده چه چیزی نیست
قاعده فهرست سیاه دامنه، سیاست IPv6 یا محدودیت روی یک حساب برنامه خاص نیست.
هر یک از این‌ها سازوکار خودش را می‌خواهد. مسدودسازی دامنه باید نام‌ها را بازتاب کند، که فیلتر بسته انجام نمی‌دهد. ترافیک IPv6 تطبیق خودش را می‌خواهد، چون عبارت ip درباره بسته‌های ip6 چیزی نمی‌گوید. محدودیت در سطح برنامه متعلق به سرویس یا یک پروکسی احرازشده است، نه به تطبیق پیشوند. جدا نگه داشتن این نیازهاست که نمی‌گذارد یک قاعده باریک چهار کار خواسته شود.
قراردادی که این قاعده می‌دهد دقیق است: ترافیک از استخر مجاز به یک پیشوند مقصد رد می‌شود، در حالی که ترافیک نامرتبط دروازه سیاست موجود خود را حفظ می‌کند. آن جمله را کنار قاعده بنویسید و نفر بعدی می‌داند برای چه بوده است.