کدام مرحله VPN شکست خورد: IPsec، کنترل L2TP یا احراز هویت PPP
آخرین مرحله‌ای را که موفق شد پیدا کنید و فقط همان لایه را اصلاح کنید: IPsec، کانال کنترل L2TP، احراز هویت PPP یا تخصیص نشانی.
گذرواژه را عوض کردید و هیچ چیز تکان نخورد، چون خطا هرگز در PPP نبود. L2TP/IPsec برای پنج تحویل کاملاً متفاوت یک خطای اتصال گزارش می‌دهد و هر تحویل تعمیر خودش را دارد. برعکس کار کنید: آخرین مرحله‌ای را که موفق شد پیدا کنید و فقط آنچه پس از آن می‌آید را تغییر دهید. ترتیب زیر هم تعیین می‌کند کدام شواهد را اول جمع کنید.
به چهار پرسش به ترتیب پاسخ دهید
یک تلاش تازه اجبار کنید، چون بعضی کارخواه‌ها خطای قبلی را نشان می‌دهند تا پروفایل قطع و دوباره وصل شود. سپس به این پاسخ دهید: آیا انجمن امنیتی IPsec وجود داشت، آیا اتصال کنترل L2TP و یک تماس پدیدار شد، آیا PPP به حکم احراز هویت رسید و آیا IPCP نشانی به کارخواه داد؟ نخستین نه همان مرحله‌ای است که اصلاح می‌کنید. هر چیز پس از آن آزموده نشده، پس نام کاربری ردشده وقتی هرگز انجمنی وجود نداشته چیزی را ثابت نمی‌کند.
پیش از مقایسه ساعت‌های دو طرف را هم‌زمان کنید. تلاشی که IPsec را پاک کرد و در PPP شکست خورد، وقتی کارخواه فقط پیام پایانی را نشان می‌دهد و گزارش سرور هنوز تلاش پیشین را نگه داشته، یک شکست واحد به نظر می‌رسد. بر پایه برچسب زمان بخوانید، نه پرصداترین خط.
وقتی فقط تصویر صفحه کاربر را دارید، به ارزان‌ترین تفکیک تکیه کنید: کلید پیش‌به‌اشتراک‌گذاشته اشتباه و xl2tpd که هرگز پاسخ نمی‌دهد همان متن را در پنجره Windows می‌سازند، اما یکی به رازی نیاز دارد که در هر دو سر تغییر کند و دیگری به دیمنی در حال اجرا یا قاعده‌ای در دیوار آتش روی خود سرور. دستگاه میانی نمی‌تواند 1701 درونی را پس از آنکه IPsec در حالت انتقال آن را پیچید بیندازد، پس دنبال صافی مسیری که وجود ندارد نگردید.
هر لایه در واقع چه چیزی را در اختیار دارد
IPsec بسته‌ها را میان دو همتا محافظت می‌کند؛ L2TP یک نشست PPP را درون همان مسیر محافظت‌شده حمل می‌کند، از این رو RFC 3193 حالت انتقال را به جای تونل اختصاصی تعیین می‌کند. برچسب کارخواه L2TP می‌گوید، پس تونل و ورود مانند یک سازوکار به نظر می‌رسند. چنین نیست: اتصال کنترل L2TP در جایی که استقرار آن را فعال کند، نقاط انتهایی تونل را احراز هویت می‌کند و PPP جداگانه کاربر را با CHAP، PAP یا MS-CHAPv2 بر پایه سیاست سرور احراز هویت می‌کند.
این تفکیک آن دو رازی را توضیح می‌دهد که مردم پیوسته اشتباه می‌گیرند. کلید پیش‌به‌اشتراک‌گذاشته همتایان IPsec را احراز هویت می‌کند. نام کاربری و گذرواژه کاربر را به PPP معرفی می‌کنند. تایپ دوباره راز اشتراکی Windows روی پروفایلی که با گواهی احراز هویت می‌کند در مرحله شکست چیزی را تغییر نمی‌دهد و ویرایش گذرواژه PPP نمی‌تواند کانال محافظت‌شده غایب را فراهم کند. همین خویشتن‌داری در بررسی هویت هم هست: برای گرفتن تونل هویت همتا یا اعتبارسنجی گواهی را خاموش نکنید، چون آنگاه مسیر وصل می‌شود نه همتا.
احراز هویت هم پایان PPP نیست. پس از پذیرش کاربر، IPCP درباره نشانی کارخواه و گزینه‌های DNS و WINS که سرور حاضر است بدهد مذاکره می‌کند. کارخواه می‌تواند CHAP یا MS-CHAPv2 را بگذراند و باز بی‌نشانی بماند، که شکستی درون PPP است نه مشکل مسیریابی. L2TP ساده بدون IPsec معتبر و بی‌محافظت می‌ماند، پس اتصال موفق هرگز ثابت نمی‌کند که ترافیک محافظت شده؛ ببینید سرور چه می‌خواهد، نه برچسب کارخواه.
بر پایه نخستین مرحله غایب تصمیم بگیرید
جدول را بر پایه نخستین مورد غایب، از چپ به راست بخوانید. ستون راست تنها کاری است که در آن لحظه ارزش دارد؛ هر چیز سمت چپش پیش‌تر اثبات شده و آزمودن دوباره‌اش پنجره قطعی را می‌سوزاند بی‌آنکه اطلاعاتی بیفزاید.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
سه سطر شایسته هشدارند. سطر 1701 جایی است که کارخواه‌های Windows پشت NAT معمولاً فرود می‌آیند: انجمن کامل می‌شود، سپس چیزی نمی‌رسد و علت کپسوله‌سازی است نه گذرواژه بد. سطر IPCP همان است که به اشتباه مشکل مسیر خوانده می‌شود، چون Windows نشانی غایب را در خطای 720 می‌پیچد و نماد سینی فقط می‌گوید اتصال شکست خورد؛ این شکست پس از احراز هویت و پیش از مسیریابی است. سطر آخر اصلاً شکست IPsec نیست، هرچند نماد سینی قطع بودن را می‌گوید.
فرمان‌هایی که لایه‌ها را جدا می‌کنند
روی سرور Linux با strongSwan، swanctl --list-sas انجمن‌های برقرارشده را با هویت همتا فهرست می‌کند و ipsec statusall میزبان‌های قدیمی‌تر strongSwan و libreswan را پوشش می‌دهد. در زیر آن ip xfrm state انجمن‌های واقعی هسته را نشان می‌دهد، در حالی که ss -lunp | grep 1701 ثابت می‌کند xl2tpd کجا بسته شده است. xl2tpd -D را در پیش‌زمینه اجرا کنید تا اتصال‌های کنترل و تماس‌ها را ببینید و اشکال‌زدایی pppd را در /etc/ppp/options.xl2tpd روشن کنید تا روش پیشنهادی و پاسخ را ببینید.
وقتی گزارش‌ها احراز هویت موفق را نشان دادند، پرسش بعدی این است که آیا IPCP کامل شد. بررسی کنید آیا ip range در بخش [lns default] از /etc/xl2tpd/xl2tpd.conf هنوز نشانی آزاد دارد و آیا /etc/ppp/options.xl2tpd واقعاً ms-dns و ms-wins را دارد اگر کارخواه انتظارشان را دارد. استخر تمام‌شده و گزینه DNS غایب روی سیم متفاوت دیده می‌شوند: اولی کارخواه را بی‌نشانی و با 720 رها می‌کند، دومی نشانی می‌دهد اما هیچ تحلیلگر نامی نمی‌دهد، پس نام‌ها شکست می‌خورند در حالی که ping به نشانی‌های خام کار می‌کند. هیچ‌کدام با وارد کردن دوباره گذرواژه تعمیر نمی‌شود.
روی کارخواه، افزونه L2TP در NetworkManager گفت‌وگوی pppd را در ژورنال می‌نویسد، پس journalctl -u NetworkManager -b معمولاً تونل بالا، احراز هویت رد شد را از هیچ تونلی نیست جدا می‌کند. در Windows، Get-VpnConnection تنظیمات واقعی احراز هویت پروفایل را گزارش می‌دهد و رویدادهای RasClient زیر Application در Event Viewer مؤلفه شکست‌خورده را نام می‌برند. وقتی پنجره بسیار مبهم است، netsh ras set tracing * enable را فعال کنید.
ضبط‌ها یک احتیاط می‌خواهند. با IPsec در حالت انتقال، UDP 1701 درونی رمزگذاری شده است، پس ضبط روی رابط بیرونی ESP نشان می‌دهد، یا UDP 4500 زیر NAT-T، و هیچ L2TP نمی‌دهد. نبودن 1701 در ضبط انتظار می‌رود و اثبات درگاه مسدود نیست؛ ببینید شمارنده‌های ESP یا 4500 تکان می‌خورند یا نه.
NAT، MTU و مسیرها: جایی که پشته گمراهتان می‌کند
NAT پیش از آنکه چیزی احراز هویت شود فرض‌ها را می‌شکند. ESP پروتکل IP خودش است، پس دستگاه ترجمه‌کننده آن را دور می‌ریزد مگر همتاها کپسوله کنند؛ UDP 4500 همین را فراهم می‌کند. روی سرور Windows که خودش پشت روتر خانگی یا دروازه NAT ابری است، مرحله IPsec با خطای 789 شکست می‌خورد تا AssumeUDPEncapsulationContextOnSendRule زیر کلید PolicyAgent روی 2 گذاشته شود و دستگاه دوباره راه‌اندازی شود، و شکست از درگاه بسته قابل تشخیص نمی‌ماند. کارخواه‌های پشت NAT آسان‌ترند: با نشانی عمومی روی سرور، NAT-T روی UDP 4500 آن‌ها را حمل می‌کند و آن مقدار دخالتی ندارد.
وقتی PPP بالا است، MTU با چاله سیاه تونل مرده را تقلید می‌کند: بسته‌های کوچک عبور می‌کنند، دست‌دهی TLS یا بارگذاری صفحه معلق می‌ماند و کارخواه شاید همچنان متصل نشان دهد. پیش از سرزنش سرور، MTU رابط را کم کنید یا MSS را در دروازه سفت کنید. مسیریابی تونل تقسیم‌شده فریبکار دیگر است؛ زیرشبکه‌ای که با ماسک اشتباه فرستاده شود تونل را سالم و یک برنامه را دسترس‌ناپذیر می‌گذارد. نام میزبان خصوصی گام خودش را می‌افزاید: اگر پرس‌وجو از تحلیلگر نام محلی بیرون رود، نام پیش از آزمودن هیچ مسیری تحلیل نمی‌شود.
سیاهه بازبینی پیش از دست زدن به اعتبارنامه‌ها
سیاهه را به ترتیب کار کنید و در نخستین مورد شکست‌خورده بایستید. هر گام ارزان است و هر یک یک کلاس کامل از ویرایش‌ها را کنار می‌گذارد.
- تأیید کنید انجمن در دو سر وجود دارد، بر پایه هویت همتا تطبیق داده شده نه برچسب متصل.
- تأیید کنید UDP 1701 به xl2tpd می‌رسد؛ انجمن بدون تماس شکست شماست.
- حکم PPP و اگر احراز هویت کرد نتیجه IPCP را بخوانید، پیش از آنکه فرض کنید گذرواژه اشتباه است.
- تنها اکنون اعتبارنامه‌ها را در قالبی که سرور انتظار دارد دوباره وارد کنید، چون پیشوند دامنه حساب را عوض می‌کند.
- اگر باز شکست خورد، دو سر را با برچسب‌های زمان هم‌تراز ضبط کنید و مرحله به مرحله مقایسه کنید.
ایستادن در گام دوم یعنی مشکل مسیر یا کپسوله‌سازی، و هیچ ویرایشی روی گذرواژه آن را تکان نمی‌دهد. ایستادن در گام سوم یعنی گزارش پیش‌تر روش یا استخر نشانی را برای اصلاح نام برده است. در هر حال تغییر بعدی تغییری است که می‌توانید توجیه کنید و دست از چرخیدن در تنظیماتی که هرگز دخیل نبودند برمی‌دارید.