Μπορούν οι πελάτες σε δύο διακομιστές OpenVPN να φτάσουν ο ένας τον άλλον;

Η στήση ενός δεύτερου OpenVPN διακομιστή σάς δίνει ένα δεύτερο σημείο σύνδεσης για πελάτες και τίποτα περισσότερο. Δεν βάζει αυτούς τους πελάτες στο δίκτυο του πρώτου διακομιστή, και η επιλογή client-to-client αλλάζει μόνο την προώθηση μέσα σε μία διεργασία διακομιστή. Οι δύο δεξαμενές γίνονται ένα δίκτυο όταν δρομολογείτε μεταξύ τους σκόπιμα, με έναν υπεύθυνο για κάθε κατεύθυνση. Όλα παρακάτω προϋποθέτουν λειτουργία TUN στον χώρο χρήστη με αυτή την εσωτερική προώθηση απενεργοποιημένη, ώστε ο πυρήνας να παίρνει την απόφαση.

Ο μύθος: μία λίστα λογαριασμών, ένα δίκτυο

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

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

Δώστε σε κάθε πύλη τη δική της δεξαμενή και διεύθυνση διαμεταγωγής

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

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

Εγκαταστήστε τη διαδρομή και στις δύο πλευρές

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

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

Σπρώξτε τη διαδρομή του πελάτη χωρίς να προσποιείστε ιδιοκτησία

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

push "route 10.64.20.0 255.255.255.0"

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

Αποδείξτε ένα αίτημα και αρνηθείτε ένα άλλο

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

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

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