🥇Üleminek OpenVPN'ilt WireGuard'ile võrgu ühendamiseks L2 võrguks

Sooviksin jagada kogemust, kuidas ühendasin võrke kolmes geograafiliselt eemal asuvas korteris, kus igas korteris toimib väravana OpenWRT ruuterid, ühte ühte võrku. Vaatamata L3 marsruutimise ja alamvõrkude koosoleku ja L2 sillastamise vahelisele valikule, kus kõik võrgu elemendid asuvad ühes alamvõrgus, valiti eelmine tehnika, mis on keerulisem seadistada, kuid pakub rohkem võimalusi, kuna loodud võrgus oli plaanis kasutada tehnoloogiaid Wake-on-Lan ja DLNA.

Osa 1: Taust

Alguses valiti protokolliks OpenVPN, kuna see suudab luua tap-seadmestiku, mis liitub sillaga probleemideta, ja teiseks toetab OpenVPN TCP protokolli, mis oli samuti oluline, kuna mitte üheski korteris ei olnud eraldatud IP-aadressi, ja STUN'i järgi ei õnnestunud mul töötada, kuna minu teenusepakkuja blokeerib mingil põhjusel sissetulevad UDP-protokolli ühendused oma võrkudest, samas kui TCP protokoll võimaldas mul edastada VPN-serveri sadama renditud VPS-i kaudu SSH. Jah, selline lähenemine tekitab suure koormuse, kuna andmed krüpteeritakse kaks korda, kuid ma ei soovinud VPS-i oma erakonda tuua, kuna oli oht, et kolmandad isikud saavad selle üle kontrolli, seega oli selle seadme omamine koduvõrgus äärmiselt soovimatu ja otsustati maksta turvalisuse nimel suure ülekuulamise eest.

Sadama edastamiseks ruuteril, kus plaaniti serveri seadistamine, kasutati programmi sshtunnel. Ma ei hakka kirjeldama tema konfiguratsioonist tingitud nüansse - see on üsna lihtne, lihtsalt mainin, et selle ülesanne oli edastada TCP-pord 1194 ruuterilt VPS-ile. Edasi seadistati OpenVPN server seadmes tap0, mis liideti sillaga br-lan. Kontrollides ühendust just loodud serveriga oma sülearvutist - sai selgeks, et idee sadama edastamiseks on õigustanud end ja minu sülearvuti sai ruuteri võrgu liikmeks, kuigi füüsiliselt ei olnud see seal.

Tööd oli jäänud vähe: oli vaja määrata IP-aadresse erinevates korterites nii, et nad ei oleks konfliktis, ja seadistada ruuterid OpenVPN klientideks.
Valiti järgmised IP-aadressid ruuteritele ja DHCP-serverite vahemikud:

192.168.10.1 vahemikuga 192.168.10.2 — 192.168.10.80 serverile
192.168.10.100 vahemikuga 192.168.10.101 — 192.168.10.149 ruuterile korteris nr 2
192.168.10.150 vahemikuga 192.168.10.151 — 192.168.10.199 ruuterile korteris nr 3

Samuti oli vajalik määrata just need aadressid OpenVPN serveri klientidele, lisades selle konfiguratsiooni järgmise rea:

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

ja lisades järgmised read faili /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

kus flat1_id ja flat2_id on seadmete nimed, mis määratakse OpenVPN-iga ühendamiseks sertifikaate luues.

Seejärel seadistati ruuterites OpenVPN kliendid, seadmed tap0 mõlemal kantakse br-lan sillasse. Sel hetkel tundus, et kõik on korras, kuna kõik kolm võrku nägid üksteist ja toimisid kui üks tervik. Kuid ilmnes ebameeldiv detail: mõnikord võisid seadmed saada IP-aadressi mitte oma ruuterilt, millega kaasnesid kõik tagajärjed. Mingi põhjusel ei jõudnud ruuter mõnes korteris DHCPDISCOVER'ile õigel ajal vastata ning seade sai vale aadressi. Mõistsin, et pean filtrima selliseid päringud tap0 igas ruuteris, kuid nagu selgus, ei saa iptables töötada seadmega, kui see on silla osa, ja sisenema pidi ebtables. Kahjuks ei olnud minu seadmetes ebtables ja pidin iga seadme pildi uuesti koostama. Pärast seda ja lisades järgmised read /etc/rc.local iga ruuteri faili oli probleem lahendatud:

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

Selline konfiguratsioon kestis kolm aastat.

Osa 2: Tutvumine WireGuardiga

Viimasel ajal on WireGuardist Internetis üha rohkem räägitud, imetledes selle konfiguratsiooni lihtsust, suurt edastuskiirus ja madalat pinget võrreldes sarnase turvalisusega. Otsides täiendavat teavet selle kohta, selgus, et bridge'i liikmena töötamine ega TCP protokoll ei ole selle poolt toetatud, mis tõi mind mõtlema, et OpenVPN jaoks pole endiselt alternatiive. Nii olen ma WireGuardiga tutvumist edasi lükanud.

