Το proxy_redirect δεν συνδέει το NGINX με τον host VPN σας
Το proxy_redirect ξαναγράφει κεφαλίδες σε απάντηση που έχει ήδη φτάσει· δεν επιλέγει ποτέ το upstream. Ελέγξτε το proxy_pass, τη διαδρομή προς το backend και μετά τις κεφαλίδες.
Το όνομα περιέχει τη λέξη redirect, οπότε κολλάει μέσα σε ένα block location όταν ένα backend πίσω από το VPN δεν είναι προσβάσιμο. Τίποτα δεν αλλάζει, και το προφανές συμπέρασμα είναι ότι η οδηγία είναι χαλασμένη ή χρειάζεται άλλη σύνταξη. Αυτό που συνέβη στην πραγματικότητα είναι απλούστερο και λιγότερο κολακευτικό: το proxy_redirect δρα σε μια απάντηση που έχει ήδη επιστρέψει, και σε αυτή την εγκατάσταση κανένα αίτημα δεν έφτασε ποτέ τόσο μακριά.
Δύο οδηγίες, δύο στιγμές σε ένα αίτημα
Ένα αίτημα HTTP μέσω αντίστροφου διακομιστή μεσολάβησης περνά από αρκετές αποφάσεις με σειρά, και οι δύο οδηγίες βρίσκονται στα αντίθετα άκρα αυτής της ακολουθίας. Η μία επιλέγει πού πηγαίνει το αίτημα. Η άλλη επεξεργάζεται ορισμένες κεφαλίδες στην απάντηση που επιστρέφει.
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
Αυτή η σειρά είναι όλη η απάντηση. Αν η δεύτερη γραμμή δεν εκτελεστεί ποτέ επειδή απέτυχε η πρώτη, η δεύτερη οδηγία δεν είναι λανθασμένα ρυθμισμένη, είναι απλώς μη προσβάσιμη. Όσο κι αν ξαναγράψετε τη δεύτερη γραμμή, η απάντηση που έπρεπε να επεξεργαστεί δεν θα δημιουργηθεί. Διαγνώστε από την πρώτη γραμμή προς τα έξω, και η μπερδεμένη συμπεριφορά ανάγεται σε μια διαδρομή που λείπει ή σε μια απορριφθείσα σύνδεση.
Η επιλογή του upstream ανήκει στο proxy_pass
Ας υποθέσουμε ότι το NGINX τρέχει σε δημόσιο host εισόδου και φτάνει μια εφαρμογή στη διεύθυνση 10.40.0.20:8080 μέσω του VPN του. Το τμήμα που επιλέγει αυτή την εφαρμογή μοιάζει έτσι, μέσα σε ένα υπάρχον block server:
location / {
proxy_pass http://10.40.0.20:8080;
}Χρησιμοποιήστε το πραγματικό σχήμα, τη διεύθυνση και τη θύρα, και αντιμετωπίστε το ως τμήμα και όχι ως εγκατάσταση. Ο host εισόδου πρέπει επίσης να κρατά τη διαδρομή VPN, μια επιτρεπόμενη διαδρομή προώθησης και λειτουργική επιστροφή κίνησης προς αυτή την υπηρεσία, γιατί ένας διακομιστής μεσολάβησης που φτάνει μια διεύθυνση στα χαρτιά χρειάζεται ακόμη τη συγκατάθεση του πυρήνα.
Η αναφορά της μονάδας proxy κρατά την επιλογή upstream χωριστά από την επανεγγραφή κεφαλίδων απάντησης και σημειώνει ότι μια τιμή proxy_pass που περιέχει URI αλλάζει τον τρόπο αντικατάστασης του αντίστοιχου προθέματος location. Η προσθήκη ή αφαίρεση τμημάτων διαδρομής χωρίς έλεγχο του URL που περιμένει η εφαρμογή είναι αξιόπιστος τρόπος να παραχθεί 404 που μοιάζει με αποτυχία δρομολόγησης.
Το proxy_redirect διορθώνει απαντήσεις που διαρρέουν ιδιωτική διεύθυνση
Μόλις ρέει η κίνηση, ένα backend μπορεί να απαντήσει με κεφαλίδα Location που ονομάζει την ιδιωτική του διεύθυνση. Ένα πρόγραμμα περιήγησης που ακολουθεί αυτή την κεφαλίδα φεύγει από το δημόσιο σημείο εισόδου και προσπαθεί να φτάσει κάτι που δεν μπορεί να επιλύσει. Μια σκόπιμα ρυθμισμένη επανεγγραφή απάντησης αντιστοιχίζει το ιδιωτικό URL στο δημόσιο:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Αντικαταστήστε και τις δύο πλευρές με πραγματικές τιμές. Κατανοήστε και το στενό πεδίο: το αντίστοιχο κείμενο των κεφαλίδων Location και Refresh ξαναγράφεται, ενώ τα URL που είναι ενσωματωμένα σε HTML, JavaScript ή αρχεία που κατεβάστηκαν δεν ξαναγράφονται.
Αν μια εφαρμογή χτίζει απόλυτους συνδέσμους παντού, η διαρκής λύση είναι η δική της ρύθμιση εξωτερικού URL, όχι ένας αυξανόμενος κατάλογος κανόνων επανεγγραφής στον διακομιστή μεσολάβησης. Η προσθήκη κανόνων μέχρι η έξοδος να φαίνεται σωστή παράγει ρύθμιση που αποτυγχάνει στην πρώτη σελίδα που δεν δοκίμασε κανείς. Μία σωστή ρύθμιση της εφαρμογής αντικαθιστά ολόκληρη τη συλλογή.
Τι δεν μπορεί να επισκευάσει η επανεγγραφή κεφαλίδας
Αρκετά γειτονικά προβλήματα μοιάζουν με προβλήματα ανακατεύθυνσης και δεν είναι. Η κεφαλίδα Host που στέλνεται προς τα πάνω μπορεί να χρειάζεται να ταιριάζει με τον εικονικό host του backend. Ένα TLS upstream μπορεί να χρειάζεται συγκεκριμένο όνομα διακομιστή και επαλήθευση πιστοποιητικού, και η επανεγγραφή μιας κεφαλίδας απάντησης δεν βοηθά σε κανένα από τα δύο.
Το πεδίο των cookies και τα χαρακτηριστικά τομέα ανήκουν στην εφαρμογή και τη ρύθμισή της. Ένας διακομιστής μεσολάβησης μπορεί όλη μέρα να πετά ή να ξαναγράφει κεφαλίδες και παρόλα αυτά να παράγει συνεδρία που αποτυγχάνει στο δεύτερο αίτημα, γιατί το cookie εκδόθηκε για host που το πρόγραμμα περιήγησης δεν επισκέφτηκε ποτέ. Αυτή η αποτυχία μοιάζει διακοπτόμενη, γι' αυτό επιβιώνει τόσο καιρό σε ουρά αιτημάτων. Η ανάγνωση του τομέα του cookie συνήθως τελειώνει την έρευνα σε ένα λεπτό.
Κρατήστε και τον έλεγχο ταυτότητας και την επιλογή backend περιορισμένα στην προβλεπόμενη εφαρμογή. Ένας δημόσιος αντίστροφος διακομιστής μεσολάβησης πρέπει να εκθέτει μία εφαρμογή μέσω του VPN του διακομιστή αντί να γίνεται μια γενική πύλη προς κάθε ιδιωτική διεύθυνση που μπορεί να φτάσει αυτός ο host. Ένα μόνο γενικό location που προωθεί ό,τι ζητά ο καλών μετατρέπει μία εκτεθειμένη υπηρεσία σε χάρτη του ιδιωτικού σας δικτύου. Ονομάστε το upstream ρητά και κρατήστε το εκεί.
Δοκιμάστε με τη σειρά που ταξιδεύει το αίτημα
Επιβεβαιώστε τρία πράγματα διαδοχικά: το NGINX επέλεξε το προβλεπόμενο location, ολοκλήρωσε ένα αίτημα προς το backend, και το πρόγραμμα περιήγησης ακολούθησε τυχόν μεταγενέστερη ανακατεύθυνση και φόρτωσε τους υποπόρους. Κάθε βήμα έχει τις δικές του γραμμές καταγραφής, και η ανάγνωσή τους με σειρά μετατρέπει ένα ασαφές 502 σε συγκεκριμένο εύρημα.
Η διάκριση που χρειάζεστε είναι ανάμεσα σε αποτυχημένη σύνδεση upstream και σε πρόγραμμα περιήγησης που στάλθηκε σε μη προσβάσιμο ιδιωτικό όνομα. Το πρώτο εμφανίζεται στο αρχείο σφαλμάτων του διακομιστή μεσολάβησης· το δεύτερο εμφανίζεται ως αίτημα που δεν φτάνει ποτέ, με το πρόγραμμα περιήγησης να παραπονιέται για host που δεν μπορεί να επιλύσει. Δύο διαφορετικά προβλήματα, δύο διαφορετικά αρχεία, και μόνο το ένα από αυτά αφορά καθόλου το proxy_redirect.