VPN مبتنی بر SSL یا پوشش TLS؟ مرزی را که شکست خورد مقایسه کنید

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

با اتصالی شروع کنید که واقعاً پیکربندی کرده‌اید

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

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

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

بررسی کنید پوشش به چه چیزی وصل می‌شود

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

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

openssl s_client -connect wrapper.lab.example:443 -servername wrapper.lab.example -verify_return_error
sudo ss -ltnp | grep 443

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

بررسی کنید طراحی چه ترافیکی را حمل می‌کند

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

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

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

مرز شکست‌خورده را بررسی کنید نه برچسب را

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

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

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