ProHoster > Blogi > Haldamine > Üleminek OpenVPN-ilt WireGuardile, et ühendada võrgud üheks L2-võrguks

Üleminek OpenVPN-ilt WireGuardile, et ühendada võrgud üheks L2-võrguks

Üleminek OpenVPN-ilt WireGuardile, et ühendada võrgud üheks L2-võrguks

Tahaksin jagada oma kogemust võrkude ühendamisest kolmes geograafiliselt kaugel asuvas korteris, millest igaüks kasutab lüüsina OpenWRT-ga ruutereid, üheks ühiseks võrguks. Alamvõrgu marsruutimisega L3 ja sillaga L2 võrkude ühendamise meetodi valimisel, kui kõik võrgusõlmed on samas alamvõrgus, eelistati teist meetodit, mida on keerulisem konfigureerida, kuid mis pakub rohkem võimalusi, kuna on läbipaistev. tehnoloogiate kasutamine kavandati loodud võrgus Wake-on-Lan ja DLNA.

1. osa: Taust

Selle ülesande rakendamise protokolliks valiti algselt OpenVPN, kuna esiteks saab sellega luua kraaniseadme, mille saab probleemideta sillale lisada ja teiseks toetab OpenVPN toimimist üle TCP-protokolli, mis oli samuti oluline, kuna ühelgi korteril polnud spetsiaalset IP-aadressi ja ma ei saanud STUN-i kasutada, kuna mu ISP blokeerib millegipärast nende võrkudest sissetulevad UDP-ühendused, samas kui TCP-protokoll võimaldas mul VPN-serveri porti renditud VPS-il SSH abil edasi saata. Jah, selline lähenemine annab suure koormuse, kuna andmed krüpteeritakse kaks korda, kuid ma ei tahtnud VPS-i oma privaatvõrku juurutada, kuna endiselt oli oht, et kolmandad osapooled saavad selle üle kontrolli, mistõttu on selline seade koduvõrgus oli äärmiselt ebasoovitav ja otsustati turvalisuse eest maksta suure üldkuluga.

Selle ruuteri pordi edastamiseks, millele oli plaanis server juurutada, kasutati programmi sshtunnel. Ma ei kirjelda selle konfiguratsiooni keerukust - seda tehakse üsna lihtsalt, märgin lihtsalt, et selle ülesandeks oli TCP-port 1194 ruuterilt VPS-i edastada. Järgmisena konfigureeriti OpenVPN-server tap0 seadmes, mis oli ühendatud br-lani sillaga. Pärast sülearvutist vastloodud serveriga ühenduse kontrollimist sai selgeks, et pordi edastamise idee õigustas end ja minu sülearvuti sai ruuteri võrgu liikmeks, kuigi see polnud füüsiliselt selles.

Asi jäi väikeseks: IP-aadresse oli vaja laiali jagada erinevates korterites, et need ei läheks vastuollu ja seadistada ruuterid OpenVPN-i klientideks.
Valiti järgmised ruuteri IP-aadressid ja DHCP-serveri vahemikud:

  • 192.168.10.1 ulatusega 192.168.10.2 - 192.168.10.80 serveri jaoks
  • 192.168.10.100 ulatusega 192.168.10.101 - 192.168.10.149 ruuterile korteris nr 2
  • 192.168.10.150 ulatusega 192.168.10.151 - 192.168.10.199 ruuterile korteris nr 3

Samuti oli vaja OpenVPN-serveri kliendiruuteritele määrata täpselt need aadressid, lisades selle konfiguratsiooni rea:

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

ja järgmiste ridade lisamine faili /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

kus flat1_id ja flat2_id on OpenVPN-iga ühenduse loomise sertifikaatide loomisel määratud seadmete nimed

Järgmisena konfigureeriti ruuterites OpenVPN-i kliendid, mõlema tap0 seadmed lisati br-lani sillale. Selles etapis tundus kõik olevat korras, kuna kõik kolm võrku näevad üksteist ja töötavad tervikuna. Selgus aga mitte eriti meeldiv detail: mõnikord võisid seadmed saada IP-aadressi mitte oma ruuterilt, koos kõigi sellest tulenevate tagajärgedega. Mingil põhjusel ei jõudnud ühe korteri ruuter DHCPDISCOVERile õigeaegselt vastata ja seade sai vale aadressi. Sain aru, et pean sellised päringud iga ruuteri tap0-s filtreerima, kuid nagu selgus, ei saa iptables seadmega töötada, kui see on silla osa ja ebtables peaks mulle appi tulema. Kahjuks ei olnud seda minu püsivaras ja ma pidin iga seadme jaoks pildid uuesti üles ehitama. Seda tehes ja lisades need read iga ruuteri faili /etc/rc.local, lahendati probleem:

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

See konfiguratsioon kestis kolm aastat.

