Μετεγκατάσταση από το OpenVPN στο WireGuard για ενοποίηση δικτύων σε ένα δίκτυο L2

Μετεγκατάσταση από το OpenVPN στο WireGuard για ενοποίηση δικτύων σε ένα δίκτυο L2

Θα ήθελα να μοιραστώ την εμπειρία μου από το συνδυασμό δικτύων σε τρία γεωγραφικά απομακρυσμένα διαμερίσματα, καθένα από τα οποία χρησιμοποιεί δρομολογητές με OpenWRT ως πύλη, σε ένα κοινό δίκτυο. Κατά την επιλογή μιας μεθόδου για το συνδυασμό δικτύων μεταξύ L3 με δρομολόγηση υποδικτύου και L2 με γεφύρωση, όταν όλοι οι κόμβοι δικτύου θα βρίσκονται στο ίδιο υποδίκτυο, προτιμήθηκε η δεύτερη μέθοδος, η οποία είναι πιο δύσκολη στη διαμόρφωση, αλλά παρέχει περισσότερες ευκαιρίες, καθώς είναι διαφανές σχεδιάστηκε χρήση τεχνολογιών στο δημιουργημένο δίκτυο Wake-on-Lan και DLNA.

Μέρος 1: Ιστορικό

Το OpenVPN επιλέχθηκε αρχικά ως το πρωτόκολλο για την υλοποίηση αυτής της εργασίας, αφού, πρώτον, μπορεί να δημιουργήσει μια συσκευή βρύσης που μπορεί να προστεθεί στη γέφυρα χωρίς προβλήματα και, δεύτερον, το OpenVPN υποστηρίζει λειτουργία μέσω του πρωτοκόλλου TCP, κάτι που ήταν επίσης σημαντικό, επειδή Κανένα από τα διαμερίσματα δεν είχε αποκλειστική διεύθυνση IP και δεν μπορούσα να χρησιμοποιήσω το STUN, επειδή για κάποιο λόγο ο ISP μου αποκλείει τις εισερχόμενες συνδέσεις UDP από τα δίκτυά τους, ενώ το πρωτόκολλο TCP μου επέτρεψε να προωθήσω τη θύρα διακομιστή VPN σε νοικιασμένο VPS χρησιμοποιώντας SSH. Ναι, αυτή η προσέγγιση δίνει μεγάλο φορτίο, καθώς τα δεδομένα είναι κρυπτογραφημένα δύο φορές, αλλά δεν ήθελα να εισαγάγω το VPS στο ιδιωτικό μου δίκτυο, καθώς υπήρχε ακόμα ο κίνδυνος τρίτων να αποκτήσουν τον έλεγχό του, επομένως, να έχουν μια τέτοια συσκευή στο οικιακό δίκτυο ήταν εξαιρετικά ανεπιθύμητη και αποφασίστηκε να πληρώσει για την ασφάλεια με ένα μεγάλο γενικό κόστος.

Για την προώθηση της θύρας στο δρομολογητή στον οποίο σχεδιαζόταν να αναπτυχθεί ο διακομιστής, χρησιμοποιήθηκε το πρόγραμμα sshtunnel. Δεν θα περιγράψω τις περιπλοκές της διαμόρφωσής του - αυτό γίνεται αρκετά εύκολα, απλώς σημειώνω ότι το καθήκον του ήταν να προωθήσει τη θύρα TCP 1194 από το δρομολογητή στο VPS. Στη συνέχεια, ο διακομιστής OpenVPN διαμορφώθηκε στη συσκευή tap0, η οποία ήταν συνδεδεμένη στη γέφυρα br-lan. Αφού έλεγξα τη σύνδεση με τον πρόσφατα δημιουργημένο διακομιστή από το φορητό υπολογιστή, έγινε σαφές ότι η ιδέα της προώθησης θύρας δικαιολογήθηκε και ο φορητός υπολογιστής μου έγινε μέλος του δικτύου του δρομολογητή, αν και δεν ήταν φυσικά σε αυτό.

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

  • 192.168.10.1 με εμβέλεια 192.168.10.2 - 192.168.10.80 για τον διακομιστή
  • 192.168.10.100 με εμβέλεια 192.168.10.101 - 192.168.10.149 για ρούτερ στο διαμέρισμα Νο. 2
  • 192.168.10.150 με εμβέλεια 192.168.10.151 - 192.168.10.199 για ρούτερ στο διαμέρισμα Νο. 3

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

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

