چرا SSL VPN و VPN سایت‌به‌سایت نقطه مقابل یکدیگر نیستند
SSL VPN و VPN سایت‌به‌سایت دو محور متفاوت را توصیف می‌کنند: چه کسی به شبکه می‌پیوندد و تونل چگونه ساخته می‌شود. نام بردن هر دو با هم یک خطای مقوله است.
از دو مدیر بخواهید همان VPN را توصیف کنند؛ یکی ممکن است بگوید «SSL VPN» و دیگری بگوید «سایت‌به‌سایت»، گویی این دو گزینه‌های رقیب در یک منو هستند. این‌ها پاسخ به پرسش‌های متفاوت‌اند و برخورد با آن‌ها به‌عنوان جایگزین، مقایسه‌هایی می‌سازد که قابل حل نیست. یک برچسب می‌گوید کدام نقاط پایانی به هم متصل می‌شوند؛ دیگری می‌گوید چه چیزی ترافیک میان آن‌ها را حمل می‌کند. محورها را جدا نگه دارید تا بیشتر بحث ناپدید شود.
دو برچسب، دو پرسش جداگانه
توپولوژی پاسخ می‌دهد که چه کسی به چه چیزی می‌پیوندد. طراحی دسترسی از راه دور کاربران یا دستگاه‌های فردی را به یک دروازه متصل می‌کند، معمولاً با هویت به‌ازای هر کاربر و مجموعه‌ای از نشانی‌ها. طراحی سایت‌به‌سایت دو شبکه را از طریق دروازه‌ها به هم می‌پیوندد، پس هویت مهم دروازه همتاست نه شخص پشت صفحه‌کلید. این‌ها مسائل عملیاتی متفاوتی هستند، از برنامه‌ریزی نشانی تا اینکه چه کسی می‌تواند در ساعت 2 بامداد دسترسی را لغو کند.
سازوکار پاسخ می‌دهد که تونل چگونه ساخته و احراز هویت می‌شود. IPsec با IKEv2، محصولی مبتنی بر TLS که IP را درون خود حمل می‌کند، و دروازه برنامه‌های رو به مرورگر گزینه‌های سازوکارند و هرکدام مذاکره، مجموعه‌های رمز و شیوه‌های شکست خود را دارند. هیچ‌یک توپولوژی را ایجاب نمی‌کند و توپولوژی سازوکار را انتخاب نمی‌کند.
دو محور را در یک جدول بگذارید و سردرگمی آشکار می‌شود، چون هر خانه شبکه را می‌توان پر کرد. کاری که جدول نمی‌تواند بکند این است که بگوید فروشنده شما کدام ترکیب را تحویل داده، زیرا نام محصولات هر دو محور را در یک عبارت بازاریابی فرو می‌ریزد.
خطای مقوله از کجا می‌آید
فروشندگان سال‌ها «SSL VPN» را به‌عنوان نقطه مقابل «IPsec VPN» می‌فروختند، که مقایسه سازوکار را شبیه انتخاب توپولوژی می‌کرد. این عبارت به خودی خود هم بد کهنه شده است، چون طراحی‌های کنونی از نسخه‌های پشتیبانی‌شده TLS استفاده می‌کنند و نام SSL عمدتاً به‌عنوان یک مقوله محصول باقی مانده است.
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
دو افسانه مرتبط از همان فروپاشی برمی‌آید. نخست اینکه IPsec یعنی سایت‌به‌سایت؛ IKEv2 برای روابط کارخواه‌به‌دروازه هم طراحی شد، پس یک لپ‌تاپ تنها می‌تواند با IPsec بپیوندد. دوم اینکه محصول مبتنی بر TLS یعنی فقط دسترسی از راه دور؛ OpenVPN به‌طور معمول برای حمل ترافیک میان دو سایت استفاده می‌شود و استفاده آن از TLS در تبادل کنترل و احراز هویت متمرکز است، نه در نشست مرورگر.
آزمونی سودمند برای هر توصیف: اگر جایگزینی یک واژه هم نقاط پایانی و هم پروتکل را تغییر دهد، جمله محورها را با هم می‌آمیزد. «SSL VPN در برابر سایت‌به‌سایت» در این آزمون شکست می‌خورد، چون واژه اول یک خانواده سازوکار و دومی یک توپولوژی را نام می‌برد.
استقراری را توصیف کنید که قابل مقایسه باشد
چهار خانه بنویسید و پر کنید: نقاط پایانی، سازوکار، احراز هویت و سطح دسترسی. یک اتصال شعبه می‌تواند به‌عنوان جفت دروازه IKEv2 میان دو پیشوند نام‌دار با احراز هویت گواهی و بدون دروازه سطح کاربر خوانده شود. یک سرویس دسترسی از راه دور می‌تواند به‌عنوان کارخواه مبتنی بر TLS خوانده شود که نشانی‌ها را به‌ازای هر کاربر تخصیص می‌دهد، در ورود عامل دوم می‌خواهد و فقط یک ناحیه داخلی DNS را منتشر می‌کند.
این جمله‌ها به گونه‌ای قابل مقایسه‌اند که نام محصولات نیستند. دو طراحی دسترسی از راه دور را می‌توان با همان جریان کاری کاربر و همان مسیر لغو سنجید و دو طراحی میان‌سایتی را با همان فهرست پیشوند، سیاست ترافیک و الزامات شکست. برچسب‌ها مقایسه را سازمان می‌دهند؛ جای آن را نمی‌گیرند.
اصطلاح‌شناسی یک لنگر منتشرشده هم دارد. سند اصطلاح‌شناسی VPN از IETF چند مدل خدمت، از جمله دسترسی از راه دور و سایت‌به‌سایت، را از سازوکارهای ساخت آن‌ها جدا می‌کند و این دقیقاً همان تمایزی است که پیوسته گم می‌شود.
پروتکل مذاکره‌شده را بخوانید، نه نام محصول را
برچسب روی جعبه مشخص نمی‌کند که یک تونل در حال اجرا بر چه چیزی توافق کرده است. مستقیم از طرف مقابل، در سمت TLS، بپرسید و نسخه پروتکل و رمزی را که دست‌دادن تولید کرده بخوانید، نه نسخه‌ای که در بروشور است.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefبرای دروازه IPsec مشاهده معادل از خروجی وضعیت خود پیاده‌سازی می‌آید که پیشنهادهای IKE و ESP در حال استفاده را گزارش می‌کند. در هر حال نکته یکی است: محور سازوکار باید از نشست زنده خوانده شود، چون کارخواه و دروازه می‌توانند تا چیزی قدیمی‌تر از انتظار هر دو مدیر پایین بیایند.
ipsec statusall | grep -E "IKE|ESP"پس از آن، پرسش‌های باقی‌مانده همان‌هایی هستند که هیچ برچسبی پاسخشان را نمی‌دهد. کدام نسخه‌های پروتکل هنوز پذیرفته می‌شوند، هویت دروازه چگونه اعتبارسنجی می‌شود، کدام مجموعه الگوریتم مجاز است، چه کسی کاربری معین را برای منبعی معین مجاز می‌کند و چه چیزی هنگام گم شدن دستگاه دسترسی را لغو می‌کند. نمودار توپولوژی و نام سازوکار آغاز آن فهرست‌اند، نه جایگزین آن.
پس دو برچسب را نگه دارید، اما آن‌ها را برای چیزی که هستند به کار ببرید: راهی کوتاه برای گفتن اینکه کدام نقاط پایانی به هم می‌پیوندند و تونل چگونه ساخته می‌شود. همان لحظه‌ای که یکی برای رد دیگری به کار رود، توصیف از توصیف کردن هر چیزی بازمانده است.