قطع TLS یا عبور مستقیم؟ انتخاب مرز معکوس پروکسی مناسب Webship

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

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

تصمیم در یک جمله

زمانی که مبدأ باید مرز TLS را داشته باشد، از عبور TLS استفاده کنید. زمانی که Webship باید ترافیک HTTP را مسیریابی، محافظت، تبدیل، کش یا مشاهده کند، از پایان TLS استفاده کنید.

هیچ یک از حالت‌ها به طور جهانی امن‌تر نیستند. حالت عبور مستقیم (Pass-through) میزان مواد حساس پردازش شده توسط لبه را کاهش می‌دهد، اما کنترل‌های امنیتی HTTP لبه را حذف می‌کند. حالت خاتمه (Termination) یک نقطه اجرای قابل بررسی اضافه می‌کند، اما Webship را بخشی از مرز اعتماد TLS می‌سازد.

| نگرانی | خاتمه TLS | عبور TLS | | --- | --- | --- | | نقطه پایانی TLS | Webship | منشأ | | متن ساده برنامه در Webship | بله | خیر | | کلیدهای جلسه فعال پایین‌دست در Webship | بله | خیر | | مسیر بر اساس مسیر HTTP یا متد | بله | خیر | | دیواره برنامه وب (WAF)، محافظ API و محدودیت‌های بدنه در Webship | بله | خیر | | کش پروکسی، بازنویسی‌ها و هدایت هدرها | بله | خیر | | ورودی مسیریابی TCP | مرجع HTTP و سیاست مسیر | ClientHello SNI | | HTTP/3 مسیریابی | داده‌های درخواست HTTP | یک منبع مشترک UDP | | مسئولیت منبع | HTTP یا TLS بالادستی به صورت جداگانه پیکربندی شده | TLS کامل، ALPN، و پشته HTTP |

بنابراین سوال مهم این نیست که «کدام سوئیچ سریع‌تر است؟» بلکه این است که «کدام مؤلفه باید مجاز باشد درخواست را ببیند و کنترل کند؟»

چه خاتمه‌ای به Webship می‌دهد

با tls_termination = true، Webship TLS سمت پایین را تکمیل کرده و درخواست رمزگشایی شده را به لوله‌کشی پروکسی معکوس HTTP خود منتقل می‌کند. این امکان ویژگی‌های زیر را فراهم می‌کند:

• مسیریابی آگاه از مسیر، میزبان و روش؛
• بازرسی WAF و محافظ API;
• محدودیت‌های بدنه درخواست و زمان‌های پایان سیاست؛
• کشینگ پراکسی و باطل‌سازی ایمن برای تولید؛
• مدیریت سربرگ‌های فوروارد و فیلدهای گزارش دسترسی HTTP؛
• پردازش پرس‌وجوی آگاه به وضعیت بدن، تلاش‌های مجدد در موارد ایمن، و سیاست قطع‌کننده مدار؛
• ترجمه پروتکل بین اتصال‌های رو به مشتری و اتصال‌های بالادستی.

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

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

چه چیزی از گذراندن محافظت می‌کند

با tls_termination = false—پیش‌فرض—Webship ترافیک رمزگذاری شده TLS یا QUIC را بدون رمزگشایی درخواست یا پاسخ HTTP منتقل می‌کند. متن آشکار برنامه و کلیدهای جلسه فعال در مبدا باقی می‌مانند.

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

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

بنابراین گذرگاه به معنای «پایان با ویژگی‌های کمتر» نیست. این یک معماری متفاوت با مالک امنیتی متفاوت است.

محدودیت‌های خاص پروتکل اهمیت دارند

برای HTTP/1.1 TLS و HTTP/2 TLS، Webship تنها تا حدی ClientHello را بررسی می‌کند که مقصد TCP پیکربندی‌شده را با SNI انتخاب کند. هر دامنه عبور مستقیم نیاز به یک مسیر catch-all path_prefix = "/" دارد زیرا مسیر واقعی درخواست همچنان رمزگذاری شده باقی می‌ماند. یک مشتری بدون SNI فقط زمانی پذیرفته می‌شود که پیکربندی شامل یک دامنه باشد.

مبدا باید ALPN مشتری را مذاکره کرده و از پروتکل انتخاب شده پشتیبانی کند. Webship نمی‌تواند یک مشتری HTTP/2 را به یک مبدا HTTP/1.1 تبدیل کند در حالی که جلسه TLS بدون تغییر عبور می‌کند.

