Τερματισμός TLS ή Διέλευση; Επιλογή του Σωστού Όρια Αντιστροφής Proxy Webship

Η επιλογή μεταξύ τερματισμού TLS και διέλευσης TLS δεν είναι μια επιφανειακή ρύθμιση διακομιστή μεσολάβησης. Καθορίζει πού τελειώνει η κρυπτογράφηση, ποιο σύστημα κρατά τα κλειδιά της συνεδρίας, εάν το Webship μπορεί να ελέγξει το HTTP και ποιο επίπεδο πρέπει να εφαρμόσει την ασφάλεια της εφαρμογής.

Webship έχει προεπιλογή το pass-through. Αυτό διατηρεί το plaintext της εφαρμογής και τα ενεργά κλειδιά συνεδρίας στην προέλευση. Ενεργοποιήστε τον τερματισμό μόνο όταν το edge πρέπει να κατανοεί και να ενεργεί σύμφωνα με το αίτημα HTTP.

Η απόφαση σε μια πρόταση

Χρησιμοποιήστε TLS pass-through όταν η προέλευση πρέπει να κατέχει το όριο TLS. Χρησιμοποιήστε TLS termination όταν Webship πρέπει να δρομολογεί, να προστατεύει, να μετατρέπει, να αποθηκεύει προσωρινά ή να παρακολουθεί την κίνηση HTTP.

Καμία λειτουργία δεν είναι παγκοσμίως πιο ασφαλής. Η διέλευση μειώνει το ευαίσθητο υλικό που χειρίζεται η άκρη, αλλά αφαιρεί τους ελέγχους ασφαλείας HTTP της άκρης. Ο τερματισμός προσθέτει ένα σημείο επιβολής που μπορεί να επιθεωρηθεί, αλλά καθιστά το Webship μέρος του αξιόπιστου ορίου TLS.

| Θέμα | Τερματισμός TLS | Διέλευση TLS | | --- | --- | --- | | Σημείο τερματισμού TLS | Webship | Προέλευση | | Απλό κείμενο εφαρμογής στο Webship | Ναι | Όχι | | Ενεργά κλειδιά συνεδρίας downstream στο Webship | Ναι | Όχι | | Δρομολόγηση κατά διαδρομή HTTP ή μέθοδο | Ναι | Όχι | | WAF, API Shield, και όρια σώματος στο Webship | Ναι | Όχι | | Μεσοθεματική προσωρινή μνήμη, επαναγραφές και προώθηση κεφαλίδων | Ναι | Όχι | | Εισερχόμενος δρομολογητής TCP | Πολιτική εξουσιοδότησης και δρομολόγησης HTTP | ClientHello SNI | | HTTP/3 δρομολόγηση | Δεδομένα αιτήματος HTTP | Μία κοινή προέλευση UDP | | Υπευθυνότητα προέλευσης | HTTP ή ξεχωριστά ρυθμισμένο upstream TLS | Πλήρης TLS, ALPN και στοίβα HTTP |

Το σημαντικό ερώτημα επομένως δεν είναι «Πιο διακόπτης είναι ταχύτερος;». Είναι «Ποιο συστατικό πρέπει να επιτραπεί να δει και να ελέγξει το αίτημα;»

Ποιος τερματισμός δίνει το Webship

Με το tls_termination = true, το Webship ολοκληρώνει το downstream TLS και εισάγει το αποκρυπτογραφημένο αίτημα στη ροή εργασίας του HTTP reverse-proxy. Αυτό καθιστά δυνατά τα ακόλουθα χαρακτηριστικά:

