ProHoster > Блог > Administracija > Migracija sa OpenVPN-a na WireGuard za konsolidaciju mreža u jednu L2 mrežu

Migracija sa OpenVPN-a na WireGuard za konsolidaciju mreža u jednu L2 mrežu

Migracija sa OpenVPN-a na WireGuard za konsolidaciju mreža u jednu L2 mrežu

Želeo bih da podelim svoje iskustvo kombinovanja mreža u tri geografski udaljena stana, od kojih svaki koristi rutere sa OpenWRT kao gateway, u jednu zajedničku mrežu. Prilikom odabira metode za kombinovanje mreža između L3 sa usmjeravanjem podmreže i L2 s premošćavanjem, kada će svi mrežni čvorovi biti u istoj podmreži, prednost je data drugoj metodi, koja je teže konfigurirati, ali pruža više mogućnosti, jer je transparentna. korištenje tehnologija planirano je u kreiranoj mreži Wake-on-Lan i DLNA.

Dio 1: Pozadina

OpenVPN je prvobitno izabran kao protokol za implementaciju ovog zadatka, jer, prvo, može kreirati tap uređaj koji se bez problema može dodati na most, a drugo, OpenVPN podržava rad preko TCP protokola, što je takođe bilo važno, jer nijedan od stanova nije imao namjensku IP adresu, a nisam mogao koristiti STUN, jer iz nekog razloga moj ISP blokira dolazne UDP konekcije sa svojih mreža, dok mi je TCP protokol omogućavao prosljeđivanje porta VPN servera na iznajmljenom VPS-u koristeći SSH. Da, ovaj pristup daje veliko opterećenje, jer se podaci šifriraju dva puta, ali nisam želio da uvodim VPS u svoju privatnu mrežu, jer je i dalje postojao rizik da treće strane preuzmu kontrolu nad njim, pa tako uređaj na kućnoj mreži bio je krajnje nepoželjan i odlučeno je platiti sigurnost uz velike režije.

Za prosljeđivanje porta na ruteru na kojem se planiralo postaviti server, korišten je program sshtunnel. Neću opisivati ​​zamršenosti njegove konfiguracije - to se radi prilično lako, samo napominjem da je njegov zadatak bio proslijediti TCP port 1194 sa rutera na VPS. Zatim je OpenVPN server konfigurisan na tap0 uređaju, koji je bio povezan na br-lan most. Nakon provjere veze sa novostvorenim serverom sa laptopa, postalo je jasno da se ideja o prosljeđivanju portova opravdala i moj laptop je postao član mreže rutera, iako fizički nije bio u njoj.

Stvar je ostala mala: bilo je potrebno distribuirati IP adrese u različitim stanovima kako se ne bi sukobljavale i konfigurirati rutere kao OpenVPN klijente.
Odabrane su sljedeće IP adrese rutera i rasponi DHCP servera:

  • 192.168.10.1 sa dometom 192.168.10.2 - 192.168.10.80 za server
  • 192.168.10.100 sa dometom 192.168.10.101 - 192.168.10.149 za ruter u stanu br.2
  • 192.168.10.150 sa dometom 192.168.10.151 - 192.168.10.199 za ruter u stanu br.3

Također je bilo potrebno dodijeliti upravo ove adrese klijentskim ruterima OpenVPN servera dodavanjem linije u njegovu konfiguraciju:

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

i dodavanjem sljedećih redova u /etc/openvpn/ipp.txt datoteku:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

gdje su flat1_id i flat2_id nazivi uređaja specificirani prilikom generiranja certifikata za povezivanje na OpenVPN

Zatim su OpenVPN klijenti konfigurisani na ruterima, tap0 uređaji na oba su dodani na br-lan most. U ovoj fazi se činilo da je sve u redu, jer sve tri mreže vide jedna drugu i rade kao cjelina. Međutim, pokazao se ne baš prijatan detalj: ponekad uređaji mogu dobiti IP adresu ne sa svog rutera, sa svim posljedicama koje su proizašle. Iz nekog razloga ruter u jednom od stanova nije stigao na vrijeme odgovoriti na DHCPDISCOVER i uređaj je dobio pogrešnu adresu. Shvatio sam da takve zahtjeve trebam filtrirati u tap0 na svakom od rutera, ali kako se ispostavilo, iptables ne može raditi s uređajem ako je dio mosta i ebtables bi mi trebao priskočiti u pomoć. Na moju žalost, to nije bilo u mom firmveru i morao sam ponovo da napravim slike za svaki uređaj. Ovim i dodavanjem ovih linija u /etc/rc.local svakog rutera, problem je riješen:

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

