TLS टर्मिनेशन या पास-थ्रू? सही Webship रिवर्स-प्रॉक्सी सीमा का चयन करना

TLS टर्मिनेशन और TLS पास-थ्रू के बीच चयन एक सजावटी प्रॉक्सी सेटिंग नहीं है। यह तय करता है कि एन्क्रिप्शन कहां समाप्त होता है, कौन सा सिस्टम सेशन कुंजियाँ रखता है, क्या Webship HTTP का निरीक्षण कर सकता है, और कौन सा लेयर एप्लिकेशन सुरक्षा लागू करना चाहिए।

Webship डिफ़ॉल्ट रूप से पास-थ्रू पर सेट होता है। यह एप्लिकेशन के प्लेनटेक्स्ट और सक्रिय सत्र कुंजियों को मूल स्रोत पर बनाए रखता है। केवल तब टर्मिनेशन सक्षम करें जब एज को HTTP अनुरोध को समझना और उस पर कार्रवाई करनी हो।

निर्णय एक वाक्य में

TLS पास-थ्रू का उपयोग तब करें जब मूल को TLS सीमा का स्वामित्व रखना हो। TLS टर्मिनेशन का उपयोग तब करें जब Webship को HTTP ट्रैफिक को रूट, सुरक्षा देना, रूपांतरित करना, कैश करना, या अवलोकन करना हो।

कोई भी मोड सार्वभौमिक रूप से अधिक सुरक्षित नहीं है। पास-थ्रू एज द्वारा हैंडल की जाने वाली संवेदनशील सामग्री को कम करता है, लेकिन एज के HTTP सुरक्षा नियंत्रण निकाल देता है। टर्मिनेशन एक निरीक्षण योग्य प्रवर्तन बिंदु जोड़ता है, लेकिन Webship को विश्वसनीय TLS सीमा का हिस्सा बना देता है।

| चिंता | TLS समाप्ति | TLS पार-अवरोधन | | --- | --- | --- | | टीएलएस एंडपॉइंट | Webship | मूल | | आवेदन का सामान्य पाठ Webship पर | हाँ | नहीं | | सक्रिय डाउनस्ट्रीम सत्र कुंजियाँ Webship पर | हाँ | नहीं | | HTTP पथ या मेथड द्वारा रूट | हां | नहीं | | WAF, API शील्ड, और बॉडी लिमिट्स @ Webship | हाँ | नहीं | | प्रॉक्सी कैश, रीराइट्स, और फॉरवर्डिंग हेडर | हां | नहीं | | टीसीपी रूटिंग इनपुट | एचटीटीपी प्राधिकरण और रूट नीति | क्लाइंटहेलो एसएनआई | | HTTP/3 रूटिंग | HTTP अनुरोध डेटा | एक साझा UDP स्रोत | | मूल जिम्मेदारी | HTTP या अलग से कॉन्फ़िगर किया गया अपस्ट्रीम TLS | पूर्ण TLS, ALPN, और HTTP स्टैक |

इसलिए महत्वपूर्ण सवाल यह नहीं है कि 'कौन सा स्विच तेज है?' बल्कि यह है 'कौन से घटक को अनुरोध को देखने और नियंत्रित करने की अनुमति दी जानी चाहिए?'

Webship क्या समाप्ति देता है

tls_termination = true के साथ, Webship डाउनस्ट्रीम TLS को पूरा करता है और डिक्रिप्ट की गई अनुरोध को अपने HTTP रिवर्स-प्रॉक्सी पाइपलाइन में फीड करता है। इससे निम्नलिखित सुविधाएँ संभव होती हैं:

