Ένας κόμβος OpenVPN, τρία LAN: σχέδιο διευθύνσεων και αρχεία iroute

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

Δουλέψτε τα βήματα με τη σειρά. Το καθένα εξαρτάται από το σχέδιο του προηγούμενου βήματος, και κανένα δεν απαιτεί νέα αρχή πιστοποίησης.

Ξεκινήστε με ένα σχέδιο που κανείς δεν χρειάζεται να μαντέψει

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

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

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Πείτε στον πυρήνα του κόμβου πού βρίσκονται τα τμήματα

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

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

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

Δώστε σε κάθε τμήμα τις διαδρομές που χρειάζεται

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

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

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

Δοκιμάστε και προς τις δύο κατευθύνσεις πριν το θεωρήσετε έτοιμο

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

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

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

Η σχεδίαση κρατιέται ενιαία γιατί κάθε επίπεδο έχει μία δουλειά: το σχέδιο κρατά τα προθέματα μοναδικά, η διαδρομή στον πυρήνα μετακινεί πακέτα, η iroute ονομάζει τον ιδιοκτήτη, και το τείχος προστασίας αποφασίζει τι επιτρέπεται. Όταν κάτι σπάσει, αυτή η λίστα είναι και η σειρά με την οποία θα το ελέγξετε.