L2TP χωρίς IPsec σε Linux: xl2tpd, pppd και NAT

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

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

Τρία αρχεία μοιράζονται τη δουλειά

Το xl2tpd τερματίζει τη σύνδεση ελέγχου και παραδίδει κάθε συνεδρία σε έναν δαίμονα PPP, οπότε η διαμόρφωση μοιράζεται σε δύο προγράμματα που δεν διαβάζουν ποτέ τα αρχεία του ενός το άλλο. Ο ακροατής ζει στο /etc/xl2tpd/xl2tpd.conf, μέσα σε ένα τμήμα [lns default] που ονομάζει τη δεξαμενή διευθύνσεων με ip range, την πλευρά του διακομιστή με local ip και την παράδοση στο PPP με pppoptfile. Ενεργοποιήστε το require authentication = yes, αφήστε το length bit και το flow bit ενεργά και διαλέξτε μια δεξαμενή που τίποτα άλλο στον host δεν χρησιμοποιεί ήδη.

Η πολιτική PPP ανήκει όποιο αρχείο ονομάζει αυτή η επιλογή, συνήθως /etc/ppp/options.xl2tpd: auth, απορρίψεις για pap, chap και mschap, require-mschap-v2, MTU και MRU 1460, και μια διεύθυνση DNS που ο πελάτης μπορεί να φτάσει αφού ανέβει η ζεύξη. Τα διαπιστευτήρια είναι πάλι τρίτο αρχείο, /etc/ppp/chap-secrets, όπου το δεύτερο πεδίο πρέπει να ταιριάζει με το όνομα του τμήματος LNS και το τέταρτο μπορεί να καρφώσει μια συγκεκριμένη διεύθυνση από τη δεξαμενή.

Γιατί το τούνελ συνδέεται και μετά κολλά

Ένα πλαίσιο Ethernet 1500 byte δεν χωρά σε μια διαδρομή που ξοδεύει ήδη byte στις δικές της κεφαλίδες. Η εξωτερική κεφαλίδα IPv4 κοστίζει 20, το UDP 8 και η κεφαλίδα L2TP περίπου 12, αφήνοντας 1460 για το PPP και το φορτίο του. Το να διαφημίζεις αυτόν τον μικρότερο αριθμό στο PPP είναι αυτό που κρατά τα μεγάλα πακέτα από το να κατατμηθούν ή να πέσουν σιωπηλά κάπου στη μέση.

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

Μία θύρα μεταφέρει δύο συνομιλίες

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

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

Κάνοντας το τούνελ χρήσιμο: προώθηση και NAT

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

Στον διακομιστή, ενεργοποιήστε την προώθηση με sysctl -w net.ipv4.ip_forward=1, μεταφράστε τη δεξαμενή με iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, μετά δεχτείτε την εξερχόμενη κίνηση του τούνελ με κανόνα FORWARD για -i ppp0 -o eth0 και την κίνηση επιστροφής με τον κατοπτρικό κανόνα συν -m state --state RELATED,ESTABLISHED. Κάντε αυτούς τους κανόνες μόνιμους στις επανεκκινήσεις, γιατί ένας διακομιστής που επιστρέφει χωρίς αυτούς μοιάζει ακριβώς με χαλασμένη διαμόρφωση L2TP.

Το να φτάσετε στο δικό του LAN του διακομιστή είναι άλλη δουλειά: προσθέστε μια διαδρομή επιστροφής για τη δεξαμενή στον δρομολογητή του LAN ή proxy ARP στον διακομιστή. Το να κρύβετε τους πελάτες πίσω από NAT όταν κάτι μέσα στο LAN πρέπει να τους απευθύνεται άμεσα απλώς προγραμματίζει μια δεύτερη συνεδρία αποσφαλμάτωσης για αργότερα.

Τι δεν κάνει η γυμνή στοίβα και πώς να το επαληθεύσετε

Κανένα μέρος αυτής της στοίβας δεν κρυπτογραφεί τα πλαίσια PPP, και τίποτα σε αυτήν δεν πιστοποιεί το απομακρυσμένο άκρο ως τον διακομιστή που διαλέξατε πραγματικά. Το MS-CHAPv2 προστατεύει μεν την ανταλλαγή διαπιστευτηρίων από έναν ακροατή που μόνο παρακολουθεί, αλλά ένας επιτιθέμενος στη διαδρομή μπορεί ακόμη να επέμβει στη συνεδρία. Ο εγγενής πελάτης των Windows προσφέρει L2TP μόνο σε συνδυασμό με IPsec, οπότε υπολογίστε Linux, firmware δρομολογητών και πελάτες τρίτων ως ομότιμούς σας. Αντιμετωπίστε τη γυμνή διαμόρφωση ως διαγνωστικό σκαλί, ποτέ ως το σημείο για να σταματήσετε.

Επαληθεύστε με σταθερή σειρά: εκτελέστε το xl2tpd -D στο προσκήνιο, παρακολουθήστε το ημερολόγιο για το στάδιο PPP, διαβάστε τη διευθυντή που δόθηκε από το ip addr και στις δύο άκρες, μετά συλλάβετε το UDP 1701 για να επιβεβαιώσετε ότι τα δεδομένα ρέουν αφού ανέβει η συνεδρία. Αν και τα τέσσερα συμφωνούν και η κίνηση αποτυγχάνει ακόμη, το σφάλμα είναι στη δρομολόγηση, στο NAT ή στο MTU και όχι στο ίδιο το L2TP.