ProHoster > Blog > Uprava > Prehod iz OpenVPN o WireGuard združiti omrežja v eno L2 omrežje

Prehod iz OpenVPN o WireGuard združiti omrežja v eno L2 omrežje

Prehod iz OpenVPN o WireGuard združiti omrežja v eno L2 omrežje

Rad bi delil svojo izkušnjo združevanja omrežij v treh geografsko oddaljenih stanovanjih, od katerih vsako uporablja usmerjevalnike z OpenWRT kot prehodom, v eno skupno omrežje. Pri izbiri načina združevanja omrežij med L3 z usmerjanjem v podomrežju in L2 s premoščanjem, ko bodo vsa omrežna vozlišča v istem podomrežju, je bila dana prednost drugemu načinu, ki je težji za konfiguracijo, vendar ponuja več možnosti, saj pregleden Uporaba tehnologij je bila načrtovana v ustvarjenem omrežju Wake-on-Lan in DLNA.

1. del: Ozadje

Protokol, izbran za izvedbo te naloge, je bil prvotno OpenVPN, ker lahko, prvič, ustvari napravo za pipanje, ki jo je mogoče brez težav dodati mostu, in drugič, OpenVPN Podpira TCP, kar je bilo prav tako pomembno, saj nobeno od stanovanj ni imelo namenskega IP-naslova. STUN-a nisem mogel uporabljati, ker moj ponudnik internetnih storitev iz nekega razloga blokira dohodne UDP povezave iz svojih omrežij. TCP mi je omogočil, da sem vrata VPN strežnika preusmeril na najeti VPS z uporabo SSH. Čeprav ta pristop ustvarja znatne stroške, saj so podatki dvojno šifrirani, nisem želel integrirati VPS-ja v svoje zasebno omrežje, saj je obstajalo tveganje, da bi tretje osebe pridobile nadzor nad njim. Zato je bila takšna naprava v mojem domačem omrežju zelo nezaželena, zato sem se odločil plačati znatne stroške za varnost.

Za posredovanje vrat na usmerjevalniku, kjer naj bi bil nameščen strežnik, sem uporabil program sshtunnel. Ne bom se spuščal v podrobnosti njegove konfiguracije – je precej preprosta. Omenil bom le, da je bil njegov namen posredovanje TCP vrat 1194 iz usmerjevalnika na VPS. Nato sem konfiguriral strežnik. OpenVPN Na napravi tap0, ki je bila povezana z mostom br-lan. Po preizkusu povezave z novo ustvarjenim strežnikom iz mojega prenosnika je postalo jasno, da je ideja o posredovanju vrat delovala in da je moj prenosnik postal član omrežja usmerjevalnika, čeprav fizično ni bil del njega.

Edino, kar je preostalo, je bilo razdeliti IP-naslove v različnih stanovanjih, da ne bi prišlo do konfliktov, in konfigurirati usmerjevalnike kot OpenVPN-stranke.
Izbrani so bili naslednji naslovi IP usmerjevalnika in obsegi strežnikov DHCP:

  • 192.168.10.1 z razponom 192.168.10.2 - 192.168.10.80 za strežnik
  • 192.168.10.100 z razponom 192.168.10.101 - 192.168.10.149 za usmerjevalnik v stanovanju št. 2
  • 192.168.10.150 z razponom 192.168.10.151 - 192.168.10.199 za usmerjevalnik v stanovanju št. 3

Prav tako je bilo treba te naslove dodeliti odjemalskim usmerjevalnikom. OpenVPN-server, tako da v njegovo konfiguracijo dodate naslednjo vrstico:

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

in dodajanje naslednjih vrstic v datoteko /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

kjer sta flat1_id in flat2_id imeni naprav, določeni pri ustvarjanju potrdil za povezavo z OpenVPN

Nato so bili usmerjevalniki konfigurirani OpenVPN- odjemalci, naprave tap0 na obeh so bile dodane mostu br-lan. Na tej točki se je zdelo vse v redu, saj so se vsa tri omrežja lahko videla in delovala kot ena enota. Vendar se je pojavila precej neprijetna podrobnost: včasih so naprave prejele IP-naslov od napačnega usmerjevalnika, z vsemi posledičnimi posledicami. Iz nekega razloga se usmerjevalnik v enem od stanovanj ni pravočasno odzval na DHCPDISCOVER in naprava je prejela napačen naslov. Spoznal sem, da moram takšne zahteve filtrirati v tap0 na vsakem usmerjevalniku, vendar se je izkazalo, da iptables ne more delovati z napravo, če je del mostu, zato sem moral uporabiti ebtables. Žal moja vdelana programska oprema tega ni vključevala, zato sem moral ponovno zgraditi slike za vsako napravo. Ko sem to storil in dodal naslednje vrstice v /etc/rc.local na vsakem usmerjevalniku, je bila težava rešena:

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

Ta konfiguracija je trajala tri leta.

2. del: Spoznavanje WireGuard

