کلاینت‌های VPN توسط نمایه عمومی فایروال Windows مسدود می‌شوند

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

مشخص کنید ترافیک واقعاً روی کدام نمایه می‌رسد

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

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

در نصب استاندارد OpenVPN یا WireGuard آداپتور VPN به‌صورت شبکه ناشناس ظاهر می‌شود و در نمایه عمومی می‌افتد، که پیش‌فرض هر شبکه‌ای است که Windows نمی‌تواند دسته‌بندی کند: هیچ کنترل‌کننده دامنه‌ای از آن پاسخ نداد و هیچ نمایه دروازه‌ای مطابقت نکرد. نام رابط اینجا اهمیتی ندارد، بنابراین نامیدن آداپتور به VPN یا Corp چیزی را تغییر نمی‌دهد. DomainAuthenticated به ماشینی نیاز دارد که به دامنه پیوسته باشد ، و واقعاً بتواند از طریق آن رابط به کنترل‌کننده دامنه برسد؛ تونل تقسیم‌شده‌ای که فقط یک زیرشبکه را حمل می‌کند این شرط را برآورده نمی‌کند.

اگر قاعده‌ای که لازم دارید از قبل به مخزن VPN محدود است و از قبل روی دسته‌ای که همین حالا خواندید اعمال می‌شود، همین‌جا توقف کنید: فیلترکردن لایه شما نیست، و جای بعدی برای نگاه‌کردن پیکربندی سرویس است. این بررسی ده ثانیه طول می‌کشد و یک ساعت ویرایش قاعده را صرفه‌جویی می‌کند. نام دسته‌ها و اینکه هر یک چه چیزی را پوشش می‌دهد در مرجع Get-NetConnectionProfile مستند شده است.

پیش از ویرایش قواعد تأیید کنید که مشکل فیلترکردن است، نه مسیریابی

Ping آزمون ضعیفی است. ممکن است ICMP عبور کند در حالی که پورت سرویس دور ریخته می‌شود، و میزبان از LAN پاسخ دهد در حالی که همان درخواست را از تونل رد می‌کند. پورتی را که کلاینت لازم دارد، از کلاینت آزمایش کنید:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

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

وقتی نتیجه هنوز مبهم است، دور ریختن‌های نمایه مربوطه را ثبت و آنها را بخوانید:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

ورودی‌هایی که نشانی و پورت کلاینت را همراه DROP ذکر می‌کنند قاطع‌اند، و می‌گویند کدام قاعده غایب بوده است. سیاهه‌ای که چیزی ندارد در حالی که SYN کلاینت هرگز دیده نمی‌شود، به بالادست میزبان اشاره دارد، بنابراین پیش از دست‌زدن به شیء دیگر فایروال، به تونل، قاعده NAT یا مسیر مخزن برگردید.

یک قاعده ورودی را به مخزن کلاینت‌ها محدود کنید

تعمیر یک قاعده مجاز ورودی است که نشانی دور آن مخزن است، نه تمام جهان. از یک نشست ارتقایافته:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

وقتی سرویس یک فایل باینری واحد است، قاعده‌ای محدود به برنامه را با -Program به‌جای فهرست پورت ترجیح دهید؛ این استثنا را هم به فرایند و هم به محدوده مبدأ محدود می‌کند.

انتخاب نمایه همان جایی است که همان اشتباه در جهت مخالف رخ می‌دهد. -Profile Public وقتی آداپتور عمومی است و عمومی می‌ماند کافی است. -Profile Any وقتی سرویس باید بدون توجه به دسته‌بندی Windows کار کند قابل دفاع است، اما تنها تا زمانی که محدوده دور باقی بماند. چیزی که هرگز قابل دفاع نیست -RemoteAddress Any روی نمایه عمومی است: آن قاعده لپ‌تاپ را به هر شبکه کافه و هتلی که به آن می‌پیوندد می‌برد و پورت را برای هر کسی که آن زیرشبکه را به اشتراک می‌گذارد باز می‌کند.

مخزن را کنار قاعده بنویسید. -RemoteAddress 10.8.0.0/24 روزی که مخزن VPN دوباره شماره‌گذاری شود بی‌صدا از مطابقت می‌افتد، و نقص دقیقاً مثل باگ اصلی به نظر می‌رسد، به همین دلیل یک بعدازظهر دیگر می‌گیرد. قواعد را بر اساس سرویس و محدوده مبدأ نام‌گذاری کنید، آنها را همراه -Group نگه دارید، و هر بار تعریف مخزن تغییر کرد دوباره بخوانید. فهرست قواعدی که می‌توانید در یک صفحه بررسی کنید بهتر از قاعده درستی است که هیچ‌کس پیدایش نمی‌کند.

دسته را تنها زمانی تغییر دهید که دسته همان تصمیم است

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

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

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

روی دستگاه مدیریت‌شده ابتدا بررسی کنید که آیا خط‌مشی گروهی یا خط پایه MDM مالک این تنظیم است. اگر هست، تغییر محلی در بازآوری بعدی برگردانده می‌شود، و gpresult /h نام خط‌مشی مالک را می‌گوید؛ همان‌جا اصلاح کنید، نه روی نقطه پایانی.

از دو سر تأیید کنید و ردی بگذارید

جریانی را که کاربر گزارش کرده، پس از تغییر، از کلاینت تأیید کنید:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

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

پیش از اعلام پایان:

• نمایه ذکرشده در قاعده، نمایه روی رابطی است که ترافیک از آن می‌رسد.
• محدوده دور مخزن VPN است، و آن مخزن با آنچه سرور واقعاً می‌دهد مطابقت دارد.
• هیچ قاعده‌ای که افزوده‌اید -RemoteAddress Any روی نمایه عمومی استفاده نمی‌کند.
• هیچ چیز برای عبور آزمون غیرفعال نشد، و هر تغییر دسته ثبت می‌کند چه کسی آن را تأیید کرده است.