ٹی ایل ایس ٹرمینیشن یا پاس تھرو؟ درست Webship ریورس پراکسی باؤنڈری کا انتخاب

TLS ختم ہونے اور TLS پاس تھرو کے درمیان انتخاب صرف ایک ظاہری پراکسی سیٹنگ نہیں ہے۔ یہ فیصلہ کرتا ہے کہ انکرپشن کہاں ختم ہوتی ہے، کون سا نظام سیشن کیز رکھتا ہے، کیاWebship HTTP کا معائنہ کر سکتا ہے، اور کون سا لیئر ایپلیکیشن سیکیورٹی کو نافذ کرنا ضروری ہے۔

Webship ڈیفالٹ کے طور پر پاس تھرو ہوتا ہے۔ یہ ایپلیکیشن کی سادہ متن اور فعال سیشن کیز کو ماخذ پر رکھتا ہے۔ صرف اس وقت ترمیم کو فعال کریں جب ایج کو HTTP درخواست کو سمجھنا اور اس پر عمل کرنا ضروری ہو۔

فیصلہ ایک جملے میں

جب اصل کو TLS کی حد کا مالک ہونا ضروری ہو تو TLS pass-through استعمال کریں۔ جب TLS termination استعمال کریں جبWebship HTTP ٹریفک کو روٹ، محفوظ، تبدیل، کیش، یا مانیٹر کرنا ضروری ہے۔

کوئی بھی موڈ جامع طور پر زیادہ محفوظ نہیں ہے۔ پاس تھرو کنارے پر ہینڈل ہونے والے حساس مواد کو کم کرتا ہے، لیکن کنارے کے HTTP سیکیورٹی کنٹرولز کو ہٹا دیتا ہے۔ ٹرمینیشن ایک قابل معائنہ نفاذی نقطہ شامل کرتا ہے، لیکن بناتا ہےWebship معتبر TLS سرحد کا حصہ۔

| تشویش | TLS اختتام | TLS پاس تھرو | | --- | --- | --- | | ٹی ایل ایس اختتامی نقطہ | Webship | اصل | | ایپلیکیشن سادہ متن پر Webship | جی ہاں | نہیں | | فعال ڈاؤن اسٹریم سیشن کیز پر Webship | جی ہاں | نہیں | | HTTP راہ یا طریقہ کے ذریعے روٹ | ہاں | نہیں | | ویب ایپلیکیشن فائر وال (WAF)، API شیلڈ، اور باڈی کی حدود پرWebship | جی ہاں | نہیں | | پراکسی کیش، ری رائٹس، اور فارورڈنگ ہیڈرز | ہاں | نہیں | | ٹی سی پی روٹنگ ان پٹ | ایچ ٹی ٹی پی اتھارٹی اور روٹ پالیسی | کلائنٹ ہیلو ایس این آئی | | HTTP/3 روٹنگ | HTTP درخواست کا ڈیٹا | ایک مشترکہ UDP ماخذ | | ماخذ کی ذمہ داری | HTTP یا علیحدہ ترتیب دیا گیا upstream TLS | مکمل TLS, ALPN، اور HTTP اسٹیک |

اہم سوال اس لیے یہ نہیں ہے کہ 'کون سا سوئچ زیادہ تیز ہے؟' بلکہ یہ ہے کہ 'کون سا جزو درخواست کو دیکھنے اور اسے کنٹرول کرنے کی اجازت دینا چاہیے؟'

کس خاتمے سےWebship

کے ساتھtls_termination = true, Webship ڈاؤن اسٹریم TLS مکمل کرتا ہے اور ڈیکرپٹ شدہ درخواست کو اپنے HTTP ریورس-پراکسی پائپ لائن میں فیڈ کرتا ہے۔ اس سے درج ذیل خصوصیات ممکن ہو جاتی ہیں:

