NO_PROPOSAL_CHOSEN στο L2TP; Σαρώστε πρώτα την πύλη

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

Τι αποκλείει το μήνυμα

Η απόρριψη συμβαίνει στη βασική λειτουργία, πριν από οποιαδήποτε ανταλλαγή L2TP ή PPP, οπότε ούτε η σήραγγα ούτε η βάση δεδομένων χρηστών έχουν ερωτηθεί. Η φάση 1 διαπραγματεύεται κρυπτογράφηση, ακεραιότητα και μια ομάδα Diffie-Hellman. Η φάση 2 διαπραγματεύεται την πρόταση ESP για τα δεδομένα. Μια αποτυχία στη φάση 1 δεν διορθώνεται αλλάζοντας μια ρύθμιση PFS της φάσης 2, και μια ολοκληρωμένη συσχέτιση IKE δεν αποδεικνύει ότι η πρόταση ESP ταιριάζει.

Καταγράψτε το backend πριν επεξεργαστείτε τη σύνταξη: ipsec --version. Το libreswan και το strongSwan δέχονται διαφορετικές γραφές της πρότασης για τους ίδιους αλγορίθμους.

Στη συνέχεια διαβάστε την απόρριψη στο πλαίσιό της με journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Σαρώστε την πύλη για το σύνολο μετασχηματισμών της

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

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

Οι παλαιότερες συσκευές προσφέρουν συχνά 3DES, SHA1 και MODP1024, επειδή αυτές ήταν οι προεπιλογές όταν αποστελλόταν το προϊόν και κανείς δεν τις επανεξέτασε. Κρατήστε την ακατέργαστη έξοδο της σάρωσης, γιατί είναι η μόνη καταγραφή του τι πρόσφερε ο ομότιμος εκείνη την ημέρα. Αν αυτή είναι η ισχυρότερη διαθέσιμη επικάλυψη, η σωστή κλιμάκωση είναι προς τον ιδιοκτήτη της πύλης, όχι προς μια διαμόρφωση πελάτη που επανενεργοποιεί αδύναμη κρυπτογραφία για όλους.

Ταιριάξτε την επικάλυψη χωρίς να απενεργοποιήσετε την ασφάλεια

Εισαγάγετε μόνο τους μετασχηματισμούς που εμφανίζονται και στη σάρωση και στην πολιτική σας. Το παρακάτω παράδειγμα αντικατοπτρίζει μια πύλη που προσφέρει 3DES, SHA1 και MODP1024 στη φάση 1. Προσέξτε την επιφύλαξη για το backend: το libreswan 4.x δεν μεταγλωττίζει την ομάδα modp1024, επομένως αυτό ισχύει για το strongSwan ή για μια έκδοση libreswan με υποστήριξη DH2. Επαληθεύστε την έκδοση πριν συμπεράνετε ότι ο πελάτης είναι χαλασμένος.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

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

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

Το NetworkManager-l2tp ξεκινά τη δική του παρουσία xl2tpd. Αν η υπηρεσία συστήματος κατέχει ήδη τη θύρα UDP 1701, ο πελάτης καταφεύγει σε μια εφήμερη θύρα προέλευσης, κάτι που επιτρέπει το RFC 3193 και ορισμένοι διακομιστές απορρίπτουν σιωπηλά. Ελέγξτε τον κάτοχο της υποδοχής πριν από την επόμενη προσπάθεια.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

Τα παλιά παραγόμενα μυστικά είναι μια άλλη αθόρυβη αιτία. Αρχεία κάτω από /etc/ipsec.d/ που ονομάζονται για μια παλιά σύνδεση μπορεί να επιβιώσουν του προφίλ που τα δημιούργησε, οπότε αφαιρέστε όσα δεν αναφέρονται πουθενά και δοκιμάστε ξανά.

Τέλος, ελέγξτε από πού προήλθε η συμβουλή. Ένα ipsec.conf γραμμένο για IKEv1 XAuth περιγράφει άλλο τύπο VPN, και η πρότασή του δεν είναι η μόνη γραμμή που θα είναι λάθος σε ένα προφίλ L2TP. Καταγράψτε το σύνολο μετασχηματισμών που εισαγάγατε δίπλα στο προφίλ, ώστε το επόμενο άτομο να μην επαναλάβει τον έλεγχο.