Δρομολόγηση πολιτικής IPv6 όταν δύο ζεύξεις ανόδου μοιράζονται το fe80::1

Έχετε δύο ζεύξεις ανόδου, και η εντολή ip -6 route show εμφανίζει το ίδιο επόμενο άλμα και στις δύο: default via fe80::1 dev uplink0 και default via fe80::1 dev uplink1. Αυτό δεν είναι σύγκρουση διπλών διευθύνσεων, και η αντιγραφή του γυμνού επόμενου άλματος fe80::1 σε πίνακα πολιτικής δεν λέει στον πυρήνα ποια ζεύξη εννοούσατε. Το πραγματικό ερώτημα είναι στενότερο από ό,τι υποδηλώνει το σύμπτωμα: χρειάζεται ο δεύτερος πίνακας μία ζεύξη ή και τις δύο, και τι κρατά αυτές τις διαδρομές ζωντανές μετά από επανεκκίνηση. Τρεις συνθήκες, ελεγμένες με σειρά, λύνουν το μεγαλύτερο μέρος.

Το ίδιο fe80::1 είναι δύο διαφορετικοί γείτονες

Οι διευθύνσεις link-local περιορίζονται σε μία ζεύξη, άρα το fe80::1 δεν είναι μία διεύθυνση τυπωμένη δύο φορές· είναι δύο γείτονες που τυχαίνει να μοιράζονται ένα επίθημα. Ο δείκτης ζώνης είναι ο τρόπος με τον οποίο ένας υπολογιστής λέει ποιον εννοεί, άρα το fe80::1%uplink0 και το fe80::1%uplink1 είναι διαφορετικοί προορισμοί για τον πυρήνα, και αυτό το επίθημα δεν ταξιδεύει ποτέ σε απομακρυσμένο δρομολογητή. RFC 4007 περιγράφει το μοντέλο ζωνών πίσω από αυτό, και γι' αυτό ένας πίνακας πολιτικής πρέπει να μεταφέρει συσκευή με κάθε link-local επόμενο άλμα.

Μια γεννήτρια διαμόρφωσης VPN που αντιγράφει αριθμητικό αναγνωριστικό ζώνης από έναν υπολογιστή σε πρότυπο αντιμετωπίζει το τοπικό πλαίσιο σαν να είναι μέρος της διεύθυνσης, και το αρχείο που γράφει είναι λάθος σε κάθε μηχάνημα του οποίου τα ονόματα ή οι δείκτες διασύνδεσης διαφέρουν. Ένας πίνακας πολιτικής επίσης δεν συγχωνεύει δύο ζεύξεις σε μία: ένα δρομολογημένο VPN μεταφέρει πακέτα μεταξύ δικτύων, αλλά δεν μεταφέρει την ταυτότητα link-local ενός απομακρυσμένου γείτονα Ethernet μέσα από τη σήραγγα, άρα η κίνηση link-local μένει στη δική της ζεύξη.

Αφαιρέστε τη συσκευή και η διαδρομή γίνεται μη εγγράψιμη. Το ip -6 route add default via fe80::1 table 200 δεν μπορεί να επιλύσει την πύλη, και το iproute2 το απορρίπτει με Error: Nexthop has invalid gateway. Προσθέστε το dev uplink0 και η εντολή πετυχαίνει, γιατί η συσκευή είναι αυτή που καρφώνει το επόμενο άλμα σε έναν από αυτούς τους δύο γείτονες. Αυτό που δεν μπορεί να σας πει η συσκευή είναι αν το uplink0 είναι η σωστή ζεύξη για αυτόν τον πίνακα, και μια διαδρομή αντιγραμμένη από άλλον υπολογιστή φέρνει μαζί της τα ονόματα διασύνδεσης εκείνου του υπολογιστή, και από εκεί προέρχονται τα πραγματικά λάθη.

Συνθήκη πρώτη: μία ζεύξη ή δύο στον πίνακα

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

Στη δεύτερη περίπτωση ο κανόνας αποφασίζει πότε συμβουλεύεται ένας πίνακας, και η διαδρομή αποφασίζει πού πηγαίνει το πακέτο μετά:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