• راستہ، میزبان، اور طریقہ کے مطابق روٹنگ؛
• WAF اور API شیلڈ معائنہ؛
• درخواست کے جسم کی حدود اور پالیسی کے ٹائم آؤٹ؛
• پراکسی کیشنگ اور جنریشن-سیف غیر مؤثر بنانے؛
• فارورڈنگ ہیڈر مینجمنٹ اور ایچ ٹی ٹی پی ایکسیس-لاگ فیلڈز؛
• باڈی-اویئر کیوری ہینڈلنگ، جہاں محفوظ ہو وہاں دوبارہ کوششیں، اور سرکٹ بریکر پالیسی؛
• کلائنٹ-سامنے اور اپ اسٹریم کنکشنز کے درمیان پروٹوکول کا ترجمہ۔

یہ وضع بھی سیکیورٹی کی ذمہ داری کو بدل دیتا ہے۔ Webship میزبان کو سرٹیفکیٹ کی نجی کلید، سیشن کیز، ڈی کرپٹ شدہ درخواست اور جواب کے ڈیٹا، قابل مشاہدہ آؤٹ پٹ، اور کسی بھی کیچ شدہ نمائندگی کا تحفظ کرنا چاہیے۔ اگر اگلا ہاپ مرموز رہنا ضروری ہے تو ٹائپ کیا گیا اپ اسٹریم TLS الگ سے ترتیب دیں؛ بصورت دیگر HTTP اپ اسٹریم صاف متن میں ہے۔

ختم ہونا دایاں حد ہے جبWebship متوقع ہے کہ یہ صرف ایک مرموز ٹرانسپورٹ ریلے کے طور پر نہیں بلکہ ایک ایپلیکیشن سے آگاہ ایج کے طور پر بھی کام کرے گا۔

کیا پاس تھرو محفوظ رکھتا ہے

کے ساتھtls_termination = false—ڈیفالٹ—Webship انکرپٹ شدہ TLS یا QUIC ٹریفک کو ریلی کرتا ہے بغیر HTTP درخواست یا جواب کو ڈکریپٹ کیے۔ ایپلیکیشن کا صاف متن اور فعال سیشن کیز اصل مقام پر رہتی ہیں۔

یہ چھوٹا اعتماد کی حد اس وقت قیمتی ہوتی ہے جب سرٹیفکیٹس کو ایپلیکیشن ٹائر پر رہنا ضروری ہو، تعمیل کی پالیسی ایج ڈی کرپشن کی اجازت نہ دے، یا کسی مخصوص اصل کی TLS شناخت کو بغیر تبدیلی کے کلائنٹ تک پہنچنا ہو۔ یہ ریلے راستے سے HTTP تجزیہ اور پالیسی کے کام کو بھی ہٹا دیتا ہے۔

تجارت کا توازن سخت ہے:Webship اسے اس چیز کی جانچ نہیں کر سکتا جسے یہ ڈی کرپٹ نہیں کر سکتا۔ یہ HTTP WAF قواعد لاگو نہیں کر سکتا، راستے کے ذریعے روٹنگ نہیں کر سکتا، ہیڈرز کو دوبارہ لکھ نہیں سکتا، باڈی کے مطابق API پالیسی نافذ نہیں کر سکتا، یا HTTP-فیلڈ ایکسیس لاگز کو پُر نہیں کر سکتا۔ اوریجن کو خود ہی یہ سب کنٹرول فراہم کرنے ہوں گے۔

اس لیے پاس تھرو کا مطلب 'کم خصوصیات کے ساتھ خاتمہ' نہیں ہے۔ یہ ایک مختلف آرکیٹیکچر ہے جس کا مختلف سیکیورٹی مالکانہ ہے۔

پروٹوکول مخصوص حدود اہمیت رکھتی ہیں

