סיום TLS או העברה ישירה? בחירת גבול פרוקסי הפוך Webship הנכון

לבחור בין סיום TLS להעברת TLS אינו רק הגדרת פרוקסי קוסמטית. זה קובע איפה ההצפנה מסתיימת, איזה מערכת מחזיקה במפתחות המפגש, האם Webship יכול לבדוק HTTP, ואיזה שכבה חייבת לאכוף את אבטחת היישום.

Webship מוגדר כברירת מחדל למעבר ישיר. זה שומר על הטקסט הפשוט של היישום ומפתחות המפגש הפעילים במקור. אפשר סיום רק כאשר הקצה חייב להבין ולהגיב לבקשת ה-HTTP.

ההחלטה במשפט אחד

השתמש ב-TLS pass-through כאשר המקור חייב להיות בעל גבול ה-TLS. השתמש ב-TLS termination כאשר Webship חייב לנתב, להגן, לשנות, לאחסן במטמון או לצפות בתעבורת HTTP.

אף מצב אינו בטוח יותר באופן אוניברסלי. מעבר ישיר מפחית את החומרים הרגישים שהקצה מטפל בהם, אך מסיר את בקרות האבטחה של HTTP בקצה. סיום מוסיף נקודת אכיפה שניתן לבדוק אותה, אך עושה את 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 reverse-proxy שלה. זה מאפשר את הפונקציות הבאות:

• ניתוב המודע לנתיב, למשתמש ולשיטה;
• בדיקת 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. כל דומיין שמעביר דרכו צריך מסלול path_prefix = "/" כולל-לַכּוֹל מכיוון שנתיב הבקשה בפועל נשאר מוצפן. לקוח ללא SNI מתקבל רק כאשר ההגדרה כוללת דומיין אחד.

המקור חייב לנהל משא ומתן על ALPN של הלקוח ולתמוך בפרוטוקול שנבחר. Webship לא יכול להמיר לקוח HTTP/2 למקור HTTP/1.1 בעוד שהפגישה של TLS עוברת ללא שינוי.

HTTP/3 משתמש ב-QUIC על גבי UDP ויש לו גבול הדוק יותר. מעבר דרך לא יכול לנתב בצורה בטוחה לפי אישור HTTP מקודד, ולכן כל מסלול HTTP/3 שמוגדר חייב לנתב לאותו מקור IP-סוקט UDP. Webship דוחה סוקטים של Unix ומקורות מעבר HTTP/3 מרובים במהלך אימות התצורה במקום לנתב באופן עמום בשקט.

טקסט ברור HTTP/1.1 ו-h2c אינם מושפעים על ידי reverse_proxy.tls_termination. ההגדרה שולטת רק ב-TLS של HTTP/1.1 למטה בזרם, TLS של HTTP/2 ו-TLS של HTTP/3.

קיבולת בקשה נמדדת

מדד הקיבולת Webship 1.3.1 Debian מדד את שני מצביי ה-reverse-proxy המוצפנים בנפרד. כל דגימה שהתקבלה דרשה אפס שגיאות HTTP, socket, פרוטוקול, פרוקסי, major-page-fault, ו-HTTP/3 אובדן חבילות.

| מצב פרוקסי הפוך | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | סיום TLS | 123,344 בקשות לשנייה | 124,957 בקשות לשנייה | 131,529 בקשות לשנייה | | מעבר TLS | 203,950 בקשות לשנייה | 266,845 בקשות לשנייה | 167,010 בקשות לשנייה |

מעבר-תגובה קטן דורש פחות עבודה מהמיישום: הוא משדר נתוני תחבורה מוצפנים במקום לסיים TLS, לנתח HTTP, להעריך מדיניות, וליצור זרם TLS חדש בצד הלקוח. שיעורי הבקשה הגבוהים יותר במעבר משקפים את המשימה הצרה הזו.