Κανένα από τα δύο αντικείμενα δεν υποκαθιστά το άλλο, και ένας πίνακας που κρατά μόνο μια προεπιλεγμένη διαδρομή μπορεί ακόμη να αποτύχει να επιλύσει την πύλη του. Αν μια προσθήκη απορριφθεί, ή η διαδρομή υπάρχει αλλά είναι άχρηστη, βάλτε το συνδεδεμένο πρόθεμα για εκείνη τη διασύνδεση στον ίδιο πίνακα, ή σημάνετε το άλμα onlink όταν αυτό το πρόθεμα δρομολογείται αλλού. Στο παραπάνω μπλοκ το 2001:db8:100::/48 αντιπροσωπεύει ακριβώς αυτό το συνδεδεμένο πρόθεμα στο uplink1, όχι έναν αυθαίρετο προορισμό. Ο κανόνας fwmark καταναλώνει μόνο ένα σημάδι που πρέπει να θέσει κάτι άλλο, από κανόνα nftables ή iptables στη διαδρομή προώθησης ή από το SO_MARK στον υποδοχέα, άρα ένα μπλοκ που αντιγράφηκε χωρίς πηγή σημαδιού δεν ταιριάζει με τίποτα.

Συνθήκη δεύτερη: οι μετρικές δεν ανιχνεύουν νεκρό πάροχο

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

Επαληθεύστε την επιλογή αφού χτιστεί ο πίνακας, και επαληθεύστε την όπως θα τη δει ο πυρήνας. Το ip -6 route get 2001:db8:100::1 εκτυπώνει τη διαδρομή που θα χρησιμοποιηθεί, μαζί με τη συσκευή και την επιλεγμένη διεύθυνση προέλευσης, και σέβεται τους κανόνες πολιτικής. Μια διεύθυνση προέλευσης που ανήκει στη λάθος ζεύξη ανόδου είναι το συνηθισμένο σημάδι ότι ένας κανόνας ταίριαξε νωρίτερα από ό,τι περιμένατε.

Συνθήκη τρίτη: αποφασίστε ποιος κατέχει τη μονιμότητα

Μια διαδρομή που προστέθηκε με το ip -6 route add επιβιώνει μέχρι την επανεκκίνηση ή μέχρι κάτι να τη σβήσει. Μια προεπιλεγμένη διαδρομή που μαθεύτηκε από αναγγελίες δρομολογητή φέρει διάρκεια ζωής και μπορεί να αποσυρθεί από τον δρομολογητή, ενώ μια χειροκίνητα προστιθέμενη προεπιλεγμένη δεν λήγει ποτέ μόνη της. Το ανακάτεμα των δύο σε έναν πίνακα είναι ο τρόπος με τον οποίο μια παρωχημένη μόνιμη διαδρομή καταλήγει να υπερισχύει μιας φρέσκιας αναγγελθείσας, πολύ καιρό αφού η ζεύξη που περιέγραφε έπαψε να υπάρχει.

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

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

Σε δρομολογητή που προωθεί για άλλους υπολογιστές, ελέγξτε το net.ipv6.conf.all.forwarding πριν κατηγορήσετε τον πίνακα. Με την προώθηση κλειστή, τα πακέτα που απευθύνονται σε άλλο δίκτυο απορρίπτονται, όσο σωστός κι αν είναι ο πίνακας 201.

Καταγράψτε τη σχεδίαση ώστε ο επόμενος να μπορεί να την ελέγξει

Μια απογραφή που αποθηκεύει μόνο το fe80::1 πετάει τα πεδία που έχουν σημασία. Καταγράψτε τον προορισμό, το επόμενο άλμα, τη συσκευή, τον πίνακα και τη μετρική μαζί, καθώς και από πού προήλθε κάθε διαδρομή — αναγγελθείσα, παραγόμενη από διαχειριστή ή στατική. Όταν κάποιος ρωτήσει αργότερα αν η δεύτερη ζεύξη ανόδου μεταφέρει πραγματικά κίνηση, αυτή η καταγραφή απαντά χωρίς εικασίες.

Πριν θεωρήσετε τον πίνακα έτοιμο, επιβεβαιώστε τον γείτονα με το ip -6 neigh show dev uplink0, ξαναδιαβάστε το ip -6 rule show για ατυχήματα σειράς, και δοκιμάστε με κίνηση που ταιριάζει στον κανόνα αντί για ping που παίρνει την προεπιλεγμένη διαδρομή. Μετά κατεβάστε σκόπιμα μία ζεύξη ανόδου και δείτε σε ποια διαδρομή πέφτει ο πυρήνας· η απάντηση πρέπει να ταιριάζει με αυτή που γράψατε.