کے لیےHTTP/1.1 ٹی ایل ایس اورHTTP/2 ٹی ایل ایس، Webship صرف یہ دیکھتا ہے کہ ClientHello میں SNI کے ذریعے ترتیب دی گئی TCP منزل منتخب کی جا سکے۔ ہر پاس تھرو ڈومین کو ایک catch-all کی ضرورت ہوتی ہےpath_prefix = "/" روٹ کیونکہ اصل درخواست کا راستہ خفیہ رہتا ہے۔ صرف اسی صورت میں ایک کلائنٹ بغیر SNI کے قبول کیا جاتا ہے جب کنفیگریشن میں ایک ہی ڈومین ہو۔

اصل کو کلائنٹ کے ALPN پر بات چیت کرنی ہوگی اور منتخب شدہ پروٹوکول کی حمایت کرنی ہوگی۔Webship کو تبدیل نہیں کر سکتاHTTP/2 گاہک کو ایکHTTP/1.1 اصل مقام جبکہ TLS سیشن بغیر تبدیلی کے گزر رہا ہے۔

HTTP/3 UDP پر QUIC استعمال کرتا ہے اور اس کی حد زیادہ سخت ہے۔ پاس-تھرو محفوظ طریقے سے encrypted HTTP اتھارٹی کے ذریعہ راستہ نہیں دے سکتا، اس لیے ہر تشکیل شدہHTTP/3 روٹ کو اسی آئی پی-ساکٹ یو ڈی پی ماخذ کی طرف حل ہونا چاہیے۔Webship یونکس ساکٹس اور متعدد کو مسترد کرتا ہےHTTP/3 تشکیلی تصدیق کے دوران اصل ذرائع کو براہِ راست گزرنے دیں بجائے اس کے کہ غیر واضح طور پر خاموشی سے روٹ کریں۔

صاف متنHTTP/1.1 اور h2c پر اثر نہیں پڑتاreverse_proxy.tls_termination. یہ سیٹنگ نیچے کی طرف کنٹرول کرتی ہےHTTP/1.1 ٹی ایل ایس، HTTP/2 ٹی ایل ایس، اورHTTP/3 صرف TLS۔

ماپا گیا درخواست کی گنجائش

وہWebship 1.3.1 ڈیبین کی صلاحیت کا معیار دو الگ الگ انکرپٹ شدہ ریورس پراکسی موڈز کو ماپتا ہے۔ ہر قبول کردہ نمونہ کے لیے زیرو HTTP، ساکٹ، پروٹوکول، پراکسی، اہم صفحہ کی خرابی، اورHTTP/3 پیکٹ نقصان کی غلطیاں۔

| ریورس پراکسی موڈ |HTTP/1.1 ٹی ایل ایس | HTTP/2 ٹی ایل ایس | HTTP/3 ٹی ایل ایس | | --- | ---: | ---: | ---: | | ٹی ایل ایس ٹرمینیشن | 123,344 آر پی ایس | 124,957 آر پی ایس | 131,529 آر پی ایس | | ٹی ایل ایس پاس-تھرو | 203,950 آر پی ایس | 266,845 آر پی ایس | 167,010 آر پی ایس |

چھوٹے ردعمل کے ذریعہ گزارنے والے طریقہ کار میں کم ایپلیکیشن کام کرنا پڑتا ہے: یہ خفیہ شدہ ٹرانسپورٹ ڈیٹا کو پہنچاتا ہے بجائے اس کے کہ TLS کو ختم کرے، HTTP کو پارس کرے، پالیسی کا جائزہ لے، اور نیا نیچے کی طرف TLS اسٹریم تیار کرے۔ زیادہ پاس-تھرو درخواست کی شرحیں اس تنگ کام کی عکاسی کرتی ہیں۔

یہ قطاریں ایک ہی خصوصیات کے مجموعے کی نمائندگی نہیں کرتی ہیں، اور انہیں یہ دعویٰ کرنے کے لیے استعمال نہیں کیا جانا چاہیے کہ ایک سیکیورٹی آرکیٹیکچر ہر جگہ بہتر ہے۔ ٹرمینیشن HTTP سے آگاہ صلاحیتوں کے لیے ادائیگی کرتا ہے جو جان بوجھ کر پاس تھرو فراہم نہیں کر سکتا۔

