Αποδοχή σύνδεσης TLS passthrough στο περιβάλλον stream του NGINX

Η προώθηση κρυπτογραφημένων bytes χωρίς να κρατά ποτέ το πιστοποιητικό είναι αυτό που κάνει ένα relay TLS passthrough, και η διάταξη είναι βολική και κάπως μπερδεμένη ταυτόχρονα. Επειδή τίποτα δεν αποκρυπτογραφείται, δεν υπάρχει τίποτα σε μορφή HTTP για φιλτράρισμα, οπότε το συνηθισμένο location block και οι κανόνες πρόσβασής του δεν έχουν καμία αξία εδώ. Η απόφαση που έχει το NGINX αφορά την ίδια τη σύνδεση: ποιος peer του δικτύου χτύπησε και αν αυτός ο peer πρέπει να προωθηθεί καθόλου.

Η απόφαση ανήκει στο stream, όχι στο HTTP

Στο περιβάλλον stream το NGINX εργάζεται με συνεδρίες TCP. Βλέπει τη διεύθυνση peer της σύνδεσης και μπορεί να εφαρμόσει διατεταγμένους κανόνες allow και deny σε αυτήν πριν φτάσει οποιοδήποτε byte στο backend. Είναι πλήρης απόφαση αποδοχής και δεν απαιτεί ιδιωτικό κλειδί, πιστοποιητικό ή ανάλυση HTTP.

Αυτές οι τρεις γραμμές δεν αντικαθιστούν ποτέ η μία την άλλη. Η αντιγραφή μιας οδηγίας πρόσβασης HTTP στο αρχείο που αναφέρει τη θύρα 443 δεν αλλάζει τίποτα, γιατί ο διακομιστής stream δεν διαβάζει ποτέ το περιβάλλον http.

Αποδεχτείτε τη σύνδεση πριν την προωθήσετε

Υποθέστε μια υπάρχουσα εγκατάσταση με διαθέσιμα τα modules stream και stream-access, πελάτες VPN που κρατούν διευθύνσεις προέλευσης στο 10.90.0.0/24, και ένα backend στο 192.168.50.20:443 που ήδη σερβίρει την επιδιωκόμενη ταυτότητα HTTPS.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Διαβάστε το ως θραύσμα νέου listener, όχι ως άμεση αντικατάσταση μιας λειτουργικής διαμόρφωσης. Ελέγξτε πρώτα τους υπάρχοντες listeners και τα include, γιατί ένας δεύτερος listener σε θύρα που είναι ήδη δεσμευμένη αποτυγχάνει στο reload, όχι τη στιγμή του αιτήματος.

Προσέξτε τι λείπει: κανένα listen ... ssl, καμία οδηγία πιστοποιητικού. Το NGINX προωθεί τη κρυπτογραφημένη ροή και το backend τερματίζει το TLS και παρουσιάζει το πιστοποιητικό που επικυρώνει ο πελάτης. Ένας πελάτης που αποτυγχάνει στη allowlist παίρνει απόρριψη της συνεδρίας TCP, όχι σελίδα HTTP 403, και κάθε εργαλείο που περιμένει κωδικό κατάστασης θα αναφέρει κάτι άχρηστο.

Τι καλύπτει η allowlist και τι όχι

Αν το relay επιλέγει ήδη backends με βάση το όνομα διακομιστή, το ssl_preread και ένα map μπορούν να συνεχίσουν αυτή τη δουλειά, εφόσον το module είναι διαθέσιμο. Το όνομα εξακολουθεί να το παρέχει ο πελάτης, και τίποτα στην παρουσίαση ενός ονόματος δεν αποδεικνύει ότι ο πελάτης εντάχθηκε στο VPN.

Ο κανόνας του παραδείγματος καλύπτει ολόκληρο τον listener stream. Αυτό τον κάνει ακατάλληλο για ένα μόνο σημείο εισόδου που εξυπηρετεί μείγμα δημόσιων ιστότοπων και ιστότοπων μόνο για VPN, όπου θα χρειαζόταν εξαίρεση ανά όνομα· ξεχωριστοί listeners είναι συνήθως σαφέστεροι από μια πολιτική εξαρτημένη από όνομα που κανείς δεν μπορεί να διαβάσει.

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

Ποια διεύθυνση βλέπει πραγματικά το NGINX;

Ένας εξισορροπητής φόρτου, ένα άλλο proxy ή source NAT μπορούν να βάλουν έναν μεσολαβητή μπροστά από το NGINX, οπότε ο peer που βλέπει δεν είναι η εσωτερική διεύθυνση του πελάτη VPN. Εξετάστε την πραγματική διαδρομή πριν επιλέξετε πρόθεμα, γιατί μια allowlist γραμμένη για λάθος διεύθυνση ή επιτρέπει σε όλους πίσω από τον μεταφραστή ή σε κανέναν.

Το πρωτόκολλο PROXY και η διαχείριση πραγματικής IP είναι νόμιμες απαντήσεις και πρέπει να ρυθμίζονται μόνο για συμβατούς, ρητά έμπιστους αποστολείς. Και οι δύο μηχανισμοί πιστεύουν ό,τι λέει ο αποστολέας, και για αυτό ακριβώς η λίστα αποστολέων πρέπει να είναι σύντομη. Η εμπιστοσύνη σε κεφαλίδα ταυτότητας από οποιονδήποτε πελάτη του διαδικτύου δεν κάνει τις πληροφορίες προέλευσης ξανά αξιόπιστες· μετατρέπει μια σωστή άρνηση σε πλαστογραφημένη αποδοχή.

Δοκιμάστε και τα δύο αποτελέσματα πριν το reload

Επικυρώστε τη διαμόρφωση, κάντε reload και μετά δοκιμάστε δύο φορές: μια νέα επιτρεπόμενη συνεδρία που πρέπει να δουλέψει και μια απορριφθείσα που δεν πρέπει. Κρατήστε την κανονική επαλήθευση πιστοποιητικού backend στη επιτρεπόμενη δοκιμή, γιατί ένα relay που συνδέεται αλλά δεν μπορεί να επικυρώσει το backend έχει λύσει ένα πρόβλημα και έχει δημιουργήσει άλλο.

nginx -t
ss -tnp | grep ':443'

Ελέγξτε επίσης τη διαδρομή προς το backend και την απάντηση ξεχωριστά. Το να περάσει η allowlist αποδεικνύει μόνο ότι το NGINX δέχτηκε τη συνεδρία· δεν μπορεί να κάνει ένα μη προσβάσιμο backend να απαντήσει και δεν μπορεί να επισκευάσει μια διαδρομή επιστροφής που έλειπε πριν ξεκινήσετε.