LocalSubnet در یک قاعده فایروال SMB کلاینت‌های VPN را پوشش نمی‌دهد
یک قاعده مجاز LocalSubnet زیرشبکه‌های خود سرور را پوشش می‌دهد، نه یک استخر VPN مسیریابی‌شده را. پیش از گسترش دامنه، نشانی مبدأ را که سرور می‌بیند مقایسه کنید.
رایانه‌های رومیزی اداری به اشتراک می‌رسند، کاربران VPN از مهلت خارج می‌شوند و همان حساب از هات‌اسپات تلفن کار می‌کند. مجوزهای اشتراک به‌ندرت تفاوت را می‌سازند؛ معمولاً نشانی‌ای که به سرور فایل می‌رسد تفاوت را می‌سازد. قاعده‌ای که به LocalSubnet محدود شده، زیرشبکه‌های متصل خود سرور را مجاز می‌کند و استخر VPNِ جداگانه مسیریابی‌شده یکی از آن‌ها نیست. دو طراحی این شکاف را می‌بندند و سوابق بسیار متفاوتی بر جای می‌گذارند.
دو طراحی، یک نشانه
طراحی اول استخر VPN را به شرط نشانی راه دور قاعده اضافه می‌کند. سپس سرور نشانی تونل هر کلاینت را می‌بیند، بنابراین گزارش‌های آن می‌تواند یک کاربر راه دور را از دیگری جدا کند. طراحی دوم ترافیک VPN را از طریق دروازه‌ای مسیریابی می‌کند که آن را پیش از دیدن سرور به نشانی LAN ترجمه می‌کند. این کار اتصال را بازمی‌گرداند و تمایز را در همان گام حذف می‌کند.
جدول نقش‌ها را توصیف می‌کند نه نشانی‌ها را، و پیشوندهای خود شما تعیین می‌کنند کدام ردیف صدق می‌کند. به‌جای کپی یک نمونه از یک پست وبلاگ، مقادیر واقعی سرور را چاپ کنید:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthجدول یک کمک تصمیم است، نه ادعایی درباره هر استقرار. میزبان دارای رابط‌های اضافی، پیوند دوم سایت یا ماسک متفاوت، مجموعه محلی متفاوتی دارد.
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
مرجع New-NetFirewallRule مایکروسافت شرایط نشانی راه دور و کلیدواژه LocalSubnet را مستند می‌کند. پیش از تصمیم‌گیری اینکه این کلیدواژه به معنای همه نشانی‌های خصوصی است، آن را بخوانید، چون چنین نیست.
مقایسه کنید سرور واقعاً چه دریافت می‌کند
قاعده مؤثر را بخوانید، نه قاعده‌ای را که کسی به یاد دارد ساخته است. بررسی کنید که فعال باشد، بر پروفایل فعال اعمال شود، و شرط نشانی راه دور آن با مبدأیی که سرور می‌بیند مطابقت داشته باشد. قاعده‌ای که فقط در پروفایل دامنه فعال است، وقتی آداپتور پس از تغییر شبکه به پروفایل عمومی رفته، هیچ کاری نمی‌کند.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionفرمان اول فیلترهای نشانی متصل به قواعد اشتراک فایل را چاپ می‌کند و دومی نشان می‌دهد کدام پروفایل‌ها فعال‌اند و ترافیک ورودی نامنطبق چگونه رفتار می‌شود. همچنین به دنبال یک قاعده مسدودسازی و خط‌مشی مدیریت‌شده مرکزی باشید. قواعد مسدودسازی بر قواعد مجاز اولویت دارند و خط‌مشی‌ای که ادغام قواعد محلی را غیرفعال می‌کند می‌تواند یک استثنای محلی جدید را بی‌اثر کند.
این همان حالتی است که قاعده در کنسول درست به نظر می‌رسد و هیچ اثری بر ترافیک ندارد. تخصیص پروفایل را همزمان بررسی کنید، چون لپ‌تاپی که به شبکه دیگری پیوسته می‌تواند بدون اینکه کسی فایروال را لمس کند به پروفایل عمومی برود.
حمل‌ونقل را پیش از ورود آزمایش کنید
دسترس‌پذیری را از احراز هویت جدا کنید. یک شنونده روی TCP 445 ثابت می‌کند که سرویسی به پورت متصل است؛ ثابت نمی‌کند که یک بسته راه دور می‌تواند به آن برسد. یک اتصال TCP کامل‌شده هم هنوز چیزی درباره راه‌اندازی نشست SMB یا مجوزهای اشتراک نمی‌گوید. پیش از ویرایش یک قاعده، دست‌دادن را از هر دو طرف آزمایش کنید.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailedفرمان اول گزارش می‌دهد که آیا دست‌دادن TCP از ماشینی که آن را اجرا می‌کنید موفق می‌شود، و دومی نشانی حل‌شده و جزئیات رابط را اضافه می‌کند. آن را از کلاینت VPN و از یک رایانه رومیزی اداری اجرا کنید و سپس مقایسه کنید. Ping به هیچ‌یک از دو پرسش پاسخ نمی‌دهد، چون ICMP ممکن است در حالی که SMB باز است مسدود شود، یا در حالی که فایروال 445 را می‌اندازد مجاز باشد.
اگر دست‌دادن فقط از VPN شکست بخورد، دامنه مبدأ مشکوک اصلی است. اگر موفق شود و اشتراک هنوز شما را رد کند، به تشخیص نشست SMB و مجوزها بروید، نه ویرایش قواعد فایروال.
وقتی NAT مبدأ تمایز را حذف می‌کند
با وجود ترجمه در مسیر، سرور نمی‌تواند کلاینت‌های VPN را با نشانی از هم جدا کند. هر کاربر راه دور به‌صورت دروازه می‌رسد. هر مجوزی که به تمایز دادن آن‌ها وابسته است باید جایی اجرا شود که هویت‌هایشان هنوز دیده می‌شود، که معمولاً یعنی متمرکزکننده VPN یا یک پروکسی احرازکننده. قاعده فایروال می‌تواند ترافیک را مجاز کند؛ نمی‌تواند تمایزی را که ترجمه حذف کرده بازگرداند.
وقتی آن نشانی دروازه مجاز شد، هر کاربر راه دور زیر یک نشانی واحد ثبت می‌شود، بنابراین قاعده کل استخر را به هر کسی که به دروازه برسد می‌دهد. اگر تصمیم برای هر کاربر مهم است، نشانی‌های اصلی را قابل مشاهده نگه دارید یا تصمیم را به لایه‌ای منتقل کنید که هنوز کاربر را می‌شناسد. در غیر این صورت هر کاربر راه دور مجوزهای تنها نشانی‌ای را که سرور می‌تواند ببیند به ارث می‌برد و مسیر حسابرسی دیگر نمی‌تواند آن‌ها را از هم جدا کند. این یک تصمیم طراحی است، نه جزئیات فایروال.
آگاهانه بین دو طراحی یکی را انتخاب کنید. وقتی سرور باید ببیند چه کسی متصل شده، قاعده را به استخر واقعی VPN محدود کنید، و مسیر ترجمه‌شده را فقط زمانی بپذیرید که سرور واقعاً به آن اطلاعات نیاز ندارد. محدوده مبدأ انتخاب‌شده را کنار قاعده ثبت کنید، چون نفر بعدی که این را عیب‌یابی می‌کند اول به جدول نشانی‌ها نگاه می‌کند.