HTTP/3 از QUIC روی UDP استفاده می‌کند و دارای مرز tighter است. مسیریابی عبوری نمی‌تواند به‌طور ایمن بر اساس مرجع HTTP رمزگذاری‌شده عمل کند، بنابراین هر مسیر HTTP/3 پیکربندی‌شده باید به همان مبدأ IP-socket UDP حل شود. Webship سوکت‌های یونیکس و مبدأهای متعددی HTTP/3 عبوری را در طول اعتبارسنجی پیکربندی رد می‌کند و به‌صورت مبهم مسیریابی نمی‌کند.

متن ساده HTTP/1.1 و h2c تحت تأثیر reverse_proxy.tls_termination قرار ندارند. این تنظیم فقط TLS HTTP/1.1، TLS HTTP/2 و TLS HTTP/3 زیرمجموعه را کنترل می‌کند.

ظرفیت درخواست اندازه‌گیری شده

معیار ظرفیت Debian 1.3.1 Webship دو حالت پروکسی معکوس رمزگذاری شده را به صورت جداگانه اندازه‌گیری کرد. هر نمونه پذیرفته‌شده نیاز به هیچ گونه خطای HTTP، سوکت، پروتکل، پروکسی، نقص صفحه اصلی و HTTP/3 از دست دادن بسته نداشت.

| حالت معکوس پراکسی | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | پایان TLS | 123,344 درخواست در ثانیه | 124,957 درخواست در ثانیه | 131,529 درخواست در ثانیه | | عبور از TLS | ۲۰۳,۹۵۰ درخواست در ثانیه | ۲۶۶,۸۴۵ درخواست در ثانیه | ۱۶۷,۰۱۰ درخواست در ثانیه |

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

این ردیف‌ها مجموعه ویژگی‌های یکسانی را نشان نمی‌دهند و نباید برای ادعا کردن اینکه یک معماری امنیتی به طور جهانی بهتر است، استفاده شوند. خاتمه برای قابلیت‌های آگاه به HTTP هزینه می‌کند که عبور مستقیم عمداً نمی‌تواند ارائه دهد.

پخش حجمی نتیجه را تغییر می‌دهد

همان معیار از یک بدنه پاسخ دقیق ۹۹٬۹۴۳٬۷۷۸ بایت برای ماتریس جریان ۱۰۰ مگابایتی استفاده کرد. در اینجا، خاتمه TLS میانگین انتقال داده بالاتری برای هر سه پروتکل ایجاد کرد:

| حالت معکوس پراکسی | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | خاتمه TLS | ۳,۵۸۵.۷ مگابایت/ثانیه | ۳,۳۵۵.۰ مگابایت/ثانیه | ۱,۹۳۸.۶ مگابایت/ثانیه | | عبور TLS | ۲٬۷۸۳٫۲ مگابایت/ثانیه | ۲٬۱۳۵٫۰ مگابایت/ثانیه | ۱٬۷۴۸٫۵ مگابایت/ثانیه |

چرا جهت تغییر می‌کند؟ در حالت خاتمه، منبع بنچمارک HTTP متن‌واضح را به Webship ارسال می‌کند و Webship مالک مسیر عمده تحویل بهینه‌شده پایین‌دستی است. پاسخ‌های بزرگ HTTP/1.1 و HTTP/2 می‌توانند از kTLS تطبیقی لینوکس و بافرینگ محدود مخصوص حمل و نقل استفاده کنند. HTTP/3 به جای kTLS از زمان‌بندی QUIC، DPLPMTUD و دسته‌بندی به ازای هر رآکتور استفاده می‌کند.

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

صلاحیت هفت‌نمونه‌ای HTTP/3 همچنین پایداری را بررسی کرد. جریان متوقف‌شده به یک میانه 1,938.6 مگابایت بر ثانیه با ضریب تغییرپذیری 2.12٪ رسید؛ عبور از گذرگاه به 1,748.5 مگابایت بر ثانیه با ضریب تغییرپذیری 1.65٪ رسید. هر دو دقیقاً بدنه را بدون هیچ خطای مشتری، پروتکل و از دست دادن بسته‌ها تحویل دادند.

پیکربندی عبور مستقیم به طور عمدی

یک پیکربندی گذر حداقلی هویت TLS را به صورت مرحله‌ای نگه می‌دارد تا یک اپراتور بتواند خاتمه را بعداً فعال کند بدون اینکه مسیرهای گواهی‌نامه را تغییر دهد:

[reverse_proxy]
enabled = true
tls_termination = false

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:443"]