Ova konfiguracija je trajala tri godine.

Dio 2: Predstavljamo WireGuard

U posljednje vrijeme na Internetu se sve više govori o WireGuardu, diveći se jednostavnosti njegove konfiguracije, velikoj brzini prijenosa, niskom pingu uz uporedivu sigurnost. Tragajući za više informacija o tome jasno je dalo do znanja da on ne podržava ni rad kao član mosta niti rad na TCP protokolu, što me je navelo da pomislim da za mene još uvijek nema alternative za OpenVPN. Zato sam odložio upoznavanje sa WireGuardom.

Prije nekoliko dana se kroz resurse, na ovaj ili onaj način koji se odnose na IT, proširila vijest da će WireGuard konačno biti uključen u Linux kernel, počevši od verzije 5.6. Novinski članci, kao i uvijek, hvale WireGuard. Ponovo sam uronio u potragu za načinima da zamijenim stari dobri OpenVPN. Ovaj put sam naleteo ovaj članak. Govorilo se o stvaranju Ethernet tunela preko L3 koristeći GRE. Ovaj članak mi je dao nadu. Ostalo je nejasno šta učiniti sa UDP protokolom. Pretraživanje me je dovelo do članaka o korištenju socata u kombinaciji sa SSH tunelom za prosljeđivanje UDP porta, međutim, primijetili su da ovaj pristup radi samo u načinu jedne veze, što znači da bi više VPN klijenata bilo nemoguće. Došao sam na ideju da postavim VPN server na VPS, i postavim GRE za klijente, ali kako se ispostavilo, GRE ne podržava enkripciju, što će dovesti do toga da ako treća lica dobiju pristup serveru , sav promet između mojih mreža je u njihovim rukama što mi nikako nije odgovaralo.

Ponovo je donesena odluka u korist redundantne enkripcije, korištenjem VPN-a preko VPN-a prema sljedećoj shemi:

Layer XNUMX VPN:
VPS To je server sa internom adresom 192.168.30.1
MS To je klijent VPS sa internom adresom 192.168.30.2
MK2 To je klijent VPS sa internom adresom 192.168.30.3
MK3 To je klijent VPS sa internom adresom 192.168.30.4

Layer XNUMX VPN:
MS To je server sa eksternom adresom 192.168.30.2 i internom 192.168.31.1
MK2 To je klijent MS sa adresom 192.168.30.2 i ima internu IP adresu 192.168.31.2
MK3 To je klijent MS sa adresom 192.168.30.2 i ima internu IP adresu 192.168.31.3

* MS - ruter-server u apartmanu 1, MK2 - ruter u apartmanu 2, MK3 - ruter u apartmanu 3
* Konfiguracije uređaja su objavljene u spojleru na kraju članka.

I tako, pingovi između čvorova mreže 192.168.31.0/24 idu, vrijeme je da pređemo na postavljanje GRE tunela. Prije toga, kako se ne bi izgubio pristup ruterima, vrijedi postaviti SSH tunele za prosljeđivanje porta 22 na VPS, tako da će npr. ruter iz apartmana 10022 biti dostupan na portu 2 VPS-a, a Ruter iz apartmana 11122 će biti dostupan na portu 3 VPS-a ruter iz apartmana XNUMX. Najbolje je konfigurirati prosljeđivanje sa istim sshtunelom, jer će vratiti tunel u slučaju da padne.

Tunel je konfigurisan, možete se povezati na SSH preko proslijeđenog porta:

ssh root@МОЙ_VPS -p 10022

Zatim onemogućite OpenVPN:

/etc/init.d/openvpn stop

Sada postavimo GRE tunel na ruteru iz apartmana 2:

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

I dodajte kreirani interfejs na most:

brctl addif br-lan grelan0

Izradimo sličnu proceduru na serverskom ruteru:

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

I, također, dodajte kreirani interfejs na most:

brctl addif br-lan grelan0

počevši od ovog trenutka, pingovi počinju uspješno da idu na novu mrežu i ja sa zadovoljstvom odlazim na kafu. Zatim, da vidim kako radi mreža na drugom kraju žice, pokušavam da uđem SSH u jedan od računara u stanu 2, ali ssh klijent se zamrzava bez traženja lozinke. Pokušavam da se povežem sa ovim računarom preko telneta na portu 22 i vidim liniju iz koje možete da razumete da se konekcija uspostavlja, SSH server se javlja, ali mi iz nekog razloga ne nudi da uđem.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Pokušavam da se povežem na njega preko VNC-a i vidim crni ekran. Uvjeravam se da je stvar u udaljenom kompjuteru, jer se iz ovog stana lako mogu spojiti na ruter koristeći internu adresu. Međutim, odlučujem da uđem SSH u ovaj računar preko rutera i iznenađen sam kada otkrijem da je veza uspjela i da udaljeni računar radi dobro, ali se ne može povezati ni s mojim računalom.

