Ποιο στάδιο του VPN απέτυχε: IPsec, έλεγχος L2TP ή έλεγχος ταυτότητας PPP

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

Απαντήστε τέσσερις ερωτήσεις με σειρά

Επιβάλετε μια νέα προσπάθεια, γιατί μερικοί πελάτες εξακολουθούν να δείχνουν το προηγούμενο σφάλμα μέχρι να αποσυνδεθεί και να συνδεθεί ξανά το προφίλ. Έπειτα απαντήστε σε αυτό: υπήρχε συσχέτιση ασφαλείας IPsec, εμφανίστηκαν σύνδεση ελέγχου L2TP και κλήση, έφτασε το PPP σε ετυμηγορία ελέγχου ταυτότητας και έδωσε το IPCP διεύθυνση στον πελάτη; Το πρώτο όχι είναι το στάδιο που διορθώνετε. Ό,τι ακολουθεί είναι αδοκίμαστο, άρα ένα απορριφθέν όνομα χρήστη δεν αποδεικνύει τίποτα όταν δεν υπήρξε ποτέ συσχέτιση.

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

Όταν έχετε μόνο το στιγμιότυπο οθόνης του χρήστη, στηριχτείτε στον φθηνότερο διαχωρισμό: ένα λάθος προκοινόμενο κλειδί και ένα xl2tpd που δεν απαντά ποτέ παράγουν το ίδιο κείμενο στο παράθυρο των Windows, όμως το ένα χρειάζεται ένα μυστικό που αλλάζει και στα δύο άκρα και το άλλο έναν δαίμονα σε λειτουργία ή έναν κανόνα τείχους προστασίας στον ίδιο τον διακομιστή. Μια συσκευή στη μέση δεν μπορεί να ρίξει το εσωτερικό 1701 αφού το IPsec σε λειτουργία μεταφοράς το έχει τυλίξει, οπότε μην ψάχνετε φίλτρο διαδρομής που δεν υπάρχει.

Τι κατέχει πραγματικά κάθε επίπεδο

Το IPsec προστατεύει πακέτα μεταξύ των δύο ομοτίμων· το L2TP μεταφέρει μια συνεδρία PPP μέσα σε εκείνη την προστατευμένη διαδρομή, γι’ αυτό το RFC 3193 ορίζει λειτουργία μεταφοράς και όχι δικό του τούνελ. Η ετικέτα του πελάτη λέει L2TP, οπότε το τούνελ και η σύνδεση μοιάζουν με έναν μηχανισμό. Δεν είναι: η σύνδεση ελέγχου L2TP πιστοποιεί τα άκρα του τούνελ όπου μια ανάπτυξη το ενεργοποιεί, και το PPP πιστοποιεί χωριστά τον χρήστη με CHAP, PAP ή MS-CHAPv2 σύμφωνα με την πολιτική του διακομιστή.

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

Ούτε ο έλεγχος ταυτότητας είναι το τέλος του PPP. Αφού γίνει δεκτός ο χρήστης, το IPCP διαπραγματεύεται τη διεύθυνση του πελάτη και τις επιλογές DNS και WINS που ο διακομιστής είναι πρόθυμος να δώσει. Ένας πελάτης μπορεί να περάσει CHAP ή MS-CHAPv2 και να μείνει χωρίς διεύθυνση, που είναι βλάβη μέσα στο PPP και όχι πρόβλημα δρομολόγησης. Το απλό L2TP χωρίς IPsec παραμένει έγκυρο και απροστάτευτο, άρα μια επιτυχημένη σύνδεση δεν αποδεικνύει ποτέ ότι η κίνηση προστατεύεται· ελέγξτε τι επιβάλλει ο διακομιστής, όχι την ετικέτα του πελάτη.

Αποφασίστε από το πρώτο απόν στάδιο

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

Τρεις γραμμές αξίζουν προειδοποίηση. Η γραμμή 1701 είναι εκεί όπου συνήθως προσγειώνονται οι πελάτες Windows πίσω από NAT: η συσχέτιση ολοκληρώνεται, μετά δεν φτάνει τίποτα, και η ενσωμάτωση είναι η αιτία και όχι ένας κακός κωδικός. Η γραμμή IPCP είναι αυτή που διαβάζεται λανθασμένα ως πρόβλημα διαδρομής, γιατί τα Windows τυλίγουν την απούσα διεύθυνση στο σφάλμα 720 και το εικονίδιο της περιοχής ειδοποιήσεων λέει μόνο ότι η σύνδεση απέτυχε· αυτή η βλάβη βρίσκεται μετά τον έλεγχο ταυτότητας και πριν τη δρομολόγηση. Η τελευταία γραμμή δεν είναι καθόλου βλάβη IPsec, αν και το εικονίδιο λέει αποσυνδεδεμένο.

Εντολές που χωρίζουν τα επίπεδα

Σε διακομιστή Linux με strongSwan, το swanctl --list-sas απαριθμεί τις εγκατεστημένες συσχετίσεις με την ταυτότητα του ομοτίμου, και το ipsec statusall καλύπτει παλαιότερους οικοδεσπότες strongSwan και libreswan. Από κάτω, το ip xfrm state δείχνει τις πραγματικές συσχετίσεις του πυρήνα, ενώ το ss -lunp | grep 1701 αποδεικνύει πού είναι δεσμευμένο το xl2tpd. Εκτελέστε το xl2tpd -D στο προσκήνιο για να δείτε συνδέσεις ελέγχου και κλήσεις να εμφανίζονται, και ενεργοποιήστε την αποσφαλμάτωση του pppd στο /etc/ppp/options.xl2tpd για να δείτε τη μέθοδο που προσφέρεται και την απάντηση.

