چرا دروازهٔ فایروال وابسته به وضعیت VPN، قاعدهٔ ping فقط از تونل نیست

یک قاعدهٔ فایروال را در نظر بگیرید که هر بار یک پروفایل VPN نام‌دار متصل می‌شود، ICMP echo را برای نشانی عمومی سرور روشن می‌کند. این را «ping فقط از تونل» می‌خوانند، و این خوانش به شکلی غلط است که اهمیت دارد. قاعده محدود نمی‌کند چه کسی می‌تواند به میزبان برسد؛ چیزی را تغییر می‌دهد که رابط عمومی پاسخ می‌دهد، در حالی که اتصال دیگری به‌طور تصادفی برقرار است. این‌ها دو سیاست متفاوت‌اند و یکی از آن‌ها بی‌صدا دامنهٔ مواجهه را گسترش می‌دهد.

قاعده‌ای که فکر می‌کنید نوشته‌اید

الزام موردنظر معمولاً باریک است: سامانهٔ پایش، یا تنها مدیر روی VPN، باید بتواند تأیید کند که سرور زنده است. وقتی به‌صورت جمله نوشته می‌شود، مثل کنترل دسترسی روی تونل به گوش می‌رسد. وقتی به‌صورت شیء فایروال نوشته می‌شود، به شرطی روی پروفایل عمومی تبدیل می‌شود، چون درخواست echo همان‌جا می‌رسد.

وقتی شرط، وضعیت اتصال باشد نه نشانی مبدأ، مجموعهٔ فرستنده‌های مجاز دیگر مجموعهٔ همتاهای VPN نیست. هر کس بتواند به نشانی عمومی برسد، تا وقتی دروازه باز است می‌تواند درخواست echo بفرستد. تونل مسیر نشد؛ تونل کلید شد.

کسانی که این ایده را تبلیغ می‌کنند معمولاً دربارهٔ اثری که می‌خواستند دروغ نمی‌گویند. آن‌ها به بررسی‌ای نیاز داشتند که فقط وقتی پیوند سالم است پاسخ دهد، و سالم بودن پیوند را آسان‌تر از راه VPN می‌شد مشاهده کرد. خطا این است که یک نشانهٔ دسترس‌پذیری را تصمیم دسترسی بدانیم و بعد آن را خودکار کنیم.

دروازه در واقع چه چیزی را کنترل می‌کند

این طراحی دو چیز مستقل را در هم می‌آمیزد، و جدا کردن آن‌ها بیشترِ اصلاح است. اولی دامنه است: کدام نشانی محلی، کدام نشانی‌های دور، کدام پروتکل و کدام نوع ICMP. دومی شرط است: اینکه شیء قاعده در این لحظه فعال است یا نه. دامنه چیزی است که فایروال برای هر بسته ارزیابی می‌کند؛ شرط چیزی است که یک script در انبار سیاست می‌نویسد، و این دو با ساعت‌هایی کاملاً متفاوت هم‌تراز می‌شوند.

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

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

شیء را یک بار بسازید، بعد آن را کلید بزنید

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

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

نام شناسهٔ پایدار است؛ نام نمایشی مستنداتی است که انسان می‌تواند ویرایش کند. بر اساس -Name هم‌تراز کنید و script دیگر نسخهٔ تکراری نمی‌سازد. همان شکل فرمان حالت IPv6 را با -Protocol ICMPv6 -IcmpType 128 پوشش می‌دهد، که قاعده‌ای جداست چون شماره‌های نوع echo در دو خانواده متفاوت است.

خانوادهٔ نشانی و نوع ICMP را به دلیل دومی هم صریح نگه دارید: -Protocol ICMPv4 بدون نوع، هر پیام ICMPv4 را که پروفایل اجازه می‌دهد مجاز می‌کند، از جمله آن‌هایی که هرگز قصد پذیرششان را نداشتید. نام بردن نوع 8 قاعده را به درخواست echo محدود می‌کند، و این تنها چیزی است که یک بررسی دسترس‌پذیری می‌فرستد.

جایی که خودکارسازی با قصد تناقض دارد

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

در خود بررسی وضعیت یک تلهٔ دامنه وجود دارد. Get-VpnConnection پروفایل‌های کارخواهی را گزارش می‌کند که روی ماشین پیکربندی شده‌اند، به‌طور پیش‌فرض برای کاربر جاری و با -AllUserConnection برای همهٔ کاربران. این فرمان کاربران دوری را که اکنون به سرور RRAS وصل شده‌اند گزارش نمی‌کند؛ آن مشاهدهٔ دیگری با فرمانی دیگر است. دروازه‌ای که روی مورد اشتباه ساخته شود به هیچ چیز وصل نیست.

سپس وضعیت‌هایی را پوشش دهید که کسی script نمی‌کند: راه‌اندازی با قاعده‌ای که از اجرای پیشین فعال مانده، سقوط کنترل‌گر در حالی که دروازه باز است، و پروفایلی که حذف می‌شود در حالی که قاعده‌اش زنده می‌ماند. هر یک به پیش‌فرض تعریف‌شده نیاز دارد، و پیش‌فرض ایمن برای یک اجازهٔ عمومی غیرفعال است. اگر الزام واقعاً پنجرهٔ نظرسنجی را تحمل نمی‌کند، قاعدهٔ وابسته به وضعیت ابزار اشتباهی است و اجرا باید در تونل باشد، نه در رابط عمومی.

در پایان، درخواست عمومی را دو بار آزمایش کنید، یک بار با اتصال انتخاب‌شدهٔ برقرار و یک بار با آن قطع، از میزبانی که روی VPN نیست. ping موفق از داخل تونل هیچ چیزی دربارهٔ این سیاست اثبات نمی‌کند، و این همان اندازه‌گیری است که بیشتر استقرارها از آن می‌گذرند.