Ανάθεση προθέματος IPv6 μέσω VPN από τοποθεσία σε τοποθεσία: λίστα ελέγχου

Το να σηκώσεις το τούνελ είναι το εύκολο μισό. Έχω δει σύνδεση από τοποθεσία σε τοποθεσία να μένει ενεργή για μέρες ενώ κάθε κεντρικός υπολογιστής στο απομακρυσμένο LAN έπαιρνε πίσω σιωπή, επειδή το ανατεθειμένο πρόθεμα πίσω από εκείνη την πύλη είχε ρυθμιστεί σε μια διεπαφή αλλά δεν δρομολογήθηκε ποτέ μέσα στο τούνελ. Οι διευθύνσεις του τούνελ απαντούσαν σε ping όλη την ώρα, και γι' αυτό ακριβώς κανείς δεν κοίταξε το πρόθεμα. Αυτή είναι η σειρά που ελέγχω όταν ένα ανατεθειμένο πρόθεμα IPv6 πρέπει να διασχίσει ένα VPN τοποθεσίας: ο χάρτης προθεμάτων, οι επιλογείς κίνησης, η προώθηση και το τείχος προστασίας, και μετά η διαδρομή επιστροφής.

Γράψτε τον χάρτη προθεμάτων πριν αγγίξετε το τούνελ

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

Για κάθε τοποθεσία, καταγράψτε το ανατεθειμένο πρόθεμα, το /64 που χρησιμοποιείται πραγματικά στο LAN, τις διευθύνσεις του τούνελ και τον ιδιοκτήτη κάθε διαδρομής. Ο πάροχος αναθέτει το 2001:db8:a1::/56 στην τοποθεσία A, η οποία εξυπηρετεί το 2001:db8:a1:10::/64 στο LAN της· η τοποθεσία B κρατά το 2001:db8:b2::/64. Αν η τοποθεσία A εξυπηρετεί μόνο αυτό το ένα /64, και τα δύο άκρα πρέπει να ονομάζουν το 2001:db8:a1:10::/64 αντί για ολόκληρο το /56.

Δύο λάθη εμφανίζονται σχεδόν κάθε φορά. Το ένα είναι να αντιμετωπίζεται το απομακρυσμένο πρόθεμα ως on-link, γεφυρώνοντάς το ή βάζοντάς το στη διεπαφή του τούνελ ώστε η πύλη να απαντά στην αίτηση γείτονα για κεντρικούς υπολογιστές που δεν μπορεί να φτάσει. Το άλλο είναι να διαφημίζεται ολόκληρο το /56 όταν έχει ρυθμιστεί μόνο ένα /64: ο πίνακας δρομολόγησης ισχυρίζεται ότι το μπλοκ είναι προσβάσιμο και οι περισσότερες διευθύνσεις πέφτουν σε μαύρη τρύπα.

Ταιριάξτε τους επιλογείς κίνησης των δύο άκρων με τις διαδρομές

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

Στο strongSwan οι επιλογείς είναι ρητοί. Στην τοποθεσία A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

Το conn της τοποθεσίας B καθρεφτίζει τα δύο υποδίκτυα. Όταν διαφωνούν, ο responder απορρίπτει το CHILD_SA με TS_UNACCEPTABLE, οπότε το θυγατρικό SA δεν ανεβαίνει ποτέ αν και το IKE_SA ανέβηκε. Και στις δύο πλευρές το ρυθμισμένο υποδίκτυο πρέπει να ισούται με αυτό που δρομολογεί ο τοπικός πυρήνας προς το τούνελ.

Το WireGuard μεταφέρει την ίδια πληροφορία στο AllowedIPs, με μια ανατροπή: το AllowedIPs είναι φίλτρο πηγής κατά τη λήψη καθώς και διαδρομή κατά την αποστολή. Αν η καταχώριση ομοτίμου της τοποθεσίας B για την τοποθεσία A παραλείπει το 2001:db8:a1:10::/64, τα πακέτα από την τοποθεσία A φτάνουν σε έγκυρη χειραψία και απορρίπτονται ως μη επιτρεπτά. Αυτό παράγει το γνωστό μοτίβο μιας χειραψίας που ανανεώνεται συνεχώς ενώ καμία απάντηση δεν φεύγει ποτέ. Συγκρίνετε και τα δύο άκρα με wg show wg0 allowed-ips. Ελέγξτε ξανά τη λίστα κάθε φορά που αλλάζει η ανάθεση· ένα παλιό /64 κρατά τη συνεδρία ζωντανή και το νέο πρόθεμα μη προσβάσιμο.