Όταν τα αρχεία καταγραφής δείξουν επιτυχή έλεγχο ταυτότητας, το επόμενο ερώτημα είναι αν ολοκληρώθηκε το IPCP. Ελέγξτε αν το ip range στην ενότητα [lns default] του /etc/xl2tpd/xl2tpd.conf έχει ακόμη ελεύθερες διευθύνσεις και αν το /etc/ppp/options.xl2tpd φέρει πράγματι ms-dns και ms-wins αν ο πελάτης τα περιμένει. Μια εξαντλημένη δεξαμενή και μια απούσα επιλογή DNS φαίνονται διαφορετικά στο καλώδιο: η πρώτη αφήνει τον πελάτη χωρίς διεύθυνση και με 720, η δεύτερη δίνει διεύθυνση αλλά κανέναν μετατροπέα, οπότε τα ονόματα αποτυγχάνουν ενώ τα ping σε ακατέργαστες διευθύνσεις δουλεύουν. Κανένα από τα δύο δεν επισκευάζεται με εκ νέου εισαγωγή του κωδικού.

Στον πελάτη, το πρόσθετο L2TP του NetworkManager γράφει τη συνομιλία του pppd στο ημερολόγιο, οπότε το journalctl -u NetworkManager -b συνήθως χωρίζει το τούνελ πάνω, έλεγχος ταυτότητας απορρίφθηκε από το κανένα τούνελ καθόλου. Στα Windows, το Get-VpnConnection αναφέρει τις πραγματικές ρυθμίσεις ελέγχου ταυτότητας του προφίλ, και τα συμβάντα RasClient στην περιοχή Application της Προβολής συμβάντων ονομάζουν το εξάρτημα που αποτυγχάνει. Όταν το παράθυρο διαλόγου είναι πολύ ασαφές, ενεργοποιήστε το netsh ras set tracing * enable.

Οι καταγραφές χρειάζονται μια προσοχή. Με IPsec σε λειτουργία μεταφοράς, το εσωτερικό UDP 1701 είναι κρυπτογραφημένο, οπότε μια καταγραφή στην εξωτερική διεπαφή δείχνει ESP, ή UDP 4500 υπό NAT-T, και καθόλου L2TP. Η απουσία 1701 σε μια καταγραφή είναι αναμενόμενη και δεν αποδεικνύει φραγμένη θύρα· παρακολουθήστε αν κινούνται οι μετρητές ESP ή 4500.

NAT, MTU και διαδρομές: πού σας παραπλανά η στοίβα

Το NAT σπάει υποθέσεις πριν πιστοποιηθεί οτιδήποτε. Το ESP είναι δικό του πρωτόκολλο IP, οπότε μια συσκευή μετάφρασης το απορρίπτει εκτός αν οι ομότιμοι ενσωματώσουν· αυτό παρέχει το UDP 4500. Σε διακομιστή Windows που βρίσκεται ο ίδιος πίσω από οικιακό δρομολογητή ή πύλη NAT cloud, το στάδιο IPsec αποτυγχάνει με σφάλμα 789 μέχρι να οριστεί το AssumeUDPEncapsulationContextOnSendRule σε 2 κάτω από το κλειδί PolicyAgent και να επανεκκινήσει το μηχάνημα, και η βλάβη παραμένει δυσδιάκριτη από κλειστή θύρα. Οι πελάτες πίσω από NAT είναι ευκολότεροι: με δημόσια διεύθυνση στον διακομιστή, το NAT-T στο UDP 4500 τους μεταφέρει και αυτή η τιμή δεν εμπλέκεται.

Όταν το PPP είναι πάνω, ένα MTU με μαύρη τρύπα μιμείται νεκρό τούνελ: μικρά πακέτα περνούν, μια χειραψία TLS ή η φόρτωση σελίδας κολλάει, και ο πελάτης μπορεί να δείχνει ακόμη συνδεδεμένος. Χαμηλώστε το MTU της διεπαφής ή σφίξτε το MSS στην πύλη πριν κατηγορήσετε τον διακομιστή. Η δρομολόγηση split-tunnel είναι ο άλλος απατεώνας· ένα υποδίκτυο που στέλνεται με λάθος μάσκα αφήνει το τούνελ υγιές και μια εφαρμογή απρόσιτη. Ένα ιδιωτικό όνομα κεντρικού υπολογιστή προσθέτει το δικό του βήμα: αν το ερώτημα φύγει μέσω του τοπικού μετατροπέα, το όνομα αποτυγχάνει να λυθεί πριν δοκιμαστεί οποιαδήποτε διαδρομή.

Λίστα ελέγχου πριν αγγίξετε διαπιστευτήρια

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

1. Επιβεβαιώστε ότι η συσχέτιση υπάρχει και στα δύο άκρα, αντιστοιχισμένη με την ταυτότητα του ομοτίμου και όχι με ετικέτα συνδεδεμένου.
2. Επιβεβαιώστε ότι το UDP 1701 φτάνει στο xl2tpd· μια συσχέτιση χωρίς κλήση είναι η βλάβη σας.
3. Διαβάστε την ετυμηγορία του PPP και, αν πιστοποίησε, το αποτέλεσμα του IPCP, πριν υποθέσετε ότι ο κωδικός είναι λάθος.
4. Μόνο τώρα εισαγάγετε ξανά τα διαπιστευτήρια στη μορφή που περιμένει ο διακομιστής, γιατί ένα πρόθεμα τομέα αλλάζει τον λογαριασμό.
5. Αν εξακολουθεί να αποτυγχάνει, καταγράψτε και τα δύο άκρα με ευθυγραμμισμένες χρονικές σημάνσεις και συγκρίνετε στάδιο προς στάδιο.

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