Vadim grelan0 uređaj sa mosta i pokrećem OpenVPN na ruteru u stanu 2 i uveravam se da mreža ponovo radi kako treba i da veze ne padaju. Pretražujući nailazim na forume na kojima se ljudi žale na iste probleme, gdje im se savjetuje da podignu MTU. Ne pre rečeno nego učinjeno. Međutim, sve dok MTU nije postavljen na dovoljno veliku vrijednost od 7000 za gretap uređaje, primijećeni su ili prekinuti TCP veze ili spori prijenosi. Zbog visokog MTU-a za gretap, MTU-ovi za WireGuard veze prvog i drugog nivoa su postavljeni na 8000 i 7500, respektivno.

Napravio sam slično podešavanje na ruteru iz apartmana 3, sa jedinom razlikom što je drugi gretap interfejs pod imenom grelan1 dodat na serverski ruter, koji je takođe dodat na br-lan most.

Sve radi. Sada možete staviti gretap sklop u autoload. Za ovo:

Stavite ove linije u /etc/rc.local na ruteru u apartmanu 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

Ovo je dodato u /etc/rc.local na ruteru u stanu 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

I na serverskom ruteru:

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

Nakon ponovnog pokretanja klijentskih rutera, otkrio sam da se iz nekog razloga ne povezuju na server. Povezivanjem na njihov SSH (srećom, prethodno sam konfigurirao sshtunnel za ovo), otkriveno je da WireGuard iz nekog razloga kreira rutu za krajnju tačku, ali nije tačan. Dakle, za 192.168.30.2, tabela ruta je navedena u tabeli ruta preko pppoe-wan interfejsa, odnosno preko Interneta, iako je ruta do nje trebala biti usmerena preko wg0 interfejsa. Nakon brisanja ove rute, veza je obnovljena. Nigdje nisam mogao pronaći upute kako natjerati WireGuard da ne kreira ove rute. Štaviše, nisam ni razumio da li je ovo karakteristika OpenWRT-a ili samog WireGuarda. Bez potrebe da se dugo bavim ovim problemom, jednostavno sam dodao na oba rutera u skripti koju je zapetljao tajmer, liniju koja je izbrisala ovu rutu: 

route del 192.168.30.2

Sumiranje

Još nisam postigao potpuno odbacivanje OpenVPN-a, jer ponekad moram da se povežem na novu mrežu sa laptopa ili telefona, a postavljanje gretap uređaja na njih je uglavnom nemoguće, ali uprkos tome, dobio sam prednost u prenosu podataka brzina između stanova i, na primjer, korištenje VNC-a više nije nezgodno. Ping se malo smanjio, ali je postao stabilniji:

Kada koristite 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

Kada koristite 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

Najviše je pogođen visokim pingom prema VPS-u koji iznosi otprilike 61.5 ms

Međutim, brzina je značajno porasla. Dakle, u stanu sa ruter-serverom imam brzinu internet konekcije od 30 Mbps, au ostalim stanovima 5 Mbps. Istovremeno, koristeći OpenVPN, nisam mogao postići brzinu prijenosa podataka između mreža veću od 3,8 Mbps prema iperf-u, dok ga je WireGuard “pumpao” na istih 5 Mbps.

WireGuard konfiguracija na VPS-u[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

WireGuard konfiguracija na MS (dodato u /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 konfiguracija na MK2 (dodato u /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 konfiguracija na MK3 (dodato u /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'

U opisanim konfiguracijama za drugi nivo VPN-a navodim port 51821 za WireGuard klijente. Teoretski, to nije neophodno, jer će klijent uspostaviti vezu sa bilo kog slobodnog neprivilegovanog porta, ali sam napravio tako da sve dolazne veze može biti odbijen na wg0 interfejsima svih rutera, osim dolaznih UDP veza na portu 51821.

Nadam se da će članak nekome biti od koristi.

PS Također, želim podijeliti svoju skriptu koja mi šalje PUSH obavijest na moj telefon u aplikaciji WirePusher kada se novi uređaj pojavi na mojoj mreži. Evo linka do skripte: github.com/r0ck3r/device_discover.

UPDATE: Konfiguracija OpenVPN servera i klijenata

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 klijent

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

Koristio sam easy-rsa za generiranje certifikata.

izvor: www.habr.com

Dodajte komentar