Nebula: ο αναμεταδότης έχει ρυθμιστεί αλλά μένει ανενεργός — τρεις ρυθμίσεις για έλεγχο

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

Χαρτογραφήστε τους τρεις ρόλους πριν επεξεργαστείτε ένα config

Το Nebula δίνει σε κάθε host μια δουλειά και οι δουλειές δεν κληρονομούνται. Ένας φάρος απαντά σε ερωτήσεις «πού είναι αυτός ο peer» ώστε οι hosts να βρίσκουν ο ένας τον άλλο. Ένας αναμεταδότης προωθεί κίνηση ανάμεσα σε δύο peers που δεν έχουν λειτουργική άμεση διαδρομή. Ένας συνηθισμένος host δεν κάνει κανένα από τα δύο. Οι τρεις ρυθμίσεις που μετράνε ζουν σε τρία διαφορετικά μηχανήματα, γι' αυτό ένα client config που φαίνεται πλήρες μπορεί να αφήσει και τους δύο peers να περιμένουν.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

Ένα σύμπτωμα χωρίζει τις δύο κατηγορίες αποτυχίας. Αν και οι δύο peers αναφέρουν ο ένας τον άλλο και το log δείχνει απόπειρες χειραψίας που δεν ολοκληρώνονται ποτέ, η ανακάλυψη δουλεύει και η διαδρομή δεδομένων είναι μπλοκαρισμένη από NAT ή από firewall. Αν ένας peer δεν μαθαίνει ποτέ τη διεύθυνση του άλλου, το πρόβλημα είναι ο φάρος ή ο στατικός χάρτης hosts του και οι ρυθμίσεις αναμεταδότη δεν μπορούν να το διορθώσουν.

Επιβεβαιώστε ποιο config φόρτωσε πραγματικά κάθε host πριν επεξεργαστείτε οτιδήποτε άλλο. Μια μονάδα που διαβάζει διαφορετική διαδρομή από το αρχείο που επεξεργαστήκατε είναι μια συνηθισμένη και ντροπιαστική αιτία του «η αλλαγή δεν έκανε τίποτα»:

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

Η γραμμή έκδοσης μετράει σε μικτό στόλο. Η διαχείριση αναμεταδότη, η συμπεριφορά διάτρησης και τα αποδεκτά κλειδιά config δεν είναι ίδια μεταξύ εκδόσεων, οπότε μην υποθέτετε ότι μια παλαιότερη έκδοση καταλαβαίνει ένα τμήμα για το οποίο δεν γράφτηκε. Ευθυγραμμίστε τους hosts στην ίδια μικρή σειρά και μετά εκτελέστε nebula -test -config /etc/nebula/config.yml σε κάθε host και συγκρίνετε την έξοδο πριν κάνετε αποσφαλμάτωση σε μια μεταφορά που ο κώδικας δεν υλοποιεί.

Ενεργοποιήστε τον ρόλο προώθησης στον host αναμεταδότη

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

relay:
  am_relay: true

Αυτή η σημαία δηλώνει πρόθεση· δεν δημιουργεί προσβασιμότητα. Ένας αναμεταδότης πρέπει να είναι προσβάσιμος και από τους δύο peers, που στην πράξη σημαίνει δημόσια διεύθυνση, εισερχόμενο UDP στη θύρα Nebula ανοιχτό στο firewall του host και σε κάθε ομάδα ασφαλείας cloud, και όχι διπλό NAT μπροστά του. Ελέγξτε το socket ακρόασης και μετά παρακολουθήστε τα πακέτα του peer να φτάνουν:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

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

Διαφημίστε τον αναμεταδότη από τον προορισμό, όχι από τον client

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

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

Οι peers αναφέρουν αυτή τη λίστα μαζί με τις διευθύνσεις τους όταν κάνουν check-in στον φάρο, οπότε η διαφήμιση διαδίδεται μέσω της ανακάλυψης και όχι μέσω άμεσης ανταλλαγής. Αν ο προορισμός δεν μπορεί να φτάσει σε φάρο, η λίστα αναμεταδοτών του δεν διαδίδεται ποτέ και ένας σωστά ρυθμισμένος αναμεταδότης μένει αδρανής. Αυτή η αποτυχία μοιάζει ακριβώς με χαλασμένο αναμεταδότη και δεν είναι.

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

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Αφήστε τον peer που συνδέεται να χρησιμοποιήσει τον αναμεταδότη

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

relay:
  use_relays: true

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

Οι ρυθμίσεις διέλευσης NAT αλληλεπιδρούν με όλα αυτά. Το punchy.punch βοηθά δύο peers να ανοίξουν άμεση διαδρομή και όταν πετυχαίνει δεν υπάρχει αναμεταδιδόμενη κίνηση για παρατήρηση· αυτό είναι επιτυχία, όχι αναμεταδότης που λείπει. Ένα ζεύγος που δουλεύει διακοπτόμενα σημαίνει συνήθως ότι η διάτρηση πετυχαίνει μερικές φορές, οπότε δοκιμάστε αυτό το ζεύγος αρκετές φορές αντί να βγάλετε συμπέρασμα από μία απόπειρα.

Επαληθεύστε με το ζεύγος που απέτυχε και μετά επαναφορτώστε

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

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

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

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

Το systemctl reload δουλεύει μόνο όταν η τοπική μονάδα ορίζει ExecReload και η μονάδα που συνοδεύει το έργο δεν το κάνει, οπότε το systemctl kill -s HUP είναι το βήμα που πετυχαίνει σε μια τυπική εγκατάσταση. Μετά την επαναφόρτωση διαβάστε το journal για τη διαδρομή config που άνοιξε η διεργασία, ώστε να ξέρετε ότι διαβάστηκε το νέο αρχείο και όχι αυτό που υποθέσατε.

Οι ρυθμίσεις αναμεταδότη και η διάτρηση NAT δρουν και οι δύο στη διαδρομή· καμία δεν δρα στην ταυτότητα. Αν το ζεύγος εξακολουθεί να αποτυγχάνει στη χειραψία του αφού τα am_relay, relays και use_relays επιβεβαιωθούν στο τρέχον config, ελέγξτε ότι και οι δύο hosts παρουσιάζουν πιστοποιητικά εκδομένα για τα ονόματα με τα οποία είναι ρυθμισμένοι και ότι το CA είναι το ίδιο και στις δύο πλευρές. Κρατήστε το πιστοποιητικό και τη ρύθμιση firewall σταθερά ενώ αλλάζετε μία ρύθμιση μεταφοράς κάθε φορά, γιατί μια αλλαγή πιστοποιητικού και μια αλλαγή αναμεταδότη που πέφτουν στην ίδια δοκιμή δεν σας λένε ποια κίνησε τη χειραψία. Μια αναντιστοιχία ονόματος ή CA αποτυγχάνει στο ίδιο σημείο με έναν αναμεταδότη που δεν βρέθηκε ποτέ, γι' αυτό αυτός ο αντιέλεγχος ανήκει στο ίδιο πέρασμα.

Μετά επιβεβαιώστε ότι κάθε δήλωση βρίσκεται στο αρχείο όπου ανήκει:

• Το am_relay: true στον host προώθησης και αυτός ο host προσβάσιμος σε UDP και από τις δύο πλευρές.
• Το relays: να ονομάζει τη διεύθυνση Nebula αυτού του host στον προορισμό.
• Το use_relays: true στον peer που ξεκινά τη σύνδεση.
• Κανόνες εισερχομένων στον προορισμό που επιτρέπουν ακόμη την πραγματική πηγή μετά την αλλαγή της διαδρομής.