Πώς η υβριδική πιστοποίηση του IKEv1 αντιστοιχεί στην πιστοποίηση χρηστών του IKEv2

Κάθε παλιό προφίλ VPN που ζητά πρώτα πιστοποιητικό διακομιστή και μετά όνομα χρήστη κουβαλά δύο γεγονότα πιστοποίησης σε μία ανταλλαγή, και αυτή η μορφή επιβιώνει του πρωτοκόλλου που την εισήγαγε. Η υβριδική λειτουργία του IKEv1 χτίστηκε ακριβώς γι' αυτό: η πύλη αποδεικνύεται με δημόσιο κλειδί και ο χρήστης αποδεικνύεται αργότερα μέσω XAuth. Το IKEv2 εκφράζει την ίδια ιδέα δύο βημάτων με άλλο μηχανισμό, και σε αυτές τις διαφορές αποτυγχάνουν οι μεταβάσεις. Κανένας αριθμός έκδοσης δεν μετατρέπει το ένα στο άλλο, και η αντιγραφή των παλιών ονομάτων επιλογών σε νέο προφίλ δίνει πελάτη που διαπραγματεύεται και μετά δεν πιστοποιεί τίποτα.

Τι έκανε η υβριδική λειτουργία μέσα στο IKEv1

Σε υβριδικό προφίλ ο αποκρινόμενος υπογράφει την ανταλλαγή της πρώτης φάσης με το πιστοποιητικό του, ενώ ο εκκινών σκόπιμα δεν παρουσιάζει κανένα. Η απόδειξη ταυτότητας είναι επομένως ασύμμετρη, και αυτό επέτρεψε σε μια πύλη να κρατήσει το υπάρχον PKI ενώ οι χρήστες κρατούσαν τους κωδικούς καταλόγου. Όταν ολοκληρωθεί η πρώτη φάση, το XAuth εκτελείται ως αίτημα και απάντηση που μεταφέρουν τα χαρακτηριστικά ονόματος χρήστη και κωδικού μέσα στο πλέον κρυπτογραφημένο κανάλι ISAKMP.

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

Πώς το IKEv2 φτάνει στις ίδιες δύο αποδείξεις

Το IKEv2 μοιράζει τη δουλειά ανάμεσα στο IKE_SA_INIT και το IKE_AUTH. Η πρώτη ανταλλαγή συμφωνεί προτάσεις και κλειδιά χωρίς καθόλου ταυτότητες· η δεύτερη μεταφέρει IDi, IDr και τα ωφέλιμα φορτία AUTH. Υπό EAP το πρώτο φορτίο AUTH του εκκινούντος βγαίνει κενό, ο αποκρινόμενος πιστοποιείται πρώτος με το πιστοποιητικό και την υπογραφή του, και μετά η συνομιλία EAP τρέχει μέσα στα μηνύματα IKE_AUTH.

Ο μηχανισμός που το κάνει ασφαλές είναι το υλικό κλειδιού. Μια επιτυχημένη μέθοδος EAP εξάγει κλειδί συνεδρίας, και το τελικό φορτίο AUTH του εκκινούντος υπολογίζεται από αυτό, ώστε η απόδειξη του χρήστη και τα κλειδιά της σήραγγας να είναι δεμένα. Το XAuth δεν έχει αντίστοιχο: τα χαρακτηριστικά του φτάνουν μετά την πρώτη φάση και δεν συνεισφέρουν τίποτα στα κλειδιά. Ακριβώς αυτό το κενό σχεδιάστηκε να κλείσει το πλαίσιο του IKEv2, και γι' αυτό μια λειτουργική σύνδεση IKEv2 επικυρώνει το πιστοποιητικό του διακομιστή πριν ζητήσει οτιδήποτε.

Αυτή η σειρά είναι και χρήσιμη διάγνωση. Όταν ένας πελάτης παραπονιέται για διαπιστευτήρια πριν σας δείξει πιστοποιητικό, δεν κάνει καθόλου ανταλλαγή EAP του IKEv2.

Κρατήστε τρεις ταυτότητες ξεχωριστές

Μια μετάβαση πάει στραβά όταν τρεις ταυτότητες καταρρέουν σε ένα πεδίο. Υπάρχει η ταυτότητα της πύλης που επικυρώνει ο πελάτης, συνήθως όνομα DNS στο subject ή στο SAN του πιστοποιητικού. Υπάρχει η ταυτότητα χρήστη που παρουσιάζεται στο EAP, ίσως σύνδεση τομέα, διεύθυνση ή ρητή συμβολοσειρά ταυτότητας EAP. Και υπάρχει η πηγή εξουσιοδότησης που αντιστοιχίζει αυτόν τον χρήστη σε δίκτυα και διαδρομές.

Η σύνταξη swanctl του strongSwan κάνει τον διαχωρισμό ορατό: η σύνδεση ορίζει remote { auth = pubkey } για την πύλη και local { auth = eap-mschapv2 } για τον χρήστη, με την ταυτότητα EAP να μεταφέρεται χωριστά.

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

Χαρτογραφήστε τις επιλογές και μετά περιμένετε τις παγίδες

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

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

Οι επιλογείς κίνησης αξίζουν δική τους προειδοποίηση. Το IKEv1 εξέφραζε την ενδιαφέρουσα κίνηση μέσω proxy ID δεμένων με ανταλλαγή quick mode, ενώ το IKEv2 διαπραγματεύεται τους επιλογείς κατά το IKE_AUTH και ο αποκρινόμενος μπορεί να τους στενέψει. Μια ασυμφωνία παράγει ένα IKE SA σε κατάσταση established χωρίς child SA, το οποίο μερικοί πελάτες δείχνουν ευχαρίστως ως συνδεδεμένο.

Αντιμετωπίστε την παλιά σύνδεση ως σύνορο

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

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

Γράψτε τέσσερα πράγματα πριν αποσύρετε το παλιό προφίλ: τη μέθοδο EAP, τη συμβολοσειρά ταυτότητας, την πηγή εξουσιοδότησης και την ημερομηνία που τελειώνει η υποστήριξη.