Mõni päev tagasi levis IT-alastes kanalites uudis, et WireGuard lisatakse lõpuks Linuxi tuumasse alates versioonist 5.6. Uudised kiitsid WireGuardi nagu alati. Sukeldusin taas vanade OpenVPN alternatiivide otsingusse. Seekord komistasin selle artikli. Artiklis räägiti Etherneti tunnelist L3 peal GRE abil. See artikkel andis mulle lootust. Üksnes jäi selgusetuks, kuidas UDP protokolliga toimetada. Otsingud viisid mind artikliteni, kus käsitleti socati koos SSH tunneli kasutamist UDP-portide edastamiseks, kuid seal märgiti, et selline lähenemine töötab ainult ühe ühenduse režiimis, mis teeks mitme VPN-kliendi töövõimetuks. Tulin mõttele luua VPN-server VPS-il ning seadistada GRE kliendid, kuid nagu selgus, ei toeta GRE krüpteerimist, mis tähendaks, et kui kolmandad isikud pääsevad serverisse ligi, saavad nad kätte kogu liikluse minu võrkude vahel, mis mind absoluutselt ei rahuldanud.

Uus otsus tehti ülisalajase krüpteerimise kasuks, kasutades VPN-i VPN-i üle järgmistel alustel:

Esimese taseme VPN:
VPS on serveriga siseaadressiga 192.168.30.1
MC on kliendiga VPS siseaadressiga 192.168.30.2
MK2 on kliendiga VPS siseaadressiga 192.168.30.3
MK3 on kliendiga VPS siseaadressiga 192.168.30.4

Teise taseme VPN:
MC on serveriga välisaadressiga 192.168.30.2 ja siseaadressiga 192.168.31.1
MK2 on kliendiga MC aadressiga 192.168.30.2 ja sise-IP-ga 192.168.31.2
MK3 on kliendiga MC aadressiga 192.168.30.2 ja sise-IP-ga 192.168.31.3

* MC — marsruuter-server korteris 1, MK2 — marsruuter korteris 2, MK3 — marsruuter korteris 3
* Seadmete konfiguratsioonid on avaldatud spolleri all artikli lõpus.

Nii et pingsed 192.168.31.0/24 võrgus töötavad, on aeg üle minna GRE-tunneli seadistamisele. Enne seda, et mitte kaotada juurdepääsu marsruutijatele, on mõistlik seadistada SSH tunneli 22 sadama edastamine VPS-ile, nii et näiteks 10022. sadamal on VPS-l juurdepääs korteri 2 marsruuterile, ning 11122. sadamal on VPS-l juurdepääs korteri 3 marsruuterile. Edastamise seadistamise parim viis on sshtunnel, kuna see taastab tunneli, kui see peaks ebaõnnestuma.

Tunnel on seadistatud, saab SSH-ks ühendust luua edastatud sadama kaudu:

ssh root@MINU_VPS -p 10022

Järgmiseks tuleb OpenVPN välja lülitada:

/etc/init.d/openvpn stop

Nüüd seadistame GRE-tunneli korteri 2 marsruuteris:

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

Ja lisame loodud liidese sillale:

brctl addif br-lan grelan0

Teeme sarnase protseduuri servermarsruuteris:

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

Ja lisame ka loodud liidese sillale:

brctl addif br-lan grelan0

alates sellest hetkest hakkavad pingsed uues võrgus tõhusalt liikuma ja ma, rahulolevalt, suundun kohvi jooma. Siis, et hinnata, kuidas võrk teisel pool kaablit töötab, proovin luua SSH ühendust ühe korteri 2 arvutiga, kuid ssh klient „hangub”, ega paku mulle parooli sisestada. Proovin sellele arvutile telnet-i kaudu 22-sadama kaudu sisse logida ja näen rida, millest võib aru saada, et ühendus luuakse, SSH-server vastab, kuid mingil põhjusel ei paku mul sisse logida.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Proovin sellele sisse logida VNC kaudu ja näen musta ekraani. Üritan end veenda, et asi on kaugmasinas, sest korteri marsruutijaga saan ma kindlalt ühendust siseaadressi kaudu. Siiski, otsustan sisse logida selle arvuti SSH-le marsruuteri kaudu ja üllatun, et ühendus õnnestub, ning kaugmasin töötab täiesti normaalselt, kuid ei saa siiski ühendust minu arvutiga.

