SSTP نخست سرور را و بعد کاربر را تأیید می‌کند

یک کلاینت SSTP می‌تواند TLS را کامل کند و باز یک ثانیه بعد کاربر را رد کند. این توالی باگ نیست، پشتهٔ پروتکل است: نخست امنیت انتقال، سپس احراز هویت کاربر. چون دو مرحله با پیام‌های متفاوت شکست می‌خورند، به اصلاح‌های متفاوت هم نیاز دارند. خواندن اینکه کدام مرحله خطا را تولید کرده، بیشتر بخش تشخیص است.

گواهی معتبر نقطهٔ پایانی را اثبات می‌کند؛ دربارهٔ حساب چیزی نمی‌گوید.

دست‌دادن TLS چه چیزی را برقرار می‌کند

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

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

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

SSTP روی HTTPS اجرا می‌شود و PPP را درون خود حمل می‌کند، با تبادل کنترل مخصوص خودش پیرامون اتصال. سپس PPP فازهای پیوند و احراز هویت خود را اجرا می‌کند، و روش احراز هویت به سیاست سرور و توانایی کلاینت بستگی دارد. PAP، CHAP، MS-CHAPv2 و EAP همه گزینه‌های احراز هویت PPP با ویژگی‌های بسیار متفاوت‌اند. بررسی کاربر در VPN همان فاز PPP است، نه لایهٔ TLS زیر آن.

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

دلیل سمت سرور بسیار سودمندتر از بازنشانی هر راز در پروفایل است. رخداد غیرفعال شدن حساب و شکست مذاکرهٔ روش در کلاینت شبیه به هم دیده می‌شوند و در سرور هیچ اشتراکی ندارند.

خطا را به مرحله نسبت دهید

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

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

پس از ورود، مجوزدهی همچنان جداست

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

این همان لایه‌بندی است که دست‌دادن نشان داد، یک سطح بالاتر.

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