SSTP در لینوکس پیش از ورود شکست می‌خورد؟ اجزای زمان اجرا را بررسی کنید

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

ورودی منو چه چیزی اضافه می‌کند و چه چیزی نه

افزونه توصیف سرویسی اضافه می‌کند که به NetworkManager می‌گوید چگونه آن را اجرا کند، و در بیشتر توزیع‌ها ویرایشگر کوچکی که فرم را می‌کشد. این تمام دامنه ورودی منو است. برنامه کلاینت از بسته منبع دیگری می‌آید و README خود افزونه این تفکیک را صریح می‌گوید: این یک افزونه است، نه کلاینت.

سپس کلاینت به PPP نیاز دارد، زیرا SSTP نشست PPP را درون اتصال TLS حمل می‌کند. بدون pppd تونل می‌تواند دست‌دادن TLS را کامل کند و باز هم در نخستین قاب کنترل بمیرد، که مانند مشکل اعتبارنامه به نظر می‌رسد و نیست. در Debian و Ubuntu قطعات به شکل network-manager-sstp، sstp-client و ppp می‌آیند و نصب تنها اولی شایع‌ترین دلیل پذیرش همه فیلدها توسط فرم و هرگز کامل نشدن اتصال است.

انتخاب دسکتاپ یک تفکیک دیگر اضافه می‌کند. Plasma پروفایل‌ها را از طریق plasma-nm ویرایش می‌کند که به جزء SSTP خود نیاز دارد و همان توصیف سرویس را می‌خواند، پس ویرایشگری بدون ورودی SSTP و CLI که پروفایل‌ها را خوب می‌سازد، نیمی از ویرایشگر غایب است نه زمان اجرای خراب.

پیش از نصب دوباره هر چیز، نخستین مرحله شکست را بخوانید

تلاش ناموفق SSTP مراحل را به ترتیبی ثابت طی می‌کند و مرحله‌ای که شکست خورده به شما می‌گوید به کدام جزء نگاه کنید.

اجرای افزونه نخستین مرحله است و شکست در آن پیامی درباره سرویس VPN می‌دهد نه درباره سرور. سپس اتصال TCP به درگاه 443 می‌آید؛ رد یا پایان مهلت در اینجا مشکل دسترسی است نه TLS. بعد دست‌دادن TLS و بررسی هویت سرور، سپس مذاکره PPP و احراز هویت حساب، و در پایان تخصیص نشانی و مسیرها. هنگام فعال‌کردن یک‌باره پروفایل journalctl -f -u NetworkManager را تماشا کنید و نخستین خط مشخص را بخوانید نه آخرین خط عمومی را.

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

اعتماد به گواهی و ورود به حساب دو دروازه جداگانه‌اند

دست‌دادن تأیید می‌کند که سرور همان است که قصد رسیدن به آن را داشتید، با صادرکننده و نامی که پیکربندی کرده‌اید. تنها پس از آن لایه PPP نام کاربری و رمز شما را به روش احراز هویت دروازه عرضه می‌کند. پس دو بررسی مستقل، با ترتیبی ثابت ارزیابی می‌شوند و هر کدام تنظیمات جداگانه دارند. چیزی که در فیلد رمز تایپ شود نمی‌تواند بر اولی اثر بگذارد.

پروفایلی که به صادرکننده اشتباه اعتماد می‌کند در دروازه اول با خطای هویت شکست می‌خورد. پروفایلی که درست به آن اعتماد دارد اما رمز کهنه ذخیره می‌کند در دومی با رد احراز هویت شکست می‌خورد. هر دو مانند VPNی به نظر می‌رسند که وصل نمی‌شود و هیچ‌کدام با درمان دیگری درست نمی‌شود.

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

بگذارید یک مالک پروفایل و اسرار را نگه دارد

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

اسرار هم مالک دارند. اتصالی که برای استفاده در سطح سیستم علامت خورده است اعتبارنامه‌ها را متفاوت از اتصال محدود به نشست کاربری شما ذخیره می‌کند، و پروفایلی که دستی در فایل کلید ساخته شده ممکن است برای عامل اسرار که انتظار دارد رمز را تعاملی ارائه کند خواندنی نباشد. پیش از دوباره‌تایپ‌کردن رمزی که هرگز مشکل نبود، بررسی کنید پروفایل چه زمینه‌ای را انتظار دارد. فعال‌کردن همان پروفایل از ترمینال با nmcli سریع‌ترین آزمون است، زیرا اعلانی که هرگز ظاهر نمی‌شود به شما می‌گوید عامل از قبل چیزی برای عرضه نداشته است.

تونل، مسیرها و مفسر را جداگانه بررسی کنید

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

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

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