και προσθέτοντας τις ακόλουθες γραμμές στο αρχείο /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

όπου flat1_id και flat2_id είναι τα ονόματα συσκευών που καθορίζονται κατά τη δημιουργία πιστοποιητικών για σύνδεση στο OpenVPN

Στη συνέχεια, οι πελάτες OpenVPN διαμορφώθηκαν στους δρομολογητές, οι συσκευές tap0 και στα δύο προστέθηκαν στη γέφυρα br-lan. Σε αυτή τη φάση όλα έδειχναν να είναι εντάξει, αφού και τα τρία δίκτυα βλέπονται και λειτουργούν ως σύνολο. Ωστόσο, αποδείχθηκε μια όχι πολύ ευχάριστη λεπτομέρεια: μερικές φορές οι συσκευές μπορούσαν να λάβουν μια διεύθυνση IP όχι από τον δρομολογητή τους, με όλες τις επακόλουθες συνέπειες. Για κάποιο λόγο, ο δρομολογητής σε ένα από τα διαμερίσματα δεν είχε χρόνο να απαντήσει έγκαιρα στο DHCPDISCOVER και η συσκευή έλαβε λάθος διεύθυνση. Συνειδητοποίησα ότι πρέπει να φιλτράρω τέτοια αιτήματα στο tap0 σε καθένα από τους δρομολογητές, αλλά όπως αποδείχθηκε, το iptables δεν μπορεί να λειτουργήσει με μια συσκευή εάν είναι μέρος μιας γέφυρας και το ebtables θα πρέπει να με σώσει. Προς λύπη μου, δεν ήταν στο υλικολογισμικό μου και έπρεπε να φτιάξω ξανά τις εικόνες για κάθε συσκευή. Κάνοντας αυτό και προσθέτοντας αυτές τις γραμμές στο /etc/rc.local κάθε δρομολογητή, το πρόβλημα λύθηκε:

ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

Αυτή η διαμόρφωση διήρκεσε τρία χρόνια.

Μέρος 2: Παρουσίαση του WireGuard

Πρόσφατα, το Διαδίκτυο μιλάει όλο και περισσότερο για το WireGuard, θαυμάζοντας την απλότητα της διαμόρφωσής του, την υψηλή ταχύτητα μεταφοράς, το χαμηλό ping με συγκρίσιμη ασφάλεια. Η αναζήτηση περισσότερων πληροφοριών σχετικά με αυτό κατέστησε σαφές ότι ούτε η εργασία ως μέλος γέφυρας ούτε η εργασία στο πρωτόκολλο TCP υποστηρίζεται από αυτό, γεγονός που με έκανε να σκεφτώ ότι δεν υπάρχουν ακόμα εναλλακτικές λύσεις στο OpenVPN για μένα. Έτσι, αναβάλλω τη γνωριμία με το WireGuard.

