🥇Overgang fra OpenVPN til WireGuard for at samle netværk i ét L2-netværk

Jeg vil gerne dele min erfaring med at sammenkoble netværk i tre geografisk adskilte lejligheder, hvor hver af dem bruger routere med OpenWRT som gateway, til et fælles netværk. Når man skulle vælge mellem L3 med routing af subnets og L2 med bridging, hvor alle netværkets noder ville befinde sig i det samme subnet, blev det andet mere komplekse, men kraftfulde valg foretrukket, da den planlagte netværk skulle muliggøre gennemsigtig brug af Wake-on-LAN og DLNA-teknologier.

Del 1: Baggrund

Som protokol til at implementere denne opgave blev OpenVPN først valgt, da det for det første kan oprette et tap-enhed, som nemt kan tilføjes til broen, og for det andet understøtter OpenVPN TCP-protokollen, hvilket var vigtigt, da ingen af lejlighederne havde en dedikeret IP-adresse, og jeg ikke kunne bruge STUN, da min udbyder af en eller anden grund blokerer indgående forbindelser via UDP-protokollen fra sine netværk, mens TCP-protokollen gjorde det muligt for mig at videresende porten fra VPN-serveren på den lejede VPS via SSH. Ja, denne tilgang giver en stor lasten, da dataene krypteres to gange, men jeg ønskede ikke at inkludere VPS i mit private netværk, da der stadig var risiko for, at tredjepart kunne få kontrol over det, og derfor var det yderst uønsket at have en sådan enhed i hjemmenetværket, så jeg besluttede at betale for sikkerhed med et stort overhead.

For at videresende porten på routeren, hvor serveren skulle opsættes, blev programmet sshtunnel brugt. Jeg vil ikke beskrive detaljerne i dens konfiguration - det gøres ret nemt, jeg vil blot bemærke, at dens opgave var at videresende TCP-port 1194 fra routeren til VPS. Derefter blev OpenVPN-serveren konfigureret på tap0-enheden, som blev tilføjet til broen br-lan. Efter at have testet forbindelsen til den nyoprettede server fra min bærbare computer - blev det klart, at ideen med portvideresendelsen fungerede, og min bærbare computer blev en del af routerens netværk, selvom den ikke fysisk befandt sig i det.

Der var kun det lille tilbage: IP-adresserne i de forskellige lejligheder skulle fordeles, så de ikke kom i konflikt, og routerne skulle konfigureres som OpenVPN-klienter.
De valgte IP-adresser for routerne og DHCP-servernes områder var:

192.168.10.1 med området 192.168.10.2 — 192.168.10.80 for serveren
192.168.10.100 med området 192.168.10.101 — 192.168.10.149 til routeren i lejlighed nr. 2
192.168.10.150 med området 192.168.10.151 — 192.168.10.199 til routeren i lejlighed nr. 3

Det var også nødvendigt at tildele netop disse adresser til OpenVPN-serverens klientroutere ved at tilføje følgende linje til dens konfiguration:

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

og tilføje følgende linjer til filen /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

hvor flat1_id og flat2_id er navnene på enhederne, angivet ved oprettelse af certifikater til forbindelse til OpenVPN

Derefter blev OpenVPN-klienter indstillet på routerne, og tap0-enhederne på begge blev tilføjet til broen br-lan. På dette tidspunkt syntes alt at fungere fint, da alle tre netværk kunne se hinanden og fungere som en helhed. Dog viste der sig en ubehagelig detalje: nogle gange kunne enhederne få en IP-adresse ikke fra deres egen router, hvilket medførte alle mulige konsekvenser. Af en eller anden grund nåede routeren i en af lejlighederne ikke at svare rettidigt på DHCPDISCOVER, så enheden fik ikke sin egen adresse. Jeg indså, at jeg måtte filtrere sådanne forespørgsler i tap0 på hver af routerne, men som det viste sig, kunne iptables ikke arbejde med enheden, hvis den var en del af broen, og jeg måtte have hjælp fra ebtables. Til min beklagelse var den ikke inkluderet i mine firmwares, så jeg måtte genopbygge billederne for hver enhed. Da jeg havde gjort dette og tilføjet disse linjer til /etc/rc.local på hver router, var problemet løst:

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

Denne konfiguration har varet i tre år.

Del 2: Introduktion til WireGuard

For nylig har der været meget snak om WireGuard på internettet, beundret for sin enkle konfiguration, høje hastighed og lave ping ved sammenlignelig sikkerhed. At søge efter yderligere information om det viste, at hverken driften som en del af en bro, eller driften over TCP-protokollen understøttes, hvilket fik mig til at tænke, at der fortsat ikke er nogen alternativer til OpenVPN for mig. Så jeg udsatte min introduktion til WireGuard.

