IKEv2 στα Windows και στο FortiGate: τρεις ρυθμίσεις που ο κόσμος συγχωνεύει

Μια συμφωνία IKEv2 ανάμεσα σε πελάτη Windows και σε πύλη FortiGate συνεχίζει να αποτυγχάνει, και η αναζήτηση ενός αριθμού που δεν ταιριάζει παράγει μια μακρύτερη λίστα αριθμών. Η λίστα γίνεται διαχειρίσιμη μόνο όταν χωριστεί σε τρεις γραμμές που αποτυγχάνουν ανεξάρτητα: η ανταλλαγή κλειδιών που προστατεύει το IKE, η προστασία που εφαρμόζεται στο CHILD SA και η πιστοποίηση που αποδεικνύει ποια είναι κάθε πλευρά. Αριθμοί ομάδας εμφανίζονται σε δύο από αυτές τις γραμμές και σημαίνουν διαφορετικά πράγματα.

Τρεις γραμμές που αποτυγχάνουν ανεξάρτητα

Η πρώτη γραμμή είναι η ανταλλαγή κλειδιών μέσα στο ίδιο το IKE, που παράγει τα κλειδιά που προστατεύουν τη διαπραγμάτευση. Η δεύτερη είναι η πρόταση για το CHILD SA, που προστατεύει την κίνηση που μεταφέρει η σήραγγα. Η τρίτη είναι η πιστοποίηση, που αποφασίζει τι παρουσιάζει κάθε πλευρά και πώς το επικυρώνει η άλλη.

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

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

Τι ελέγχουν τα δύο πεδία των Windows

Τα Windows κρατούν δύο πεδία χωριστά: το DHGroup ρυθμίζει την ίδια την ανταλλαγή IKE, ενώ το PfsGroup ρυθμίζει την πολιτική IPsec που προστατεύει την κίνηση στη σήραγγα. Ανήκουν σε διαφορετικές φάσεις. Η σύγκριση ενός πεδίου IKE των Windows με μια τιμή φάσης 2 του FortiGate ελέγχει το λάθος ζεύγος, και οι αριθμοί μπορεί να ταιριάζουν ενώ η υποκείμενη ανταλλαγή εξακολουθεί να αποτυγχάνει.

Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA

Η δεύτερη και η τρίτη εντολή αναφέρουν τις ενώσεις ασφαλείας που υπάρχουν πραγματικά, και αυτό είναι το πιο κοντινό σε απάντηση που μπορεί να σας δώσει ένας πελάτης. Μια ένωση κύριας λειτουργίας χωρίς ένωση γρήγορης λειτουργίας είναι πρόβλημα CHILD SA, και είναι το σημάδι μιας ασυμφωνίας φάσης 2 και όχι ενός προβλήματος πιστοποιητικού.

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

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

Η πιο επίμονη λανθασμένη συμπερασματολογία σε αυτόν τον τομέα είναι ότι η επιλογή μιας ομάδας DH ελλειπτικής καμπύλης απαιτεί πιστοποιητικό ελλειπτικής καμπύλης. Μια ομάδα DH παρέχει υλικό ανταλλαγής κλειδιών· ο αλγόριθμος υπογραφής διαπραγματεύεται από το πλαίσιο πιστοποίησης, και οι δύο είναι ξεχωριστές αποφάσεις στο IKEv2.

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

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

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

Βάλτε κάθε ιδιωτικό κλειδί με τον πραγματικό του κάτοχο

Μια πύλη που παρουσιάζει το δικό της πιστοποιητικό χρειάζεται το ιδιωτικό κλειδί που ταιριάζει με αυτό. Ένας ομότιμος που επικυρώνει μια αλυσίδα χρειάζεται το πιστοποιητικό CA και συγκεκριμένα δεν χρειάζεται το κλειδί υπογραφής της CA. Η σύγχυση αυτών των τριών στοιχείων είναι ο τρόπος με τον οποίο ο κόσμος καταλήγει να εισάγει ένα ιδιωτικό κλειδί CA σε μια συσκευή VPN για να εμφανιστεί ένα πιστοποιητικό σε άλλη κατηγορία.

Στο FortiOS οι ρόλοι είναι διακριτοί: ένα τοπικό πιστοποιητικό με το κλειδί του, ένα απομακρυσμένο πιστοποιητικό που χρησιμοποιείται για την ταυτοποίηση ενός ομότιμου και μια καταχώριση απομακρυσμένης CA που εδραιώνει εμπιστοσύνη σε πιστοποιητικά που υπέγραψε αυτή η CA. Μια καταχώριση απομακρυσμένης CA χωρίς ιδιωτικό κλειδί δεν είναι ελλιπής· είναι σωστή για τον σκοπό της.

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

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