Το ping προς τον ομότιμο του IPv6 tunnel σας αποτυγχάνει; Ελέγξτε τη διεύθυνση ::

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

Το σύμπτωμα που δείχνει τη διεύθυνση

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

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

Το RFC 4291 διατηρεί το αναγνωριστικό διεπαφής με όλα τα μηδενικά ως διεύθυνση anycast του δρομολογητή υποδικτύου, επομένως ένα /64 όπως 2001:db8:4a::/64 δεν περιέχει κανέναν χρησιμοποιήσιμο κεντρικό υπολογιστή στη διεύθυνση 2001:db8:4a::. Η δέσμευση αξίζει τη θέση της: οι αναγγελίες δρομολογητή και η ανακάλυψη γειτόνων απευθύνονται σε αυτή τη μορφή, και ένας δρομολογητής απαντά για το πρόθεμα που εξυπηρετεί. Η εκχώρηση αυτής της τιμής σε άκρο tunnel δίνει ρόλο δρομολογητή σε ένα φύλλο, και γι' αυτό δεν επιστρέφει τίποτα. Κάθε άλλο αναγνωριστικό στο πρόθεμα λειτουργεί ως κεντρικός υπολογιστής, οπότε η επισκευή είναι συνήθως ένα ψηφίο.

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

Εκχωρήστε διευθύνσεις κεντρικών υπολογιστών και δρομολογήστε το πρόθεμα

Επιλέξτε ::1 και ::2 για τα δύο άκρα, προσθέστε μία με ip -6 addr add 2001:db8:4a::2/64 dev tun0, και μετά δρομολογήστε το απομακρυσμένο πρόθεμα αντί να προσπαθείτε να το διευθυνσιοδοτήσετε. Μια διαδρομή για 2001:db8:4a::/64 μέσω του tunnel κάνει την μακρινή πλευρά προσβάσιμη· μόνη της η διεύθυνση απλώς κάνει τη τοπική διεπαφή ρυθμισμένη.

Για πλήρες tunnel υπάρχει ένα τρίτο βήμα, μια προεπιλεγμένη διαδρομή για καθολικό unicast μέσω της συσκευής, που είναι το IPv6 ισοδύναμο της αποστολής όλων στο tunnel. Αν το παραλείψετε, το IPv6 συνεχίζει να χρησιμοποιεί τον φυσικό σύνδεσμο ενώ το IPv4 ταξιδεύει μέσα στο tunnel, οπότε ο κεντρικός υπολογιστής διαρρέει ακριβώς την κίνηση που πιστεύατε ότι καλύπτεται. Επιβεβαιώστε με ip -6 route get 2001:4860:4860::8888 και διαβάστε ποια συσκευή αναφέρει αντί να υποθέσετε την απάντηση.

Το multicast απορρίπτεται πριν από τη δρομολόγηση

Το Android επικυρώνει διευθύνσεις και διαδρομές για VpnService.Builder μέσω LinkAddress, και αυτός ο κατασκευαστής απορρίπτει το multicast ευθέως. Δώστε του ένα πρόθεμα multicast ως διαδρομή και το αποτέλεσμα είναι αποτυχία κακών παραμέτρων LinkAddress αντί για διαδρομή, που είναι απάντηση επικύρωσης και όχι δικτύου. Η απόρριψη ταιριάζει με το μέσο: μια συσκευή tun σημείου-προς-σημείο δεν έχει multicast στο επίπεδο ζεύξης, οπότε μια ομαδική διαδρομή σε αυτήν δεν έχει μοντέλο παράδοσης να εγκαταστήσει. Οι ομαδικές διευθύνσεις δημιουργούνται και καταναλώνονται από την ίδια τη στοίβα αντί να ρυθμίζονται με το χέρι.

Οι διευθύνσεις IPv6 all-nodes και solicited-node υπάγονται στον ίδιο κανόνα. Η διεπαφή τις φέρει επειδή τις έβαλε εκεί η στοίβα, όχι επειδή τις σκόπευε μια πολιτική.

Τι μπορεί να μεταφέρει ένα tunnel αντ' αυτού

Η μετακίνηση ανακάλυψης multicast μέσω tunnel απαιτεί ένα επίπεδο που κατανοεί τη συμμετοχή σε ομάδες: μια γέφυρα TAP που παρουσιάζει τμήμα Ethernet, ένα relay σε επίπεδο εφαρμογής ή ένα πρωτόκολλο δρομολόγησης στο οποίο λέγεται ρητά σε ποιους ομοτίμους να αναπαράγει. Τίποτα από αυτά δεν υπάρχει στο μοντέλο VpnService, όπου η εφαρμογή διαβάζει και γράφει πακέτα και δεν έχει κλήση που να εντάσσεται σε ομάδα για το tunnel. Είτε προσθέστε το στοιχείο που κατανοεί ομάδες είτε αφαιρέστε την απαίτηση από τον σχεδιασμό.

Το unicast, αντίθετα, δεν χρειάζεται τίποτα επιπλέον πέρα από τις διευθύνσεις και τις διαδρομές παραπάνω, γι' αυτό συνήθως αναμένεται από τα tunnel να το μεταφέρουν και μετά κατηγορούνται όταν αποτυγχάνει ένα πρωτόκολλο ανακάλυψης.

Τρεις έλεγχοι πριν εκχωρήσετε οτιδήποτε

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

Μια διαδρομή που η πλατφόρμα δεν εγκατέστησε ποτέ δεν μπορεί να εντοπιστεί περιμένοντας περισσότερο, και μια διεύθυνση που δεν υπήρξε ποτέ κεντρικός υπολογιστής δεν μπορεί να επισκευαστεί με καλύτερο ping.