Μύθοι για το MTU στο VPN: γιατί συρρικνώνονται τα πακέτα σας και πού πάει ο χώρος

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

Δύο μύθοι προκαλούν τα περισσότερα από αυτά. Ο πρώτος είναι ότι το MTU της διεπαφής της σήραγγας είναι το MTU της διαδρομής. Ο δεύτερος είναι ότι η ενθυλάκωση κοστίζει «μία κεφαλίδα» και ότι το PPPoE δεν κοστίζει τίποτα που αξίζει να μετρηθεί. Και οι δύο είναι λανθασμένοι με τρόπους που κάνουν τον αριθμό που επιλέγετε να φαίνεται αυθαίρετος, ενώ στην πραγματικότητα καθορίζεται.

Μύθος πρώτος: το MTU της σήραγγας είναι το MTU της διαδρομής

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

Η ανακάλυψη MTU της διαδρομής υπάρχει για να συμβιβάσει τα δύο και εξαρτάται από ανατροφοδότηση. Στο IPv4, ένας δρομολογητής που δεν μπορεί να προωθήσει πακέτο πλήρους μεγέθους πρέπει να στέλνει μήνυμα ICMP «fragmentation needed» και ο αποστολέας μειώνει την εκτίμησή του. Στο IPv6, το αντίστοιχο είναι μήνυμα Packet Too Big και οι δρομολογητές δεν κατατμίζουν καθόλου στη διέλευση. Όταν αυτή η ανατροφοδότηση φιλτράρεται, ο αποστολέας συνεχίζει να παράγει πακέτα που η διαδρομή δεν μπορεί να μεταφέρει, και τίποτα δεν του λέει γιατί.

Μύθος δεύτερος: η ενθυλάκωση κοστίζει μία κεφαλίδα

Μετρήστε ειλικρινά τα εξωτερικά στρώματα. Μια εξωτερική κεφαλίδα IP είναι 20 byte στο IPv4 ή 40 στο IPv6. Η ενθυλάκωση UDP για διέλευση NAT προσθέτει 8. Το πρωτόκολλο της σήραγγας προσθέτει τη δική του κεφαλίδα, ένα διάνυσμα αρχικοποίησης ή nonce, γέμισμα μέχρι το όριο μπλοκ ή ευθυγράμμισης του κρυπταλγορίθμου, έναν επίλογο και μια τιμή ελέγχου ακεραιότητας. Ανάλογα με το πρωτόκολλο και τον αλγόριθμο, το σύνολο φτάνει άνετα τις δεκάδες byte πριν καν αρχίσει το εσωτερικό πακέτο.

Έπειτα αφαιρέστε ξανά τις κεφαλίδες του ίδιου του εσωτερικού πακέτου. Ένα τμήμα TCP μέσα στη σήραγγα φέρει τη δική του κεφαλίδα IP 20 byte και κεφαλίδα TCP 20 byte, και το MSS του TCP προκύπτει από το MTU, όχι από το ονομαστικό ωφέλιμο φορτίο της σήραγγας. Γι' αυτό το ping με μικρότερο ωφέλιμο φορτίο μπορεί να πετύχει ενώ μια μεταφορά αρχείου κολλάει: τα εργαλεία δοκιμάζουν διαφορετικά πράγματα και μόνο ένα από αυτά ασκεί τμήμα TCP πλήρους μεγέθους.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Η πρώτη εντολή αναφέρει το ρυθμισμένο MTU της σήραγγας. Οι δύο δοκιμές στέλνουν ωφέλιμο φορτίο 1472 byte, που με 28 byte κεφαλίδων IPv4 και ICMP είναι πακέτο 1500 byte, και μετά ένα μικρότερο. Αν η μεγάλη δοκιμή αποτύχει εντελώς και η μικρή πετύχει, έχετε βλάβη που εξαρτάται από το μέγεθος και όχι γενικό πρόβλημα δρομολόγησης.

Μύθος τρίτος: το PPPoE σας δίνει ακόμη καθαρά 1500

Μια συμβατική ζεύξη πρόσβασης PPPoE δεν μεταφέρει πακέτο IP 1500 byte. Η κεφαλίδα PPPoE μαζί με το πεδίο πρωτοκόλλου PPP καταναλώνουν 8 byte μέσα στο πλαίσιο Ethernet, αφήνοντας 1492 για το πακέτο IP. Αυτό είναι το παραδοσιακό όριο που περιγράφει το RFC 2516. Αν τρέχετε VPN πάνω σε τέτοια ζεύξη, το κόστος της σήραγγας βγαίνει από αυτά τα 1492, όχι από τα 1500.

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

Γιατί η βλάβη φαίνεται επιλεκτική

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

Ένα δεύτερο, συναφές λάθος είναι να συγχέονται τρεις αριθμοί: το MTU της διεπαφής, το MSS του TCP και η δική του ρύθμιση κατακερματισμού ή γεμίσματος του πρωτοκόλλου. Το σφίξιμο MSS σε έναν δρομολογητή ξαναγράφει το διαφημιζόμενο MSS ώστε ο αποστολέας να φτιάχνει μικρότερα τμήματα· δεν αλλάζει το MTU της σήραγγας και δεν βοηθά την κίνηση UDP. Το να δοθεί ο ίδιος αριθμός και στα τρία επειδή μοιάζουν σχετικά είναι ο τρόπος που μια καλοπροαίρετη αλλαγή χαλάει μια λειτουργική ρύθμιση.

Τι να αλλάξετε και με ποια σειρά

Ξεκινήστε με στοιχεία. Επιβεβαιώστε με τις δοκιμές παραπάνω ότι η βλάβη εξαρτάται από το μέγεθος και μετά βρείτε το μικρότερο μέγεθος που περνά και το μεγαλύτερο που αποτυγχάνει. Ελέγξτε το πραγματικό MTU της ζεύξης πρόσβασης πριν κατηγορήσετε τη σήραγγα· μια ζεύξη PPPoE περιορίζει τον προϋπολογισμό πριν τον αγγίξει το VPN. Κρατήστε σημείωση των αρχικών τιμών ώστε η αλλαγή να μπορεί να ανακληθεί.

Έπειτα εφαρμόστε τη μικρότερη προσαρμογή που τεκμηριώνει ο πελάτης. Πολλοί πελάτες εκθέτουν MTU σήραγγας μαζί με επιλογή διόρθωσης MSS, και η επιλογή MSS είναι συχνά ο καλύτερος μοχλός για το TCP επειδή φτάνει στον αποστολέα χωρίς να μικραίνει κάθε πακέτο. Δοκιμάστε ξανά τον ίδιο προορισμό και την ίδια μεταφορά και καταγράψτε τους αριθμούς στους οποίους καταλήξατε. Μια τιμή σήραγγας που δουλεύει σε ένα δίκτυο πρόσβασης δεν είναι παγκόσμια σταθερά, και ο επόμενος χώρος θα έχει τον δικό του προϋπολογισμό.