قانون شنونده firewalld در برابر سیاست ارسال: هر کدام چه می‌کنند

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

دو سیاست، یک تونل

سیاست بیرونی به پرسشی ساده پاسخ می‌دهد: آیا بسته‌ای از این مبدأ می‌تواند به UDP 1194 روی این میزبان برسد؟ سیاست درونی به پرسش دیگری پاسخ می‌دهد: آیا کلاینت احراز‌هویت‌شده پشت آن تونل می‌تواند به این مقصد، با این پروتکل، روی این درگاه برسد؟ اولی درباره یک سوکت است، دومی درباره یک مسیر، و firewalld آن‌ها را با اشیای متفاوت مدل می‌کند چون در نقاط متفاوتی تصمیم‌گیری می‌شوند. یکی ویژگی یک سوکت روی این میزبان است و دیگری ویژگی مسیری از درون آن.

نتیجه عملی این است که یک تونل کارکننده هیچ چیزی درباره سیاست دوم نمی‌گوید و یک سیاست دوم درست سیاست اول را غیرضروری نمی‌کند.

شنونده واقعی بیرونی را مجاز کنید

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

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

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

مقصد رمزگشایی‌شده را جداگانه مجاز کنید

اتصال به سرویسی که روی خود سرور VPN اجرا می‌شود سیاست ورودی محلی است. اتصالی که به میزبان دیگری در LAN ارسال می‌شود به سیاست ارسال نیاز دارد، ارسال فعال‌شده در هسته و یک مسیر بازگشت — این‌ها سه نیاز جداگانه‌اند که مردم معمولاً آن‌ها را در یکی ادغام می‌کنند. اشیای سیاست مدرن firewalld ترافیک جهت‌دار میان ناحیه ورودی و ناحیه خروجی را توصیف می‌کنند و همان جای درست برای بیان این است که کدام مبدأهای VPN می‌توانند به کدام سرویس‌های خصوصی برسند.

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

چرا اعتماد به واسط میان‌بر اشتباه است

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

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

سه چیز را بررسی کنید، از جمله یک رد

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

ناحیه، درگاه، انتقال و شیء سیاست را در یادداشت‌های سرور ثبت کنید. در غیر این صورت تغییر بعدی روی این میزبان از همان گمان شروع می‌شود.