Αποκλείστε πρώτα την προώθηση, το τείχος προστασίας και το MTU

Πριν διαβάσετε άλλη γραμμή αρχείου καταγραφής, επιβεβαιώστε ότι οι πύλες προωθούν καθόλου. Το sysctl net.ipv6.conf.all.forwarding πρέπει να επιστρέφει 1 και στις δύο, με εφαρμογή και στις διεπαφές του τούνελ και του LAN. Μαζί του έρχεται μια παγίδα: μόλις ενεργοποιηθεί η προώθηση, μια διεπαφή με accept_ra=1 σταματά να δέχεται αναγγελίες δρομολογητή από τον πάροχο, οπότε το μηχάνημα μπορεί να χάσει την ανάντη προεπιλεγμένη διαδρομή του ενώ δρομολογεί άψογα μέσα στο τούνελ. Ορίστε accept_ra=2 όπου χρειάζεται ακόμη RA από τον πάροχο.

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

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

Το MTU βρίσκεται πίσω από αυτό. Ένα τούνελ συρρικνώνει το χρησιμοποιήσιμο MTU κάτω από 1500, και το IPv6 απαιτεί κάθε ζεύξη να μεταφέρει τουλάχιστον 1280. Τα μικρά ping περνούν, μια συνεδρία SSH παγώνει σε μια μεγάλη ριπή, και το /proc/net/snmp6 δείχνει μηνύματα πακέτο-πολύ-μεγάλο που δεν επιστρέφουν ποτέ. Ορίστε ρητά το MTU του τούνελ ή περιορίστε το TCP MSS στον πίνακα mangle, και αφήστε το ICMPv6 που αναφέρει το μικρότερο MTU να επιστρέψει.

Δοκιμάστε τη διαδρομή επιστροφής, όχι τη διεύθυνση του τούνελ

Η αποτυχία που κοστίζει περισσότερο χρόνο είναι η μονόδρομη δρομολόγηση. Κάθε πύλη δρομολογεί το απομακρυσμένο πρόθεμα μέσα στο τούνελ, αλλά οι κεντρικοί υπολογιστές απαντούν μέσω της δικής τους προεπιλεγμένης πύλης επειδή εκεί ζει το /64 τους. Το να φτάσει ένα πακέτο στον προορισμό είναι μόνο η μισή διαδρομή.

Δύο εντολές ξεκαθαρίζουν τα περισσότερα. Στην τοποθεσία A, το ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 δείχνει ποια διεπαφή θα χρησιμοποιούσε μια απάντηση από αυτή την πηγή· εκτελέστε τον κατοπτρικό έλεγχο στην τοποθεσία B. Έπειτα δημιουργήστε κίνηση από έναν κεντρικό υπολογιστή και όχι από την πύλη και συγκρίνετε τους μετρητές στα δύο άκρα.

Αν η αίτηση γείτονα για το απομακρυσμένο πρόθεμα εμφανιστεί στο τούνελ, αυτό το πρόθεμα είναι on-link κάπου όπου δεν θα έπρεπε να είναι· διορθώστε το πριν προσαρμόσετε διαδρομές. Το Proxy NDP καλύπτει περιπτώσεις όπου η γεφύρωση είναι πραγματικά απαραίτητη, δεν είναι υποκατάστατο μιας διαδρομής.

Σχεδιάστε για το πρόθεμα που αλλάζει κάτω από τα πόδια σας

Η ανάθεση προθέματος είναι μίσθωση μεταξύ του δρομολογητή που αναθέτει και αυτού που ζητά, και μια ανανέωση μπορεί να επιστρέψει διαφορετικό μπλοκ: διαφορετικό /56 μετά από μετακόμιση παρόχου ή μικρότερη μίσθωση από τον χρόνο που το τούνελ είναι ενεργό. Κάθε σημείο που ονομάζει το παλιό πρόθεμα γίνεται παρωχημένο ταυτόχρονα: διαδρομές, επιλογείς, AllowedIPs, κανόνες τείχους προστασίας, εγγραφές DNS και οποιαδήποτε παρακολούθηση κωδικοποιεί κυριολεκτικές διευθύνσεις. Η ροή μηνυμάτων είναι στο RFC 8415.

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

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