Μετάβαση από VPN βασισμένο σε PPP χωρίς να αντιγραφούν οι παραδοχές του

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

Βήμα 1: καταγράψτε τι παρέχει η παλιά σύνδεση

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

Για το L2TP/IPsec, διαχωρίστε ρητά τα δύο επίπεδα. Η ταυτότητα του ομοτίμου IPsec ταυτοποιεί τα μηχανήματα. Το PPP ταυτοποιεί τον χρήστη, συνήθως με CHAP ή MSCHAPv2.

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

Βήμα 2: σχεδιάστε την αντικατάσταση σκόπιμα

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

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

Βήμα 3: εφαρμόστε σταδιακά και επαληθεύστε και την άδεια και την άρνηση

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

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

Πριν μετακινήσετε την πρόσβαση διαχειριστή, επιβεβαιώστε ότι έχετε εξουσιοδοτημένη διαδρομή ανάκτησης που δεν εξαρτάται από το τούνελ που αλλάζετε.

Βήμα 4: αποσύρετε την παλιά ταυτότητα

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

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

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

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