Γιατί ένα 403 από ιστότοπο VPN δεν είναι αποτυχία του proxy

Οι χρήστες αποσυνδέουν το VPN, συναντούν ένα 403 σε έναν εσωτερικό ιστότοπο και αναφέρουν ότι το proxy είναι χαλασμένο. Τρία ξεχωριστά πράγματα μπορούν να παράγουν αυτή τη σελίδα: η προέλευση απέρριψε το αίτημα, το μπροστινό proxy αρνήθηκε να ανοίξει τη σήραγγα ή το proxy ζήτησε τα δικά του διαπιστευτήρια. Κάθε ένα από αυτά είναι σωστή απάντηση σε διαφορετική ερώτηση, και η ισοπέδωσή τους σε μία γενική σελίδα αποτυχίας καταστρέφει τη μόνη απόδειξη που έχετε. Ταξινομήστε την απόρριψη κατά το στοιχείο που την παρήγαγε και μετά συγκρίνετε τη διαδρομή δικτύου που χρησιμοποιεί στην πραγματικότητα κάθε στοιχείο.

Ονομάστε το στοιχείο που παρήγαγε το 403

Ένας κωδικός κατάστασης HTTP ανήκει στο μέρος που τον έστειλε. Όταν η προέλευση επιστρέφει 403, έχει αναλύσει το αίτημα και έχει αποφασίσει ότι ο καλών μπορεί να μην έχει τον πόρο, κάτι που είναι απάντηση εξουσιοδότησης και όχι πρόβλημα μεταφοράς. Όταν ένα μπροστινό proxy απαντά 403 σε ένα CONNECT, αρνήθηκε να χτίσει καθόλου τη σήραγγα και τίποτα πιο πάνω δεν ήρθε ποτέ σε επαφή. Όταν απαντά 407, θέλει τα δικά του διαπιστευτήρια, που δεν έχουν καμία σχέση με τη σύνδεση της εφαρμογής.

Το RFC 9110 ορίζει αυτούς τους ρόλους, συμπεριλαμβανομένης της πρόκλησης που αφορά το proxy. Διαβάστε την κατάσταση της ίδιας της απάντησης και οποιαδήποτε κεφαλίδα Proxy-Authenticate πριν διαβάσετε το σώμα, γιατί μια φιλική σελίδα σφάλματος HTML συνήθως κρύβει ποιο στοιχείο την έγραψε.

Τι κρύβει μια σήραγγα CONNECT από έναν αναμεταδότη byte

Μόλις ένα proxy επιστρέψει 200 σε CONNECT, αναμεταδίδει byte και το πρόγραμμα περιήγησης κρατά τη δική του συνεδρία TLS με την προέλευση. Ένα proxy που αναμεταδίδει byte επομένως δεν μπορεί να διαβάσει το κρυπτογραφημένο 403 μέσα σε αυτή τη συνεδρία και δεν γίνεται ποτέ ο συγγραφέας της απόρριψης. Μια άρνηση πριν ανοίξει η σήραγγα είναι ένα εντελώς διαφορετικό γεγονός, που παράγεται ένα επίπεδο πιο κάτω.

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

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

Συγκρίνετε τη διαδρομή εξόδου του proxy με τη διεύθυνση σήραγγας του προγράμματος περιήγησης

Ένα πρόγραμμα περιήγησης συνδεδεμένο σε VPN δεν μετακινεί αυτόματα έναν ξεχωριστό διακομιστή proxy σε αυτή τη σήραγγα. Η προέλευση βλέπει τη διεύθυνση εξόδου του proxy, και αν το proxy εξακολουθεί να βγαίνει από την τοπική προεπιλεγμένη διαδρομή, ο προστατευμένος ιστότοπος βλέπει μια διεύθυνση στην οποία ποτέ δεν είχε ρυθμιστεί να έχει εμπιστοσύνη. Η εσωτερική διεύθυνση VPN στον φορητό υπολογιστή είναι αόρατη σε αυτή την προέλευση. Αυτός είναι ο πιο συνηθισμένος λόγος που μια λειτουργική σήραγγα εξακολουθεί να δίνει 403 από έναν ιστότοπο που συμπεριφέρεται σωστά για όλους τους άλλους.