• δρομολόγηση με επίγνωση της διαδρομής, του κεντρικού υπολογιστή και της μεθόδου;
• Έλεγχος WAF και API Shield;
• όρια σώματος αιτήματος και χρονικά όρια πολιτικής;
• προσωρινή αποθήκευση και ακύρωση ασφαλής για παραγωγή;
• διαχείριση κεφαλίδας προώθησης και πεδία ημερολογίου πρόσβασης HTTP;
• χειρισμός ερωτημάτων με επίγνωση του σώματος, επαναλήψεις εκεί που είναι ασφαλές, και πολιτική διακόπτη κυκλώματος;
• μετάφραση πρωτοκόλλου μεταξύ των συνδέσεων προς τον πελάτη και προς την ανώτερη σύνδεση.

Αυτό το режим αλλάζει επίσης την ευθύνη ασφάλειας. Ο κεντρικός υπολογιστής Webship πρέπει να προστατεύει το ιδιωτικό κλειδί του πιστοποιητικού, τα κλειδιά συνεδρίας, τα αποκωδικοποιημένα δεδομένα αιτήσεων και απαντήσεων, την έξοδο παρατηρησιμότητας και οποιαδήποτε αποθηκευμένη αναπαράσταση. Εάν το επόμενο βήμα πρέπει να παραμείνει κρυπτογραφημένο, διαμορφώστε ξεχωριστά TLS upstream με τύπο· διαφορετικά, το HTTP upstream είναι σε καθαρό κείμενο.

Ο τερματισμός είναι το δεξιό όριο όταν αναμένεται το Webship να λειτουργεί ως άκρη που γνωρίζει εφαρμογές, και όχι μόνο ως κρυπτογραφημένος ενδιάμεσος διαμετακομιστής.

Τι διατηρεί η διέλευση

Με το tls_termination = false—το προεπιλεγμένο—Webship μεταφέρει κρυπτογραφημένη κίνηση TLS ή QUIC χωρίς να αποκρυπτογραφεί το αίτημα ή την απάντηση HTTP. Το απλό κείμενο της εφαρμογής και τα ενεργά κλειδιά συνεδρίας παραμένουν στην προέλευση.

Αυτό το μικρότερο όριο εμπιστοσύνης είναι πολύτιμο όταν τα πιστοποιητικά πρέπει να παραμείνουν στο επίπεδο της εφαρμογής, η πολιτική συμμόρφωσης απαγορεύει την αποκωδικοποίηση στην άκρη, ή μια ταυτότητα TLS συγκεκριμένης προέλευσης πρέπει να φτάσει στον πελάτη αναλλοίωτη. Επίσης, αφαιρεί την ανάλυση HTTP και την εφαρμογή πολιτικής από τη διαδρομή αναμετάδοσης.

Ο συμβιβασμός είναι αυστηρός: Webship δεν μπορεί να ελέγξει ό,τι δεν μπορεί να αποκρυπτογραφήσει. Δεν μπορεί να εφαρμόσει κανόνες HTTP WAF, να κατευθύνει βάσει διαδρομής, να επαναγράψει κεφαλίδες, να επιβάλει πολιτική API που γνωρίζει το περιεχόμενο του σώματος ή να συμπληρώσει αρχεία καταγραφής πρόσβασης πεδίων HTTP. Η προέλευση πρέπει να παρέχει όλα αυτά τα μέτρα ελέγχου από μόνη της.

Η μεταβίβαση λοιπόν δεν είναι «τερματισμός με λιγότερα χαρακτηριστικά». Είναι μια διαφορετική αρχιτεκτονική με διαφορετικό ιδιοκτήτη ασφάλειας.

Τα όρια που αφορούν συγκεκριμένο πρωτόκολλο έχουν σημασία

Για τους HTTP/1.1 TLS και HTTP/2 TLS, ο Webship ελέγχει το ClientHello μόνο αρκετά ώστε να επιλέξει τον ρυθμισμένο προορισμό TCP μέσω SNI. Κάθε domain διέλευσης χρειάζεται μια γενική διαδρομή path_prefix = "/" επειδή η πραγματική διαδρομή του αιτήματος παραμένει κρυπτογραφημένη. Ένας πελάτης χωρίς SNI γίνεται δεκτός μόνο όταν η διαμόρφωση έχει ένα domain.

