تنها فایروال ویندوز به‌عنوان کلید قطع VPN: آیا دوام می‌آورد؟

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

سه شرط، به این ترتیب

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

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

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

طبقه‌بندی نخستین دروازه است

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

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundAction

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

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

استثنای نقطه پایانی علاوه بر قاعده به مسیر هم نیاز دارد

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

New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
  -Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32

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

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

DNS و IPv6 همان جایی است که باز شکست می‌خورد

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

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

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

با متوقف کردن کلاینت آزمایش کنید، نه با کشیدن کابل

تنها آزمایش معنادار آن است که شکستی را که از آن محافظت می‌کنید تقلید کند. سرویس را متوقف کنید، فرایند را بکشید یا آداپتور ساخته‌شده توسط کلاینت را غیرفعال کنید، سپس تلاش کنید به اینترنت و به یک نام برسید:

Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443

هر سه باید شکست بخورند. اگر اولی موفق شود، مسدودسازی برقرار نیست؛ اگر دومی جایی که اولی شکست خورد موفق شود، نشت DNS دارید؛ اگر سومی موفق شود، IPv6 پوشش داده نشده است. هر نتیجه دقیقاً به یکی از شکاف‌های بالا اشاره می‌کند.

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

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