• पथ, होस्ट, और मेथड-सचेत रूटिंग;
• WAF और API शील्ड निरीक्षण;
• अनुरोध-शरीर की सीमाएँ और नीति समय सीमा;
• प्रॉक्सी कैशिंग और जेनरेशन-सुरक्षित अमान्यकरण;
• फॉरवर्डिंग-हेडर प्रबंधन और HTTP एक्सेस-लॉग फ़ील्ड;
• बॉडी-सचेत क्वेरी हैंडलिंग, सुरक्षित होने पर पुनः प्रयास, और सर्किट-ब्रेकर नीति;
• क्लाइंट-फेसिंग और अपस्ट्रीम कनेक्शनों के बीच प्रोटोकॉल अनुवाद।

यह मोड सुरक्षा जिम्मेदारी को भी बदल देता है। Webship होस्ट को प्रमाणपत्र निजी कुंजी, सत्र कुंजियाँ, डिक्रिप्ट किए गए अनुरोध और प्रतिक्रिया डेटा, प्रेक्षण आउटपुट, और कोई भी कैशेड प्रतिनिधित्व सुरक्षित रखना होगा। यदि अगला हॉप एन्क्रिप्टेड रहना है, तो अलग से टाइप किए गए अपस्ट्रीम TLS को कॉन्फ़िगर करें; अन्यथा HTTP अपस्ट्रीम स्पष्ट पाठ (cleartext) में है।

समाप्ति वह दाएं सीमा है जब Webship से उम्मीद की जाती है कि यह केवल एन्क्रिप्टेड ट्रांसपोर्ट रिले के रूप में नहीं बल्कि एप्लिकेशन-अवेयर एज के रूप में व्यवहार करेगा।

क्या पास-थ्रू संरक्षित करता है

tls_termination = false के साथ—जो डिफ़ॉल्ट है—Webship एन्क्रिप्टेड TLS या QUIC ट्रैफिक को बिना HTTP अनुरोध या प्रतिक्रिया को डिक्रिप्ट किए मध्यस्थ करता है। एप्लिकेशन का सादे पाठ और सक्रिय सत्र कुंजी मूल स्थान पर रहती हैं।

वह छोटा ट्रस्ट बॉन्डरी तब मूल्यवान होता है जब प्रमाणपत्रों को एप्लिकेशन टियर पर ही रखना आवश्यक हो, अनुपालन नीति एज डिक्रिप्शन को मना करती हो, या किसी मूल-विशेष TLS पहचान को बिना बदले क्लाइंट तक पहुंचाना आवश्यक हो। यह रिले पाथ से HTTP पार्सिंग और नीति कार्य को भी हटा देता है।

इसका समझौता सख्त है: Webship उस चीज़ का निरीक्षण नहीं कर सकता जिसे वह डिक्रिप्ट नहीं कर सकता। यह HTTP WAF नियम लागू नहीं कर सकता, पथ के अनुसार रूटिंग नहीं कर सकता, हेडर को पुनर्लेखित नहीं कर सकता, बॉडी-संवेदनशील API नीति लागू नहीं कर सकता, या HTTP-फ़ील्ड एक्सेस लॉग भर नहीं सकता। मूल स्रोत को ये सभी नियंत्रण स्वयं प्रदान करने होंगे।

इसलिए पास-थ्रू का मतलब 'कम फीचरों के साथ समाप्ति' नहीं है। यह एक अलग वास्तुकला है जिसका सुरक्षा मालिक भी अलग है।

प्रोटोकॉल-विशिष्ट सीमाएँ मायने रखती हैं

एसएसएल/टीएलएस HTTP/1.1 और HTTP/2 के लिए, Webship केवल इतना ही ClientHello का निरीक्षण करता है कि SNI द्वारा कॉन्फ़िगर किए गए TCP गंतव्य का चयन किया जा सके। प्रत्येक पास-थ्रू डोमेन को एक कैच-ऑल path_prefix = "/" मार्ग की आवश्यकता होती है क्योंकि वास्तविक अनुरोध पथ एन्क्रिप्टेड रहता है। कोई SNI के बिना क्लाइंट केवल तब स्वीकार किया जाता है जब कॉन्फ़िगरेशन में सिर्फ एक डोमेन हो।

