Peer του WireGuard μη προσβάσιμο ενώ ένα άλλο δουλεύει: λίστα ελέγχου

Ένας peer του WireGuard περνά κίνηση και ένας δεύτερος ολοκληρώνει τη χειραψία αλλά δεν φτάνει ποτέ σε τίποτα πίσω από το τούνελ. Ο peer που δουλεύει σας λέει ότι η διεπαφή, η θύρα UDP και το κλειδί του διακομιστή είναι μάλλον εντάξει. Δεν σας λέει τίποτα για τα AllowedIPs του δεύτερου peer, την εσωτερική διεύθυνση προέλευσης ή τους κανόνες προώθησης ανάμεσά τους. Δουλέψτε τη λίστα με τη σειρά και σταματήστε στο πρώτο βήμα του οποίου η συνθήκη αποτυγχάνει.

Βήμα 1: Γράψτε τη διαδρομή που πρέπει να ακολουθήσει το πακέτο

Δύο πελάτες στον ίδιο κόμβο δεν φτάνουν αυτόματα ο ένας στον άλλο. Σε σχεδίαση κόμβου και ακτίνων ο διακομιστής λαμβάνει το πακέτο στο wg0 και πρέπει να το προωθήσει πάλι έξω από το wg0 προς τον άλλο peer, κάτι που απαιτεί προώθηση IP και κανόνα προώθησης. Σε άμεση σχεδίαση peer προς peer κάθε πλευρά χρειάζεται το endpoint της άλλης και τη διεύθυνση του τούνελ της μέσα στα AllowedIPs. Αποφασίστε ποια σχεδίαση αποσφαλματώνετε πριν διαβάσετε οποιαδήποτε ρύθμιση.

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

Βήμα 2: Συγκρίνετε τα AllowedIPs και στις δύο πλευρές, όχι μόνο στη μία

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

Διαβάστε τη ζωντανή κατάσταση αντί για το αρχείο, γιατί μια επαναφόρτωση μπορεί να απέτυχε σιωπηλά: sudo wg show wg0 allowed-ips. Στον διακομιστή η καταχώριση του peer που αποτυγχάνει πρέπει να περιλαμβάνει τη διεύθυνση του τούνελ του, για παράδειγμα 10.90.0.3/32. Στον πελάτη η καταχώριση του peer-διακομιστή πρέπει να περιλαμβάνει τον προορισμό που δοκιμάζετε, είτε είναι η διεύθυνση τούνελ του κόμβου είτε το απομακρυσμένο υποδίκτυο. Τα επικαλυπτόμενα εύρη κάνουν την αναζήτηση ασαφή και μπορούν να επιλέξουν peer που δεν θέλατε, γι’ αυτό κρατήστε τα χωριστά.

Βήμα 3: Ελέγξτε την εσωτερική διεύθυνση προέλευσης

Ένας πελάτης που δρομολογεί το 10.90.0.3 μέσω wg0 αλλά στέλνει πακέτα από τη διεύθυνση Wi-Fi του θα απορριφθεί από τον παραλήπτη, γιατί η προέλευση δεν ταιριάζει με τα AllowedIPs του peer. Επιβεβαιώστε τι επιλέγει πραγματικά ο πυρήνας με ip route get 10.90.0.3 from 10.90.0.2, και επιβεβαιώστε τη διεύθυνση που έχει ανατεθεί στη διεπαφή του τούνελ με ip -brief addr show wg0.

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

Βήμα 4: Ελέγξτε την προώθηση του κόμβου και τη διαδρομή επιστροφής

Αν ο κόμβος πρέπει να προωθεί μεταξύ peers, ο πυρήνας χρειάζεται net.ipv4.ip_forward=1, και το τείχος προστασίας πρέπει να δέχεται τη ροή που προωθείται: είσοδος στο wg0, έξοδος στο wg0, από τη διεύθυνση τούνελ του αποστολέα προς του παραλήπτη. Συχνή αστοχία είναι ένας κανόνας εισόδου που δέχεται UDP 51820 αλλά δεν υπάρχει κανόνας προώθησης], οπότε η χειραψία πετυχαίνει και το ωφέλιμο φορτίο πεθαίνει. Καταγράψτε τους ενεργούς κανόνες με sudo nft list ruleset ή το αντίστοιχο για τον διαχειριστή τείχους προστασίας σας.

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

Τέλος, διαχωρίστε τη χειραψία από τα δεδομένα. Ένας peer που ολοκληρώνει τη χειραψία αλλά κολλάει σε μεγάλες μεταφορές έχει συνήθως πρόβλημα MTU ή MSS σε εκείνη τη συγκεκριμένη διαδρομή, όχι πρόβλημα AllowedIPs. Δοκιμάστε πρώτα με ένα μικρό ping, μετά με ένα πλήρους μεγέθους, και συγκρίνετε τους δύο peers.

Βήμα 5: Αλλάξτε ένα πράγμα και κρατήστε τον peer που δουλεύει άθικτο

Κάντε μία μόνο αλλαγή στη διαδρομή που αποτυγχάνει και δοκιμάστε ξανά και τους δύο peers. Η αντικατάσταση των AllowedIPs κάθε peer με 0.0.0.0/0 είναι ο ταχύτερος τρόπος να σπάσετε τον peer που ήδη δούλευε, γιατί αλλάζει την απόφαση δρομολόγησης για όλη την κίνηση σε εκείνη τη διεπαφή. Επεξεργαστείτε την μία εγγραφή, επαναφορτώστε και διαβάστε ξανά τη ζωντανή κατάσταση.

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