TLS lezárás vagy átengedés? A megfelelő Webship reverse-proxy határ kiválasztása

A TLS megszakítás és a TLS átviteli mód közötti választás nem kozmetikai proxy-beállítás. Ez határozza meg, hol ér véget a titkosítás, melyik rendszer tartja a munkamenet-kulcsokat, képes-e a Webship ellenőrizni a HTTP-t, és melyik rétegnek kell érvényesítenie az alkalmazásbiztonságot.

Webship alapértelmezettként átviteli módban működik. Ez az alkalmazás tiszta szövegét és az aktív munkamenetkulcsokat az eredeti helyen tartja. A lezárást csak akkor engedélyezze, ha a peremnek meg kell értenie és kezelnie kell a HTTP-kérést.

A döntés egy mondatban

Használjon TLS átjárást akkor, ha az eredetnek kell birtokolnia a TLS határt. Használjon TLS lezárást akkor, ha Webship-nak kell irányítania, védenie, átalakítania, gyorsítótáraznia vagy figyelnie a HTTP-forgalmat.

egyik mód sem mindenütt biztonságosabb. A pass-through csökkenti az élen kezelt érzékeny anyagokat, de eltávolítja az él HTTP biztonsági vezérlőit. A termination hozzáad egy ellenőrizhető érvényesítési pontot, de a Webship a megbízható TLS határ részévé válik.

| Aggodalom | TLS végződés | TLS átengedés | | --- | --- | --- | | TLS végpont | Webship | Eredet | | Alkalmazás sima szövege a Webship | Igen | Nem | | Aktív downstream munkamenetkulcsok a Webship-n | Igen | Nem | | Útvonal HTTP útvonal vagy módszer szerint | Igen | Nem | | WAF, API Shield és testméret-korlátozások a Webship | Igen | Nem | | Proxy gyorsítótár, átírások és továbbított fejléc | Igen | Nem | | TCP útvonal bevitel | HTTP hitelesítés és útvonal szabályzat | ClientHello SNI | | HTTP/3 útválasztás | HTTP kérés adatai | Egy megosztott UDP forrás | | Eredeti felelősség | HTTP vagy külön konfigurált upstream TLS | Teljes TLS, ALPN és HTTP verem |

A fontos kérdés tehát nem az, hogy „Melyik kapcsoló gyorsabb?” Hanem az, hogy „Melyik komponensnek kell engedélyezni, hogy lássa és irányítsa a kérést?”

Milyen megszüntetés ad Webship-t

A tls_termination = true segítségével a Webship befejezi a downstream TLS-t, és a titkosított kérelmet a HTTP visszafordító proxy folyamatába táplálja. Ez a következő funkciókat teszi lehetővé:

• útvonal-, hoszt- és módszer-tudatos útválasztás;
• WAF és API Shield vizsgálat;
• kérés-törzs korlátai és szabályzati időkorlátok;
• proxy gyorsítótárazás és generációbiztos érvénytelenítés;
• továbbító-fejléc kezelés és HTTP hozzáférési napló mezők;
• testtudatos KÉRÉS kezelés, biztonságos újrapróbálkozások, és áramkör-megszakító politika;
• protokollfordítás a klienssel szembeni és a felsőszintű kapcsolatok között.

Ez a mód a biztonsági felelősséget is megváltoztatja. A Webship gazdagépnek védenie kell a tanúsítvány privát kulcsát, a munkamenetkulcsokat, a dekódolt kérés- és válaszadatokat, a megfigyelhetőségi kimenetet, valamint bármely gyorsítótárazott reprezentációt. Ha a következő ugrásnak titkosítottnak kell maradnia, konfiguráljon külön típusos upstream TLS-t; ellenkező esetben a HTTP upstream tiszta szöveg.

A megszűnés a jobb oldali határ, amikor a Webship-t alkalmazás-tudatos élként kell viselkednie, nem csupán titkosított átvitel közvetítőjeként.

Mit őriz meg a továbbengedés

A tls_termination = false – az alapértelmezett – Webship titkosított TLS vagy QUIC forgalmat továbbít anélkül, hogy dekódolná a HTTP kérést vagy választ. Az alkalmazás egyszerű szövege és a aktív munkamenetkulcsok az eredeti helyen maradnak.

Ez a kisebb bizalmi határ értékes, amikor a tanúsítványoknak az alkalmazásrétegen kell maradniuk, a megfelelőségi szabályzat tiltja a peremdekódolást, vagy egy eredeti-specifikus TLS-azonosságnak változatlanul kell eljutnia az ügyfélhez. Emellett eltávolítja a HTTP-parszolást és a szabályzatkezelést a relé útvonalból.

