Πελάτης VPN σε διακομιστή LAN: γιατί οι απαντήσεις φεύγουν με λάθος δρόμο

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

Η απάντηση είναι νέο πακέτο, όχι αντιστροφή

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

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

Κρατήστε δύο υποδίκτυα στο μυαλό σας καθώς διαβάζετε τα υπόλοιπα. Το ένα είναι η δεξαμενή διευθύνσεων VPN από την οποία έρχονται οι απομακρυσμένοι πελάτες, σε αυτό το παράδειγμα 10.64.0.0/24. Το άλλο είναι το LAN που πρέπει να συνεχίσει να λειτουργεί, 172.16.24.0/24 με τον δρομολογητή του στο 172.16.24.1. Το σφάλμα είναι ότι η κίνηση μεταξύ τους αποφασίζεται από την προεπιλεγμένη διαδρομή.

Αποδείξτε το με την καταγραφή και την αναζήτηση

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

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

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

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

Εγκαταστήστε τη στενότερη διαδρομή που ξεπερνά τη σήραγγα

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Χρησιμοποιήστε replace αντί για add, επειδή ένας πελάτης που επανασυνδέεται θα έχει εγκαταστήσει τη δική του εγγραφή και ένα δεύτερο add αποτυγχάνει με σφάλμα υπάρχουσας διαδρομής που διαβάζεται σαν πρόβλημα δικαιωμάτων. Σε κεντρικό υπολογιστή Windows το ισοδύναμο είναι route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, όπου το -p διατηρεί την εγγραφή μετά από επανεκκινήσεις, αφού ο πελάτης μπορεί να ξαναχτίσει τον πίνακα όταν η σήραγγα επανέλθει. Σε σύγχρονο κεντρικό υπολογιστή Windows το υποστηριζόμενο ισοδύναμο είναι New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, με την παλαιότερη εντολή route να διατηρείται ως παλαιότερη μορφή.

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

Κρατήστε την απάντηση μετά από επανασύνδεση

Μια διαδρομή που προστέθηκε με το χέρι επιβιώνει το πολύ μέχρι την επόμενη επανασύνδεση. Αν η δεξαμενή πελατών είναι δυναμική, καρφιτσώστε την στη διαμόρφωση του διακομιστή ώστε το πρόθεμα που δρομολογήσατε να παραμείνει το πρόθεμα που λαμβάνουν οι πελάτες; διαφορετικά η εγγραφή δείχνει σε κενό εύρος και το σύμπτωμα επιστρέφει εβδομάδες αργότερα χωρίς προφανή αιτία. Το να γράψετε τη διαδρομή στο δικό του up-script του πελάτη είναι η άλλη αξιόπιστη επιλογή, επειδή εκτελείται αφού ο πελάτης ξαναγράψει τον πίνακα.

Ένα τείχος προστασίας με κατάσταση μπορεί ακόμη να νικήσει μια σωστή διαδρομή. Αν η καταγραφή τώρα δείχνει την απάντηση να φεύγει από eth0 και ο πελάτης εξακολουθεί να λαμβάνει λήξη χρόνου, ελέγξτε αν ο κεντρικός υπολογιστής απορρίπτει το πακέτο πριν σταλεί. Αυστηρό φιλτράρισμα αντίστροφης διαδρομής και net.ipv4.conf.all.rp_filter ρυθμισμένο σε 1 απορρίπτουν πακέτα των οποίων η πηγή δεν θα δρομολογούνταν πίσω από τη διεπαφή από την οποία έφτασαν, που είναι ακριβώς η ασύμμετρη περίπτωση που μόλις δημιουργήσατε και μετά διορθώσατε, και η κατάσταση conntrack λέει την ίδια ιστορία για τις προωθημένες θύρες.

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