Πώς να στήσεις ένα τεστ WireGuard με δύο peers που αποδεικνύει μία διαδρομή

Ένα τεστ WireGuard που μεταφέρει προεπιλεγμένη διαδρομή, πρόθεμα LAN, DNS και εξαίρεση τείχους προστασίας δεν μπορεί να σου πει ποιο από αυτά χάλασε. Περίκοψέ το σε δύο peers, ένα ζεύγος διευθύνσεων και μία επιτρεπτή υπηρεσία, και η βλάβη δεν έχει πού να κρυφτεί. Η βαρετή βάση είναι η διάγνωση. Χτίσε την πρώτη· παίρνει δεκαπέντε λεπτά και σου γλιτώνει το απόγευμα που αλλιώς θα περνούσες μαντεύοντας.

Αυτό που αποδεικνύει η βάση είναι στενότερο απ' ό,τι περιμένουν οι περισσότεροι. Αποδεικνύει ότι δύο ταυτότητες συμφωνούν, ότι το UDP φτάνει στη θύρα ακρόασης και ότι ένας επιτρεπτός προορισμός μεταφέρει αίτημα. Το forwarding, το NAT, οι διαδρομές LAN και το DNS είναι ξεχωριστές λειτουργίες που προστίθενται μετά, μία κάθε φορά.

Κλειδιά, διευθύνσεις και το μοναδικό endpoint

Δημιούργησε ζεύγος κλειδιών σε κάθε σύστημα και μετακίνησε μεταξύ τους μόνο τα δημόσια μισά. wg genkey | tee privatekey | wg pubkey > publickey είναι η τεκμηριωμένη μονόγραμμη εντολή, και αφήνει το ιδιωτικό κλειδί σε ένα αρχείο που μπορείς έπειτα να προστατεύσεις. Διάλεξε διευθύνσεις τούνελ από ένα εύρος που δεν εμφανίζεται σε καμία άλλη διαμόρφωση που έχεις, όπως 10.99.0.1/24 και 10.99.0.2/24. Σημείωσε ποια διεύθυνση ανήκει σε ποιο μηχάνημα, γιατί κάθε επόμενος έλεγχος εξαρτάται από αυτή την αντιστοίχιση.

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

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

Τα πεδία που ανήκουν στο wg και εκείνα που δεν ανήκουν

Το βασικό σύνολο πεδίων είναι μικρό: PrivateKey και ListenPort κάτω από το Interface, PublicKey, AllowedIPs και Endpoint κάτω από το Peer. Τα Address και DNS ανήκουν στο wg-quick και όχι στο ίδιο το wg, και αυτή η διάκριση δαγκώνει τη στιγμή που η ίδια διαμόρφωση περνά σε άλλο εργαλείο.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

Το AllowedIPs κουβαλά δύο δουλειές μαζί. Επιλέγει ποιοι προορισμοί μπαίνουν στο τούνελ, και εξουσιοδοτεί τον peer να χρησιμοποιεί αυτές τις διευθύνσεις προέλευσης κατά την άφιξη. Γι' αυτό η αντίστοιχη εγγραφή στην άλλη πλευρά πρέπει να ονομάζει ακριβώς τη διεύθυνση του τούνελ σου· ένα /32 για λάθος peer διαβάζεται ως πρόβλημα δρομολόγησης και συμπεριφέρεται ως πρόβλημα εξουσιοδότησης. Το Γρήγορη εκκίνηση του WireGuard δείχνει το ίδιο σχήμα δύο peers με τη βασική διατύπωση αν θέλεις να συγκρίνεις ονόματα πεδίων.

Διαβάζοντας το handshake αντί για το εικονίδιο

Σήκωσε τη διεπαφή μέσω ό,τι τη διαχειρίζεται, μετά διάβασε κατάσταση αντί για φωτάκι. wg show εκτυπώνει το τελευταίο handshake ανά peer μαζί με μετρητές byte, και ένα handshake μέσα στα τελευταία λεπτά σημαίνει ότι κλειδιά, endpoint και διαδρομή UDP δουλεύουν όλα. Ένας μετρητής που ανεβαίνει μόνο προς μία κατεύθυνση είναι η δική του απάντηση, και δεν είναι η ίδια βλάβη με ένα handshake που δεν γίνεται ποτέ.

Οι δύο βλάβες υπονοούν διαφορετικές έρευνες. Η παντελής απουσία handshake δείχνει αναντιστοιχία κλειδιών, λάθος Endpoint, μπλοκαρισμένο UDP ή τείχος προστασίας που ρίχνει το ίδιο το handshake. Ένα handshake που πετυχαίνει ενώ τα δεδομένα δεν πάνε πουθενά δείχνει AllowedIPs, υπηρεσία που δεν ακούει στη διεύθυνση του τούνελ, ή τείχος προστασίας υπολογιστή που δέχεται τη θύρα για το LAN αλλά όχι για τη διεπαφή του τούνελ. Αυτά είναι διαφορετικά μισά του συστήματος, και η βάση τα χωρίζει πριν αρχίσεις να αλλάζεις κανόνες.

Αποδεικνύοντας μία επιτρεπτή υπηρεσία, μετά το αντίστροφο

Κάνε ένα αίτημα στη διεύθυνση τούνελ του άλλου peer σε μια υπηρεσία που υποτίθεται ότι απαντά, και διάλεξε κάτι καλύτερο από ping. Μια απούσα απάντηση ICMP μπορεί να είναι φιλτράρισμα υπολογιστή και όχι βλάβη τούνελ, οπότε ένα σιωπηλό ping δεν αποδεικνύει καμία κατεύθυνση. Μια σύνδεση TCP σε θύρα που ξέρεις ότι είναι ανοιχτή, ή ένα αίτημα που επιστρέφει δεδομένα, σου δίνει απάντηση που μπορείς να ερμηνεύσεις.

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

Κρατώντας τη βάση ως αναφορά

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

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