A kompromisszum szigorú: Webship nem tudja ellenőrizni azt, amit nem tud dekódolni. Nem tud HTTP WAF szabályokat alkalmazni, útvonal szerint irányítani, fejlécet átírni, testre érzékeny API szabályt érvényesíteni, vagy HTTP-mező hozzáférési naplókat kitölteni. Az eredetnek kell mindezeket a vezérléseket biztosítania.

Ezért a pass-through nem „kevesebb funkcióval rendelkező leállítás”. Ez egy másik architektúra, más biztonsági tulajdonossal.

A protokollspecifikus korlátok számítanak

A HTTP/1.1 TLS és a HTTP/2 TLS esetén a Webship csak éppen annyira vizsgálja a ClientHello-t, hogy kiválaszthassa a konfigurált TCP célpontot az SNI alapján. Minden átjáró domainnek szüksége van egy mindent elfogadó path_prefix = "/" útvonalra, mert a tényleges kéréstöbblet titkosított marad. Az SNI nélküli kliens csak akkor kerül elfogadásra, ha a konfigurációban csak egy domain szerepel.

Az originnek tárgyalnia kell az ügyfél ALPN-jét és támogatnia kell a kiválasztott protokollt. Webship nem tud egy HTTP/2 ügyfelet HTTP/1.1 originre konvertálni, miközben a TLS-munkamenet változatlanul halad át.

HTTP/3 a QUIC-et használja UDP felett, és szorosabb határértékkel rendelkezik. A pass-through nem tud biztonságosan titkosított HTTP-autorítás alapján útválasztani, így minden konfigurált HTTP/3 útvonalnak ugyanahhoz az IP-cím/soket UDP eredethez kell feloldódnia. Webship elutasítja a Unix socketeket és a több HTTP/3 pass-through eredetet a konfiguráció ellenőrzése során, ahelyett hogy csendben kétértelműen útválasztana.

A Cleartext HTTP/1.1 és a h2c nincs hatással reverse_proxy.tls_termination által. A beállítás csak a downstream HTTP/1.1 TLS-t, HTTP/2 TLS-t és HTTP/3 TLS-t szabályozza.

Mért kérésteljesítmény

A Webship 1.3.1 Debian kapacitás-benchmark külön mérte a két titkosított fordított proxy módot. Minden elfogadott minta nulla HTTP-, socket-, protokoll-, proxy-, nagy-oldalhiba- és HTTP/3 csomagvesztési hibát igényelt.

| Visszafordító-proxy mód | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS megszüntetés | 123,344 RPS | 124,957 RPS | 131,529 RPS | | TLS átjárás | 203 950 RPS | 266 845 RPS | 167 010 RPS |

A kis válaszátviteli átjárásnak kevesebb alkalmazásmunkát kell végeznie: titkosított szállítási adatokat továbbít ahelyett, hogy leállítaná a TLS-t, HTTP-t elemezne, szabályzatot értékelne és új leirányauló TLS-adatfolyamot hozna létre. A magasabb átviteli kérések aránya azt a szűkebb feladatot tükrözi.

Ezek a sorok nem azonos jellemzőkészleteket képviselnek, és nem szabad őket arra használni, hogy egyik biztonsági architektúra univerzálisan jobb lenne. A terminálás fizet az HTTP-tudatos képességekért, amelyeket a szándékosan áthaladó (pass-through) megoldások nem tudnak biztosítani.

A tömeges streamelés megváltoztatja az eredményt

Ugyanaz a referenciaérték pontosan 99 943 778 bájt méretű választ adott a 100 MB-os streaming mátrixhoz. Itt a TLS-lezárás minden három protokoll esetében magasabb medián adatátviteli sebességet eredményezett:

| Visszafordító-proxy mód | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS megszüntetés | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | TLS átengedés | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |

Miért változik az irány? Lezárási módban a benchmark eredete titkosítatlan HTTP-t küld a Webship-nek, és a Webship birtokolja az optimalizált downstream tömeges útvonalat. A nagy HTTP/1.1 és HTTP/2 válaszok adaptív Linux kTLS-t és korlátozott, szállítóspecifikus pufferelést használhatnak. A HTTP/3 QUIC ütemezést, DPLPMTUD-t és reaktoronkénti csomagolást használ kTLS helyett.

Átmenő módban az origin birtokolja a downstream TLS-t, és a Webship továbbítja a keletkező titkosított adatfolyamot vagy QUIC csomagokat. Ez megőrzi az origin TLS határát, de nem használhatja a Webship HTTP-érzékeny tömeges válaszútvonalát.