Πριν από λίγες μέρες, διαδόθηκε η είδηση ​​μέσω πόρων που σχετίζονται με τον έναν ή τον άλλον τρόπο με το IT ότι το WireGuard θα συμπεριληφθεί επιτέλους στον πυρήνα του Linux, ξεκινώντας από την έκδοση 5.6. Τα άρθρα ειδήσεων, όπως πάντα, επαίνεσαν το WireGuard. Βυθίστηκα ξανά στην αναζήτηση τρόπων αντικατάστασης του παλιού καλού OpenVPN. Αυτή τη φορά έπεσα πάνω αυτο το αρθρο. Μίλησε για τη δημιουργία μιας σήραγγας Ethernet πάνω από το L3 χρησιμοποιώντας GRE. Αυτό το άρθρο μου έδωσε ελπίδα. Παρέμενε ασαφές τι να γίνει με το πρωτόκολλο UDP. Η αναζήτηση με οδήγησε σε άρθρα σχετικά με τη χρήση του socat σε συνδυασμό με μια σήραγγα SSH για την προώθηση μιας θύρας UDP, ωστόσο, παρατήρησαν ότι αυτή η προσέγγιση λειτουργεί μόνο σε λειτουργία απλής σύνδεσης, πράγμα που σημαίνει ότι οι πολλαπλοί πελάτες VPN θα ήταν αδύνατοι. Μου ήρθε η ιδέα να δημιουργήσω έναν διακομιστή VPN σε ένα VPS και να διαμορφώσω το GRE για πελάτες, αλλά όπως αποδείχθηκε, το GRE δεν υποστηρίζει κρυπτογράφηση, γεγονός που θα οδηγήσει στο γεγονός ότι εάν τρίτα μέρη αποκτήσουν πρόσβαση στον διακομιστή, όλη η κίνηση μεταξύ των δικτύων μου είναι στα χέρια τους που δεν μου ταίριαζε καθόλου.

Και πάλι, η απόφαση ελήφθη υπέρ της πλεονάζουσας κρυπτογράφησης, χρησιμοποιώντας VPN μέσω VPN σύμφωνα με το ακόλουθο σχήμα:

VPN επιπέδου XNUMX:
VPS είναι υπηρέτης με εσωτερική διεύθυνση 192.168.30.1
MS είναι πελάτης VPS με εσωτερική διεύθυνση 192.168.30.2
MK2 είναι πελάτης VPS με εσωτερική διεύθυνση 192.168.30.3
MK3 είναι πελάτης VPS με εσωτερική διεύθυνση 192.168.30.4

Επίπεδο XNUMX VPN:
MS είναι υπηρέτης με εξωτερική διεύθυνση 192.168.30.2 και εσωτερική 192.168.31.1
MK2 είναι πελάτης MS με τη διεύθυνση 192.168.30.2 και έχει εσωτερική IP 192.168.31.2
MK3 είναι πελάτης MS με τη διεύθυνση 192.168.30.2 και έχει εσωτερική IP 192.168.31.3

* MS - router-server στο διαμέρισμα 1, MK2 - router στο διαμέρισμα 2, MK3 - router στο διαμέρισμα 3
* Οι διαμορφώσεις συσκευών δημοσιεύονται στο spoiler στο τέλος του άρθρου.

Και έτσι, τα ping μεταξύ των κόμβων του δικτύου 192.168.31.0/24 πηγαίνουν, ήρθε η ώρα να προχωρήσουμε στη ρύθμιση του τούνελ GRE. Πριν από αυτό, για να μην χάσετε την πρόσβαση στους δρομολογητές, αξίζει να ρυθμίσετε τις σήραγγες SSH για την προώθηση της θύρας 22 στο VPS, έτσι ώστε, για παράδειγμα, ένας δρομολογητής από το διαμέρισμα 10022 να είναι διαθέσιμος στη θύρα 2 του VPS και Ο δρομολογητής από το διαμέρισμα 11122 θα είναι διαθέσιμος στη θύρα 3 του δρομολογητή VPS από το διαμέρισμα XNUMX. Είναι καλύτερο να ρυθμίσετε τις παραμέτρους της προώθησης με το ίδιο sshtunnel, καθώς θα επαναφέρει το τούνελ σε περίπτωση που πέσει.

Το τούνελ έχει διαμορφωθεί, μπορείτε να συνδεθείτε στο SSH μέσω της προωθημένης θύρας:

ssh root@МОЙ_VPS -p 10022

Στη συνέχεια, απενεργοποιήστε το OpenVPN:

/etc/init.d/openvpn stop

Τώρα ας δημιουργήσουμε μια σήραγγα GRE στο δρομολογητή από το διαμέρισμα 2:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

Και προσθέστε τη διεπαφή που δημιουργήθηκε στη γέφυρα:

brctl addif br-lan grelan0