Η προέλευση πρέπει να διαπραγματευτεί το ALPN του πελάτη και να υποστηρίξει το επιλεγμένο πρωτόκολλο. Webship δεν μπορεί να μετατρέψει έναν πελάτη HTTP/2 σε προέλευση HTTP/1.1 ενώ η συνεδρία TLS περνάει αμετάβλητη.

HTTP/3 χρησιμοποιεί QUIC μέσω UDP και έχει ένα αυστηρότερο όριο. Το Pass-through δεν μπορεί να δρομολογήσει με ασφάλεια βάσει κρυπτογραφημένης εξουσίας HTTP, οπότε κάθε διαμορφωμένη HTTP/3 διαδρομή πρέπει να επιλύει στην ίδια προέλευση IP-socket UDP. Webship απορρίπτει τα Unix sockets και πολλαπλές HTTP/3 προελεύσεις pass-through κατά την επικύρωση της διαμόρφωσης αντί να δρομολογεί ασαφώς σιωπηλά.

Το Cleartext HTTP/1.1 και το h2c δεν επηρεάζονται από το reverse_proxy.tls_termination. Η ρύθμιση ελέγχει μόνο το downstream HTTP/1.1 TLS, το HTTP/2 TLS και το HTTP/3 TLS.

Μετρημένη χωρητικότητα αιτήσεων

Το Webship 1.3.1 σημείο αναφοράς χωρητικότητας Debian μέτρησε ξεχωριστά τις δύο κρυπτογραφημένες λειτουργίες αντιστροφής proxy. Κάθε αποδεκτό δείγμα απαιτούσε μηδενικά σφάλματα HTTP, socket, πρωτοκόλλου, proxy, κύριας σφάλματος σελίδας και HTTP/3 απώλειας πακέτου.

| Λειτουργία reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Τερματισμός TLS | 123.344 RPS | 124.957 RPS | 131.529 RPS | | Διέλευση TLS | 203.950 RPS | 266.845 RPS | 167.010 RPS |

Η διέλευση με μικρή απόκριση έχει λιγότερη εργασία εφαρμογής να εκτελέσει: μεταβιβάζει κρυπτογραφημένα δεδομένα μεταφοράς αντί να τερματίζει το TLS, να αναλύει το HTTP, να αξιολογεί την πολιτική και να δημιουργεί ένα νέο ρεύμα TLS προς τα κάτω. Οι υψηλότεροι ρυθμοί αιτήσεων διέλευσης αντανακλούν αυτή τη στενότερη εργασία.

Αυτές οι σειρές δεν αντιπροσωπεύουν ταυτόσημα σύνολα λειτουργιών και δεν θα πρέπει να χρησιμοποιούνται για να υποστηρίξουν ότι μια αρχιτεκτονική ασφάλειας είναι παγκοσμίως καλύτερη. Η τερματισμός πληρώνει για δυνατότητες που κατανοούν το HTTP και που οι διελεύσεις εκ προθέσεως δεν μπορούν να παρέχουν.

Η μαζική ροή αλλάζει το αποτέλεσμα

Ο ίδιος δείκτης χρησιμοποιούσε ακριβώς σώμα απάντησης 99.943.778 bytes για τον πίνακα ροής 100 MB. Εδώ, η τερματισμός TLS παρείχε υψηλότερη μεσαία διαμετακόμιση φορτίου για όλα τα τρία πρωτόκολλα:

| Λειτουργία reverse-proxy | 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 |

Γιατί αλλάζει η κατεύθυνση; Σε λειτουργία τερματισμού, η προέλευση του benchmark στέλνει HTTP σε καθαρό κείμενο προς Webship, και Webship κατέχει τη βελτιστοποιημένη downstream μαζική διαδρομή. Μεγάλες απαντήσεις HTTP/1.1 και HTTP/2 μπορούν να χρησιμοποιούν προσαρμοστικό Linux kTLS και περιορισμένη στοχευμένη αποθήκευση μεταφοράς. Το HTTP/3 χρησιμοποιεί QUIC pacing, DPLPMTUD και ομαδοποίηση ανά αντιδραστήρα αντί για kTLS.