[[reverse_proxy.policies]]
name = "default"
path_prefixes = ["/"]
total_timeout_ms = 30000

گواهی Webship مرحله‌بندی شده معتبر است اما توسط نشست‌های عبور فعال استفاده نمی‌شود. مبدا در 10.0.0.20:443 باید TLS را خاتمه دهد و از پروتکل مذاکره‌شده با مشتری پشتیبانی کند.

فعال کردن خاتمه زمانی که لبه به HTTP نیاز دارد

برای یک لبه آگاه به برنامه، خاتمه را فعال کنید و ترافیک HTTP حاصل را به مبدا انتخاب‌شده ارسال کنید:

[reverse_proxy]
enabled = true
tls_termination = true

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/api"
strip_path_prefix = true
upstreams = ["10.0.0.20:8080", "10.0.0.21:8080"]

[[reverse_proxy.policies]]
name = "default"
hosts = ["app.example.com"]
path_prefixes = ["/"]
max_body_bytes = 1048576
request_body_idle_timeout_ms = 5000
upstream_header_timeout_ms = 5000
response_body_idle_timeout_ms = 5000
downstream_write_idle_timeout_ms = 5000
total_timeout_ms = 30000

این پیکربندی می‌تواند HTTP را مسیریابی و بررسی کند. زمانی که شبکه بین Webship و منبع به‌طور پیش‌فرض مورد اعتماد یا ایزوله نیست، TLS بالاسری را اضافه کنید.

تغییر حالت بدون راه‌اندازی مجدد Webship

Webship می‌تواند tls_termination را از طریق بازگذاری فایل پیکربندی یا ابزار webship.reverse_proxy.apply_config MCP که نسخه را بررسی می‌کند، تغییر دهد. شیء و نسخه فعلی را با webship.reverse_proxy.get_config بخوانید، فقط فیلد مورد نظر را در شیء کامل بازگشتی تغییر دهید و آن را با expected_version_idمطابقت دهید ارسال کنید.

اتصالات جدید TCP از حالت جدید استفاده می‌کنند. کلاینت‌های HTTP/3 به حمل‌ونقل UDP جایگزین شده دوباره متصل می‌شوند. تغییرات مسیر گواهی و کلید به فرآیند محدود هستند و نیاز به راه‌اندازی مجدد دارند، بنابراین قبل از سوئیچ زنده، یک هویت پایان معتبر آماده نگاه داشته شود.

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

چک‌لیست انتخاب عملی

وقتی همه این موارد صادق هستند، گزینه عبور را انتخاب کنید:

1. مبداء باید مرز گواهی و کلیدهای نشست را حفظ کند.
2. مسیردهی TCP در سطح SNI—یا یک مبدأ UDP مشترک HTTP/3—کافی است.
3. مبدأ، WAF لازم، مجوز، ثبت لاگ‌ها، محدودیت‌های بدنه و کنترل‌های سوء استفاده را فراهم می‌کند.
4. هیچ کش لبه، بازنویسی مسیر، سیاست هدر فورواردینگ، یا ترجمه پروتکل HTTP مورد نیاز نیست.

وقتی هر یک از این موارد در Webship لازم است، گزینه خاتمه را انتخاب کنید:

1. مسیر بر اساس میزبان، مسیر یا روش.
2. درخواست‌ها را با WAF یا API Shield بررسی کنید.
3. اعمال محدودیت‌های اندازه بدنه، زمان‌های انتظار HTTP، یا احراز هویت لبه.
4. پاسخ‌ها را کش کنید یا هدرهای HTTP را بازنویسی کنید.
5. ترجمه بین پروتکل‌های HTTP پایین‌دست و بالادست.
6. فیلدهای HTTP را در مرز پروکسی مشاهده کنید.

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

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

مستندات کامل [reverse-proxy](/docs/1.3.1) را بخوانید، [benchmark matrix](/benchmarks) پذیرفته شده را مقایسه کنید، یا Webship را از [Downloads](/downloads) دانلود کنید.

منابع و روش محتوا

مقادیر عملکرد میانگین‌های پذیرفته شده از بنچمارک ظرفیت یکپارچه دبیان Webship 1.3.1 به تاریخ ۱۱ سپتامبر ۲۰۲۶ هستند؛ دروازه‌های پذیرش آن نیازمند صفر خطا در مشتری، HTTP، سوکت، پروتکل، پراکسی، خطای صفحه اصلی، و از دست رفتن بسته HTTP/3 هستند.