OpenVPN χωρίς πιστοποιητικό πελάτη: πολιτική διακομιστή, όχι προφίλ

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

Το προφίλ δεν είναι η πολιτική

Το Community OpenVPN 2.6 έρχεται με υποχρεωτικά πιστοποιητικά πελάτη, επειδή το verify-client-cert έχει από προεπιλογή την τιμή require. Η ρύθμιση σε none σταματά την απαίτηση πιστοποιητικού και παραδίδει την ταυτοποίηση πελάτη σε όποια διάταξη ονόματος χρήστη και κωδικού πρόσβασης εκτελεί ήδη ο διακομιστής. Οι παλαιότεροι οδηγοί καταφεύγουν στο client-cert-not-required, την παλαιότερη γραφή της ίδιας ιδέας, οπότε χρησιμοποιήστε την οδηγία που τεκμηριώνει η εγκατεστημένη έκδοσή σας. Σε κάθε περίπτωση η αλλαγή γίνεται στον διακομιστή, και κανένα προφίλ πελάτη δεν μπορεί να την εκτελέσει.

Το απόσπασμα παρακάτω είναι ολόκληρη η αλλαγή στην πλευρά του διακομιστή, και από μόνο του δεν είναι λειτουργική διαμόρφωση ταυτοποίησης. Το verify-client-cert none αφαιρεί την απαίτηση πιστοποιητικού, ενώ το username-as-common-name κάνει το όνομα λογαριασμού την ταυτότητα που βλέπουν οι μεταγενέστερες επιστροφές κλήσεων και τα αρχεία ανά πελάτη. Καμία από τις δύο γραμμές δεν ελέγχει κωδικό πρόσβασης, άρα πρέπει να υπάρχει ακόμη ένας επαληθευτής.

verify-client-cert none
username-as-common-name

Αυτός ο επαληθευτής είναι ένα πρόσθετο ή ένα σενάριο που οδηγείται από το auth-user-pass-verify, και πρέπει να βρίσκεται στη θέση του πριν σημαίνει κάτι οποιαδήποτε από τις παραπάνω γραμμές. Η αντίστροφη σειρά σας δίνει ένα παράθυρο στο οποίο ο διακομιστής δεν ζητά πιστοποιητικό και δεν ελέγχει λογαριασμό.

Τι εξακολουθεί να επαληθεύει τον διακομιστή

Η εγκατάλειψη του πιστοποιητικού πελάτη δεν σημαίνει εγκατάλειψη του TLS. Ο διακομιστής κρατά το πιστοποιητικό και το κλειδί του, και ο πελάτης κρατά την εμπιστοσύνη CA και τους ελέγχους ονόματος κεντρικού υπολογιστή που τον εμποδίζουν να μιλήσει με έναν απατεώνα. Η αφαίρεση του remote-cert-tls server ή του πακέτου CA επειδή ο πελάτης δεν έχει πια πιστοποιητικό είναι μια συχνή και σοβαρή παρερμηνεία, και η αναφορά 2.6 δηλώνει ρητά ότι οι δύο κατευθύνσεις είναι ανεξάρτητες. Η μία αποδεικνύει τον διακομιστή στον πελάτη· η άλλη αποδεικνύει τον πελάτη στον διακομιστή.

Ένα προφίλ μπορεί επίσης να φέρει μπλοκ tls-auth ή tls-crypt. Πρόκειται για κοινό κλειδί καναλιού ελέγχου με δικό του κύκλο διανομής και ανανέωσης, οπότε ένα αρχείο χωρίς γραμμές πιστοποιητικού ή κλειδιού δεν είναι αυτόματα ασφαλές για δημοσίευση. Αντιμετωπίστε το ως μυστικό μέχρι να το διαβάσετε.

Ένα αρχείο πιστοποιητικού που αντιγράφηκε από λειτουργικό προφίλ δεν αποδεικνύει τίποτα από μόνο του· η κατοχή σημαίνει ότι κρατάτε το ιδιωτικό κλειδί που του ταιριάζει, κάτι που ελέγχει μια εγκατάσταση με ταυτοποίηση πιστοποιητικού. Ένα αρχείο που περιέχει πιστοποιητικό δεν είναι αρχείο με το οποίο μπορείτε να ταυτοποιηθείτε.

Τι πρέπει να κάνει ο επαληθευτής

Με την απαίτηση πιστοποιητικού αφαιρεμένη, όλα στηρίζονται στον επαληθευτή: ένα πρόσθετο ή ένα σενάριο που οδηγείται από το auth-user-pass-verify. Πρέπει να απορρίπτει μη έγκυρα διαπιστευτήρια, να απορρίπτει απενεργοποιημένους ή μη επιλέξιμους λογαριασμούς και να αποτυγχάνει κλειστά όταν δεν μπορεί να φτάσει το backend του. Το username-as-common-name ενεργοποιείται συχνά παράλληλα, και αλλάζει την ταυτότητα που βλέπουν οι μεταγενέστερες επιστροφές κλήσεων και τα αρχεία διαμόρφωσης ανά πελάτη. Δεν επαληθεύει κωδικό πρόσβασης και δεν καθιστά επιλέξιμο έναν μη επιλέξιμο λογαριασμό. Είναι ξεχωριστές εργασίες, και η σύγχυσή τους είναι ο τρόπος με τον οποίο μια μετάβαση περνά τη δοκιμή της ευτυχισμένης διαδρομής και αποτυγχάνει στο πρώτο πραγματικό περιστατικό.

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

Αλλάξτε μαζί πολιτική, προφίλ και αντιστοίχιση

Συντονίστε τρία πράγματα: την οδηγία του διακομιστή, το προφίλ του πελάτη και την αντιστοίχιση ταυτότητας ανά πελάτη. Αλλάξτε τα χωριστά και οι πελάτες αποτυγχάνουν πριν την επαλήθευση, ή συνδέονται με όνομα που ο διαχειριστής δεν περίμενε, κάτι που είναι χειρότερο επειδή μοιάζει με επιτυχία. Μια σύνδεση που πετυχαίνει με λάθος ταυτότητα είναι δυσκολότερο να την προσέξεις από μια που αποτυγχάνει.

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

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