چرا PPTP و L2TP/IPsec پیش از پرسش نام کاربری متوقف می‌شوند؟
نبودِ پرسش نام کاربری یعنی PPP هرگز آغاز نشده است، پس خطا در انتقال، تبادل کلید یا برپایی تونل است. پیش از نصب دوباره، ترتیب مرحله‌ها را بررسی کنید.
نبودِ پرسش نام کاربری یک هدیهٔ تشخیصی است: PPP هنوز آغاز نشده، پس حساب، گذرواژه و سیاست دامنه هنوز پرسیده نشده‌اند. در اتصال PPTP یا L2TP/IPsec کلاینت تنها زمانی اعتبارنامه می‌خواهد که تونل وجود داشته باشد و سرور جلسهٔ PPP را آغاز کرده باشد. هر چیزی که پیش از آن لحظه شکست بخورد، انتقال، تبادل کلید یا برپایی تونل است، که سطحی بسیار کوچک‌تر از «VPN خراب است» است.
پرسشِ غایب، خطا را به سه مرحله محدود می‌کند
آخرین مرحله‌ای را که آشکارا موفق شده بنویسید، چون هرکدام صاحب و راه‌حل متفاوتی دارد. حدس زدن تنظیمات حساب در حالی که دو مرحله عقب‌تر گیر کرده‌اید، همان راهی است که یک بعدازظهر ناپدید می‌شود.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
کلاینتی که بدون پرسش زمانش تمام می‌شود هرگز تداعی IPsec نگرفته، پس خطا در IKE است یا در اینکه بسته‌های شما اصلاً به دروازه می‌رسند یا نه. کلاینتی که اعلام می‌کند اعتبارنامه را بررسی می‌کند و سپس می‌افتد، از آنچه پیام القا می‌کند جلوتر رفته است. پرسشی که پس از آن رد شدن بیاید، احراز هویت PPP است و جای آن مقاله‌ای دربارهٔ حساب است، نه این مقاله.
مرحلهٔ یک: پروتکلی که دیوار آتش بی‌صدا رهایش می‌کند
PPTP برای کانال کنترل خود به TCP 1723 و برای مسیر داده به پروتکل IP شمارهٔ 47 نیاز دارد و این دو جداگانه سفر می‌کنند. بسیاری از شبکه‌ها 1723 را عبور می‌دهند و پروتکل 47 را رها می‌کنند، که تونلی می‌سازد مذاکره می‌کند و سپس هیچ چیز حمل نمی‌کند. مسیریابی که NAT انجام می‌دهد به گذر پشتیبانی‌شده از GRE نیز نیاز دارد، و مسیر دسترسی تنها IPv6 در هیچ پیکربندی نمی‌تواند PPTP را حمل کند.
L2TP روی IPsec پورت 500 را برای IKE و پورت 4500 را برای گذر از NAT خرج می‌کند، سپس خودِ ترافیک L2TP را در 1701 می‌پیچد، در حالی که ESP پس از برقراری تداعی بار محافظت‌شده را حمل می‌کند. دو پورت کنترل را مجاز کنید اما ESP را نه، و دقیقاً همان نشانهٔ عنوان را می‌گیرید: پیشرفت دیدنی، سپس کلاینت مرده پیش از هر گفت‌وگوی اعتبارنامه. آزمایش از هات‌اسپات گوشی راهی ارزان برای جدا کردن مشکل کلاینت از مشکل مسیر است.
مرحلهٔ دو: کلیدی که کلید نیست، پیشنهادی که ارائه نمی‌شود
کلید از پیش به‌اشتراک‌گذاشته‌ای که نمی‌خواند سریع و بی‌صدا شکست می‌خورد، و نسخهٔ معمولش کلیدی است که روی صفحه درست به نظر می‌رسد اما یک شکست خطِ چسبانده یا فاصله‌ای در پایان دارد. روی کلاینت لینوکس گفت‌وگو لزوماً منبع حقیقت نیست: افزونهٔ L2TP در NetworkManager رازها را در پرونده‌هایی زیر /etc/ipsec.d/ نگه می‌دارد، و پروندهٔ قدیمی‌تری برای هر اتصال که /etc/ipsec.secrets هنوز آن را شامل می‌شود به‌جای پرونده‌ای که همین حالا تایپ کردید به کار می‌رود. آن پرونده را به جای امنی کپی کنید، از مسیر شمول بیرونش بیاورید و سپس کلید را دستی دوباره تایپ کنید.
نیمهٔ دیگر این مرحله پیشنهاد است. هر دو سر باید بر یک مجموعهٔ الگوریتم فاز 1 — رمزگذاری، یکپارچگی و گروه Diffie-Hellman — و بر تبدیل‌های ESP متناظر برای فاز 2 توافق کنند، وگرنه تداعی اصلاً شکل نمی‌گیرد. دروازه‌ای که تنها 3DES و SHA1 و MODP1024 را ارائه می‌دهد کلاینتی را که برای الگوریتم‌های قوی‌تر تنظیم شده رد می‌کند، و گزارشش نام تبدیل ردشده را می‌آورد. گزارش اگر آن را بخوانید نام ناسازگاری را می‌آورد، به‌جای اینکه سرویس را دوباره راه‌اندازی کنید. به‌جای کپی کردن رشته‌ای از الگوریتم از یک انجمن، از دروازه بپرسید واقعاً چه تبدیل‌هایی را مذاکره می‌کند: ike-scan که به نشانی آن نشانه گرفته شود تبدیل‌هایی را برمی‌گرداند که مذاکره خواهد کرد. اگر تنها پیشنهاد رمزنگاری‌ای باشد که سیاست شما دیگر اجازه نمی‌دهد، اصلاح جای دروازه است، نه پایین آوردن کلاینت.
در ویندوز کلید و روش احراز هویت در پروفایل VPN زندگی می‌کنند، و ناسازگاری پیش از پرسش اعتبارنامه ظاهر می‌شود نه پس از آن. جایی که گیرنده یک Windows Server است، تأیید کنید که نقش دسترسی از راه دور نصب است، گواهی با نامی که کلاینت‌ها به آن وصل می‌شوند می‌خواند، و هیچ پالایهٔ پورتی باریک‌تر از پروتکل‌های بالا نیست.
مرحلهٔ سه: تونل هست و PPP هرگز آغاز نمی‌شود
وقتی IKE کامل می‌شود و پرسش همچنان ظاهر نمی‌شود، به دیمن تونل نگاه کنید نه به دیوار آتش. L2TP به چیزی نیاز دارد که روی UDP 1701 گوش دهد — xl2tpd یا kl2tpd در لینوکس، سرویس دسترسی از راه دور در ویندوز — و سرویسی که نصب اما متوقف است از دید کلاینت همانند بسته‌ای رهاشده به نظر می‌رسد. پیش از باز کردن دوبارهٔ قواعدی که پیش‌تر تأیید کرده‌اید گوش‌دهنده را بررسی کنید. سپس PPP باید مذاکره کند، و نخستین تبادل LCP همان جایی است که شکست خاموش معمولاً فرود می‌آید.
یک تله در این مرحله اصلاً خطای شبکه نیست: ویندوز هم‌زمان تنها یک اتصال از یک نوع VPN را مجاز می‌کند، پس تلاش دوم خطای 937 را برمی‌گرداند، «اتصال دیگری از این نوع در حال استفاده است». این یک قاعدهٔ محلی است و راه دور زدنش دستگاه دیگر، نوع تونل دیگر یا شریک شدن در همان یک اتصالی است که از قبل وجود دارد.
گزارش را به ترتیب مرحله‌ها بخوانید نه با حدس زدن
کلاینت را متوقف کنید، دوباره راه‌اندازی کنید، و اجزا را به ترتیبی بخوانید که گزارش می‌نویسند. یعنی نخست دیمن IPsec — strongSwan یا Libreswan، و ipsec --version می‌گوید کدام — سپس دیمن L2TP، سپس pppd. هر جزئی که پیش از شکست آخرین نوشته را داشته باشد مرحلهٔ نیازمند بررسی را نشان می‌دهد، چون هر چیزی که در این ترتیب پس از آن بیاید اصلاً اجرا نشده است.
با اتصال تازه تأیید کنید نه با نشست ذخیره‌شده، چون کلاینتی که از حافظهٔ نهان دوباره وصل می‌شود می‌تواند بخش‌هایی از تبادل را رد کند و نتیجه‌ای کهنه را بازتولید کند. دسترسی، تبادل کلید، تونل و PPP را یکی‌یکی و به همین ترتیب تأیید کنید. آن‌گاه پرسش غایب از حالت معما بیرون می‌آید و به خط دوم فهرستی تبدیل می‌شود که واقعاً می‌توانید رویش کار کنید. همین فهرست را هم به تیم شبکه می‌دهید، وگرنه از آن‌ها خواسته می‌شود دیوار آتش را برای خطایی بررسی کنند که در دیمنی راه‌نیافتاده زندگی می‌کند.