שורות אלה אינן מייצגות קבוצות תכונות זהות, ואין להשתמש בהן כדי לטעון שארכיטקטורת אבטחה אחת טובה יותר באופן אוניברסלי. סיום מתגמל על יכולות המודעות ל-HTTP אשר מעבר ישיר באופן מכוון לא יכול לספק.

שידור בכמות גדולה משנה את התוצאה

אותו מדד השתמש בגוף תגובה בגודל מדויק של 99,943,778 בתים עבור מטריצת הזרמת 100 מגה-בתים. כאן, סיום TLS יצר תפוקה ממוצעת גבוהה יותר עבור כל שלושת הפרוטוקולים:

| מצב פרוקסי הפוך | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | סיום TLS | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | מעבר TLS | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |

מדוע הכיוון משתנה? במצב סיום, מקור הבenchmark שולח HTTP בטקסט ברור ל-Webship, ו-Webship מחזיק בנתיב ההעברה הכבדה המיועלת. תגובות גדולות של HTTP/1.1 ו-HTTP/2 יכולות להשתמש ב-kTLS אדפטיבי ללינוקס ובאחסון זמני מוגבל בהתאם להובלה. HTTP/3 משתמש בקצב QUIC, DPLPMTUD, ואצווה לפי ריאקטור במקום kTLS.

במצב מעבר-דרך, המקור מחזיק ב-TLS של הזרם היוצא ו-Webship מעביר את הזרם המוצפן שנוצר או את חבילות ה-QUIC. זה שומר על גבול ה-TLS של המקור, אך אינו יכול להשתמש במסלול התגובה הכמותית המודעת ל-HTTP של 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. ניתוב TCP ברמת SNI—או מקור UDP משותף אחד HTTP/3—מספיק.
3. המוצא מספק את ה-WAF הנדרש, הרשאות, רישום, מגבלות גוף ושליטה על שימוש לרעה.
4. אין צורך בזיכרון מטמון בקצה, בהפניית נתיב, במדיניות כותרת העברה או בתרגום פרוטוקול HTTP.

בחר סיום כאשר כל אחד מהדברים האלה נדרש ב-Webship:

1. ניתוב לפי מארח, נתיב או שיטה.
2. בדוק בקשות עם WAF או מגן API.
3. לאכוף מגבלות על גוף הבקשה, זמני חיבור HTTP, או אימות בקצה.
4. לאחסן תגובות במטמון או לשכתב כותרות HTTP.
5. תרגם בין פרוטוקולי HTTP יורדים ועולים.
6. צפה בשדות HTTP בגבול הפרוקסי.

לא משנה באיזה מצב תבחרו, בדקו SNI, ALPN, זהות תעודה, ביטול מצד הלקוח, סגירה חלקית במעלה הזרם, ודיוק תגובה מדויק. מדדו את קיבולת הבקשה וקצב השידור בנפרד: המצב המהיר ביותר עבור תגובה קטנה לא בהכרח המצב המהיר ביותר עבור גוף של 100MB.

Webship עושה את המעבר כברירת מחדל מכיוון שסוכן-ביניים לא צריך להרחיב בשקט את גבול האמון שלו. סיום נשאר בחירה פעילה ומפורשת בתפעול כאשר התנהגות קצה המודעת ל-HTTP שווה את האחריות הזאת.

קרא את כל [התיעוד של פרוקסי הפוך](/docs/1.3.1), השווה את [מטריצת הבנצ'מרק](/benchmarks) המקובלת, או הורד את Webship מ-[הורדות](/downloads).

מקורות ושיטת תוכן

ערכי הביצועים הם חציונים מקובלים מתוך מִדָּדוּת הקיבולת המאוחדת של Debian גרסה 1.3.1 Webship בתאריך 11 בספטמבר 2026; שערי הקבלה שלה מחייבים אפס שגיאות של לקוח, HTTP, סוקט, פרוטוקול, פרוקסי, תקלות עמודי עיקריים, ואובדן חבילות HTTP/3.