بلک اسٹریمنگ نتیجہ بدل دیتا ہے

اسی بینچ مارک نے 100 MB اسٹریمنگ میٹرکس کے لیے بالکل 99,943,778 بائٹ کے ردعمل کے جسم کا استعمال کیا۔ یہاں، TLS ٹرمینیشن نے تمام تین پروٹوکولز کے لیے زیادہ میڈین پے لوڈ تھروپٹ پیدا کیا:

| ریورس پراکسی موڈ |HTTP/1.1 ٹی ایل ایس | HTTP/2 ٹی ایل ایس | HTTP/3 ٹی ایل ایس | | --- | ---: | ---: | ---: | | ٹی ایل ایس ٹرمینیشن | 3,585.7 می بی/س | 3,355.0 می بی/س | 1,938.6 می بی/س | | ٹی ایل ایس پاس تھرو | 2,783.2 می بی/س | 2,135.0 می بی/س | 1,748.5 می بی/س |

رویہ کیوں بدلتا ہے؟ اختتامی حالت میں، بنچ مارک اوریجن صاف متن HTTP بھیجتا ہےWebship، اور Webship باخبر نیچے بہاؤ کے بڑے راستے کا مالک ہے۔ بڑاHTTP/1.1 اورHTTP/2 جوابات تطبیقی لینکس kTLS اور محدود نقل و حمل-مخصوص بفرنگ استعمال کر سکتے ہیں۔HTTP/3 kTLS کے بجائے QUIC پیسنگ، DPLPMTUD، اور فی-ری ایکٹر بیچنگ استعمال کرتا ہے۔

پاس تھرو موڈ میں، اوریجن ڈاؤن اسٹریم TLS کا مالک ہوتا ہے اورWebship نتیجے میں پیدا ہونے والے خفیہ شدہ اسٹریم یا QUIC پیکٹس کو ریلی کرتا ہے۔ یہ اصل TLS حد کو برقرار رکھتا ہے، لیکن یہ استعمال نہیں کر سکتاWebship'ایچ ٹی ٹی پی سے آگاہ بلک-ریسپانس راستہ'۔

سات نمونےHTTP/3 قابلیت کے علاوہ استحکام بھی چیک کیا گیا۔ ختم شدہ سٹریمنگ نے 1,938.6 MiB/s کی اوسط حاصل کی جس میں 2.12٪ تغیر کا گتانک تھا؛ پاس تھرو نے 1,748.5 MiB/s حاصل کی جس میں 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 کو روٹ اور معائنہ کر سکتی ہے۔ جب نیٹ ورک کے درمیان ہو تو اپ اسٹریم TLS شامل کریںWebship اور ماخذ پہلے سے قابل اعتماد یا الگ تھلگ نہیں ہے۔

ری اسٹارٹ کیے بغیر موڈز تبدیل کریںWebship

Webship بدل سکتا ہےtls_termination ایک کنفیگریشن فائل کے دوبارہ لوڈ یا ورژن چیک کے ذریعےwebship.reverse_proxy.apply_config MCP ٹول۔ موجودہ آبجیکٹ اور ورژن کو پڑھیں webship.reverse_proxy.get_configصرف پورے واپس کیے گئے آبجیکٹ میں مطلوبہ فیلڈ کو تبدیل کریں، اور اسے مطابقت رکھنے والے کے ساتھ جمع کرائیںexpected_version_id.

نئی TCP کنکشنز نئے موڈ کا استعمال کرتی ہیں۔HTTP/3 کلائنٹس متبادل شدہ UDP ٹرانسپورٹ سے دوبارہ جڑتے ہیں۔ سرٹیفکیٹ اور کی چابی کے راستے کے تبدیلیاں عمل سے منسلک رہتی ہیں اور دوبارہ شروع کرنے کی ضرورت ہوتی ہے، لہٰذا لائیو سوئچ سے پہلے ایک درست اختتامی شناخت تیار رکھیں۔