Ας εκτελέσουμε μια παρόμοια διαδικασία στο δρομολογητή διακομιστή:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

Και, επίσης, προσθέστε τη δημιουργημένη διεπαφή στη γέφυρα:

brctl addif br-lan grelan0

ξεκινώντας από αυτή τη στιγμή, τα ping αρχίζουν να πηγαίνουν με επιτυχία στο νέο δίκτυο και εγώ, με ικανοποίηση, πηγαίνω να πιω καφέ. Στη συνέχεια, για να δω πώς λειτουργεί το δίκτυο στην άλλη άκρη του καλωδίου, προσπαθώ να μεταφέρω SSH σε έναν από τους υπολογιστές του διαμερίσματος 2, αλλά ο πελάτης ssh παγώνει χωρίς να μου ζητηθεί κωδικός πρόσβασης. Προσπαθώ να συνδεθώ σε αυτόν τον υπολογιστή μέσω telnet στη θύρα 22 και βλέπω μια γραμμή από την οποία μπορείτε να καταλάβετε ότι η σύνδεση δημιουργείται, ο διακομιστής SSH ανταποκρίνεται, αλλά για κάποιο λόγο δεν μου προσφέρει να μπω.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

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

Βγάζω τη συσκευή grelan0 από τη γέφυρα και ξεκινάω το OpenVPN στο δρομολογητή του διαμερίσματος 2 και βεβαιωθώ ότι το δίκτυο λειτουργεί ξανά σωστά και οι συνδέσεις δεν πέφτουν. Ψάχνοντας συναντώ φόρουμ όπου οι άνθρωποι παραπονιούνται για τα ίδια προβλήματα, όπου τους συμβουλεύεται να αυξήσουν το MTU. Όχι νωρίτερα. Ωστόσο, έως ότου το MTU ρυθμίστηκε σε μια αρκετά μεγάλη τιμή των 7000 για συσκευές gretap, παρατηρήθηκαν είτε διακοπείσες συνδέσεις TCP είτε αργές μεταδόσεις. Λόγω του υψηλού MTU για το gretap, τα MTU για τις συνδέσεις WireGuard του πρώτου και του δεύτερου επιπέδου ορίστηκαν σε 8000 και 7500, αντίστοιχα.

Έκανα μια παρόμοια ρύθμιση στο δρομολογητή από το διαμέρισμα 3, με τη μόνη διαφορά ότι μια δεύτερη διεπαφή gretap με το όνομα grelan1 προστέθηκε στο δρομολογητή διακομιστή, η οποία προστέθηκε επίσης στη γέφυρα br-lan.

Όλα λειτουργούν. Τώρα μπορείτε να βάλετε το συγκρότημα gretap σε αυτόματη φόρτωση. Για αυτό:

Τοποθετήστε αυτές τις γραμμές στο /etc/rc.local στο δρομολογητή στο διαμέρισμα 2:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

Προστέθηκε αυτό στο /etc/rc.local στο δρομολογητή στο διαμέρισμα 3:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

Και στο δρομολογητή διακομιστή:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 7000
ip link set grelan1 up
brctl addif br-lan grelan1

Μετά την επανεκκίνηση των δρομολογητών-πελατών, διαπίστωσα ότι για κάποιο λόγο δεν συνδέονται με τον διακομιστή. Συνδέοντας στο SSH τους (ευτυχώς, είχα ρυθμίσει προηγουμένως το sshtunnel για αυτό), ανακαλύφθηκε ότι το WireGuard για κάποιο λόγο δημιουργεί μια διαδρομή για το τελικό σημείο, ενώ είναι λανθασμένη. Έτσι, για το 192.168.30.2, ο πίνακας διαδρομής καθορίστηκε στον πίνακα δρομολογίων μέσω της διεπαφής pppoe-wan, δηλαδή μέσω του Διαδικτύου, αν και η διαδρομή προς αυτό θα έπρεπε να κατευθυνθεί μέσω της διεπαφής wg0. Μετά τη διαγραφή αυτής της διαδρομής, η σύνδεση αποκαταστάθηκε. Δεν μπόρεσα να βρω οδηγίες πουθενά για το πώς να αναγκάσω το WireGuard να μην δημιουργήσει αυτές τις διαδρομές. Επιπλέον, δεν κατάλαβα καν αν αυτό είναι χαρακτηριστικό του OpenWRT ή του ίδιου του WireGuard. Χωρίς να χρειάζεται να αντιμετωπίσω αυτό το πρόβλημα για μεγάλο χρονικό διάστημα, απλά πρόσθεσα και στους δύο δρομολογητές σε ένα σενάριο που βρόχτηκε από ένα χρονόμετρο, μια γραμμή που διέγραψε αυτήν τη διαδρομή:

