IPIP μέσα στο WireGuard: τα επιπλέον 20 byte που δεν υπολόγισε κανείς

Μικρά ping διασχίζουν το τούνελ όλη μέρα, το πανό SSH φτάνει και μετά η συνεδρία παγώνει τη στιγμή που ξεκινά μια μεταφορά αρχείου. Αυτό το μοτίβο δείχνει έναν προϋπολογισμό byte μετρημένο στο λάθος επίπεδο, όπου το εξωτερικό τούνελ διαστασιολογήθηκε για το δικό του κόστος και κανείς δεν αφαίρεσε το εσωτερικό. Ένα ένθετο πακέτο IPIP είναι απλώς άλλο ένα πακέτο IP για το WireGuard, και γι' αυτό ακριβώς καταναλώνει byte που δεν δεσμεύσατε ποτέ. Η διόρθωση είναι αριθμητική και χωρά σε τρεις εντολές και έναν πίνακα.

Το σύμπτωμα που το προδίδει

Τα προβλήματα κατακερματισμού ανακοινώνονται μέσω μεγέθους, ποτέ μέσω διευθύνσεων. Ο peer σας απαντά σε ένα ping 56 byte για μια ώρα και μετά σωπαίνει στα 1400 byte, ενώ το τούνελ μένει σηκωμένο και καμία διαδρομή δεν άλλαξε. Η χειραψία χωρά, το πρώτο πλήρες παράθυρο TCP όχι, και η μεταφορά κολλά δευτερόλεπτα αφού φάνηκε υγιής.

Μετρήστε το όριο πριν επεξεργαστείτε οτιδήποτε, γιατί ένα όριο που δεν μετρήθηκε είναι αυτό που θα κυνηγήσετε δύο φορές. Στείλτε έναν μόνο ανιχνευτή κάτω από το ύποπτο μέγεθος με το bit do-not-fragment ενεργό, ping -M do -s 1000 10.9.0.2, και μετά επαναλάβετε σε μέγεθος που ξέρετε ήδη ότι είναι πολύ μεγάλο. Όταν η ανατροπή ακολουθεί το μέγεθος του ωφέλιμου φορτίου ενώ ο προορισμός μένει ίδιος, η δρομολόγηση κάνει τη δουλειά της και λείπει μια κεφαλίδα από τον προϋπολογισμό.

Μετρήστε κάθε κεφαλίδα μία φορά, στο σωστό επίπεδο

Ξεκινήστε από το μικρότερο MTU στη διαδρομή και όχι από τη διεπαφή του τούνελ, γιατί ο τοίχος βρίσκεται πάνω από τα δύο άκρα. Το WireGuard ξοδεύει 60 byte σε εξωτερική μεταφορά IPv4: 20 για IP, 8 για UDP και 32 για τη δική του κεφαλίδα, και 80 byte όταν αυτή η μεταφορά είναι IPv6. Ένα wg0 1420 byte κρατά 20 byte περιθώριο κάτω από τα 1440 που μια διαδρομή 1500 byte μπορεί πραγματικά να παραδώσει, και γι' αυτό ο αριθμός που αντιγράφηκε από ένα wiki ταιριάζει ακόμη εδώ. Σχεδιάστε ολόκληρη τη στοίβα στο διάγραμμα, γιατί όποιος αλλάξει το MTU μετά θα διαλέξει αλλιώς έναν νέο στρογγυλό αριθμό και θα κληρονομήσει το σφάλμα σας.

Η πέμπτη γραμμή είναι όπου χαλάνε οι προϋπολογισμοί, γιατί τα 1400 byte που μεταφέρει μια ένθετη διεπαφή περιλαμβάνουν ήδη τις δικές του 40 byte κεφαλίδων του αρχικού πακέτου. Μόνο 1360 από αυτά τα byte φτάνουν στη διεργασία που διαβάζει το αρχείο. Αντιμετωπίστε τα 1400 ως ωφέλιμο φορτίο εφαρμογής, όπως σας καλεί κάθε διάγραμμα χωρίς αυτή τη στήλη, και η εσωτερική συσκευή καταλήγει 40 byte υπερβολικά γενναιόδωρη απέναντι σε έναν τοίχο που δεν μετακινήθηκε.

Ρυθμίστε τα δύο MTU χωριστά

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

ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400

Ο κανόνας που αξίζει να θυμάστε: εσωτερικό MTU = εξωτερικό MTU - 20 όταν το πακέτο που μεταφέρει το τούνελ IPIP είναι IPv4, και - 40 μόλις οποιαδήποτε πλευρά του εσωτερικού πακέτου είναι IPv6, γιατί η ένθετη κεφαλίδα μεγαλώνει από 20 byte σε 40. Τίποτε άλλο δεν ανήκει σε αυτή την αφαίρεση. Το κόστος του WireGuard ξοδεύτηκε ήδη όταν διαλέξατε 1420, και η χρέωσή του δύο φορές παράγει ένα τούνελ που λειτουργεί τέλεια και μένει αργό όσο κανείς δεν το μετρά. Μια εγκατάσταση όπου και οι δύο συσκευές φέρουν στρογγυλό 1400 είναι το αποτύπωμα ακριβώς αυτού του λάθους.

Το IPv6 σε οποιαδήποτε πλευρά του ένθετου πακέτου ακυρώνει κάθε αριθμό παραπάνω, οπότε επανυπολογίστε αντί να αντιγράψετε έναν αριθμό από παρόμοιο ιστότοπο. Οι κεφαλίδες που αφαιρούνται είναι 40 byte η καθεμία μόλις το IPv6 εμφανιστεί στην εξωτερική διαδρομή ή στο αρχικό datagram, και ο αριθμός του ωφέλιμου φορτίου πέφτει ακριβώς τόσο.

Ο κανόνας firewall που πιθανότατα δεν χρειάζεστε

Μεταξύ δύο peer του WireGuard το μόνο στο σύρμα είναι UDP, οπότε ένας κανόνας εισόδου για το πρωτόκολλο 4, τον αριθμό που αποδίδει το RFC 2003 στην ενθυλάκωση IPv4-σε-IPv4, ούτε δημιουργεί την ένθετη διαδρομή ούτε τη διατηρεί ζωντανή. Η κεφαλίδα IPIP ζει μέσα στο κρυπτογραφημένο ωφέλιμο φορτίο, όπου κανένα firewall άκρου δεν τη βλέπει. Το άνοιγμα του πρωτοκόλλου 4 ούτως ή άλλως δεν αγοράζει τίποτα πέρα από έναν ακόμη επιτρεπόμενο δρόμο προς τον υπολογιστή.

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

Τι επικυρώνει πραγματικά το WireGuard

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

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

Επαληθεύστε με σκάλα, όχι με ένα ping

Δοκιμάστε μεγέθη που περικλείουν το όριο που υπολογίσατε και μετά επιβεβαιώστε τι πιστεύει ο πυρήνας για τις δύο συσκευές. Με 1360 byte ωφέλιμου φορτίου συν 40 byte κεφαλίδων που κάνουν 1400, η πρώτη ηχώ παρακάτω χωρά και η δεύτερη κάθεται ένα byte πέρα από το όριο:

ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0

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