tun0 نیست؟ IPsec رمزگشایی‌شده را در nftables با meta ipsec تطبیق دهید

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

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

دو بسته، یک رابط

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

آنچه آن را متمایز می‌کند زمینه مسیر امنیتی ورودی متصل به بسته است. nftables آن را به‌صورت meta ipsec exists نمایش می‌دهد که وقتی بسته از مسیر امنیتی IPsec رسیده باشد درست است. آن را با استخر کارخواهان، مقصد و سرویس ترکیب کنید و قاعده به‌قدر کافی مشخص می‌شود که ایمن باشد.

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

قاعده هدایت را بنویسید

فرض کنید یک سرویس دسترسی از راه دور IPv4 احراز هویت شده با کارخواهان در 10.90.0.0/24 و یک مقصد تأییدشده در 203.0.113.40 دارید. قطعه قاعده برای آن جریان چنین است.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

اصطلاح oifname ارزش نگه داشتن دارد. تصمیم خروج را مستند می‌کند و مانع می‌شود قاعده در جهتی تطبیق پیدا کند که قصدش را نداشتید، و این در دروازه‌ای با چند مسیر به اینترنت اهمیت دارد. روی یک جعبه آزمایش با یک پیوند بالاسو اصطلاح زائد به نظر می‌رسد و دقیقاً به همین دلیل پیش از آنکه جعبه پیوند دوم را بگیرد حذف می‌شود.

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

زمینه ورودی، زمینه خروجی نیست

همان خانواده عبارات جهت دیگر را با rt ipsec پوشش می‌دهد که انجمن امنیتی خروجی را توصیف می‌کند که بسته از آن استفاده خواهد کرد. این به پرسش دیگری پاسخ می‌دهد: نه اینکه این بسته از کجا آمده، بلکه آیا در مرحله بعد محافظت خواهد شد.

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

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

NAT تصمیم دیوار آتش نیست

ترافیک به سمت اینترنت از یک استخر کارخواه خصوصی معمولاً به ترجمه مبدأ نیاز دارد تا پاسخ راه بازگشت را پیدا کند. اما ترافیکی که برای سیاست خروجی IPsec دیگری انتخاب شده باید معافیت لازم خود را حفظ کند، و پوشاندن هر مبدأ خصوصی بدون فکر کردن به تصمیم حفاظت بعدی این را خراب می‌کند.

پذیرش درون زنجیره NAT هم مجوز عمومی نیست. NAT و پالایش وظایف متفاوتی دارند و زنجیره NAT هر بسته بعدی یک جریان برقرار را بررسی نمی‌کند، و دقیقاً به همین دلیل تکیه بر آن برای امنیت قواعدی تولید می‌کند که در آزمون کار می‌کنند و زیر بار شکست می‌خورند.

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

سرویس درونی دقیق را بررسی کنید

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

مرجع nftables عبارت meta ipsec، rt ipsec و عبارت‌های مخصوص جهت را مستند می‌کند و همان‌جاست که باید نحو را با نسخه نصب‌شده‌تان بررسی کنید. و دامنه را صریح نگه دارید: این یک نمونه IPv4 است، درباره IPv6 چیزی نمی‌گوید و هدایت دلخواه درگاه عمومی را بخشی از سرویس VPN نمی‌کند.