Always On VPN دسترسی به LAN نیست: فهرست بررسی منابع

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

گام 1: پیش از آزمودن، منبع را یادداشت کنید

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

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

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

گام 2: مشخص کنید کدام تونل باید آن را حمل کند

Windows Always On VPN تونل دستگاه و تونل کاربر دارد که به‌صورت نمایه‌های جداگانه با گواهی‌ها و دامنه‌های جداگانه پیکربندی می‌شوند. تونل دستگاه معمولاً فقط زیرساخت لازم پیش از ورود مانند مدیریت و سرویس‌های دامنه را حمل می‌کند؛ دسترسی گسترده کارکنان به برنامه‌ها به تونل کاربر تعلق دارد.

فیلترهای ترافیک ویژگی تونل دستگاه هستند و به همین دلیل نمونه مایکروسافت آن‌ها را برای ترافیک مدیریت به کار می‌برد. کپی کردن آن نمونه در یک نمایه عمومی دسترسی به منابع، تونلی می‌دهد که وصل می‌شود اما مجموعه اشتباه را حمل می‌کند. اتصال فعال را با Get-VpnConnection تأیید کنید و زیر همان اتصال آزمون کنید.

گام 3: مسیر را برای نشانی واقعی بررسی کنید

نام را یک بار حل کنید و سپس مسیر را ببینید: Find-NetRoute -RemoteIPAddress 10.20.5.10 واسط انتخاب‌شده، گام بعدی و نشانی مبدأ را گزارش می‌کند. اگر واسط آداپتور فیزیکی باشد، پیشوند در مجموعه مسیرهای تونل نیست یا کارخواه آن را با تونل تقسیم‌شده کنار گذاشته است. به‌جای افزودن مسیر محلی، با تعریف نمایه مقایسه کنید.

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

گام 4: حل نام‌های خصوصی را جداگانه بیازمایید

نام‌های خصوصی مسیر سیاست خودشان را دارند. نمایه می‌تواند قواعد NRPT و فهرست جست‌وجوی پسوند DNS را تحویل دهد که تا زمانی که تونل برپاست معتبرند. با Get-DnsClientNrptPolicy بخوانید کارخواه واقعاً چه دریافت کرده و سپس در همان نشست یک نام و یک نشانی را بیازمایید. اگر نام‌ها شکست بخورند و نشانی‌ها کار کنند، مشکل حل‌کننده است؛ اگر هر دو شکست بخورند، مسیر.

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

گام 5: فیلترها، هویت و دروازه خود برنامه را بررسی کنید

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

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