SSM πάνω από OpenVPN: παρακολούθηση μίας πηγής και μίας ομάδας από άκρη σε άκρη

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

Καθορίστε πρώτα την πηγή, την ομάδα και τον δέκτη

Γράψτε τρεις τιμές πριν αγγίξετε οποιαδήποτε συσκευή: τη διεύθυνση πηγής που θα στέλνει, τη διεύθυνση ομάδας στην οποία θα εγγραφεί ο δέκτης και το υποδίκτυο όπου ζει ο δέκτης. Για μια ενδεικτική ροή IPv4, μια πηγή 10.50.0.10 και μια ομάδα 232.20.30.40 είναι το είδος ζεύγους που ταιριάζει σε σχεδιασμό ειδικό για πηγή. Οτιδήποτε πιο αόριστο από αυτές τις τρεις τιμές δεν μπορεί να δοκιμαστεί.

Το εύρος 232/8 είναι δεσμευμένο για multicast ειδικό για πηγή και το μοντέλο περιγράφεται στο RFC 4607. Αν η ομάδα σας βρίσκεται έξω από αυτό το εύρος ενώ πιστεύετε ότι τρέχετε SSM, σταματήστε και επιβεβαιώστε τι σκοπεύει πραγματικά η ανάπτυξη, γιατί η εγγραφή του δέκτη και η απόφαση προώθησης του δρομολογητή εξαρτώνται και οι δύο από το να είναι συνεπές το μοντέλο.

Ελέγξτε ότι ο δέκτης εγγράφηκε στην πηγή

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

Σε δέκτη Linux, ελέγξτε σε τι εγγράφηκε πραγματικά το socket και τι κατέγραψε ο πυρήνας. Το αρχείο ρυθμίσεων της εφαρμογής δεν είναι απόδειξη· ο πίνακας συμμετοχών είναι. Διαβάστε τον όσο ο δέκτης τρέχει πραγματικά, γιατί μια εγγραφή μπορεί να παραμείνει λίγο αφού τερματιστεί η διεργασία που τη δημιούργησε. Μια παλιά εγγραφή από προηγούμενη δοκιμή είναι αξιόπιστη πηγή ψευδούς βεβαιότητας.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

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

Επαληθεύστε τη διαδρομή επιστροφής πριν κοιτάξετε τη σήραγγα

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

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

Έπειτα επιβεβαιώστε ότι το TTL της πηγής είναι αρκετά μεγάλο για να επιβιώσει από τα δρομολογημένα άλματα που σχεδιάσατε. Μια ροή που λειτουργεί στον πρώτο δρομολογητή και πεθαίνει στον δεύτερο είναι συχνά ζήτημα TTL και όχι ζήτημα πολιτικής.

Διαβάστε την κατάσταση multicast του πυρήνα και όχι τη ρύθμιση

Η ρύθμιση σας λέει τι ζητήσατε· ο πυρήνας σας λέει τι συμβαίνει. Σε κάθε άλμα Linux, διαβάστε τις εγγραφές δρομολόγησης multicast και επιβεβαιώστε ότι υπάρχει λίστα εισερχόμενων και εξερχόμενων διασυνδέσεων για το ακριβές ζεύγος πηγής και ομάδας. Μια εγγραφή για την ομάδα με πηγή μπαλαντέρ είναι διαφορετικό αντικείμενο και δεν θα εξηγήσει ροή ειδική για πηγή.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

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

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

Αποφασίστε πώς η σήραγγα αναπαράγει πραγματικά τα πακέτα

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

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

Τέλος, επαληθεύστε στον δέκτη με στενή παρατήρηση: την ακριβή πηγή, ομάδα και θύρα, στη διασύνδεση που περιμένετε, ενώ ένας εξουσιοδοτημένος δέκτης είναι εγγεγραμμένος. Το SSM επιλέγει αποστολέα και η επιλογή δεν είναι ταυτοποίηση αυτού του αποστολέα, ούτε άδεια σε άλλη κίνηση multicast να διασχίσει την ίδια πολιτική.