TLS টার্মিনেশন না পাস-থ্রু? সঠিক Webship রিভার্স-প্রক্সি বাউন্ডারি নির্বাচন

TLS টার্মিনেশন এবং TLS পাস-থ্রু মধ্যে নির্বাচনের সিদ্ধান্ত কোনো সাজ-সজ্জার প্রক্সি সেটিং নয়। এটি নির্ধারণ করে এনক্রিপশন কোথায় समाप्त হয়, কোন সিস্টেম সেশন কী ধারণ করে, কি না Webship HTTP পরীক্ষা করতে পারে, এবং কোন স্তরটি অ্যাপ্লিকেশন নিরাপত্তা প্রয়োগ করতে হবে।

Webship ডিফল্টভাবে পাস-থ্রু এ থাকে। এটি অ্যাপ্লিকেশন প্লেইনটেক্সট এবং সক্রিয় সেশন কী-গুলোকে উৎসে রাখে। শুধুমাত্র তখনই টার্মিনেশন সক্ষম করুন যখন এজকে HTTP অনুরোধটি বোঝা এবং তার উপর কার্যকর করতে হবে।

একটি বাক্যে সিদ্ধান্ত

যখন উৎসকে TLS সীমা নিজের হাতে রাখতে হবে তখন TLS পাস-থ্রু ব্যবহার করুন। যখন TLS টার্মিনেশন ব্যবহার করতে হবে তখনWebship HTTP ট্রাফিককে রাউট করতে, সুরক্ষা দিতে, রূপান্তর করতে, ক্যাশ করতে, বা পর্যবেক্ষণ করতে হবে।

উভয় মোডই সার্বজনীনভাবে আরও নিরাপদ নয়। পাস-থ্রু প্রান্ত দ্বারা পরিচালিত সংবেদনশীল উপাদান কমায়, তবে প্রান্তের HTTP নিরাপত্তা নিয়ন্ত্রণগুলি সরিয়ে দেয়। টার্মিনেশন একটি পরিদর্শনযোগ্য প্রয়োগ পয়েন্ট যুক্ত করে, তবে তৈরি করে Webship ভরসাযোগ্য TLS সীমার অংশ।

| উদ্বেগ | TLS শেষ করা | TLS পাস-থ্রু | | --- | --- | --- | | TLS এন্ডপয়েন্ট | Webship | উত্স | | অ্যাপ্লিকেশন প্লেইনটেক্সটে Webship | হ্যাঁ | না | | সক্রিয় ডাউনস্ট্রিম সেশন কী সমূহ সময়ে Webship | হ্যাঁ | না | | HTTP পাথ বা মেথড দ্বারা রুট | হ্যাঁ | না | | WAF, API শিল্ড, এবং বডি সীমা Webship | হ্যাঁ | না | | প্রক্সি ক্যাশ, পুনর্লিখন, এবং ফরোয়ার্ডিং হেডার | হ্যাঁ | না | | টিসিপি রাউটিং ইনপুট | এইচটিটিপি অথরিটি এবং রুট পলিসি | ক্লায়েন্টহেলো এসএনআই | | HTTP/3 রাউটিং | এইচটিটিপি অনুরোধ ডেটা | একটি শেয়ার করা ইউডিপি উত্স | | উৎসের দায়িত্ব | HTTP বা আলাদাভাবে কনফিগার করা আপস্ট্রিম TLS | সম্পূর্ণ TLS, ALPN, এবং HTTP স্ট্যাক |

তাহলে গুরুত্বপূর্ণ প্রশ্নটি হল 'কোন সুইচটি দ্রুত?' নয়। এটি হল 'কোন উপাদানকে অনুরোধটি দেখার এবং নিয়ন্ত্রণ করার অনুমতি দিতে হবে?'

কোন সমাপ্তি দেয়Webship

সহtls_termination = true, Webship ডাউনস্ট্রিম TLS সম্পূর্ণ করে এবং ডিক্রিপ্ট হওয়া অনুরোধটি এর HTTP রিভার্স-প্রক্সি পাইপলাইনে প্রবাহিত করে। যার ফলে নিম্নলিখিত বৈশিষ্ট্যগুলো সম্ভব হয়:

• পাথ, হোস্ট, এবং মেথড-সচেতন রাউটিং;
• WAF এবং API শিল্ড পরিদর্শন;
• রিকোয়েস্ট-বডির সীমা এবং নীতিমালা সময়সীমা;
• প্রক্সি ক্যাশিং এবং জেনারেশন-নিরাপদ অবৈধকরণ;
• ফরওয়ার্ডিং-হেডার ব্যবস্থাপনা এবং HTTP অ্যাক্সেস-লগ ক্ষেত্রসমূহ;
• শরীর-সচেতন QUERY পরিচালনা, যেখানে নিরাপদ সেখানে পুনরায় চেষ্টা, এবং সার্কিট-ব্রেকার নীতি;
• ক্লায়েন্ট-মুখীন এবং আপস্ট্রিম সংযোগের মধ্যে প্রোটোকল অনুবাদ।