A hétmintás HTTP/3 minősítés a stabilitást is ellenőrizte. A befejezett streaming 1 938,6 MiB/s mediánt ért el 2,12%-os szóráskoefficienssel; a pass-through 1 748,5 MiB/s-t ért el 1,65%-os szóráskoefficienssel. Mindkettő pontosan a teljes adatot szolgáltatta nulla kliens-, protokoll- és csomagvesztési hibával.

Állítsa be a továbbítást szándékosan

A minimális átmeneti konfiguráció a TLS-azonosságot készen tartja, így a kezelő később engedélyezheti a lezárást anélkül, hogy megváltoztatná a tanúsítvány útvonalait:

[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

A színpadra állított Webship tanúsítvány érvényesítve van, de az aktív átmenő munkamenetek nem használják. A 10.0.0.20:443 eredetnek le kell zárnia a TLS-t és támogatnia kell a kliens által tárgyalt protokollt.

Engedélyezze a terminálást, amikor az élnek HTTP-re van szüksége

Az alkalmazás-érzékeny élhez engedélyezze a terminálást, és küldje a keletkező HTTP-forgalmat a kiválasztott eredethez:

[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

Ez a konfiguráció képes HTTP forgalmat irányítani és ellenőrizni. Adjon hozzá upstream TLS-t, ha a hálózat Webship és az eredeti kiszolgáló között még nem megbízható vagy izolált.

Váltás módok között újraindítás nélkül Webship

Webship képes megváltoztatni a tls_termination-t konfigurációs fájl újratöltésével vagy a verzió-ellenőrzött webship.reverse_proxy.apply_config MCP eszközzel. Olvassa be a jelenlegi objektumot és verziót webship.reverse_proxy.get_config segítségével, csak a kívánt mezőt módosítsa a teljes visszakapott objektumban, és küldje el a megfelelő expected_version_id-val.

Az új TCP kapcsolatok az új módot használják. A HTTP/3 kliens újracsatlakozik a lecserélt UDP átviteli módszerhez. A tanúsítvány- és kulcsútvonal változtatások továbbra is a folyamathoz kötöttek, és újraindítást igényelnek, ezért tarts egy érvényes lezárási azonosítót előkészítve a tényleges váltás előtt.

A verzióellenőrzés megakadályozza, hogy egy operátor felülírjon egy egyidejű konfigurációs módosítást. Egy elutasított frissítés az aktív futási időt és a tárolt konfigurációt változatlanul hagyja.

Egy praktikus kiválasztási ellenőrzőlista

Válassza a továbbengedést, ha mindezek igazak:

1. Az eredetinek meg kell tartania a tanúsítványhatárt és a munkamenetkulcsokat.
2. Az SNI-szintű TCP útválasztás – vagy egy közös HTTP/3 UDP forrás – elegendő.
3. Az origin biztosítja a szükséges WAF-ot, engedélyezést, naplózást, törzs korlátokat és visszaélés elleni vezérlőket.
4. Nincs szükség él-cache-re, útvonal-átírásra, továbbítási fejléc szabályra vagy HTTP protokoll átalakításra.

Válassza a megszüntetést, ha bármelyikre szükség van a Webship esetén:

1. Továbbítás hoszt, útvonal vagy módszer szerint.
2. Kérdések ellenőrzése WAF-fel vagy API Shield-del.
3. Érvényesítse a test korlátait, a HTTP időkorlátokat vagy a perem hitelesítést.
4. Válaszok gyorsítótárazása vagy HTTP-fejlécek átírása.
5. Fordítson le a downstream és upstream HTTP protokollok között.
6. Figyelje az HTTP mezőket a proxy határán.

Bármelyik módot is választja, tesztelje az SNI-t, az ALPN-t, a tanúsítványazonosságot, az ügyfél lemondását, a feláramló félbontást és a pontos válaszintegritást. A kérések kapacitását és a streamelési átvitelt külön mérje: a leggyorsabb mód egy kis válasz esetén nem feltétlenül a leggyorsabb mód egy 100 MB-os testhez.

Webship alapértelmezetté teszi a pass-through-t, mert egy proxy nem terjesztheti tétlenül a bizalmi határát. A terminálás továbbra is élő, explicit operációs választás marad, amikor az HTTP-tudatos él viselkedés megéri ezt a felelősséget.

Olvasd el a teljes [reverse-proxy dokumentációt](/docs/1.3.1), hasonlítsd össze az elfogadott [benchmark mátrixot](/benchmarks), vagy töltsd le a Webship fájlt a [Letöltésekből](/downloads).

Források és tartalom módszer

A teljesítményértékek a 2026. szeptember 11-i Webship 1.3.1 egységes Debian kapacitás-benchmarkból elfogadott mediánok; az elfogadási küszöbeinek követelménye nincs kliens-, HTTP-, socket-, protokoll-, proxy-, főoldal-hibás és HTTP/3 csomagvesztési hiba.