مقدار رجیستری NAT-T در ویندوز: نخست توپولوژی را بررسی کنید

یک اتصال VPN ویندوز شکست می‌خورد، جستجو یک مقدار رجیستری برمی‌گرداند و مقدار همراه با راه‌اندازی مجدد وارد می‌شود. این توالی گاهی کار می‌کند و هرگز چیزی را توضیح نمی‌دهد. تنظیم مورد بحث به یک پرسش پاسخ می‌دهد: سرور نسبت به دستگاه NAT کجاست؛ و تا وقتی ندانید کدام پروتکل و در کدام مرحله شکست خورده، بی‌معناست.

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

AssumeUDPEncapsulationContextOnSendRule تعیین می‌کند که آیا پیاده‌سازی IPsec ویندوز تلاش می‌کند با همتایی پشت دستگاه NAT ارتباط برقرار کند. مقدار پیش‌فرض مستند 0 آن حالت را مجاز نمی‌کند، 1 آن را وقتی سرور سمت پشت NAT است مجاز می‌کند، و 2 حالتی را پوشش می‌دهد که هر دو سر ترجمه شوند. اینها گزاره‌هایی درباره توپولوژی‌اند: چه کسی کجاست.

اگر آن را به‌صورت یک توالی بخوانید، اعداد ترجمه‌ی بیشتر را توصیف می‌کنند نه قابلیت اطمینان بیشتر. تنظیم 2 در شبکه‌ای که هیچ چیزی ترجمه نمی‌شود اتصال را سریع‌تر یا پایدارتر نمی‌کند و خطای احراز هویت را هم برطرف نمی‌کند. راهنمای NAT مایکروسافت برای L2TP/IPsec سیاست و بافت تاریخی پلتفرم آن را مستند می‌کند. آن بافت را با نسخه و نقش ویندوزی که واقعاً اجرا می‌کنید بسنجید، زیرا سندی که چندین انتشار را از سر گذرانده، گزاره‌ای درباره هر بیلد کنونی نیست.

توپولوژی را پیش از عدد تطبیق دهید

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

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

نخست مرحله شکست را بررسی کنید

L2TP/IPsec دست‌کم سه شکست متمایز تولید می‌کند: همتا در دسترس نیست، حفاظت IPsec برقرار نمی‌شود، و احراز هویت کاربر PPP پس از وجود تونل رد می‌شود. حساب ردشده با تغییر سیاست NAT تعمیر نمی‌شود، و ناسازگاری پیشنهادها با راه‌اندازی مجدد تعمیر نمی‌شود.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

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

SSTP روی HTTPS و IKEv2 بومی گزارش‌ها و کنترل‌های خودشان را دارند. هیچ‌کدام فقط به این دلیل که روی ویندوز هم اجرا می‌شوند به یک مورد NAT-traversal تبدیل نمی‌شوند.

تغییر را با راهی برای بازگشت انجام دهید

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

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