OpenVPN σε PPPoE: να μειώσετε το link-mtu, το tun-mtu ή το mssfix;

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

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

Τρεις διακόπτες, τρία διαφορετικά επίπεδα

Το link-mtu είναι ο εξωτερικός προϋπολογισμός: το κρυπτογραφημένο ωφέλιμο φορτίο συν την κεφαλίδα OpenVPN, την κεφαλίδα UDP και την εξωτερική κεφαλίδα IP. Περιγράφει τι φεύγει από το μηχάνημα, γι’ αυτό είναι ο αριθμός που περιορίζει η φυσική διαδρομή.

Το tun-mtu είναι ο εσωτερικός προϋπολογισμός: η διεπαφή που βλέπει η κίνησή σας. Είναι μεγαλύτερο από αυτό που μπορεί να μεταφέρει η διαδρομή κατά ακριβώς το overhead του τούνελ, και το OpenVPN συνήθως το παράγει αντί να σας αναγκάζει να το ορίσετε.

Το mssfix είναι εντελώς διαφορετικός μηχανισμός. Ξαναγράφει το μέγιστο μέγεθος τμήματος που ανακοινώνεται κατά τις χειραψίες TCP, ώστε οι ομότιμοι TCP να επιλέγουν τμήματα που χωρούν μετά την ενθυλάκωση. Δεν αλλάζει το MTU της διεπαφής και δεν έχει κανένα αποτέλεσμα στο UDP.

Αν ορίσετε ρητά το link-mtu, το OpenVPN αφαιρεί το δικό του overhead για να υπολογίσει το εσωτερικό MTU. Αυτό το overhead δεν είναι σταθερά· εξαρτάται από τον κρυπταλγόριθμο και την πιστοποίηση, γι’ αυτό μια τιμή αντιγραμμένη από ένα φόρουμ μπορεί να είναι λάθος σε άλλο προφίλ. Αν ορίσετε και link-mtu και tun-mtu, δίνετε στον πελάτη δύο αντιφατικές οδηγίες.

Μετρήστε τη διαδρομή πριν επιλέξετε οποιονδήποτε αριθμό

Μετρήστε από τη φυσική διεπαφή, όχι μέσα από το τούνελ, και θυμηθείτε ότι το ping αναφέρει ωφέλιμο φορτίο, όχι μέγεθος πακέτου. Προσθέστε 28 byte για τις κεφαλίδες IPv4 και ICMP πριν συγκρίνετε το ωφέλιμο φορτίο με ένα πλαίσιο 1500 byte, και κρατήστε αυτή τη διόρθωση στο μυαλό σας όταν ένας ομότιμος αναφέρει διαφορετικό αριθμό.

Σε πελάτη Linux, το ping -M do -s 1472 απαγορεύει τον κατακερματισμό και αποτυγχάνει αν το πακέτο είναι πολύ μεγάλο. Μειώστε το ωφέλιμο φορτίο ώσπου να περάσει, και μετά προσθέστε 28 για να πάρετε το MTU της διαδρομής. Το PPPoE κοστίζει 8 byte, οπότε το 1492 είναι φυσιολογικό σε DSL. Το DS-Lite και ορισμένες κινητές διαδρομές κοστίζουν 40 ή περισσότερα, και η απάντηση είναι συνήθως χαμηλότερη από ό,τι υποδηλώνει η ονομαστική ταχύτητα ζεύξης.

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

Περιορίστε πρώτα το TCP, συρρικνώστε το τούνελ μετά

Οι χειραψίες TCP είναι το μόνο που αγγίζει το mssfix, γι’ αυτό συνήθως είναι ο λιγότερο παρεμβατικός έλεγχος για να δοκιμάσετε πρώτα. Ορίστε το λίγο κάτω από τον πραγματικό προϋπολογισμό της διαδρομής, σπρώξτε την ίδια τιμή από τον διακομιστή ώστε να συμφωνούν και τα δύο άκρα, και δοκιμάστε ξανά μια μεγάλη λήψη. Αν το κόλλημα λυθεί, το πρόβλημα ήταν το μέγεθος τμήματος TCP, και τίποτα άλλο δεν χρειάζεται να αλλάξει.

Μειώστε το εσωτερικό MTU όταν η κίνηση που επηρεάζεται δεν είναι TCP. Μια υπηρεσία UDP, ένα τούνελ μέσα στο τούνελ ή μια εφαρμογή που στέλνει πακέτα UDP πλήρους μεγέθους θα συνεχίσει να αποτυγχάνει μετά από περιορισμό MSS επειδή τίποτα δεν ξαναγράφει το μέγεθος των πακέτων της. Μειώστε το tun-mtu για αυτή την περίπτωση, ή ορίστε το link-mtu και αφήστε τον πελάτη να υπολογίσει την εσωτερική τιμή, αλλά ποτέ και τα δύο.

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

Γιατί οι μικρές δοκιμές συνεχίζουν να λειτουργούν

Τα ερωτήματα DNS, οι ηχώ ICMP και οι χειραψίες TCP βρίσκονται όλα πολύ κάτω από το μέγεθος που αποτυγχάνει. Το τούνελ φαίνεται επομένως υγιές σε κάθε γρήγορη δοκιμή, ενώ οι χειραψίες TLS και οι απαντήσεις HTTP αποτυγχάνουν σιωπηλά. Ακριβώς αυτός ο συνδυασμός, ένα traceroute που δουλεύει και ένας περιηγητής που κολλάει στην πρώτη μεγάλη απάντηση, είναι το σημάδι που πρέπει να ψάξετε. Πιάστε μια δοκιμή πλήρους μεγέθους πριν πιάσετε ένα νέο προφίλ.

Επαληθεύστε με την κίνηση που απέτυχε. Φέρτε μια μεγάλη σελίδα, στείλτε ένα πακέτο UDP πλήρους μεγέθους αν αυτή είναι η επηρεαζόμενη υπηρεσία, και επαναλάβετε από δεύτερο πελάτη σε άλλη σύνδεση. Καταγράψτε το μετρημένο MTU της διαδρομής και την τιμή που επιλέξατε, γιατί ο επόμενος που θα αγγίξει το προφίλ θα θεωρήσει αλλιώς τον αριθμό αυθαίρετο.

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