Οι απομακρυσμένοι χρήστες δεν φτάνουν στη δεύτερη τοποθεσία μέσω του κόμβου VPN

Ένας απομακρυσμένος χρήστης συνδέεται στον κόμβο, φτάνει στον διακομιστή αρχείων στο δικό του LAN και όλα φαίνονται υγιή. Μετά ανοίγει έναν κοινόχρηστο φάκελο στο 10.20.0.50 στα κεντρικά γραφεία, τον οποίο ο κόμβος φτάνει μέσω ξεχωριστού τούνελ τοποθεσίας-με-τοποθεσία, και λήγει ο χρόνος αναμονής. Και τα δύο τούνελ είναι ενεργά και οι δύο μετρητές ανεβαίνουν, άρα κανένα τούνελ δεν είναι σπασμένο. Η διέλευση από τον κόμβο είναι τρεις αποφάσεις δρομολόγησης σε τρεις συσκευές, και ένα τούνελ μεταφέρει μόνο τα προθέματα για τα οποία χτίστηκε. Ακολουθεί η σειρά με την οποία ελέγχω, και η εντολή που δείχνει αν κάθε βήμα ισχύει.

Η διέλευση απαιτεί τρεις αναζητήσεις, όχι ένα τούνελ

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

Γι' αυτό ο έλεγχος κάθε τούνελ χωριστά αποδεικνύει τόσο λίγα. Το ping στη διεύθυνση LAN του κόμβου ασκεί την πρώτη απόφαση, και το ping στον κόμβο από τα κεντρικά γραφεία ασκεί την τρίτη. Το πακέτο που αποτυγχάνει έχει ως πηγή τη δεξαμενή χρηστών και ως προορισμό τη δεύτερη τοποθεσία, οπότε γράψτε πρώτα αυτά τα προθέματα. Εδώ η δεξαμενή είναι 10.80.0.0/24, το LAN του κόμβου είναι 10.10.0.0/24 και τα κεντρικά γραφεία είναι 10.20.0.0/24.

Σπρώξτε το απομακρυσμένο πρόθεμα στον απομακρυσμένο πελάτη

Σε έναν διακομιστή απομακρυσμένης πρόσβασης OpenVPN ο πελάτης μαθαίνει τις διαδρομές κατά τη σύνδεση. Χωρίς push, ένας πελάτης με διαχωρισμένο τούνελ στέλνει το 10.20.0.50 στη δική του πύλη και το πακέτο δεν μπαίνει ποτέ στο τούνελ.

push "route 10.20.0.0 255.255.255.0"

Μια διαδρομή που σπρώχνεται ενεργοποιείται όταν συνδεθεί ο πελάτης, οπότε ένας χρήστης που μένει συνδεδεμένος δεν βλέπει τίποτα μέχρι να επανασυνδεθεί. Επαληθεύστε στον πελάτη: ip route get 10.20.0.50 σε Linux, route print σε Windows. Η έξοδος πρέπει να ονομάζει τη διεπαφή του τούνελ.

Το push δεν βοηθά τον κόμβο. Είναι μήνυμα προς τον πελάτη, όχι διαδρομή στον διακομιστή και όχι άδεια προώθησης, οπότε ένας κόμβος με τέλεια γραμμή push εξακολουθεί να ρίχνει τη ροή ένα άλμα πιο πέρα. Αυτός είναι ο συνήθης λόγος που οι άνθρωποι συμπεραίνουν ότι το push απέτυχε.

Δώστε στον κόμβο πραγματική διαδρομή εξόδου

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

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Όπου το σκέλος τοποθεσίας-με-τοποθεσία είναι το ίδιο OpenVPN, η διαδρομή μπορεί να ζει σε εκείνη τη διαμόρφωση με τη διεύθυνση τούνελ του ομότιμου ως πύλη: route 10.20.0.0 255.255.255.0 172.30.0.2. Η πύλη δεν είναι προαιρετική. Αν την παραλείψετε, το επόμενο άλμα πέφτει σε προεπιλογή της υλοποίησης, που διαφέρει μεταξύ πελάτη με μία απομακρυσμένη θέση και κόμβου με πολλούς ομότιμους.

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

Επεκτείνετε την απέναντι πλευρά στη δεξαμενή χρηστών

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

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Το local_ts της μίας συσκευής είναι το remote_ts της άλλης. Αντιγράψτε το μπλοκ του κόμβου στα κεντρικά γραφεία και το ζεύγος αντιστρέφεται, οπότε το θυγατρικό SA δεν ανεβαίνει ποτέ.