मूल को क्लाइंट के ALPN का बातचीत करना और चयनित प्रोटोकॉल का समर्थन करना चाहिए। Webship एक HTTP/2 क्लाइंट को HTTP/1.1 मूल में तब परिवर्तित नहीं कर सकता जब TLS सत्र बिना बदले गुजर रहा हो।

HTTP/3 QUIC का उपयोग UDP पर करता है और इसकी सीमा अधिक सघन है। पास-थ्रू सुरक्षित रूप से एन्क्रिप्टेड HTTP प्राधिकरण द्वारा मार्ग नहीं कर सकता, इसलिए हर कॉन्फ़िगर किया गया HTTP/3 रूट उसी IP-सॉकेट UDP मूल को हल करना चाहिए। Webship यूनिक्स सॉकेट और कई HTTP/3 पास-थ्रू मूलों को कॉन्फ़िगरेशन सत्यापन के दौरान अस्वीकार करता है बजाय इसके कि अस्पष्ट रूप से मार्ग करे।

Cleartext HTTP/1.1 और h2c reverse_proxy.tls_termination से प्रभावित नहीं होते हैं। यह सेटिंग केवल डाउनस्ट्रीम HTTP/1.1 TLS, HTTP/2 TLS, और 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 टीएलएस | | --- | ---: | ---: | ---: | | TLS समाप्ति | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | टीएलएस पास-थ्रू | 2,783.2 मेबी/से | 2,135.0 मेबी/से | 1,748.5 मेबी/से |

दिशा क्यों बदलती है? टर्मिनेशन मोड में, बेंचमार्क मूल Webship को स्पष्ट टेक्स्ट HTTP भेजता है, और Webship ऑप्टिमाइज़्ड डाउनस्ट्रीम बल्क पथ का मालिक है। बड़े HTTP/1.1 और HTTP/2 प्रतिक्रियाएँ अनुकूलनशील Linux kTLS और सीमित परिवहन-विशिष्ट बफ़रिंग का उपयोग कर सकती हैं। HTTP/3 kTLS के बजाय QUIC pacing, DPLPMTUD, और प्रति-रिएक्टर बैचिंग का उपयोग करता है।

पास-थ्रू मोड में, ओरिज़िन डाउनस्ट्रीम TLS का मालिक होता है और Webship resulting एन्क्रिप्टेड स्ट्रीम या QUIC पैकेट्स को मध्यस्थ करता है। इससे ओरिज़िन TLS सीमा बनी रहती है, लेकिन यह Webship के HTTP-संवेदनशील बल्क-रिस्पॉन्स पाथ का उपयोग नहीं कर सकता।

सात-सैंपल 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 को मार्ग दे सकता है और निरीक्षण कर सकता है। जब Webship और ओरिजिन के बीच नेटवर्क पहले से भरोसेमंद या अलग नहीं हो, तो अपस्ट्रीम TLS जोड़ें।

बिना पुनः प्रारंभ किए मोड बदलें Webship

Webship कॉन्फ़िगरेशन-फ़ाइल रीलोड या संस्करण-चेक किए गए webship.reverse_proxy.apply_config MCP टूल के माध्यम से tls_termination को बदल सकता है। वर्तमान ऑब्जेक्ट और संस्करण को 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) की तुलना करें, या [डाउनलोड्स](/downloads) से Webship डाउनलोड करें।

स्रोत और सामग्री विधि

प्रदर्शन मान Webship 1.3.1 संप्रेषित डेबियन क्षमता बेंचमार्क, दिनांक 11 सितंबर, 2026 से स्वीकृत माध्य हैं; इसके स्वीकृति गेट्स में शून्य क्लाइंट, HTTP, सॉकेट, प्रोटोकॉल, प्रॉक्सी, मेजर-पेज-फॉल्ट, और HTTP/3 पैकेट-हानि त्रुटियां आवश्यक हैं।