آیا یک پوشش TLS به شما شبکه خصوصی می‌دهد؟ معمولاً نه
پوشش از یک اتصال پیکربندی‌شده بین دو انتهای خود محافظت می‌کند. یک VPN مسیریابی‌شده ترافیک همه برنامه‌ها را حمل می‌کند، که مدل دسترسی متفاوتی است.
TLS از یک کانال بین دو نقطه پایانی محافظت می‌کند و درباره اینکه کدام سرویس‌ها داخل آن قرار دارند چیزی نمی‌گوید. پوشش آن کانال را به یک فرستنده پیکربندی‌شده تبدیل می‌کند، برای یک شنونده، به یک مقصد. محصولی که به نام SSL VPN فروخته می‌شود معمولاً یک رابط، یک جدول مسیر و یک مدل دسترسی را پیرامون همان اصل اولیه اضافه می‌کند. اشتباه گرفتن این دو همان چیزی است که باعث می‌شود یک تونل سالم با دسترسی شبکه اشتباه گرفته شود.
یک پوشش سرویس در واقع چه چیزی را به هم وصل می‌کند
پوشش روی یک درگاه محلی گوش می‌دهد و آنچه می‌رسد را به مقصدی پیکربندی‌شده هدایت می‌کند، چه میزبان و درگاه باشد و چه برنامه‌ای محلی. آن مقصد را کسی انتخاب می‌کند که فایل پیکربندی را نوشته است، هر بار یک شنونده. نصب بسته هیچ مسیری، هیچ رابط مجازی و هیچ دسترسی‌پذیری برای چیزی که صریحاً فهرست نشده ایجاد نمی‌کند. پیکربندی را پیش از توصیف بسته بخوانید، چون توصیف یک دسته از کاربرد را پوشش می‌دهد و فایل مورد شما را.
پس پرسش مفید درباره یک پوشش این نیست که رمزگذاری می‌کند یا نه، بلکه این است که در هر انتهای زنجیره‌ای که می‌سازد چه چیزی قرار دارد.
application -> local listener -> TLS connection -> remote listener -> configured backend
آن زنجیره را از پیکربندی بخوانید، نه از نام بازاریابی. هر پیکان یک گام شبکه جداگانه با نشانی و قواعد دسترسی خودش است.
جایی را پیدا کنید که کانال TLS پایان می‌یابد
اگر پوشش TLS را پایان دهد، هر چیزی که به بعد هدایت می‌کند اتصالی تازه با ویژگی‌های تازه است. جریان می‌تواند متن ساده روی یک بخش خصوصی باشد، یا می‌تواند پروتکل محافظت‌شده دیگری را درون خود حمل کند. فرض کردن هر یک از این دو بدون خواندن پیکربندی بک‌اند همان راهی است که مردم به این نتیجه می‌رسند که لایه بیرونی از داده‌هایی محافظت می‌کند که دیگر هرگز آن‌ها را نمی‌بیند. گام هدایت‌شده شایسته بررسی جداگانه خودش است، روی نشانی و درگاه خودش.
شنونده و بک‌اند را جداگانه بررسی کنید، چون دست‌دهی موفقی که در درگاه ورودی رخ می‌دهد درباره سرویس پشت آن چیزی نمی‌گوید.
ss -ltnp | grep -F 443 openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates
فرمان نخست نشان می‌دهد کدام فرایند مالک درگاه است و روی کدام نشانی گوش می‌دهد. دومی گواهی‌ای را چاپ می‌کند که کلاینت واقعاً دریافت می‌کند، و این همان بررسی هویتی است که شماره درگاه نمی‌تواند جای آن را بگیرد.
آنچه یک VPN مسیریابی‌شده اضافه می‌کند و پوشش اضافه نمی‌کند
VPN مسیریابی‌شده یک رابط نصب می‌کند، مالکیت پیشوندهای انتخاب‌شده را می‌گیرد و با مسیریابی و سیاست دسترسی میزبان یکپارچه می‌شود. هر برنامه روی ماشین بدون اینکه بداند تونل وجود دارد بهره می‌برد. پوشش آن دسترسی را به یک شنونده پیکربندی‌شده می‌دهد و همان‌جا می‌ایستد.
پذیرش دوباره جداست. VPNی که یک کلاینت را احراز هویت می‌کند هنوز به مجوزی نیاز دارد که بگوید کلاینت به کدام منابع می‌تواند برسد، و پوششی که یک همتا را احراز هویت می‌کند هنوز به بک‌اندی نیاز دارد که مجوزهای خودش را اجرا کند.
ترکیب مشروعی وجود دارد: پروتکل VPN که درون یک پوشش TLS روی چیدمان TCP که آگاهانه پشتیبانی می‌شود حمل می‌شود. این دو لایه را روی هم می‌گذارد و پوشش و VPN را به یک نوع شیء تبدیل نمی‌کند.
مرزی را که شکست می‌خورد مقایسه کنید
پیش از تغییر هر چیزی، نشانی بخش جلویی، شنونده، هویت همتا، هدف بک‌اند و عملیات برنامه را بنویسید. سپس قابل‌مقایسه را با قابل‌مقایسه بسنجید: موفقیت از طریق نام میزبان یا درگاه متفاوت اثبات نمی‌کند که شرایط دیوار آتش و گواهی یکسان بوده است.
درخواست ردشده بک‌اند هرگز نباید با غیرفعال کردن بررسی هویت بخش جلویی اصلاح شود. این کار یک شکست مجوز قابل‌تشخیص را با یک شکست اعتماد غیرقابل‌تشخیص عوض می‌کند.
curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30
سنجاق کردن نام به نشانی انتخاب‌شده، حل نام را از دسترسی‌پذیری جدا می‌کند، و این معمولاً سریع‌ترین راه برای فهمیدن این است که کدام یک از آن دو خراب است.
مقایسه‌ای که اهمیت دارد، جفت نقطه پایانی محافظت‌شده، بار حمل‌شده، برنامه‌هایی که از آن استفاده می‌کنند و مجوز اجراشده در مقصد را نام می‌برد. TLS به این توصیف کمک می‌کند بی‌آنکه آن را کامل کند.