Eemaldan seadme grelan0 sillast ja käivitan OpenVPN korteri 2 marsruuteris ning veendun, et võrk töötab taas õigesti ja ühendused ei katke. Otsing viib mind foorumitesse, kus inimesed kurdavad samade probleemide üle, kus neile soovitatakse tõsta MTU-d. Öeldud — tehtud. Siiski, kuni MTU ei olnud seatud piisavalt suureks — 7000 gretap seadmetele, esines kas TCP ühenduste katkestusi või madalat edastuskiirus. Suure MTU tõttu gretap jaoks — WireGuardi esimese ja teise taseme ühenduste MTU oli seadistatud vastavalt 8000 ja 7500.

Viisin sarnase seadistuse läbi ka korteri 3 marsruuteris, ainsa erinevusega, et servermarsruuteris lisandus teine gretap liides nimega grelan1, mis samuti lisati sillale br-lan.

Kõik töötab. Nüüd võib gretap-i kogumise seadistada automaatseks käivitamiseks. Selleks:

Panin need read /etc/rc.local korteri 2 marsruuterisse:

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

Lisasin selle /etc/rc.local oma korteri ruuterisse 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

Ja ruuter-serveris:

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 klientide ruuterite taaskäivitamist avastasin, et nad mingil põhjusel ei saa serveriga ühendust. Kui ma nendega SSH kaudu ühendust sõlmisin (õnneks olin ma eelnevalt seadnud sshtunneli selleks), selgus, et WireGuard mingil põhjusel loob faili 'endpoint' vale marsruudi. Nii et 192.168.30.2 osas oli marsruudi tabelis märgitud marsruut läbi pppoe-wan liidese, st interneti kaudu, kuigi marsruut pidi olema suunatud wg0 liidese kaudu. Pärast marsruudi eemaldamist taastati ühendus. Ma ei leidnud kuskilt juhiseid, kuidas sundida WireGuard neid marsruute mitte looma. Veelgi enam, ma isegi ei saanud aru, kas see on OpenWRT spetsiifiline probleem või WireGuard'i enda omadus. Et mitte pikka aega selle probleemiga vaeva näha, lisasin mõlemasse ruuterisse skripti, mis käivitub taimeri järgi, et eemaldada see marsruut:

route del 192.168.30.2

Kokkuvõtteks

OpenVPN'ist ma täielikult loobuda ei suutnud, kuna mul on aeg-ajalt vaja ühenduda uue võrguga oma sülearvutist või telefonist, ja gretap seadistamine neile pole tavaliselt võimalik. Kuid hoolimata sellest, sain andmeedastuse kiirusest suurema kasu kahe korteri vahel ning näiteks VNC kasutamine ei tekita enam ebamugavusi. Pingi vähenemine oli märkimisväärselt väike, kuid see 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

WireGuard'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=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

Suur mõju on tõhusa pingi olemasolul VPS'ile, mille väärtus on umbes 61.5 ms.

Kuid kiirus on märkimisväärselt suurenenud. Niisiis, korteris, kus on ruuter-server, sain internetiühenduse kiirus 30 Mbit/s, teistes korterites aga 5 Mbit/s. Samuti ei õnnestunud mul OpenVPN'i kasutamisel andmeedastuse kiirus ulatuda kahe võrgu vahel üle 3,8 Mbit/s iperfi näidud, samas kui WireGuard tõstis selle samale 5 Mbit/s.

WireGuard'i konfiguratsioon VPS'il[Interface] Aadress = 192.168.30.1/24 Kuulamisport = 51820 Privaatvõti =

[Peer]
PublicKey =
AllowedIPs = 192.168.30.2/32

[Peer]
PublicKey =
AllowedIPs = 192.168.30.3/32

[Peer]
PublicKey =
AllowedIPs = 192.168.30.4/32

WireGuard'i konfiguratsioon MS'i jaoks (lisatakse /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'i konfiguratsioon MK2 jaoks (lisatakse /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'i konfiguratsioon MK3 jaoks (lisatakse /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 konfiguratsioonides teise taseme VPN'i jaoks määran klientidele WireGuard'i pordi 51821. Ideaalis pole see vajalik, kuna klient loob ühenduse igalt vabalt tõhusalt portilt, kuid tegin seda, et saaksin blokeerida kõik sissetulevad ühendused wg0 liidese kaudu kõigis ruuterites, välja arvatud sissetulevad UDP-ühendused pordile 51821.

Loodan, et artikkel on kellelegi kasulik.

P.S. Samuti tahan jagada oma skripti, mis saadab mulle PUSH-teate telefonile WirePusheri rakenduses, kui minu võrgus ilmub uus seade. Siin on link skriptile: github.com/r0ck3r/device_discover.

UUENDUS: OpenVPN-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-klient

client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Muuda ruuteri välise IP aadressi
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

Allikas: habr.com

Üleminek OpenVPN-ilt WireGuardile, et liita võrgud ühte L2 võrku

Osa 1: Taust

Osa 2: Tutvumine WireGuardiga

Kokkuvõtteks