SSTP همان PPP روی HTTPS است، نه یک صفحه وب روی پورت 443

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

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

مرحله 1: TCP و TLS

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

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

مرحله 2: درخواست HTTPS

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

کد پاسخ و روش را در گزارش سرور بخوانید. رد شدن در این مرحله مشکلی متفاوت از پایان مهلت TCP است و هر دو به اصلاح‌های متفاوتی می‌رسند.

مرحله 3: پیام‌های کنترل

پس از پذیرش درخواست، SSTP پیام‌های کنترلی را رد و بدل می‌کند که تونل را مذاکره و آماده می‌کنند. این‌ها پیام‌های پروتکل درون بدنه HTTPS هستند نه درخواست‌های HTTP، پس پروکسی‌ای که بدنه‌ها را بررسی و بازنویسی می‌کند می‌تواند آن‌ها را بشکند در حالی که درخواست‌های صفحه دست‌نخورده می‌مانند.

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

مرحله 4: PPP کنترل را می‌گیرد

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

گواهی پذیرفته‌شده و ورود ردشده متناقض نیستند. این‌ها مراحل پیاپی با نتایج مستقل هستند.

احراز هویت چند نقش دارد

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

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

آزمایش مرورگر چه چیزی را می‌تواند و چه چیزی را نمی‌تواند نشان دهد

بارگذاری یک صفحه در آن نشانی حل DNS، دسترس‌پذیری TCP و وجود چیزی که گوش می‌دهد و HTTP صحبت می‌کند را اثبات می‌کند. اثبات نمی‌کند که روش پذیرفته می‌شود، تبادل کنترل دوام می‌آورد یا احراز هویت PPP پیکربندی شده است. از کلاینتی استفاده کنید که SSTP را پیاده‌سازی می‌کند، نه اینکه نمایه دیگری را با تغییر پورت تبدیل کنید.

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