V zadnjem času se na internetu vse več govori o WireGuard, občudoval sem njegovo enostavno konfiguracijo, visoko hitrost prenosa, nizek ping in primerljivo varnost. Iskanje dodatnih informacij o njem je pokazalo, da ne podpira niti članov mostu niti protokola TCP, kar me je prepričalo, da ni druge možnosti. OpenVPN Zame še vedno ni tam. Zato odlašam s spoznavanjem WireGuard.

Pred nekaj dnevi se je po virih, povezanih z IT, razširila novica, da WireGuard bo končno vključen v jedro Linux, začenši z različico 5.6. Novice so bile kot vedno pohvaljene WireGuardSpet sem se poglobil v iskanje načinov, kako nadomestiti dobro staro OpenVPNTokrat sem naletel/a na ta članek. Govorilo je o ustvarjanju ethernetnega tunela prek L3 z uporabo GRE. Ta članek mi je dal upanje. Ostalo je nejasno, kaj storiti s protokolom UDP. Iskanje me je pripeljalo do člankov o uporabi socat v povezavi s tunelom SSH za posredovanje vrat UDP, vendar so opazili, da ta pristop deluje samo v načinu ene povezave, kar pomeni, da bi bilo več odjemalcev VPN nemogoče. Prišel sem na idejo, da bi nastavil strežnik VPN na VPS in nastavil GRE za odjemalce, vendar se je izkazalo, da GRE ne podpira šifriranja, kar bo privedlo do dejstva, da če tretje osebe dobijo dostop do strežnika , ves promet med mojimi omrežji je v njihovih rokah, kar mi ni prav nič ustrezalo.

Ponovno se je odločilo za redundantno šifriranje z uporabo VPN prek VPN po naslednji shemi:

Layer XNUMX VPN:
VPS je strežnik z internim naslovom 192.168.30.1
DČ je stranko VPS z internim naslovom 192.168.30.2
MK2 je stranko VPS z internim naslovom 192.168.30.3
MK3 je stranko VPS z internim naslovom 192.168.30.4

VPN sloja XNUMX:
DČ je strežnik z zunanjim naslovom 192.168.30.2 in notranjim 192.168.31.1
MK2 je stranko DČ z naslovom 192.168.30.2 in ima notranji IP 192.168.31.2
MK3 je stranko DČ z naslovom 192.168.30.2 in ima notranji IP 192.168.31.3

* DČ - usmerjevalnik-strežnik v apartmaju 1, MK2 - router v stanovanju 2, MK3 - router v stanovanju 3
* Konfiguracije naprav so objavljene v spojlerju na koncu članka.

In tako, pingi med vozlišči omrežja 192.168.31.0/24 gredo, čas je, da nadaljujemo z nastavitvijo tunela GRE. Pred tem, da ne izgubite dostopa do usmerjevalnikov, je vredno nastaviti SSH tunele za posredovanje vrat 22 v VPS, tako da bo na primer usmerjevalnik iz stanovanja 10022 na voljo na vratih 2 VPS in usmerjevalnik iz apartmaja 11122 bo na voljo na vratih 3 VPS usmerjevalnik iz apartmaja XNUMX. Najbolje je konfigurirati posredovanje z istim sshtunnelom, saj bo obnovil tunel v primeru padca.

Predor je konfiguriran, na SSH se lahko povežete prek posredovanih vrat:

ssh root@МОЙ_VPS -p 10022

Nato morate onemogočiti OpenVPN:

/etc/init.d/openvpn stop

Zdaj pa nastavimo tunel GRE na usmerjevalniku iz stanovanja 2:

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

In dodajte ustvarjeni vmesnik v most:

brctl addif br-lan grelan0

Izvedimo podoben postopek na strežniškem usmerjevalniku:

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

In tudi dodajte ustvarjeni vmesnik v most:

brctl addif br-lan grelan0

od tega trenutka začnejo pingi uspešno iti v novo omrežje in z zadovoljstvom grem piti kavo. Nato, da vidim, kako deluje omrežje na drugi strani žice, poskušam vzpostaviti SSH v enega od računalnikov v stanovanju 2, vendar odjemalec ssh zamrzne, ne da bi me pozval k vnosu gesla. Poskušam se povezati s tem računalnikom prek telneta na vratih 22 in vidim vrstico, iz katere lahko razumete, da se povezava vzpostavlja, strežnik SSH se odziva, vendar mi iz neznanega razloga ne ponudi vstopa.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Poskušam se povezati z njim prek VNC in vidim črn zaslon. Prepričujem se, da je zadeva v oddaljenem računalniku, saj se iz tega stanovanja zlahka povežem na router po internem naslovu. Vendar se odločim za SSH v ta računalnik prek usmerjevalnika in presenečen ugotovim, da je povezava uspešna in da oddaljeni računalnik deluje dobro, vendar se tudi ne more povezati z mojim računalnikom.

