L2TP وصل می‌شود اما مذاکره PPP شکست می‌خورد: کدام مرحله؟

تونل IPsec برقرار می‌شود، کلاینت همتای محافظت‌شده‌ای نشان می‌دهد و سپس اتصال پیش از رسیدن چیزی به زیرشبکه خصوصی قطع می‌شود. این شکاف کار خود PPP است: گزینه‌های پیوند، احراز هویت کاربر و تخصیص نشانی همه پس از وجود تونل رمزنگاری‌شده رخ می‌دهند. هیچ چیز در تبادل موفق مرحله یک، گذرواژه یا نشانی درونی نمی‌دهد. مراحل را به ترتیب بخوانید؛ شکست معمولاً خودش را نام می‌گذارد.

تونل تنها لایه نخست است

L2TP قاب‌های PPP را درون تونلی محافظت‌شده با IPsec حمل می‌کند، یعنی دو مذاکره مستقل باید موفق شوند تا بسته‌ای مسیریابی شود. مذاکره بیرونی ثابت می‌کند دو طرف بر کلیدها و هویت‌ها توافق دارند. مذاکره درونی پارامترهای پیوند، اینکه کاربر احراز هویت می‌شود یا نه و کلاینت چه نشانی می‌گیرد را تعیین می‌کند.

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

آخرین مرحله‌ای را که موفق شد بخوانید

گزارش را به جلو بگردید و در نخستین مرحله‌ای که کامل نشد توقف کنید. نخست LCP می‌آید، سپس احراز هویت و سپس IPCP برای پارامترهای IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

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

بریده گزارش را همراه با نام مرحله در تیکت نگه دارید. دنباله چسبانده‌شده بدون مرز مرحله، خواننده بعدی را به حدس زدن دعوت می‌کند و حدس زدن در اینجا یک ساعت هزینه دارد.

توافق میان کلاینت و سرور

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

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

نشانی را بررسی کنید، نه ورود را

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

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

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

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