ProHoster > Blog > Amministrazione > Migrazione da OpenVPN à WireGuard per cunsulidà e rete in una rete L2

Migrazione da OpenVPN à WireGuard per cunsulidà e rete in una rete L2

Migrazione da OpenVPN à WireGuard per cunsulidà e rete in una rete L2

Vogliu sparte a mo sperienza di cumminà e rete in trè appartamenti geograficamente remoti, ognuna di e quali usa router OpenWRT cum'è una porta, in una reta cumuna. Quandu sceglite un metudu per cumminà e rete trà L3 cù routing di subnet è L2 cù ponte, quandu tutti i nodi di rete seranu in a listessa subnet, a preferenza hè stata data à u sicondu metudu, chì hè più difficiuli di cunfigurà, ma furnisce più opportunità, postu chì l'usu trasparenti di e tecnulugia hè stata pianificata in a reta chì hè creatu Wake-on-Lan è DLNA.

Parte 1: Sfondate

OpenVPN hè statu inizialmente sceltu cum'è u protokollu per l'implementazione di stu compitu, postu chì, prima, pò creà un dispositivu di tap chì pò esse aghjuntu à u ponte senza prublemi, è in segundu, OpenVPN sustene l'operazione nantu à u protocolu TCP, chì era ancu impurtante, perchè nimu. di l'appartamenti avianu un indirizzu IP dedicatu, è ùn aghju micca pussutu utilizà STUN, postu chì u mo fornitore per una certa ragione blocca e cunnessione UDP entranti da e so rete, mentre chì u protocolu TCP m'hà permessu di trasmette u portu di u servitore VPN à VPS affittu cù SSH. Iè, stu approcciu dà una grande carica, postu chì i dati sò criptati duie volte, ma ùn vulia micca intruduce un VPS in a mo reta privata, postu chì ci era ancu u risicu di u terzu per piglià u cuntrollu, dunque, avè un tali dispusitivu. nantu à a mo reta di casa era estremamente indesevule è hè statu decisu di pagà per a sicurità cun un grande overhead.

Per rinvià u portu nantu à u router nantu à quale era previstu di implementà u servitore, u prugramma sshtunnel hè stata utilizata. Ùn descriveraghju micca l'intricacies di a so cunfigurazione - hè fattu abbastanza facilmente, aghju da nutà chì u so compitu era di trasmette u portu TCP 1194 da u router à u VPS. Dopu, u servitore OpenVPN hè stata cunfigurata nantu à u dispusitivu tap0, chì era cunnessu à u ponte br-lan. Dopu avè verificatu a cunnessione à u servitore novu creatu da u laptop, hè diventatu chjaru chì l'idea di u portu forwarding era ghjustificata è u mo laptop hè diventatu un membru di a reta di u router, ancu s'ellu ùn era micca fisicamente in questu.

Ci era solu una piccula cosa da fà: era necessariu di distribuisce l'indirizzi IP in diversi appartamenti per ùn avè micca cunflittu è cunfigurà i routers cum'è clienti OpenVPN.
I seguenti indirizzi IP di router è intervalli di servitori DHCP sò stati scelti:

  • 192.168.10.1 cun gamma 192.168.10.2 - 192.168.10.80 per u servitore
  • 192.168.10.100 cun gamma 192.168.10.101 - 192.168.10.149 per u router in l'appartamentu N ° 2
  • 192.168.10.150 cun gamma 192.168.10.151 - 192.168.10.199 per u router in l'appartamentu N ° 3

Era ancu necessariu d'assignà esattamente questi indirizzi à i router di u cliente di u servitore OpenVPN aghjunghjendu a linea à a so cunfigurazione:

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

è aghjunghjendu e seguenti linee à u schedariu /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

induve flat1_id è flat2_id sò i nomi di i dispositi specificati quandu creanu certificati per cunnette à OpenVPN

In seguitu, i clienti OpenVPN sò stati cunfigurati nantu à i routers, i dispositivi tap0 nantu à i dui sò stati aghjuntu à u ponte br-lan. À questu stadiu, tuttu paria esse bè cum'è e trè rete puderanu vede è travaglià cum'è una. Tuttavia, un ditagliu micca assai piacevule emerge: qualchì volta i dispositi puderanu riceve un indirizzu IP micca da u so router, cù tutte e cunsequenze chì ne seguitanu. Per una certa ragione, u router in unu di l'appartamenti ùn hà micca avutu u tempu di risponde à DHCPDISCOVER in u tempu è u dispusitivu hà ricevutu un indirizzu chì ùn era micca pensatu. Aghju realizatu chì aghju bisognu di filtrà tali richieste in tap0 nantu à ognunu di i routers, ma cum'è hè risultatu, iptables ùn pò micca travaglià cù u dispusitivu s'ellu hè parte di un ponte è ebtables deve vene à u mo aiutu. À u mo disgrazia, ùn era micca in u mo firmware è aghju avutu à ricustruisce l'imaghjini per ogni dispusitivu. Fendu questu è aghjunghjendu sti linii à /etc/rc.local di ogni router, u prublema hè stata risolta:

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

Sta cunfigurazione durò trè anni.

Parte 2: Introduzione di WireGuard

Ricertamenti, a ghjente in Internet hà sempre più cuminciatu à parlà di WireGuard, admirendu a simplicità di a so cunfigurazione, alta velocità di trasmissione, ping bassu cù una sicurità paragunabili. A ricerca di più infurmazione nantu à questu hà fattu chjaru chì nè u travagliu cum'è un membru di ponte nè u travagliu nantu à u protokollu TCP era supportatu da ellu, chì m'hà fattu pensà chì ùn ci era ancu micca alternative à OpenVPN per mè. Allora aghju rimandatu à cunnosce WireGuard.

Uni pochi ghjorni fà, a nutizia sparghje in e risorse in una manera o l'altra ligata à l'IT chì WireGuard serà infine inclusu in u kernel Linux, cumincendu cù a versione 5.6. L'articuli di notizie, cum'è sempre, elogiavanu WireGuard. Aghju tornatu in a ricerca di modi per rimpiazzà u bonu vechju OpenVPN. Sta volta aghju incuntratu stu articulu. Parlava di creà un tunnel Ethernet nantu à L3 cù GRE. Questu articulu m'hà datu speranza. Ùn era micca chjaru chì fà cù u protocolu UDP. A ricerca m'hà purtatu à articuli nantu à l'usu di socat in cunghjunzione cù un tunnel SSH per trasmette un portu UDP, però, anu nutatu chì questu approcciu solu funziona in modu di cunnessione unicu, vale à dì, u travagliu di parechji clienti VPN seria impussibile. Aghju avutu l'idea di installà un servitore VPN nantu à un VPS è di stallà GRE per i clienti, ma cum'è s'hè risultatu, GRE ùn sustene micca a criptografia, chì porta à u fattu chì, se terzu accede à u servitore. , tuttu u trafficu trà e mo rete serà in e so mani, chì ùn mi cunvene micca in tuttu.

Una volta, a decisione hè stata presa in favore di a criptografia redundante, utilizendu VPN sopra VPN utilizendu u schema seguente:

Livellu 1 VPN:
VPS hè servitore cù indirizzu internu 192.168.30.1
MS hè cliente VPS cù indirizzu internu 192.168.30.2
MK2 hè cliente VPS cù indirizzu internu 192.168.30.3
MK3 hè cliente VPS cù indirizzu internu 192.168.30.4

VPN di u sicondu livellu:
MS hè servitore cù indirizzu esternu 192.168.30.2 è internu 192.168.31.1
MK2 hè cliente MS cù l'indirizzu 192.168.30.2 è hà un IP internu 192.168.31.2
MK3 hè cliente MS cù l'indirizzu 192.168.30.2 è hà un IP internu 192.168.31.3

* MS - router-server in l'appartamentu 1, MK2 - router in l'appartamentu 2, MK3 - router in l'appartamentu 3
* E cunfigurazioni di u dispositivu sò publicate in u spoiler à a fine di l'articulu.

È cusì, i pings sò in esecuzione trà i nodi di rete 192.168.31.0/24, hè ora di passà à a stallazione di un tunnel GRE. Prima di questu, per ùn perde micca l'accessu à i routers, vale a pena stallà tunnellati SSH per trasmette u portu 22 à u VPS, cusì chì, per esempiu, u router da l'appartamentu 10022 serà accessibile in u portu 2 di u VPS, è u router da l'appartamentu 11122 serà accessibile nantu à u portu 3 u router da l'appartamentu XNUMX. Hè megliu cunfigurà l'inviu cù u stessu sshtunnel, postu chì restaurà u tunelu si falla.

U tunelu hè cunfiguratu, pudete cunnette à SSH via u portu trasmessu:

ssh root@МОЙ_VPS -p 10022

Dopu duvete disattivà OpenVPN:

/etc/init.d/openvpn stop

Avà stallà un tunnel GRE nantu à u router da l'appartamentu 2:

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

È aghjunghje l'interfaccia creata à u ponte:

brctl addif br-lan grelan0

Facemu una prucedura simili nantu à u router di u servitore:

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

È aghjunghje ancu l'interfaccia creata à u ponte:

brctl addif br-lan grelan0

partendu da questu mumentu, i pings cumincianu à andà cun successu à a nova reta è eiu, cun satisfaczione, andemu à beie caffè. Allora, per evaluà cumu a reta travaglia in l'altru finale di a linea, pruvate à SSH in unu di l'urdinatori in l'appartamentu 2, ma u cliente ssh si congela senza dumandà una password. Pruvate di cunnette à questu computer via telnet in u portu 22 è vecu una linea da quale possu capisce chì a cunnessione hè stata stabilita, u servitore SSH risponde, ma per una certa ragione ùn solu ùn m'invita à logà. in.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Pruvate di cunnette vi via VNC è vede un screnu neru. Mi cunvince chì u prublema hè cù l'urdinatore remoto, perchè possu facilmente cunnette à u router da questu appartamentu cù l'indirizzu internu. In ogni casu, decisu di cunnette à l'SSH di questu computer per mezu di u router è sò sorpresu di truvà chì a cunnessione hè successu, è l'urdinatore remotu funziona abbastanza nurmale, ma ancu ùn pò micca cunnette à u mo urdinatore.

Eliminate u dispositivu grelan0 da u ponte è eseguite OpenVPN nantu à u router in l'appartamentu 2 è assicuratevi chì a reta funziona cum'è l'aspittà di novu è e cunnessione ùn sò micca abbandunati. Circhendu, aghju incontratu fori induve a ghjente si lamenta di i stessi prublemi, induve sò cunsigliati per elevà u MTU. Nantu à dì chè fattu. Tuttavia, finu à chì u MTU hè statu stabilitu abbastanza altu - 7000 per i dispositi gretap, sia abbandunà e cunnessione TCP sia i tassi di trasferimentu bassi sò stati osservati. A causa di l'altu MTU per gretap, i MTU per e cunnessione WireGuard Layer 8000 è Layer 7500 sò stati stabiliti à XNUMX è XNUMX rispettivamente.

Aghju realizatu una cunfigurazione simili nantu à u router da l'appartamentu 3, cù l'unica diferenza hè chì una seconda interfaccia gretap chjamata grelan1 hè stata aghjuntu à u router di u servitore, chì hè ancu aghjuntu à u ponte br-lan.

Tuttu travaglia. Avà pudete mette l'assemblea gretap in startup. Per questu:

Aghju piazzatu queste linee in /etc/rc.local nantu à u router in l'appartamentu 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

Aggiuntu questu à /etc/rc.local nantu à u router in l'appartamentu 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

È nantu à u router di u servitore:

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

Dopu avè riavviatu i routers di u cliente, aghju scupertu chì per una certa ragione ùn eranu micca cunnessi à u servitore. Dopu avè cunnessu à u so SSH (per furtuna, aghju avutu prima cunfiguratu sshtunnel per questu), hè statu scupertu chì WireGuard per una certa ragione creava una strada per l'endpoint, ma era sbagliata. Allora, per 192.168.30.2, a tabella di rotta indicava una strada per l'interfaccia pppoe-wan, vale à dì, per Internet, ancu s'è a strada per ellu duveria esse stata rotta per l'interfaccia wg0. Dopu à sguassà sta strada, a cunnessione hè stata restaurata. Ùn aghju micca pussutu truvà struzzioni in ogni locu nantu à cumu furzà WireGuard à ùn creà micca queste rotte. Inoltre, ùn aghju mancu capitu s'ellu era una funzione di OpenWRT o WireGuard stessu. Senza avè da trattà cù stu prublema per un bellu pezzu, aghju aghjustatu solu una linea à i dui routers in un script cronometratu chì hà eliminatu sta strada: 

route del 192.168.30.2

Riunione

Ùn aghju micca ancu ottinutu un abbandunamentu cumpletu di OpenVPN, postu chì qualchì volta aghju bisognu di cunnette à una nova rete da un laptop o un telefunu, è stallà un dispositivu gretap nantu à elli hè generalmente impussibile, ma malgradu questu, aghju avutu un vantaghju in a velocità. di trasferimentu di dati trà appartamenti è, per esempiu, l'usu di VNC ùn hè più inconveniente. Ping diminuì ligeramente, ma diventò più stabile:

Quandu si usa 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

Quandu si usa 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

Hè più affettatu da u ping altu à u VPS, chì hè di circa 61.5 ms

Tuttavia, a velocità hè aumentata significativamente. Allora, in un appartamentu cù un router di servitore aghju una velocità di cunnessione Internet di 30 Mbit/sec, è in altri appartamenti hè 5 Mbit/sec. À u listessu tempu, mentre aduprate OpenVPN, ùn era micca capaci di ottene una velocità di trasferimentu di dati trà e rete di più di 3,8 Mbit/sec sicondu i letture iperf, mentri WireGuard l'hà "boosted" à u listessu 5 Mbit/sec.

Configurazione WireGuard nantu à 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

Configurazione WireGuard nantu à MS (aghjustatu à /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'

Configurazione WireGuard nantu à MK2 (aghjustatu à /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'

Configurazione WireGuard nantu à MK3 (aghjustatu à /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'

In e cunfigurazioni descritte per VPN di u sicondu livellu, aghju indicatu i clienti WireGuard à u portu 51821. In teoria, questu ùn hè micca necessariu, postu chì u cliente stabiliscerà una cunnessione da qualsiasi portu senza privileghju, ma aghju fattu cusì chì era pussibule di pruibisce. tutte e cunnessione entrate nantu à l'interfacce wg0 di tutti i routers eccettu e cunnessione UDP in entrata à u portu 51821.

Spergu chì l'articulu serà utile à qualchissia.

PS Inoltre, vogliu sparte u mo script chì m'invia una notificazione PUSH à u mo telefunu in l'applicazione WirePusher quandu un novu dispositivu appare nantu à a mo reta. Eccu u ligame à u script: github.com/r0ck3r/device_discover.

aghjuntu: Configurazione di u servitore OpenVPN è i clienti

Servitore 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

Client 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

Aghju utilizatu easy-rsa per generà certificati

Source: www.habr.com

Add a comment