Napravo grelan0 vzamem iz mostu in jo zaženem. OpenVPN Na usmerjevalniku v stanovanju 2 sem potrdil, da omrežje spet deluje pravilno in da povezave ne prekinjajo. Med iskanjem sem naletel na forume, kjer so se ljudje pritoževali nad istimi težavami in kjer so jim svetovali, naj zvišajo MTU. Rečeno, storjeno. Vendar pa sem do takrat, ko je bil MTU nastavljen dovolj visoko – 7000 za naprave gretap – naletel bodisi na prekinjene TCP povezave bodisi na nizke hitrosti prenosa. Zaradi visokega MTU za gretap je bil MTU za povezave WireGuard Prva in druga raven sta bili določeni na 8000 oziroma 7500.

Podobno sem nastavil na usmerjevalniku iz stanovanja 3, z edino razliko, da je bil strežniškemu usmerjevalniku dodan drugi vmesnik gretap z imenom grelan1, ki je bil dodan tudi mostu br-lan.

Vse dela. Zdaj lahko sklop gretap postavite v samodejno nalaganje. Za to:

Te vrstice sem postavil v /etc/rc.local na usmerjevalniku v stanovanju 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

To dodano v /etc/rc.local na usmerjevalniku v stanovanju 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

In na strežniškem usmerjevalniku:

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

Po ponovnem zagonu odjemalskih usmerjevalnikov sem ugotovil, da se iz nekega razloga niso povezali s strežnikom. Po povezavi z njihovim SSH (na srečo sem za to predhodno konfiguriral sshtunnel), sem ugotovil, da WireGuard Iz nekega razloga ustvari pot za končno točko, vendar je ta napačna. Na primer, za 192.168.30.2 je tabela poti določila pot prek vmesnika pppoe-wan, tj. prek interneta, čeprav bi morala biti pot do nje usmerjena prek vmesnika wg0. Po brisanju te poti je bila povezava obnovljena. Ali lahko kje najdem navodila, kako prisiliti ... WireGuard Ustvarjanju teh poti se nisem mogel izogniti. Poleg tega sploh nisem razumel, ali je to funkcija OpenWRT ali ... WireGuardBrez veliko časa za ugotavljanje težave sem preprosto dodal vrstico v skripto časovne zanke na obeh usmerjevalnikih, ki je izbrisala to pot:

route del 192.168.30.2

Povzema

Popolna zavrnitev OpenVPN Tega še nisem dosegel, saj se moram občasno povezati z novim omrežjem iz prenosnika ali telefona, nastavitev naprave gretap pa je na njih na splošno nemogoča. Kljub temu pa sem pridobil prednost pri hitrosti prenosa podatkov med stanovanji in uporaba VNC-ja je na primer zdaj brez težav. Ping se je nekoliko zmanjšal, vendar je postal bolj stabilen:

Pri uporabi 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

Pri uporabi 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

Nanj večinoma vpliva visok ping do VPS, ki znaša približno 61.5 ms

Vendar se je hitrost znatno povečala. Tako imam v stanovanju z usmerjevalnikom-strežnikom hitrost internetne povezave 30 Mbps, v drugih stanovanjih pa 5 Mbps. Poleg tega med uporabo OpenVPN Glede na odčitke iperf nisem mogel doseči hitrosti prenosa podatkov med omrežji, večje od 3,8 Mbps, medtem ko WireGuard "napihnil" ga je na istih 5 Mbit/s.

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

[Vrstnik]
JavniKljuč = <VPN_1_MS_PUBLIC_KEY>
Dovoljeni naslovi IP = 192.168.30.2/32

[Vrstnik]
JavniKljuč = <VPN_2_MK2_JAVNI_KLJUČ>
Dovoljeni naslovi IP = 192.168.30.3/32

[Vrstnik]
JavniKljuč = <VPN_2_MK3_JAVNI_KLJUČ>
Dovoljeni naslovi IP = 192.168.30.4/32

Konfiguracija WireGuard na MS (dodano v /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'

Konfiguracija WireGuard na MK2 (dodano v /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'

Konfiguracija WireGuard na MK3 (dodano v /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'

V opisanih konfiguracijah za VPN druge ravni strankam nakazujem WireGuard Vrata 51821. To ne bi smelo biti potrebno, saj bo odjemalec vzpostavil povezavo s katerih koli prostih, neprivilegiranih vrat, vendar sem to naredil tako, da sem lahko zavrnil vse dohodne povezave na vmesnikih wg0 vseh usmerjevalnikov, razen dohodnih UDP povezav na vrata 51821.

Upam, da bo članek komu koristen.

PS Prav tako želim deliti svoj skript, ki mi v aplikaciji WirePusher pošlje PUSH obvestilo na moj telefon, ko se v mojem omrežju pojavi nova naprava. Tukaj je povezava do skripta: github.com/r0ck3r/device_discover.

UPDATE: Konfiguracija OpenVPN-strežniki in odjemalci

OpenVPN-strežnik

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

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

Za ustvarjanje potrdil sem uporabil easy-rsa.

Vir: www.habr.com

Kupite zanesljivo gostovanje za strani z DDoS zaščito, VPS VDS strežniki 🔥 Kupite zanesljivo spletno gostovanje z zaščito DDoS, VPS VDS strežniki | ProHoster