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

از حامل بیرونی آغاز کنید

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

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

کپسوله‌سازی را به سمت درون دنبال کنید

درون کانال محافظت‌شده یک تبادل کنترل SSTP نشسته است، سپس یک نشست PPP، سپس بسته شبکه‌ای که مشتری می‌خواهد تحویل داده شود. هر لایه مذاکره خودش، پیام‌های خطای خودش و ماشین حالت خودش را دارد. بنابراین یک خرابی می‌تواند از یک دیدگاه خرابی TLS و از دیدگاهی دیگر خرابی PPP به نظر برسد. خواندن لایه‌ها به ترتیب می‌گوید کدام ماشین حالت ایستاده است.

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

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

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

پیش از خواندن برداشت، ناظر را برچسب بزنید

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

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

بررسی‌هایی را که نمودار نمی‌تواند اثبات کند نگه دارید

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

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

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"

مقالات مرتبط