For nogle dage siden fløj nyheden om, at WireGuard endelig vil blive inkluderet i Linux-kernen fra version 5.6, rundt på IT-ressourcer. Nyhedsartiklerne, som altid, roste WireGuard. Jeg dykkede igen ned i søgninger efter måder at erstatte den gode gamle OpenVPN. Denne gang stødte jeg på denne artikel. Det blev nævnt, at man kunne oprette en Ethernet-tunnel over L3 ved hjælp af GRE. Denne artikel gav mig håb. Det var dog stadig uklart, hvad man skulle gøre med UDP-protokollen. Mine søgninger bragte mig til artikler om at bruge socat i kombination med en SSH-tunnel for at videresende UDP-porten, men de nævnte, at denne tilgang kun fungerede i én forbindelse, hvilket ville gøre det umuligt for flere VPN-klienter at fungere. Jeg fik ideen om at opsætte en VPN-server på en VPS, og til klienterne konfigurere GRE, men som det viste sig, understøtter GRE ikke kryptering, hvilket ville betyde, at hvis tredjeparter fik adgang til serveren, ville hele trafikken mellem mine netværk være i deres hænder, hvilket jeg ikke kunne acceptere.

Igen blev der truffet beslutning om overdreven kryptering ved at bruge VPN over VPN efter følgende skema:

VPN på første niveau:
VPS Baggrunden indeholder tekstur af siden og illustrationer, og dens opløsning er lavere end maskens. Baggrunden gemmes tabsløst for opfattelse med en opløsning på 100 dpi. serveren med intern adresse 192.168.30.1
MS Baggrunden indeholder tekstur af siden og illustrationer, og dens opløsning er lavere end maskens. Baggrunden gemmes tabsløst for opfattelse med en opløsning på 100 dpi. klient VPS med intern adresse 192.168.30.2
MK2 Baggrunden indeholder tekstur af siden og illustrationer, og dens opløsning er lavere end maskens. Baggrunden gemmes tabsløst for opfattelse med en opløsning på 100 dpi. klient VPS med intern adresse 192.168.30.3
MK3 Baggrunden indeholder tekstur af siden og illustrationer, og dens opløsning er lavere end maskens. Baggrunden gemmes tabsløst for opfattelse med en opløsning på 100 dpi. klient VPS med intern adresse 192.168.30.4

VPN på andet niveau:
MS Baggrunden indeholder tekstur af siden og illustrationer, og dens opløsning er lavere end maskens. Baggrunden gemmes tabsløst for opfattelse med en opløsning på 100 dpi. serveren med ekstern adresse 192.168.30.2 og intern 192.168.31.1
MK2 Baggrunden indeholder tekstur af siden og illustrationer, og dens opløsning er lavere end maskens. Baggrunden gemmes tabsløst for opfattelse med en opløsning på 100 dpi. klient MS med adresse 192.168.30.2 og har intern IP 192.168.31.2
MK3 Baggrunden indeholder tekstur af siden og illustrationer, og dens opløsning er lavere end maskens. Baggrunden gemmes tabsløst for opfattelse med en opløsning på 100 dpi. klient MS med adresse 192.168.30.2 og har intern IP 192.168.31.3

* MS — router-server i lejlighed 1, MK2 — router i lejlighed 2, MK3 — router i lejlighed 3
* Enhedskonfigurationerne er offentliggjort i spoileret i slutningen af artiklen.

Så, pingene mellem noderne i netværket 192.168.31.0/24 kører, det er tid til at konfigurere GRE-tunnelen. Før dette, for ikke at miste adgangen til routerne, skal der konfigureres SSH-tunneler til videresendelse af port 22 til VPS, således at, for eksempel, routeren fra lejlighed 2 vil være tilgængelig på port 10022, og routeren fra lejlighed 3 vil være tilgængelig på port 11122. Det er bedst at udføre videresendelsen med sshtunnel, da det vil genoprette tunnelen, hvis den falder.

Tunnelen er konfigureret, man kan oprette forbindelse til SSH gennem den videresendte port:

ssh root@MIN_VPS -p 10022

Dernæst skal OpenVPN deaktiveres:

/etc/init.d/openvpn stop

Nu konfigurerer vi GRE-tunnelen på routeren fra lejlighed 2:

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

Og vi tilføjer det oprettede interface til broen:

brctl addif br-lan grelan0

Vi udfører en lignende procedure på routeren-serveren:

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

Og også tilføjer vi det oprettede interface til broen:

brctl addif br-lan grelan0

Fra nu af begynder pingene at fungere korrekt i det nye netværk, og jeg kan tilfreds gå ud for at drikke kaffe. For at vurdere, hvordan netværket fungerer i den anden ende af ledningen, forsøger jeg at oprette forbindelse via SSH til en af computeren i lejlighed 2, men SSH-klienten "hænger" og tilbyder ikke at indtaste kodeord. Jeg prøver at oprette forbindelse til denne computer via telnet på port 22 og ser en linje, der antyder, at forbindelsen etableres, SSH-serveren svarer, men af en eller anden grund tilbyder den ikke at logge ind.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Jeg forsøger at forbinde til den samme computer via VNC og ser en sort skærm. Jeg overbeviser mig selv om, at det er den fjerntliggende computers skyld, for jeg kan uden problemer oprette forbindelse til routeren fra denne lejlighed via den interne adresse. Men jeg beslutter mig for at forbinde til SSH på denne computer gennem routeren og opdager med overraskelse, at forbindelsen lykkes, og den fjerntliggende computer fungerer ganske normalt, men den kan heller ikke forbinde til min computer.

