L2TP/IPsec وقتی سرویس IKEEXT غیرفعال است کار نمیکند
بدون IKEEXT، بدون IPsec: L2TP و IKEv2 شکست میخورند در حالی که انواع دیگر همچنان وصل میشوند. سرویس را بررسی کنید و سپس پیش از ویرایش پروفایل ببینید چه چیزی آن را غیرفعال کرده است.
یک لپتاپ به دروازه IKEv2 میرسد اما در برابر دروازه L2TP/IPsec شکست میخورد، و خطا پیش از آنکه هیچ نام کاربری فرستاده شود ظاهر میشود. پروفایل معمولاً اولین مظنون و معمولاً اشتباه است. ویندوز تبادل کلید IPsec را در یک سرویس اجرا میکند و تا وقتی آن سرویس غیرفعال است، کلاینت داخلی پشتهای برای مذاکره ندارد. پیش از دست زدن به حتی یک فیلد پروفایل، سرویس را بررسی کنید و سپس ببینید چه چیزی آن را غیرفعال کرده است.
سرویس پشت شکست
IKE and AuthIP IPsec Keying Modules که در فهرست سرویسها با نام IKEEXT نمایش داده میشود، تبادل کلید را انجام میدهد و سوکتهای UDP 500 و 4500 را در ویندوز نگه میدارد. آن را غیرفعال کنید تا هم L2TP/IPsec و هم IKEv2 مذاکرهکننده خود را از دست بدهند، در حالی که PPTP و SSTP میتوانند به کار خود ادامه دهند چون به آن وابسته نیستند. همین شکاف توضیح میدهد چرا کاربر میتواند گزارش کند که یک نوع VPN کار میکند و نوع دیگر روی همان دستگاه مرده است. سرویس بخشی از سیستمعامل است، بنابراین هیچ تنظیم پروفایلی نمیتواند جای آن را بگیرد.
آزاد کردن آن دو پورت همان عارضهای است که توصیههای بد تولید میکند. یک ابزار یا نوشته انجمن متوجه میشود که 500 و 4500 اشغال شدهاند، سرویس را برای آزاد کردن آنها متوقف میکند و بدینترتیب IPsec را بیصدا از میزبان حذف میکند. این دو اثر یک کنشاند، پس هر راهنمایی که پاکسازی پورتها را توصیه کند، یک معاوضه را توصیف میکند نه یک تعمیر.
سرویس را بدون حدس زدن برگردانید
از مدیر سرویس دو پرسش کنید: نوع راهاندازی چیست و وضعیت کنونی چیست. اولی میگوید آیا سرویس پس از راهاندازی مجدد برمیگردد؛ دومی میگوید آیا اکنون در حال اجراست. هر دو پرسوجو را از یک خط فرمان ارتقایافته اجرا کنید تا همان پوسته بتواند بعداً تنظیم را تغییر دهد.
sc qc ikeext
sc query ikeext
نوع راهاندازی Disabled کل نشانه را توضیح میدهد و راهحل آن است که آن را به Automatic برگردانید و سرویس را راه بیندازید. در کنسول Services ورودی با نام نمایشی خود، IKE and AuthIP IPsec Keying Modules، ظاهر میشود، پس جستجوی IKEEXT در آن فهرست چیزی پیدا نمیکند. اگر سرویس تازه پس از آنکه یک اتصال ناموفق از قبل اجرا شده بود راهاندازی شده، دوباره راهاندازی کنید، چون پشتهای که با آن ترتیب مقداردهی شده باشد میتواند به شکلهایی شکست بخورد که بیربط به نظر میرسند.
sc config ikeext start= auto
net start ikeext
چه چیزی دوباره آن را خاموش میکند
برخی مجموعههای VPN شخص ثالث پیادهسازی IPsec خود را دارند و هنگام نصب IKEEXT را غیرفعال میکنند و پس از آن کلاینت ویندوز از کار میافتد. حذف آن محصول دیگر L2TP/IPsec را روی دستگاههایی که ویرایش پروفایل هیچ نتیجهای نمیداد بازگرداند و نصب دوباره بدون مؤلفه متضاد نیز همین کار را کرد. سرویس هنگام نصب غیرفعال شد، نه اینکه کاربر آن را تغییر داده باشد.
خطمشی گروهی هم میتواند نوع راهاندازی را تثبیت کند؛ در این صورت یک تغییر محلی در بازآوری بعدی برگردانده میشود و مدیر مالک خطمشی باید آن را تغییر دهد. نوع راهاندازی را پیش از راهاندازی مجدد، پس از آن و پس از بهروزرسانی محصول دیگر همراه با تاریخ ثبت کنید. مقداری که پیاپی به Disabled برمیگردد، مالک خود را از روی الگو لو میدهد نه با حدس.
نخست مرحله را بخوانید، سپس گزارش را
وقتی سرویس در حال اجراست، مرحله شکست تعیین میکند بعد کجا را ببینید. توقف در حین IKE معمولاً یعنی UDP 500 یا 4500 هرگز به سرور نرسیده یا سرور پشت NAT بدون تنظیم کپسولهسازی متناظر است. رسیدن به درخواست اعتبارنامه و شکست در همانجا یک مشکل احراز هویت PPP است نه IPsec. تونلی که بالا میآید و به جایی نمیرسد یک خطای مسیریابی یا تونل تقسیمشده است و تنها اولی از آن سه در پروفایل VPN جای دارد.
پروفایلهای دارای گواهی مرحله خود را اضافه میکنند. کلاینت باید به مرجع صادرکننده اعتماد کند و گواهی باید سرور در حال اعتبارسنجی را نام ببرد؛ وقتی هر یک از این دو شرط برآورده نشود، دیالوگ همچنان خطای مذاکره اولیه را گزارش میکند، پس گزارش رویداد همان جایی است که دلیل واقعی ظاهر میشود. پیش از ویرایش پروفایل، مدخل گزارش را بخوانید، چون دیالوگ چند خطای متمایز را در یک جمله فشرده میکند. گواهی منقضی همان دیالوگ سرویس غیرفعال را تولید میکند و همین است که مدخل گزارش را مهم میکند.
برای هر تلاش، مرحله شکست، متن خطا و مهر زمانی را ثبت کنید. این سه فیلد مشکل دسترسیپذیری را از مشکل احراز هویت و از مشکل مسیریابی جدا میکنند و تغییر بعدی را به تصمیم تبدیل میکنند نه حدس.
چیزی که یک تعمیر محلی نمیتواند ثابت کند
بازگرداندن سرویس نیمی از مسیر را که روی لپتاپ است درست میکند. سرویس کارآمد تنها نیمه محلی را ثابت میکند: طرف دور هنوز باید پیشنهاد انتخابشده، اعتبارنامههای دادهشده و نشانی مبدأیی که بسته از آن میآید را بپذیرد. هیچ کاری روی لپتاپ دیوار آتشی را که UDP 500 را پیش از رسیدن به همتا دور میریزد جبران نمیکند. وضعیت موفق سرویس یک پیششرط است نه گواهی بر اینکه تونل بالا خواهد آمد.
غیرفعال کردن IKEEXT برای آزاد کردن پورتها تنها وقتی قابل دفاع است که بپذیرید VPNهای IPsec ویندوز از کار میافتند. این کار تعارض پورت را با حذف ویژگیای که به پورت نیاز داشت حل میکند و این بهندرت همان معاوضهای است که کاربر در نظر داشت. پیش از تغییر هر چیز، تأیید کنید که سرویس وجود دارد، روی Automatic تنظیم شده و در حال اجراست، که پشته دوم IPsec نصب نیست و که کلید از پیش اشتراکگذاشتهشده یا زنجیره گواهی با دروازه مطابقت دارد.
- IKEEXT وجود دارد، روی Automatic تنظیم شده و پیش از اتصال کلاینت در حال اجراست.
- چیز دیگری UDP 500 یا 4500 را نگه نمیدارد.
- پشته دوم IPsec از کلاینت قدیمی باقی نمیماند.
- کلید یا زنجیره گواهی با پیکربندی دروازه مطابقت دارد.
- مرحله شکست پیش از ویرایش پروفایل ثبت شد.