Δοκιμάστε τις δύο διαδρομές χωριστά ώστε οι διευθύνσεις να μην μπορούν να μπερδευτούν.

curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/private

Το πρώτο αίτημα δείχνει τι απαντά η προέλευση για τη δική σας διεύθυνση, το δεύτερο δείχνει τι απαντά για του proxy. Ένα ταιριαστό ζεύγος 403 δείχνει τους κανόνες εξουσιοδότησης της προέλευσης· ένα 200 που ακολουθείται από 403 δείχνει τη διαδρομή του proxy. Ρωτήστε τον ιδιοκτήτη της προέλευσης ποιες διευθύνσεις προέλευσης δέχεται στην πραγματικότητα το σύνολο κανόνων αντί να υποθέσετε ότι η δεξαμενή VPN περιλαμβάνεται.

Δοκιμάστε κάθε όριο με ένα αίτημα που το απομονώνει

Απομονώστε το επίπεδο του proxy ζητώντας του κάτι που δεν μπορεί να αρνηθεί για λόγους εφαρμογής. Ένα CONNECT σε έναν κεντρικό υπολογιστή που το proxy επιτρέπεται να φτάσει, με την έξοδο να απορρίπτεται, σας λέει αν η είσοδος στη σήραγγα λειτουργεί καθόλου.

curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'

Αν αυτό εκτυπώσει 200 για το CONNECT και μετά μια χειραψία TLS, η είσοδος του proxy είναι εντάξει και το μεταγενέστερο 403 ήρθε από την προέλευση. Αν εκτυπώσει 407, δώστε διαπιστευτήρια proxy με --proxy-user και επαναλάβετε πριν βγάλετε οποιοδήποτε συμπέρασμα για τον ιστότοπο. Αν εκτυπώσει 403 στη γραμμή CONNECT, η ίδια η λίστα επιτρεπόμενων του proxy είναι το όριο που πρέπει να εξεταστεί και η εφαρμογή δεν εμπλέκεται.

Κρατήστε τα διαπιστευτήρια έξω από το ιστορικό του κελύφους και έξω από επικολλημένες απομαγνητοφωνήσεις. Ένας κωδικός πρόσβασης proxy που πληκτρολογείται σε γραμμή εντολών είναι ορατός σε άλλους τοπικούς χρήστες, και ένα καταγεγραμμένο ίχνος CONNECT με διαπιστευτήρια είναι χειρότερο από καθόλου ίχνος.

Κρατήστε την ετυμηγορία αναγνώσιμη αντί να ξαναγράψετε τη σελίδα

Μόλις μάθετε ποιο στοιχείο αρνήθηκε, διατηρήστε αυτή την απάντηση. Ένα αντίστροφο proxy που μετονομάζει ένα 403 της προέλευσης σε χρονικό όριο 504, ή το αντικαθιστά με σελίδα επιτυχίας, κρύβει μια απόφαση εξουσιοδότησης πίσω από μια ιστορία διαθεσιμότητας και στέλνει τον επόμενο ανταποκριτή στη λάθος ομάδα. Οι προσαρμοσμένες σελίδες σφάλματος είναι καλές όταν διατηρούν την κατάσταση και προσθέτουν πλαίσιο.

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

Ολοκληρώστε με μια γραπτή ετυμηγορία που ονομάζει το στοιχείο, την κατάσταση που παρήγαγε και τη διεύθυνση προέλευσης που είδε η προέλευση. Καταγράψτε το ακριβές αίτημα, τις ισχύουσες ρυθμίσεις proxy και την ώρα, ώστε η επόμενη αναφορά να μπορεί να αντιπαραβληθεί με τα ίδια στοιχεία αντί να ξαναεξαχθεί από τη μνήμη. Αυτή η καταγραφή απαντά στην επόμενη αναφορά σε δευτερόλεπτα και σταματά το ίδιο 403 από το να διαγνωστεί ξανά ως διακοπή VPN.