Jeg fjerner grelan0-enheden fra broen og starter OpenVPN på routeren i lejlighed 2 og bekræfter, at netværket igen fungerer som det skal, og forbindelserne brydes ikke. Jeg støder på nogle fora, hvor folk klager over de samme problemer, hvor de får råd til at hæve MTU. Ord sagt — ord gjort. Men indtil MTU ikke var sat tilstrækkeligt højt — 7000 for gretap-enhederne, blev der observeret enten TCP-forbindelsesbrud eller lav transmitteringshastighed. På grund af den høje MTU for gretap — MTU for WireGuard-forbindelser på første og anden niveau blev sat til henholdsvis 8000 og 7500.

Jeg udførte en lignende opsætning på routeren i lejlighed 3, med den eneste forskel, at der blev tilføjet et andet gretap-interface med navnet grelan1 til routeren-serveren, som også blev tilføjet til broen br-lan.

Alt fungerer. Nu kan gretap-opsætningen placeres i opstart. For dette:

Jeg placerede disse linjer i /etc/rc.local på routeren i lejlighed 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

Jeg tilføjede dette til /etc/rc.local på routeren i lejligheden 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

Og på router-serveren:

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

Efter genstart af klientrouterne opdagede jeg, at de af en eller anden grund ikke kunne oprette forbindelse til serveren. Da jeg tilsluttede mig deres SSH (heldigvis havde jeg forudkonfigureret sshtunnel til dette), blev det opdaget, at WireGuard på en eller anden måde opretter en rute for endpointet, men en forkert. Så for 192.168.30.2 var der angivet en rute i routetabellen gennem interface pppoe-wan, dvs. gennem internettet, selvom ruten skulle være rettet gennem interface wg0. Efter at have fjernet denne rute blev forbindelsen genoptaget. Jeg kunne ikke finde nogen instruktioner om, hvordan man tvinger WireGuard til ikke at oprette disse ruter. Desuden forstod jeg ikke engang, om det var en funktion af OpenWRT eller selve WireGuard. Uden at bruge tid på at finde ud af dette problem, tilføjede jeg bare en linje til begge routere i et script, der kørte cyklisk, som slettede denne rute:

route del 192.168.30.2

Afslutningsvis

Jeg har endnu ikke opnået en fuldstændig opgivelse af OpenVPN, da jeg har brug for nogle gange at oprette forbindelse til et nyt netværk fra min bærbare computer eller telefon, og opsætningen af gretap-enheden på dem er generelt umulig. Men trods dette har jeg opnået en fordel i dataoverførselshastighed mellem lejlighederne, og f.eks. giver brugen af VNC nu ikke problemer. Ping er blevet reduceret en smule, men er blevet mere stabil:

Ved brug af 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

Ved brug af 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

Det påvirkes i højere grad af den høje ping til VPS, som er ca. 61,5 ms

Men hastigheden er steget betydeligt. Så i lejligheden med serverrouteren har jeg en internetforbindelse på 30 Mbps, mens de andre lejligheder har 5 Mbps. Desuden kunne jeg under brug af OpenVPN ikke opnå en datatransmissionshastighed mellem netværkene på mere end 3,8 Mbps ifølge iperf, mens WireGuard 'pumpede' det op til de samme 5 Mbps.

WireGuard-konfiguration på VPS[Interface] Adresse = 192.168.30.1/24 LyttePort = 51820 PrivatNøgle =

[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-konfiguration på MC (tilføjes i /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-konfiguration på MK2 (tilføjes i /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-konfiguration på MK3 (tilføjes i /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'

I de beskrevne konfigurationer for niveau to VPN angiver jeg WireGuard-klienterne port 51821. Teoretisk set er dette ikke nødvendigt, da klienten vil oprette forbindelse fra enhver ledig ikke-privilegeret port, men jeg gjorde det, så man kunne forbyde alle indgående forbindelser på wg0-interfacene på alle routere, undtagen indgående UDP-forbindelser til port 51821.

Jeg håber, at artiklen vil være nyttig for nogen.

P.S. Jeg vil også dele mit script, der sender en PUSH-notifikation til min telefon i WirePusher-appen, når der optræder en ny enhed i mit netværk. Her er linket til scriptet: github.com/r0ck3r/device_discover.

OPDATERING: Konfiguration af OpenVPN-server og klienter

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 # Skift til din routers Eksterne 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

Jeg brugte easy-rsa til at generere certifikater.

Kilde: habr.com

Overgang fra OpenVPN til WireGuard for at samle netværk i et L2-netværk

Del 1: Baggrund

Del 2: Introduktion til WireGuard

Afslutningsvis