Ο πελάτης OpenVPN φτάνει στον διακομιστή αλλά όχι στους κεντρικούς υπολογιστές LAN: λίστα ελέγχου

Ο πελάτης λέει συνδεδεμένος, η διεύθυνση της σήραγγας απαντά σε ping, και τίποτα στο LAN του γραφείου δεν ανταποκρίνεται. Το βλέπω σχεδόν μετά από κάθε αναβάθμιση πελάτη, και το πρώτο ένστικτο είναι να ανοίξω το τείχος προστασίας, που συνήθως είναι λάθος κίνηση: η σήραγγα είναι εντάξει, και η διακοπή βρίσκεται σε ένα από τα τρία άλματα που πρέπει να περάσει το πακέτο. Διαβείτε τη διαδρομή με τη σειρά που την ακολουθεί το πακέτο, πρώτα η διαδρομή του πελάτη, μετά η προώθηση στον διακομιστή, μετά το ταξίδι της επιστροφής, και θα βρείτε τον υπεύθυνο της βλάβης σε λίγα λεπτά.

Πρώτο βήμα: παρατηρήστε την απόφαση δρομολόγησης του πελάτη

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

ip route get 192.168.50.10

Αν η απάντηση αναφέρει τον φυσικό σας προσαρμογέα και την πύλη του γραφείου, καμία αλλαγή στην πλευρά του διακομιστή δεν μπορεί να βοηθήσει. OpenVPN διανέμει διαδρομές μόνο όταν ο διακομιστής τις σπρώχνει, οπότε αναζητήστε push "route 192.168.50.0 255.255.255.0" στη διαμόρφωση του διακομιστή και μετά επανασυνδέστε τον πελάτη. Οι περισσότεροι πελάτες εφαρμόζουν τις ωθημένες διαδρομές κατά τη σύνδεση, όχι όταν επαναφορτώνετε το προφίλ.

Στα Windows η ίδια ερώτηση έχει διαφορετική εντολή. Find-NetRoute -RemoteIPAddress 192.168.50.10 εκτυπώνει τη διεπαφή και το επόμενο άλμα που θα διάλεγε η στοίβα, και route print -4 δείχνει αν το ωθημένο πρόθεμα υπάρχει καθόλου.

Δεύτερο βήμα: επιβεβαιώστε ότι ο διακομιστής θα προωθήσει το πακέτο

Αν η διαδρομή του πελάτη είναι σωστή, το πακέτο φτάνει στον διακομιστή και ο διακομιστής πρέπει να δεχτεί να το προωθήσει. Ο διακόπτης του πυρήνα είναι η πρώτη πύλη, και το sysctl net.ipv4.ip_forward πρέπει να επιστρέψει 1. Η ρύθμισή του με echo 1 > /proc/sys/net/ipv4/ip_forward λειτουργεί μέχρι την επόμενη επανεκκίνηση, και γι’ αυτό ακριβώς το ίδιο παράπονο επιστρέφει εβδομάδες αργότερα.

Γράψτε το κάπου που επιβιώνει από επανεκκίνηση:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Η δεύτερη πύλη είναι ο πίνακας φίλτρων. Ένας κεντρικός υπολογιστής με εγκατεστημένο Docker συχνά φέρει πολιτική FORWARD με τιμή DROP, και η σήραγγα κληρονομεί αυτή την απόφαση. Το iptables -L FORWARD -v -n δείχνει και την πολιτική και τους μετρητές πακέτων· αν η πολιτική είναι DROP, η προώθηση χρειάζεται ρητή αποδοχή για την κατεύθυνση από τη σήραγγα προς το LAN και μία για την απάντηση.

Τρίτο βήμα: ακολουθήστε το πακέτο στο LAN και αναζητήστε την απάντηση

Παρατηρήστε και τις δύο πλευρές του διακομιστή ταυτόχρονα. Καταγράψτε στη σήραγγα και στη διεπαφή LAN, φιλτραρισμένα σε έναν πελάτη και έναν κεντρικό υπολογιστή, ώστε η έξοδος να παραμένει αναγνώσιμη:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Τα αιτήματα που εμφανίζονται στο tun0 και ξανά στο eth0 με πηγή 10.8.0.x, και μετά ακολουθεί σιωπή, σημαίνουν ότι το πακέτο έφτασε και η απάντηση πήγε αλλού. Ο κεντρικός υπολογιστής LAN απαντά στην προεπιλεγμένη πύλη του, η πύλη δεν έχει διαδρομή για τη δεξαμενή VPN, και η απάντηση πεθαίνει στον δρομολογητή του LAN. Το ping στον κεντρικό υπολογιστή LAN από τον διακομιστή δεν αποδεικνύει τίποτα γι’ αυτή τη διαδρομή, γιατί αυτή η κίνηση δεν διασχίζει ποτέ τη σήραγγα.

Τέταρτο βήμα: επιλέξτε ανάμεσα σε μετάφραση και διαδρομή επιστροφής

Δύο επισκευές κλείνουν την τρύπα, και η επιλογή έχει συνέπειες πέρα από το αν δουλεύει το ping. Η μετάφραση πηγής κάνει τον διακομιστή φαινομενικό αποστολέα:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Περιορίστε τον κανόνα στη δεξαμενή και στη διεπαφή LAN, μετά κάντε τον μόνιμο, αλλιώς η επόμενη επαναφόρτωση του τείχους προστασίας αφαιρεί ήσυχα τη διόρθωσή σας. Το κόστος είναι η ταυτότητα: κάθε πελάτης φαίνεται σαν τον διακομιστή VPN στα αρχεία καταγραφής LAN και στους κανόνες πρόσβασης, και per-client policy becomes guesswork.

Μια στατική διαδρομή για το 10.8.0.0/24 στον δρομολογητή LAN, που δείχνει στον διακομιστή VPN, κρατά τις διευθύνσεις των πελατών ορατές και είναι η καλύτερη μακροπρόθεσμη απάντηση όταν αυτός ο δρομολογητής είναι δικός σας. Πολλοί χώροι τρέχουν και τα δύο για καιρό, NAT για την άμεση επισκευή και τη διαδρομή μόλις γραφτεί η πολιτική του τείχους προστασίας. Αν ο διακομιστής είναι ομότιμος από τοποθεσία σε τοποθεσία και όχι δεξαμενή, η πλευρά του διακομιστή χρειάζεται επίσης ένα iroute για το απομακρυσμένο υποδίκτυο, αλλιώς η διαδρομή του ομοτίμου υπάρχει αλλά η κίνηση των πελατών δεν συνδέεται ποτέ με αυτήν.

Πέμπτο βήμα: επαληθεύστε από τον πελάτη και καταγράψτε τι άλλαξε

Κλείστε τον κύκλο από τον πελάτη, όχι από τον διακομιστή. Συνδεθείτε σε μια πραγματική υπηρεσία στον κεντρικό υπολογιστή LAN, μετά επιβεβαιώστε ότι οι μετρητές μετάφρασης κινήθηκαν με το iptables -t nat -L POSTROUTING -v -n, γιατί ένας κανόνας με μηδέν πακέτα είναι κανόνας που δεν ταίριαξε ποτέ. Το conntrack -L -s 10.8.0.5 δείχνει τη ροή και την κατάστασή της όταν χρειάζεστε απόδειξη ότι η κατεύθυνση επιστροφής παρακολουθείται.

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