Ο δρομολογημένος πελάτης VPN φτάνει στον διακομιστή αλλά όχι στους κεντρικούς υπολογιστές του LAN
Ένας δρομολογημένος πελάτης μπορεί να συνδεθεί και παρόλα αυτά να χάνει κάθε απάντηση από έναν κεντρικό υπολογιστή του LAN. Προσθέστε τη διαδρομή επιστροφής στην πύλη και μετά ελέγξτε την προώθηση και το φιλτράρισμα πακέτων.
Η σήραγγα ανεβαίνει, ο πελάτης κάνει ping στον διακομιστή VPN και ένας κοινόχρηστος φάκελος σε μηχάνημα ένα άλμα πιο πέρα δεν απαντά ποτέ. Τίποτα στη διαμόρφωση του πελάτη δεν το εξηγεί, γιατί το αίτημα όντως έφυγε από τον πελάτη και όντως έφτασε. Αυτό που απέτυχε είναι η διαδρομή επιστροφής και η συσκευή που απέτυχε είναι συνήθως η πύλη του LAN και όχι ο κεντρικός υπολογιστής VPN. Η ιχνηλάτηση του πακέτου απάντησης εξηγεί όλη αυτή την κατηγορία συμπτωμάτων.
Ακολουθήστε την απάντηση, όχι το αίτημα
Ο διακομιστής VPN αποκρυπτογραφεί το πακέτο του πελάτη και το προωθεί στο LAN με τη διεύθυνση του πελάτη ακόμη στο πεδίο προέλευσης. Ο κεντρικός υπολογιστής προορισμού απαντά σε αυτή τη διεύθυνση και τώρα ο δικός του πίνακας δρομολόγησης αποφασίζει τα πάντα. Η προεπιλεγμένη πύλη του δεν γνωρίζει τίποτα για τη δεξαμενή της σήραγγας, οπότε η απάντηση φεύγει προς τον πάροχο διαδικτύου και απορρίπτεται κάπου σε εκείνη τη διαδρομή.
Στον πελάτη το σύμπτωμα είναι ένα σιωπηλό χρονικό όριο: καμία άρνηση, κανένα reset, απλώς τίποτα. Η περιήγηση σε έναν κοινόχρηστο φάκελο κολλάει, το ping αναφέρει ότι δεν υπάρχει απάντηση και τα αρχεία καταγραφής του διακομιστή φαίνονται υγιή επειδή ο διακομιστής έκανε τη δουλειά του.
Βάλτε τη διαδρομή επιστροφής εκεί όπου κοιτούν οι κεντρικοί υπολογιστές
Κάθε κεντρικός υπολογιστής του LAN συμβουλεύεται την προεπιλεγμένη πύλη του, άρα η πύλη είναι η μόνη συσκευή που πρέπει να ξέρει πού βρίσκεται η δεξαμενή της σήραγγας. Προσθέστε εκεί μια στατική διαδρομή και κάθε κεντρικός υπολογιστής κληρονομεί τη σωστή διαδρομή χωρίς να τον αγγίξετε.
Αν η πύλη διανέμει τη δική της διεύθυνση ως επιλογή DHCP, διανείμετε τη διαδρομή με αυτόν τον τρόπο ώστε οι νέες μηχανές να την παίρνουν αυτόματα. Διαφορετικά η διαδρομή ζει σε ένα αρχείο διαμόρφωσης και εξαφανίζεται στην επόμενη ανακατασκευή.
# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14
Γιατί το Source NAT φαίνεται να το διορθώνει
Η συγκάλυψη της δεξαμενής πελατών πίσω από τη διεύθυνση του διακομιστή VPN αφαιρεί το πρόβλημα αφαιρώντας τη διεύθυνση του πελάτη από το πακέτο. Οι απαντήσεις επιστρέφουν τότε στον διακομιστή, που ξέρει ήδη πώς να φτάσει στη σήραγγα, και όλα λειτουργούν. Το κόστος είναι ότι οι εσωτερικοί κεντρικοί υπολογιστές δεν βλέπουν πια ποιος είναι ο πελάτης και κάθε σύνδεση μοιάζει να προέρχεται από μία μηχανή.
Αυτή η ανταλλαγή είναι μερικές φορές σωστή, για παράδειγμα όταν μια συσκευή προμηθευτή δεν μπορεί να πάρει στατική διαδρομή. Μην κάνετε τον κανόνα ευρύτερο από τη σημερινή δεξαμενή, γιατί ένας κανόνας γραμμένος για /24 παύει να ταιριάζει την ημέρα που η δεξαμενή θα αριθμηθεί ξανά σε /16, και το πρώτο σημάδι είναι μια παρτίδα νέων πελατών που συνδέονται και δεν φτάνουν πουθενά.
iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v
Η διαδρομή στο cloud χρειάζεται τρεις ρυθμίσεις
Σε ένα VPC το ίδιο κενό επιστρέφει με άλλη μορφή, γιατί το υποδίκτυο δεν έχει καθόλου διαδρομή για το εύρος των πελατών. Ο πίνακας δρομολόγησης χρειάζεται μια εγγραφή για τη δεξαμενή της σήραγγας που να στοχεύει τη διεπαφή δικτύου του στιγμιοτύπου, και η διεπαφή χρειάζεται απενεργοποιημένο τον έλεγχο προέλευσης και προορισμού ώστε η πλατφόρμα να δέχεται πακέτα των οποίων η προέλευση δεν είναι η δική της διεύθυνση. Οι ομάδες ασφαλείας και τα ACL δικτύου πρέπει επίσης να επιτρέπουν τη δεξαμενή και προς τις δύο κατευθύνσεις.
Κάθε παράλειψη παράγει ξεχωριστή μερική αποτυχία. Παραλείψτε την εγγραφή του πίνακα δρομολόγησης και τα ιδιωτικά στιγμιότυπα απαντούν σε ένα υποδίκτυο που δεν μπορεί να μεταφέρει την απάντηση πίσω στη δεξαμενή. Με τον έλεγχο ακόμη ενεργό, η πλατφόρμα απορρίπτει την απάντηση αφού το στιγμιότυπο την έχει ήδη στείλει. Χωρίς τον κανόνα της ομάδας ασφαλείας το ίδιο το αίτημα δεν φτάνει ποτέ και ο πελάτης βλέπει το χρονικό όριο ένα επίπεδο νωρίτερα.
Εκτελέστε τους ελέγχους με αυτή τη σειρά
Επιβεβαιώστε την προώθηση και την πολιτική φιλτραρίσματος πριν κατηγορήσετε τη δρομολόγηση, γιατί ένας κεντρικός υπολογιστής που δεν θα προωθήσει αποτυγχάνει με τον ίδιο σιωπηλό τρόπο. Μετά διαβάστε την ενεργή ρύθμιση αντίστροφης διαδρομής στη διεπαφή που μεταφέρει τη σήραγγα, αφού ένα αυστηρό φίλτρο μπορεί να απορρίψει απαντήσεις που φτάνουν από απροσδόκητη κατεύθυνση.
Τελειώστε με μια καταγραφή στον κεντρικό υπολογιστή του LAN όσο ο πελάτης του κάνει ping. Ένα αίτημα που φτάνει χωρίς αντίστοιχη απάντηση αποδεικνύει τη διαδρομή επιστροφής και ένα αίτημα που δεν φτάνει ποτέ μεταφέρει το σφάλμα πίσω στον διακομιστή ή στη σήραγγα.
sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp
Ο έλεγχος προέλευσης και προορισμού τεκμηριώνεται στον οδηγό ελαστικών διεπαφών δικτύου. Ρυθμίστε τον στη διεπαφή που μεταφέρει πραγματικά την κίνηση της σήραγγας, όχι σε έναν άσχετο προσαρμογέα που είναι συνδεδεμένος στο ίδιο στιγμιότυπο.