Γιατί το PPP CHAP από μόνο του δεν αρκεί για μια απαίτηση MPPE

Ένα προφίλ PPTP που επιμένει στην κρυπτογράφηση συνήθως αποτυγχάνει στο ίδιο σημείο: το PPP συμφωνεί σε μια ανταλλαγή ταυτοποίησης που δεν παράγει ποτέ το κλειδοϋλικό που χρειάζεται το MPPE. Η σήραγγα φαίνεται μισοζωντανή, ο κωδικός πρόσβασης γίνεται δεκτός και η ζεύξη πέφτει πριν περάσει από αυτήν οποιαδήποτε κίνηση. Το να φτάνεις στο αναπτυσσόμενο μενού CHAP μέχρι να συνδεθεί κάτι κρύβει το πραγματικό ελάττωμα, και αυτό είναι ένα συμβόλαιο ανάμεσα στη μέθοδο ταυτοποίησης και την πολιτική προστασίας. Οι έλεγχοι παρακάτω είναι διατεταγμένοι ώστε ο καθένας να αποκλείει μια φθηνότερη αιτία από τον επόμενο.

Δύο διαπραγματεύσεις τρέχουν μέσα σε μία σύνδεση PPTP

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

Το απλό CHAP είναι η ανταλλαγή πρόκλησης-απόκρισης στο RFC 1994, χτισμένη σε ένα κοινό μυστικό και τίποτα άλλο. Το MS-CHAPv2 είναι διαφορετική ανταλλαγή με διαφορετικά μηνύματα και διαφορετική έξοδο, τυποποιημένη στο RFC 2759. Η κοινή λέξη στα δύο ονόματα είναι το μόνο που έχουν κοινό στο καλώδιο. Κανένα από τα δύο ονόματα δεν λέει τι παράγει η ανταλλαγή, και αυτό είναι το μόνο μέρος που μετράει.

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

Ταιριάξτε την απαιτούμενη μέθοδο με τα κλειδιά που μπορεί να παράγει

Τα κλειδιά MPPE δεν είναι ιδιότητα του PPP γενικά. Για την οικογένεια Microsoft CHAP η εξαγωγή ορίζεται στο RFC 3079, και παίρνει ως είσοδο την έξοδο μιας ανταλλαγής MS-CHAP και όχι ένα κοινό μυστικό. Οι μέθοδοι EAP φτάνουν στο ίδιο σημείο από άλλη διαδρομή, με τον διακομιστή ταυτοποίησης να επιστρέφει τα κλειδιά ως ιδιότητες MS-MPPE-Recv-Key και MS-MPPE-Send-Key. Το απλό CHAP δεν εμφανίζεται σε καμία από τις δύο διαδρομές, και αυτός είναι όλος ο λόγος που υπάρχει η αναντιστοιχία.

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

Ο κανόνας που προκύπτει είναι σύντομος: αν το προφίλ απαιτεί MPPE, η μέθοδος πρέπει να είναι παραλλαγή MS-CHAP ή μέθοδος EAP της οποίας τα κλειδιά επιστρέφει ο διακομιστής. Η απόρριψη μόνο του MS-CHAPv2 δεν το επιβάλλει, γιατί και το MS-CHAPv1 εξάγει κλειδιά και παραμένει διαθέσιμο εκτός αν απορριφθεί χωριστά· η απόρριψη και των δύο αφήνει το απλό CHAP και το PAP, που δεν εξάγουν τίποτα και καθιστούν την απαίτηση ανεκπλήρωτη. Ονομάστε ρητά την αποδεκτή μέθοδο αντί να απαριθμείτε αυτές που δεν σας αρέσουν. Το να εγκαταλείψετε την απαίτηση κρυπτογράφησης για να συνδεθεί ένας πελάτης είναι υποβάθμιση, όχι επισκευή.

Διαβάστε τις επιλογές του διακομιστή πριν επεξεργαστείτε έναν πελάτη

Οι περισσότερες από αυτές τις αναντιστοιχίες είναι ορατές στον διακομιστή σε δύο αρχεία, και το διάβασμά τους κοστίζει λιγότερο από την ανακατασκευή ενός πελάτη. Σε ένα τελικό σημείο PPTP Linux οι σχετικές ρυθμίσεις ζουν στο αρχείο επιλογών του pppd που περνά το pptpd. Εκτελέστε το στον διακομιστή, όχι από οθόνη κατάστασης πελάτη. Ξεκινήστε με τις γραμμές που απαιτούν, απορρίπτουν ή ονομάζουν έναν τρόπο προστασίας:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

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

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

Εντοπίστε την αποτυχία κατά φάση PPP

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

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

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

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

Σχεδιάστε την έξοδο πριν απενεργοποιηθεί το παλιό τελικό σημείο

Το MPPE είναι ένας ιστορικός μηχανισμός προστασίας ζεύξης, και η παρουσία του δεν κάνει το PPTP λογική επιλογή για μια νέα ανάπτυξη. Η τρέχουσα καθοδήγηση της Microsoft συμβουλεύει ήδη κατά του PPTP και κατά του L2TP/IPsec με προκοινόμενο κλειδί για νέες αναπτύξεις απομακρυσμένης πρόσβασης. Το να κρατάτε ζωντανό ένα παλιό τελικό σημείο είναι απόφαση για μια υπάρχουσα υπηρεσία, όχι πρότυπο για την επόμενη.

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

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