ورژن چیکنگ ایک آپریٹر کو ایک ساتھ ہونے والی کنفیگریشن کی تبدیلی پر اوور رائٹ کرنے سے روکتی ہے۔ نامنظور شدہ اپ ڈیٹ فعال رن ٹائم اور محفوظ شدہ کنفیگریشن کو بغیر تبدیلی کے چھوڑ دیتی ہے۔

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

جب یہ سب درست ہوں تو پاس تھرو کا انتخاب کریں:

1. اصل کو سرٹیفکیٹ کی حد اور سیشن کیز کو برقرار رکھنا چاہیے۔
2. SNI-سطح TCP راؤٹنگ—یا ایک مشترکہHTTP/3 UDP ماخذ—کافی ہے۔
3. اصل فراہم کرتا ہے ضروری WAF، اجازت، لاگ ان، باڈی کی حدود، اور بدسلوکی کے کنٹرولز۔
4. کسی ایج کیش، پاتھ ری رائٹ، فارورڈنگ ہیڈر پالیسی، یا HTTP پروٹوکول ترجمے کی ضرورت نہیں ہے۔

ان میں سے کسی کی ضرورت ہونے پر ختم کرنے کا انتخاب کریں Webship:

1. میزبان، راستے، یا طریقے کے ذریعے راستہ
2. درخواستوں کا معائنہ کریں WAF یا API شیلڈ کے ساتھ۔
3. باڈی کی حدود، HTTP ٹائم آؤٹس، یا ایج تصدیق کو نافذ کریں۔
4. جوابات کو کیش کریں یا HTTP ہیڈرز کو دوبارہ لکھیں۔
5. ڈاؤن اسٹریم اور اپ اسٹریم HTTP پروٹوکولز کے درمیان ترجمہ کریں۔
6. پراکسی کی حد پر HTTP فیلڈز کا مشاہدہ کریں۔

جو بھی طریقہ آپ منتخب کریں، SNI، ALPN، سرٹیفکیٹ کی شناخت، کلائنٹ کی منسوخی، اپ اسٹریم ہاف کلوز، اور جواب کی صحیح سالمیت کا معائنہ کریں۔ درخواست کی صلاحیت اور اسٹریمنگ کے تھروپٹ کو الگ الگ ناپیں: ایک چھوٹے جواب کے لیے سب سے تیز طریقہ لازمی طور پر 100 MB کے باڈی کے لیے سب سے تیز طریقہ نہیں ہوتا۔

Webship پاس تھرو کو ڈیفالٹ بناتا ہے کیونکہ ایک پروکسی کو خاموشی سے اپنے اعتماد کی حد کو بڑھانا نہیں چاہیے۔ ٹرمینیشن ایک فعال، واضح عملی انتخاب رہتا ہے جب HTTP سے آگاہ ایج کا رویہ اس ذمہ داری کے قابل ہو۔

مکمل [ریورس پراکسی ڈاکیومنٹیشن](/docs/1.3.1) پڑھیں، قبول شدہ [بینچمارک میٹرکس](/benchmarks) کا موازنہ کریں، یا ڈاؤن لوڈ کریںWebship سے [ڈاؤن لوڈز](/downloads)۔

ذرائع اور مواد کا طریقہ

کارکردگی کی قدریں قبول شدہ اوسط ہیںWebship 1.3.1 یکجہتی ڈیبیان صلاحیت بینچ مارک مورخہ 11 ستمبر 2026؛ اس کے قبولیت کے دروازے میں صفر کلائنٹ، HTTP، ساکٹ، پروٹوکول، پراکسی، میجر-پیج-فالٹ، اورHTTP/3 پیکٹ نقصان کی غلطیاں۔