2. osa: WireGuardi tutvustus

Viimasel ajal on Internet üha enam rääkinud WireGuardist, imetledes selle konfiguratsiooni lihtsust, suurt edastuskiirust, madalat pingi võrreldava turvalisusega. Selle kohta lisateavet otsides selgus, et see ei toeta tööd sillaliikmena ega TCP-protokolli kallal, mis pani mind mõtlema, et OpenVPN-ile pole minu jaoks endiselt alternatiive. Nii et lükkasin WireGuardiga tutvumise edasi.

Paar päeva tagasi levis IT-ga seotud ressursside kaudu nii või teisiti uudis, et WireGuard jõuab lõpuks 5.6 versioonist alates Linuxi kernelisse. Uudisteartiklid, nagu alati, kiitsid WireGuardi. Sukeldusin taas vana hea OpenVPN-i asendamise võimaluste otsimisse. Seekord sattusin kokku Selle artikli. See rääkis Etherneti tunneli loomisest L3 kaudu GRE abil. See artikkel andis mulle lootust. Ebaselgeks jäi, mida UDP-protokolliga peale hakata. Otsing viis mind artikliteni, mis käsitlevad socati kasutamist koos SSH-tunneliga UDP-pordi edastamiseks, kuid nad märkisid, et see lähenemisviis töötab ainult ühe ühenduse režiimis, mis tähendab, et mitu VPN-klienti oleks võimatu. Tulin ideele seadistada VPN-server VPS-is ja seadistada klientide jaoks GRE, kuid nagu selgus, ei toeta GRE krüptimist, mis toob kaasa asjaolu, et kui kolmandad osapooled saavad serverile juurdepääsu , kogu liiklus minu võrkude vahel on nende kätes, mis mulle üldse ei sobinud.

Jällegi otsustati üleliigse krüptimise kasuks, kasutades VPN-i üle VPN-i vastavalt järgmisele skeemile:

XNUMX. kihi VPN:
VPS see on server siseaadressiga 192.168.30.1
MS see on klient VPS siseaadressiga 192.168.30.2
MK2 see on klient VPS siseaadressiga 192.168.30.3
MK3 see on klient VPS siseaadressiga 192.168.30.4

XNUMX. kihi VPN:
MS see on server välise aadressiga 192.168.30.2 ja sisemisega 192.168.31.1
MK2 see on klient MS aadressiga 192.168.30.2 ja selle sisemine IP on 192.168.31.2
MK3 see on klient MS aadressiga 192.168.30.2 ja selle sisemine IP on 192.168.31.3

* MS - ruuter-server korteris 1, MK2 - ruuter korteris 2, MK3 - ruuter korteris 3
* Seadme konfiguratsioonid on avaldatud artikli lõpus olevas spoileris.

Ja nii, pingid võrgu 192.168.31.0/24 sõlmede vahel lähevad, on aeg liikuda edasi GRE tunneli seadistamise juurde. Enne seda, et mitte kaotada juurdepääsu ruuteritele, tasub seadistada SSH tunnelid pordi 22 suunamiseks VPS-ile, et näiteks korteri 10022 ruuter oleks saadaval VPS-i pordis 2 ja ruuter korterist 11122 on saadaval VPS-i pordis 3. Ruuter korterist XNUMX. Kõige parem on konfigureerida suunamine sama sshtunneliga, kuna see taastab tunneli, kui see kukkub.

Tunnel on konfigureeritud, saate SSH-ga ühenduse luua edastatud pordi kaudu:

ssh root@МОЙ_VPS -p 10022

Järgmisena keelake OpenVPN:

/etc/init.d/openvpn stop

Nüüd paneme 2. korteri ruuterile üles GRE tunneli:

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

Ja lisage loodud liides sillale:

brctl addif br-lan grelan0

Teeme sarnase protseduuri serveri ruuteris:

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

Ja lisaks lisage loodud liides sillale:

brctl addif br-lan grelan0

sellest hetkest alates hakkavad pingid edukalt uude võrku minema ja mina lähen rahulolevalt kohvi jooma. Seejärel, et näha, kuidas juhtme teises otsas olev võrk töötab, proovin SSH-i sisestada ühte korteri 2 arvutisse, kuid ssh-klient hangub ilma parooli küsimata. Üritan selle arvutiga 22. pordi kaudu telneti kaudu ühendust saada ja näen rida, kust saab aru, et ühendus luuakse, SSH server vastab, aga millegipärast ei paku sisenemist.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Proovin sellega VNC kaudu ühendust luua ja näen musta ekraani. Veen ennast, et asi on kaugarvutis, sest saan sellest korterist siseaadressi abil lihtsalt ruuteriga ühenduse luua. Siiski otsustan sellesse arvutisse ruuteri kaudu SSH-i sisestada ja olen üllatunud, kui avastan, et ühendus õnnestub ja kaugarvuti töötab hästi, kuid ei saa ka minu arvutiga ühendust.