এই মোডটি নিরাপত্তার দায়িত্বও পরিবর্তন করে। Webship হোস্টকে সার্টিফিকেট ব্যক্তিগত কী, সেশন কী, ডিক্রিপ্ট করা অনুরোধ এবং প্রতিক্রিয়া ডেটা, পর্যবেক্ষণ আউটপুট এবং যেকোনো ক্যাশ করা উপস্থাপনাগুলি সুরক্ষিত রাখতে হবে। যদি পরবর্তী হপকে এনক্রিপ্টেড রাখতে হয়, তবে টাইপ করা আপস্ট্রিম TLS আলাদাভাবে কনফিগার করুন; অন্যথায় HTTP আপস্ট্রিম ক্লিয়ারটেক্সট হবে।

সমাপ্তি হল যখন ডান সীমাWebship এটি কেবল একটি এনক্রিপ্টেড ট্রান্সপোর্ট রিলে হিসেবে নয়, একটি অ্যাপ্লিকেশন-সচেতন এজ হিসেবে আচরণ করার প্রত্যাশা করা হচ্ছে।

কী পাস-থ্রু সংরক্ষণ করে

সহtls_termination = false—ডিফল্ট—Webship এইটি HTTP অনুরোধ বা প্রতিক্রিয়ার ডিক্রিপ্ট না করেই এনক্রিপ্ট করা TLS বা QUIC ট্রাফিক রিলে করে। অ্যাপ্লিকেশন প্লেইনটেক্সট এবং সক্রিয় সেশন কী মূল উৎসে থাকে।

যখন সার্টিফিকেটগুলো অ্যাপ্লিকেশন টিয়ারে থাকতে হবে, অনুগামী নীতি এজ ডিক্রিপশনকে নিষিদ্ধ করে, অথবা একটি মূল-নির্দিষ্ট TLS পরিচয় ক্লায়েন্টের কাছে অপরিবর্তিত পৌঁছাতে হবে, তখন সেই ছোট ট্রাস্ট সীমা মূল্যবান হয়। এটি রিলে পথে HTTP পার্সিং এবং নীতি কাজও সরিয়ে দেয়।

বাণিজ্য-বিনিময় কঠোর:Webship যা ডিক্রিপ্ট করতে পারে না তা পরীক্ষা করতে পারে না। এটি HTTP WAF নিয়ম প্রয়োগ করতে পারে না, পাথ অনুযায়ী রুটে দিতে পারে না, হেডার পুনরায় লিখতে পারে না, বডি-সচেতন API নীতি প্রয়োগ করতে পারে না, বা HTTP-ফিল্ড অ্যাক্সেস লগ পূরণ করতে পারে না। উৎসকে নিজেই সেই সমস্ত নিয়ন্ত্রণ প্রদান করতে হবে।

অতএব, পাস-থ্রু হল 'কম ফিচারের সঙ্গে টার্মিনেশন' নয়। এটি একটি ভিন্ন আর্কিটেকচার যার একটি ভিন্ন নিরাপত্তা মালিক রয়েছে।

প্রোটোকল-নির্দিষ্ট সীমাগুলি গুরুত্বপূর্ণ

এর জন্যHTTP/1.1 টিএলএস এবংHTTP/2 টিএলএস, Webship SNI দ্বারা কনফিগার করা TCP গন্তব্য নির্বাচন করার জন্য ClientHello কে শুধু যথেষ্ট পর্যন্ত পরিদর্শন করে। প্রতিটি পাস-থ্রু ডোমেইনের জন্য একটি ক্যাচ-অল প্রয়োজন।path_prefix = "/" রুট কারণ প্রকৃত অনুরোধের পথ এনক্রিপ্টেড থাকে। শুধুমাত্র যখন কনফিগারেশনে একটি ডোমেইন থাকে, তখন SNI ছাড়া ক্লায়েন্টকে গ্রহণ করা হয়।

উৎপত্তি অবশ্যই ক্লায়েন্টের ALPN নিয়ে আলোচনা করতে হবে এবং নির্বাচিত প্রোটোকলকে সমর্থন করতে হবে।Webship রূপান্তর করা যায় না HTTP/2 একজন ক্লায়েন্টকেHTTP/1.1 অরিজিন যখন TLS সেশন অপরিবর্তিতভাবে অতিক্রম করে।

HTTP/3 UDP এর উপর QUIC ব্যবহার করে এবং একটি কঠোর সীমা রয়েছে। পাস-থ্রু নিরাপদভাবে এনক্রিপ্টেড HTTP অথরিটি দ্বারা রুট করতে পারে না, তাই প্রতিটি কনফিগার করাHTTP/3 রুটটি অবশ্যই একই আইপি-সকেট ইউডিপি উৎসে সমাধান করতে হবে।Webship ইউনিক্স সকেট এবং একাধিক প্রত্যাখ্যান করেHTTP/3 কনফিগারেশন বৈধকরণের সময় নিঃশব্দে অস্পষ্টভাবে রুট করার পরিবর্তে উৎসগুলি সরাসরি পার হওয়া।