Η παλαιότερη σύνταξη ipsec.conf χρησιμοποιεί leftsubnet χωρισμένο με κόμμα. Η ενεργή συσχέτιση ασφαλείας κρατά τους επιλογείς που διαπραγματεύτηκε, οπότε επαναφέρετε το τούνελ μετά την αλλαγή. Ένας επιλογέας που άλλαξε στις 10:00 και δοκιμάστηκε απέναντι σε SA που ανέβηκε στις 09:40 εξακολουθεί να αποτυγχάνει, ενώ το αρχείο διαμόρφωσης φαίνεται σωστό καθ' όλη τη διάρκεια.

Έπειτα ελέγξτε το τελευταίο άλμα. Το ip route get 10.80.0.25 στο απομακρυσμένο άκρο πρέπει να δείχνει μέσα στο τούνελ. Αν η υπηρεσία χρησιμοποιεί δρομολογητή LAN ως προεπιλεγμένη πύλη της, ο δρομολογητής χρειάζεται και τη διαδρομή επιστροφής, αλλιώς η απάντηση πεθαίνει εκεί. Η εκτέλεση του tcpdump -ni eth1 host 10.80.0.25 σε εκείνο το τμήμα δείχνει αν η απάντηση έφυγε καθόλου από το άκρο.

Επιτρέψτε τη ροή στον κόμβο

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

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Το φιλτράρισμα αντίστροφης διαδρομής είναι η ήσυχη αποτυχία δίπλα του: με τα δύο σκέλη σε διαφορετικές διεπαφές, το rp_filter=1 μπορεί να ρίξει την απάντηση ενώ ο μετρητής του κανόνα αποδοχής δεν κινείται ποτέ. Συγκρίνετε το iptables -vnL FORWARD πριν και μετά από μια προσπάθεια. Ένας κανόνας που δεν αυξάνεται ποτέ δεν προσεγγίζεται, οπότε κοιτάξτε ένα επίπεδο πιο κάτω αντί να τον ξαναγράψετε.

Αν μόνο μία ομάδα χρειάζεται διέλευση, βάλτε τη διαδρομή σε αρχείο ανά πελάτη κάτω από το client-config-dir αντί να διευρύνετε το καθολικό push. Το Source NAT στον κόμβο αφαιρεί επίσης την ανάγκη διαδρομής επιστροφής στην απέναντι πλευρά, αλλά κρύβει τη διεύθυνση του χρήστη, οπότε τα αρχεία καταγραφής της απομακρυσμένης τοποθεσίας και οι κανόνες βάσει διευθύνσεων παύουν να ξεχωρίζουν τους χρήστες.

Επαληθεύστε από τον πελάτη και μετά κυλήστε πίσω αντίστροφα

Δοκιμάστε μια θύρα TCP, όχι μόνο ICMP, γιατί ένα ping μπορεί να περάσει ενώ η υπηρεσία μένει αποκλεισμένη. Τα nc -vz 10.20.0.50 445 και traceroute -n 10.20.0.50 από τον πελάτη δείχνουν αν το δεύτερο άλμα είναι η διεύθυνση του τούνελ του κόμβου. Στον κόμβο, το tcpdump -ni tun0 host 10.20.0.50 και το ίδιο φίλτρο στη διεπαφή τοποθεσίας-με-τοποθεσία: αίτημα και στα δύο χωρίς απάντηση σε κανένα μεταφέρει το πρόβλημα στην απέναντι πλευρά.

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

Κρατήστε λίστα επαναφοράς, γιατί άλλαξαν τέσσερα αντικείμενα και τρία ξεχνιούνται εύκολα: η διαδρομή που σπρώχτηκε, η διαδρομή του κόμβου, οι επιλογείς και οι κανόνες του τείχους προστασίας. Ανατρέψτε τα αντίστροφα, επαναφέρετε το SA και αφήστε έναν χρήστη να επανασυνδεθεί. Μια μερική επαναφορά αφήνει διαδρομή που δείχνει σε τούνελ που δεν ταιριάζει πλέον, και αυτό διαβάζεται δυσκολότερα από την αρχική σιωπή. Το εγχειρίδιο του OpenVPN 2.6 τεκμηριώνει τα push, route και iroute για την έκδοσή σας.