Σε λειτουργία διέλευσης, η προέλευση κατέχει το downstream TLS και το Webship μεταβιβάζει το προκύπτον κρυπτογραφημένο ρεύμα ή τα πακέτα QUIC. Αυτό διατηρεί το όριο TLS της προέλευσης, αλλά δεν μπορεί να χρησιμοποιήσει την διαδρομή μαζικής απόκρισης που γνωρίζει HTTP του Webship.

Η επταδειγματική HTTP/3 πιστοποίηση ελέγχηκε επίσης για σταθερότητα. Το τερματισμένο streaming έφτασε σε μέση τιμή 1.938,6 MiB/s με συντελεστή μεταβολής 2,12%· το pass-through έφτασε τα 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. Προσθέστε upstream 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—ή μία κοινή HTTP/3 προέλευση UDP—είναι επαρκής.
3. Η προέλευση παρέχει το απαραίτητο WAF, εξουσιοδότηση, καταγραφή, όρια σώματος και ελέγχους κατάχρησης.
4. Δεν απαιτείται cache ακμής, επανεγγραφή διαδρομής, πολιτική κεφαλίδας προώθησης ή μετάφραση πρωτοκόλλου HTTP.

Επιλέξτε τερματισμό όταν απαιτείται οποιοδήποτε από αυτά στο Webship:

1. Διαδρομή ανά κεντρικό υπολογιστή, διαδρομή ή μέθοδο.
2. Ελέγξτε αιτήματα με WAF ή API Shield.
3. Εφαρμόστε όρια σώματος, χρονικά όρια HTTP ή έλεγχο ταυτότητας άκρου.
4. Αποθηκεύστε προσωρινά τις απαντήσεις ή ξαναγράψτε τις κεφαλίδες HTTP.
5. Μεταφράστε μεταξύ των πρωτοκόλλων HTTP downstream και upstream.
6. Παρατηρήστε τα πεδία HTTP στα όρια του διακομιστή μεσολάβησης.

Όποια λειτουργία και αν επιλέξετε, ελέγξτε το SNI, το ALPN, την ταυτότητα του πιστοποιητικού, την ακύρωση από τον πελάτη, το ημι-κλείσιμο ανάντη και την ακεραιότητα της ακριβούς απόκρισης. Μετρήστε ξεχωριστά την ικανότητα αιτήσεων και τη ροή δεδομένων: η ταχύτερη λειτουργία για μια μικρή απόκριση δεν είναι απαραίτητα η ταχύτερη λειτουργία για ένα σώμα 100 MB.

Webship καθιστά το pass-through προεπιλεγμένο επειδή ένα proxy δεν πρέπει να διευρύνει σιωπηλά τα όρια εμπιστοσύνης του. Ο τερματισμός παραμένει μια ενεργή, σαφής λειτουργική επιλογή όταν η συμπεριφορά edge με γνώση HTTP αξίζει αυτή την ευθύνη.

Διαβάστε την πλήρη [τεκμηρίωση αντίστροφου proxy](/docs/1.3.1), συγκρίνετε τον αποδεκτό [πίνακα αναφοράς](/benchmarks), ή κατεβάστε το Webship από τα [Ληφθέντα](/downloads).

Πηγές και μέθοδος περιεχομένου

Οι τιμές απόδοσης είναι αποδεκτές διάμεσες από το Webship 1.3.1 ενοποιημένο benchmark δυναμικότητας Debian με ημερομηνία 11 Σεπτεμβρίου 2026· οι πύλες αποδοχής του απαιτούν μηδενικά σφάλματα πελάτη, HTTP, socket, πρωτοκόλλου, proxy, major-page-fault και HTTP/3 απώλειας πακέτων.