Võtan grelan0 seadme sillast välja ja käivitan 2. korteri ruuteris OpenVPN-i ning veendun, et võrk töötab taas korralikult ja ühendused ei katke. Otsides satun foorumitesse, kus kurdetakse samade probleemide üle, kus soovitatakse MTU-d tõsta. Pole varem öeldud kui tehtud. Siiski, kuni MTU seadistati gretapi seadmete jaoks piisavalt suureks väärtuseks 7000, täheldati kas TCP-ühenduste katkemist või aeglast edastust. Gretapi kõrge MTU tõttu määrati esimese ja teise taseme WireGuardi ühenduste MTU väärtuseks vastavalt 8000 ja 7500.

Sarnase seadistuse tegin ka 3. korteri ruuteris, ainsa erinevusega, et serveri ruuterile lisati teine ​​gretapi liides nimega grelan1, mis lisati ka br-lani sillale.

Kõik töötab. Nüüd saate gretapi komplekti automaatlaadimisse panna. Selle jaoks:

Need read paigutati korteri 2 ruuteri kausta /etc/rc.local:

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

Lisas selle korteri 3 ruuteri faili /etc/rc.local:

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

Ja serveri ruuteris:

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

Pärast kliendiruuterite taaskäivitamist avastasin, et mingil põhjusel ei saanud nad serveriga ühendust. Ühendades nende SSH-ga (õnneks olin varem sshtunneli selleks konfigureerinud), avastati, et WireGuard loob mingil põhjusel lõpp-punktile marsruudi, olles samas vale. Nii et 192.168.30.2 jaoks määrati marsruudi tabel marsruuditabelis läbi pppoe-wan liidese, st Interneti kaudu, kuigi marsruut selleni oleks pidanud olema suunatud wg0 liidese kaudu. Pärast selle marsruudi kustutamist ühendus taastati. Ma ei leidnud kuskilt juhiseid, kuidas sundida WireGuardi neid marsruute mitte looma. Lisaks ei saanud ma isegi aru, kas see on OpenWRT või WireGuardi enda funktsioon. Ilma, et oleksin pidanud selle probleemiga pikka aega tegelema, lisasin lihtsalt mõlemale ruuterile taimeriga silmustatud skripti rea, mis selle marsruudi kustutas: 

route del 192.168.30.2

Kokkuvõtteks

Ma pole veel saavutanud OpenVPN-i täielikku tagasilükkamist, kuna mul on mõnikord vaja sülearvutist või telefonist uude võrku ühenduda ja nendes gretapi seadme seadistamine on üldiselt võimatu, kuid hoolimata sellest sain andmeedastuses eelise. kiirus korterite vahel ja näiteks VNC kasutamine pole enam ebamugav. Ping vähenes veidi, kuid muutus stabiilsemaks:

OpenVPN-i kasutamisel:

[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

WireGuardi kasutamisel:

[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

Seda mõjutab enamasti kõrge VPS-i ping, mis on ligikaudu 61.5 ms

Kiirus on aga märgatavalt kasvanud. Seega on mul ruuter-serveriga korteris Interneti-ühenduse kiirus 30 Mbps ja teistes korterites 5 Mbps. Samas ei suutnud ma OpenVPN-i kasutades saavutada iperfi järgi võrkude vahelist andmeedastuskiirust üle 3,8 Mbps, samas kui WireGuard “pumpas” selle sama 5 Mbps peale.

WireGuardi konfiguratsioon VPS-is[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

WireGuardi konfiguratsioon MS-is (lisatud faili /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'

WireGuardi konfiguratsioon MK2-s (lisatud faili /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'

WireGuardi konfiguratsioon MK3-s (lisatud faili /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'

Kirjeldatud teise taseme VPN-i konfiguratsioonides määran WireGuardi klientidele pordi 51821. Teoreetiliselt pole see vajalik, kuna klient loob ühenduse mis tahes tasuta mitteprivilegeeritud pordist, kuid tegin selle nii, et kõik sissetulevad ühendused saab keelata kõigi ruuterite wg0 liidestel, välja arvatud sissetulevad UDP-ühendused pordis 51821.

Loodan, et artikkel on kellelegi kasulik.

PS Samuti soovin jagada oma skripti, mis saadab mulle rakenduses WirePusher mu telefoni PUSH-teate, kui minu võrku ilmub uus seade. Siin on link skriptile: github.com/r0ck3r/device_discover.

UPDATE: OpenVPN-i serveri ja klientide konfiguratsioon

OpenVPN server

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-i klient

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

Sertifikaatide genereerimiseks kasutasin easy-rsa-d.

Allikas: www.habr.com

Lisa kommentaar