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

Δύο διαπραγματεύσεις με ξεχωριστές λίστες προτάσεων

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

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

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

Ποια πεδία ανήκουν σε ποια πρόταση

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

FieldIKE SA proposalCHILD SA proposal
EncryptionRequiredRequired
IntegrityRequired unless AEADRequired unless AEAD
PRFRequiredNot present
DH groupRequiredOnly for PFS
ESNNot presentOptional

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

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

Πώς επιλέγεται μία πλήρης προσφορά

Κάθε πρόταση είναι ένα σύνολο, και ο απαντών αναζητά ένα σύνολο όπου κάθε απαιτούμενο πεδίο είναι αποδεκτό. Δύο λίστες μπορεί να περιέχουν και οι δύο AES και SHA-256 και παρ' όλα αυτά να μην έχουν καμία συμβατή καταχώριση, επειδή διαφέρει το μήκος κλειδιού, το PRF ή η ομάδα DH. Η σύγκριση γίνεται ανά πρόταση, όχι ανά αλγόριθμο.

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

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

Το AEAD αφαιρεί ένα πεδίο αντί να προσθέτει ένα

Τα AES-GCM και ChaCha20-Poly1305 επαληθεύουν και κρυπτογραφούν σε μία λειτουργία. Όταν επιλεγεί οποιοδήποτε από τα δύο για ESP, ο αλγόριθμος ακεραιότητας δεν διαπραγματεύεται χωριστά, γιατί η κατασκευή AEAD τον καλύπτει ήδη. Μια πρόταση που συνδυάζει AES-GCM με SHA-256 είναι επομένως περιττή στην καλύτερη περίπτωση και απορρίπτεται στη χειρότερη.

Το PRF παραμένει ξεχωριστό στην πλευρά του IKE, αφού παράγει κλειδιά για το κανάλι ελέγχου αντί να προστατεύει τα ωφέλιμα φορτία. Γι' αυτό μια πρόταση IKE μπορεί νόμιμα να συνδυάζει έναν κρυπταλγόριθμο AEAD με PRF και ομάδα DH, ενώ η αντίστοιχη πρόταση ESP απαριθμεί μόνο τον κρυπταλγόριθμο AEAD και την προαιρετική ομάδα PFS.

Το μήκος κλειδιού είναι μέρος του διακριτικού κρυπτογράφησης, οπότε τα AES-128-GCM και AES-256-GCM είναι διαφορετικές προσφορές. Ένα προφίλ αντιγραμμένο από οδηγό που υποθέτει κλειδιά 256-bit δεν θα ταιριάξει με τελικό σημείο ρυθμισμένο για 128-bit, ακόμη και αν και οι δύο γραμμές λένε AES-GCM. Δύο ομότιμοι μπορούν να συμφωνήσουν στην οικογένεια κρυπταλγορίθμων και παρ' όλα αυτά να απορρίψει ο ένας τον άλλον εξαιτίας του αριθμού μετά την παύλα.

Διαβάστε την εγκατεστημένη SA, όχι τη διαμόρφωση

Η διαμορφωμένη λίστα προτάσεων είναι μια προσφορά και η εγκατεστημένη SA είναι το αποτέλεσμα. Στο strongSwan και σε πυρήνα Linux, και οι δύο όψεις είναι διαθέσιμες:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas εκτυπώνει τους διαπραγματευμένους αλγορίθμους ανά SA, συμπεριλαμβανομένου του αν το CHILD χρησιμοποιεί AEAD. ip xfrm state δείχνει τι εγκατέστησε πραγματικά ο πυρήνας, και εκεί είναι το σημείο για να επιβεβαιώσετε ότι μια ανανέωση κλειδιών δεν έπεσε σε διαφορετικό σύνολο από αυτό που καταγράψατε.

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

Σχετικά άρθρα