route del 192.168.30.2

Συνοψίζοντας

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

Όταν χρησιμοποιείτε το OpenVPN:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms

--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms

Όταν χρησιμοποιείτε το WireGuard:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms

Επηρεάζεται κυρίως από υψηλό ping σε VPS που είναι περίπου 61.5ms

Ωστόσο, η ταχύτητα έχει αυξηθεί σημαντικά. Έτσι, σε ένα διαμέρισμα με δρομολογητή-διακομιστή, έχω ταχύτητα σύνδεσης στο Διαδίκτυο 30 Mbps, και σε άλλα διαμερίσματα, 5 Mbps. Ταυτόχρονα, ενώ χρησιμοποιούσα το OpenVPN, δεν μπορούσα να πετύχω ρυθμό μεταφοράς δεδομένων μεταξύ δικτύων άνω των 3,8 Mbps σύμφωνα με το iperf, ενώ το WireGuard το «άντλησε» στα ίδια 5 Mbps.

Διαμόρφωση WireGuard σε VPS[Interface] Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_1_МС>
AllowedIPs = 192.168.30.2/32

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2>
AllowedIPs = 192.168.30.3/32

[Peer] PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3>
AllowedIPs = 192.168.30.4/32

Διαμόρφωση WireGuard στο MS (προστέθηκε στο /etc/config/network)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.2/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - сервер
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option listen_port '51821'
        list addresses '192.168.31.1/24'
        option auto '1'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list allowed_ips '192.168.31.2'

config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3

        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list allowed_ips '192.168.31.3'

Διαμόρφωση WireGuard στο MK2 (προστέθηκε στο /etc/config/network)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.3/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list addresses '192.168.31.2/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

Διαμόρφωση WireGuard στο MK3 (προστέθηκε στο /etc/config/network)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.4/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list addresses '192.168.31.3/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

Στις περιγραφόμενες διαμορφώσεις για το VPN δεύτερου επιπέδου, καθορίζω τη θύρα 51821 σε πελάτες WireGuard. Θεωρητικά, αυτό δεν είναι απαραίτητο, καθώς ο πελάτης θα δημιουργήσει μια σύνδεση από οποιαδήποτε δωρεάν μη προνομιακή θύρα, αλλά το έκανα έτσι ώστε όλες οι εισερχόμενες συνδέσεις μπορεί να απορριφθεί στις διεπαφές wg0 όλων των δρομολογητών, εκτός από τις εισερχόμενες συνδέσεις UDP στη θύρα 51821.

Ελπίζω ότι το άρθρο θα είναι χρήσιμο σε κάποιον.

PS Επίσης, θέλω να μοιραστώ το σενάριό μου που μου στέλνει μια ειδοποίηση PUSH στο τηλέφωνό μου στην εφαρμογή WirePusher όταν εμφανίζεται μια νέα συσκευή στο δίκτυό μου. Εδώ είναι ένας σύνδεσμος για το σενάριο: github.com/r0ck3r/device_discover.

ΕΚΣΥΓΧΡΟΝΊΖΩ: Διαμόρφωση διακομιστή OpenVPN και πελάτες

Διακομιστής OpenVPN

client-to-client

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key

dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzo

Πελάτης OpenVPN

client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind

ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem

comp-lzo
persist-tun
persist-key
verb 3

Χρησιμοποίησα το easy-rsa για τη δημιουργία πιστοποιητικών.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο