🥇Transizione da OpenVPN nantu WireGuard cumbinà e rete in una sola 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

U protocolu sceltu per implementà stu compitu hè statu inizialmente OpenVPN, perchè, prima, pò creà un dispusitivu di tap chì pò esse aghjuntu à u ponte senza nisun prublema, è secondu, OpenVPN Supporta TCP, chì era ancu impurtante, postu chì nisunu di l'appartamenti avia un indirizzu IP dedicatu. Ùn pudia micca aduprà STUN perchè u mo ISP, per qualchì ragione, blocca e cunnessione UDP entranti da e so rete. TCP m'hà permessu di trasmette u portu di u servitore VPN à u VPS affittatu utilizendu SSH. Mentre questu approcciu crea un sovraccaricu significativu, postu chì i dati sò doppiamente criptati, ùn vulia micca integrà u VPS in a mo rete privata, postu chì ci era u risicu chì terze parti ne pigliassinu u cuntrollu. Dunque, avè un tale dispositivu nantu à a mo rete domestica era assai indesiderabile, allora aghju decisu di pagà un sovraccaricu significativu per a sicurezza.

Per trasmette u portu di u router induve u servitore era previstu di esse implementatu, aghju utilizatu u prugramma sshtunnel. Ùn entreraghju micca in i dettagli di a so cunfigurazione - hè abbastanza faciule. Nuteraghju solu chì u so scopu era di trasmette u portu TCP 1194 da u router à u VPS. Dopu, aghju cunfiguratu u servitore. OpenVPN Nant'à u dispusitivu tap0, chì era cunnessu à u ponte br-lan. Dopu avè pruvatu a cunnessione à u servitore appena creatu da u mo laptop, hè diventatu chjaru chì l'idea di l'inoltru di portu avia funzionatu, è u mo laptop era diventatu membru di a rete di u router, ancu s'ellu ùn ne facia micca fisicamente parte.

L'unica cosa chì restava da fà era di distribuisce l'indirizzi IP in diversi appartamenti in modu chì ùn si cunflittessinu micca è cunfigurà i router cum'è OpenVPN-clienti.
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 assignà questi indirizzi à i router di i clienti. OpenVPN-server, aghjunghjendu a seguente 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 dispusitivi specificati quandu si creanu certificati per a cunnessione à OpenVPN

In seguitu, i router sò stati cunfigurati OpenVPN- i clienti, i dispusitivi tap0 nant'à tramindui sò stati aghjunti à u ponte br-lan. À questu puntu, tuttu pareva bè, postu chì e trè rete pudianu vede si è funziunà cum'è una sola unità. Tuttavia, hè apparsu un dettagliu piuttostu spiacevule: qualchì volta i dispusitivi ricevenu un indirizzu IP da u router sbagliatu, cù tutte e cunsequenze chì ne derivanu. Per qualchì ragione, u router in unu di l'appartamenti ùn hà micca rispostu à DHCPDISCOVER in tempu, è u dispusitivu hà ricevutu l'indirizzu sbagliatu. M'aghju resu contu chì avia bisognu di filtrà tali richieste in tap0 nant'à ogni router, ma cum'è s'hè rivelatu, iptables ùn pò micca funziunà cù un dispusitivu s'ellu face parte di un ponte, dunque avia bisognu di utilizà ebtables. Sfurtunatamente, u mo firmware ùn l'includia micca, dunque aghju avutu à ricustruisce l'imagine per ogni dispusitivu. Dopu avè fattu questu è aghjuntu e seguenti linee à /etc/rc.local nant'à ogni router, u prublema hè statu risoltu:

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: Cunnosce WireGuard

Ultimamente, si parla sempre di più nant'à Internet di WireGuard, ammirendu a so facilità di cunfigurazione, l'alta velocità di trasferimentu, u ping bassu è a sicurezza paragunabile. Una ricerca di informazioni supplementari hà rivelatu chì ùn supporta nè i membri di u bridge nè u supportu di u protocolu TCP, ciò chì m'hà fattu crede chì ùn ci era alternativa. OpenVPN per mè ùn hè ancu quì. Cusì aghju rimandatu à cunnosce WireGuard.

Qualchi ghjorni fà, a nutizia si hè sparsa per mezu di risorse ligate à l'informatica in un modu o in l'altru chì WireGuard serà infine inclusu in u kernel Linux, cuminciendu cù a versione 5.6. L'articuli di nutizie, cum'è sempre, sò stati elogiati WireGuardMi sò immersu torna in a ricerca di modi per rimpiazzà u bonu vechju OpenVPNSta volta aghju scontru 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.

Pigliu u dispusitivu grelan0 fora di u ponte è l'aghju eseguitu. OpenVPN Nantu à u router in l'appartamentu 2, aghju cunfirmatu chì a rete funzionava di novu currettamente è chì e cunnessione ùn si perdevanu micca. Circendu, aghju trovu fori induve a ghjente si lagnava di i stessi prublemi, è induve era cunsigliatu di aumentà u MTU. Dittu subitu, fattu. Tuttavia, finu à chì u MTU ùn hè statu impostu abbastanza altu - 7000 per i dispositivi gretap - aghju sperimentatu cunnessione TCP perse o velocità di trasferimentu basse. A causa di l'altu MTU per gretap, u MTU per e cunnessione WireGuard U primu è u secondu livellu sò stati fissati rispettivamente à 8000 è 7500.

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 router di i clienti, aghju scupertu chì per qualchì ragione ùn si cunnettevanu micca à u servitore. Dopu avè cunnessu à u so SSH (per furtuna, avia prima cunfiguratu sshtunnel per questu), aghju scupertu chì WireGuard Per qualchì ragione, crea una strada per u puntu finale, ma hè sbagliata. Per esempiu, per 192.168.30.2, a tavula di routing hà specificatu una strada attraversu l'interfaccia pppoe-wan, vale à dì, attraversu internet, ancu s'è a strada versu ella duveria esse stata diretta attraversu l'interfaccia wg0. Dopu avè sguassatu sta strada, a cunnessione hè stata restaurata. Possu truvà struzzioni in qualchì locu nantu à cumu furzà WireGuard Ùn aghju pussutu evità di creà ste rotte. Inoltre, ùn aghju mancu capitu s'ellu si trattava di una caratteristica di OpenWRT o di WireGuardSenza passà assai tempu à capisce u prublema, aghju simpliciamente aghjuntu una linea à u script di u timer-loop nantu à i dui routers chì hà sguassatu sta strada:

route del 192.168.30.2

Riunione

Rifiutu cumpletu OpenVPN Ùn aghju ancu riesciutu à fà què, postu chì qualchì volta aghju bisognu di cunnette mi à una nova rete da un urdinatore purtatile o un telefunu, è cunfigurà un dispusitivu gretap nant'à elli hè generalmente impussibile. Tuttavia, malgradu questu, aghju ottenutu un vantaghju in a velocità di trasferimentu di dati trà l'appartamenti, è aduprà VNC, per esempiu, hè avà senza prublemi. U ping hè diminuitu ligeramente ma hè diventatu 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. Cusì, in l'appartamentu cù u router-server, aghju una velocità di cunnessione internet di 30 Mbps, è in l'altri appartamenti hè di 5 Mbps. Inoltre, durante l'usu OpenVPN Ùn aghju pussutu ottene una velocità di trasferimentu di dati trà e rete superiore à 3,8 Mbps secondu e letture iperf, mentre WireGuard l'hà "pompatu" finu à i stessi 5 Mbit/sec.

Cunfigurazione WireGuard nantu à VPS[Interface] Address = 192.168.30.1/24 ListenPort = 51820 PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[Peer]
Chjave Pubblica = <VPN_1_MS_CHEVIA_PUBLICA>
IP permessi = 192.168.30.2/32

[Peer]
Chjave Pubblica = <VPN_2_MK2_CHEVIA_PUBLICA>
IP permessi = 192.168.30.3/32

[Peer]
Chjave Pubblica = <VPN_2_MK3_CHEVIA_PUBLICA>
IP permessi = 192.168.30.4/32

Cunfigurazione WireGuard nant'à MS (aghjuntu à /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'

Cunfigurazione WireGuard nant'à MK2 (aghjuntu à /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'

Cunfigurazione WireGuard nant'à MK3 (aghjuntu à /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 a VPN di secondu livellu, indicu à i clienti WireGuard Portu 51821. Questu ùn deve esse necessariu, postu chì u cliente stabilirà una cunnessione da qualsiasi portu liberu è senza privilegi, ma l'aghju fattu cusì per pudè nigà tutte e cunnessione entranti nantu à l'interfacce wg0 di tutti i router, eccettu per e cunnessione UDP entranti à 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: Cunfigurazione OpenVPN-servitori è clienti

OpenVPN-servitore

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-cliente

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

Perekhod s OpenVPN nantu WireGuard per cumminà e rete in una rete L2

Parte 1: Sfondate

Parte 2: Cunnosce WireGuard

Riunione

ProHoster