সরাসরি লেখাHTTP/1.1 এবং h2c দ্বারা প্রভাবিত হয় নাreverse_proxy.tls_termination. সেটিং নিয়ন্ত্রণ করে ডাউনস্ট্রীমHTTP/1.1 টিএলএস, HTTP/2 টিএলএস, এবং HTTP/3 শুধুমাত্র TLS।

মাপা অনুরোধ ক্ষমতা

দ্য Webship ১.৩.১ ডেবিয়ান সক্ষমতা বেন্চমার্ক দুটি এনক্রিপ্ট করা রিভার্স-প্রক্সি মোড আলাদা করে পরিমাপ করেছিল। প্রতিটি স্বীকৃত নমুনার জন্য শূন্য HTTP, সকেট, প্রোটোকল, প্রক্সি, মেজর-পেজ-ফল্ট এবং HTTP/3 প্যাকেট-হ্রাস ত্রুটিগুলি।

| রিভার্স-প্রক্সি মোড | HTTP/1.1 টিএলএস | HTTP/2 টিএলএস | HTTP/3 টিএলএস | | --- | ---: | ---: | ---: | | টিএল এস টার্মিনেশন | 123,344 RPS | 124,957 RPS | 131,529 RPS | | TLS পাস-থ্রু | ২০৩,৯৫০ আরপিএস | ২৬৬,৮৪৫ আরপিএস | ১৬৭,০১০ আরপিএস |

ছোট-প্রতিক্রিয়া পাস-থ্রুতে কম অ্যাপ্লিকেশন কাজ সম্পন্ন করতে হয়: এটি TLS শেষ করার, HTTP বিশ্লেষণ করার, নীতিমালা মূল্যায়ন করার এবং নতুন ডাউনস্ট্রিম TLS স্ট্রিম তৈরি করার পরিবর্তে এনক্রিপ্ট করা ট্রান্সপোর্ট ডেটা রিলেতে কাজ করে। উচ্চতর পাস-থ্রু অনুরোধের হার সেই সংকীর্ণ কাজকে প্রতিফলিত করে।

এই সারিগুলি একই ধরনের বৈশিষ্ট্যের সেট উপস্থাপন করে না, এবং এগুলি ব্যবহার করে এটি দাবি করা উচিত নয় যে একটি নিরাপত্তা স্থাপত্য সর্বজনীনভাবে ভাল। টার্মিনেশন এমন HTTP-সচেতন ক্ষমতার জন্য মূল্য দেয় যা উদ্দেশ্যমূলকভাবে পাস-থ্রু প্রদান করতে পারে না।

বাল্ক স্ট্রিমিং ফলাফল পরিবর্তন করে

একই বেঞ্চমার্কটি ১০০ এমবি স্ট্রিমিং ম্যাট্রিক্সের জন্য ঠিক ৯৯,৯৪৩,৭৭৮-বাইটের রেসপন্স বডি ব্যবহার করেছিল। এখানে, TLS টার্মিনেশন তিনটি প্রোটোকলের জন্যই উচ্চতর মধ্যম পে-লোড থ্রুপুট উৎপন্ন করেছিল:

| রিভার্স-প্রক্সি মোড | HTTP/1.1 টিএলএস | HTTP/2 টিএলএস | HTTP/3 টিএলএস | | --- | ---: | ---: | ---: | | TLS টার্মিনেশন | ৩,৫৮৫.৭ মিবি/সেক | ৩,৩৫৫.০ মিবি/সেক | ১,৯৩৮.৬ মিবি/সেক | | টিএলএস পাস-থ্রু | 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-সচেতন বহুল-প্রতিক্রিয়া পথ।

সাত-নমুনাHTTP/3 যোগ্যতাও স্থিতিশীলতা পরীক্ষা করেছিল। সমাপ্ত স্ট্রিমিং ১,৯৩৮.৬ MiB/s মিডিয়ানের সাথে ২.১২% ভেরিয়েশন সহ পৌঁছেছিল; পাস-থ্রু ১,৭৪৮.৫ MiB/s পৌঁছেছিল ১.৬৫% ভেরিয়েশন সহ। উভয়ই শূন্য ক্লায়েন্ট, প্রোটোকল এবং প্যাকেট-ক্ষতির ত্রুটি সহ সঠিক বডি সরবরাহ করেছিল।

সচেতনভাবে পাস-থ্রু কনফিগার করুন

একটি ন্যূনতম পাস-থ্রু কনফিগারেশন 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 একীকৃত ডেবিয়ান সক্ষমতা বেঞ্চমার্ক যা ১১ সেপ্টেম্বর, ২০২৬ তারিখের; এর গ্রহণের গেটগুলিতে শূন্য ক্লায়েন্ট, HTTP, সকেট, প্রটোকল, প্রক্সি, মেজর-পেজ-ফল্ট, এবং HTTP/3 প্যাকেট-হ্রাস ত্রুটি।