🥇Övergång från OpenVPN på WireGuard att kombinera nätverk till ett L2-nätverk

Jag skulle vilja dela med mig av min erfarenhet av att kombinera nätverk i tre geografiskt avlägsna lägenheter, som var och en använder routrar med OpenWRT som gateway, till ett gemensamt nätverk. När man valde en metod för att kombinera nätverk mellan L3 med subnät routing och L2 med bryggning, när alla nätverksnoder kommer att vara i samma subnät, föredrogs den andra metoden, som är svårare att konfigurera, men ger fler möjligheter, eftersom transparent användning av teknik planerades i det skapade nätverket Wake-on-Lan och DLNA.

Del 1: Bakgrund

Protokollet som valdes för att implementera denna uppgift var initialt OpenVPN, eftersom det för det första kan skapa en avtappningsanordning som kan läggas till bryggan utan problem, och för det andra, OpenVPN Den stöder TCP, vilket också var viktigt, eftersom ingen av lägenheterna hade en dedikerad IP-adress. Jag kunde inte använda STUN eftersom min internetleverantör, av någon anledning, blockerar inkommande UDP-anslutningar från sina nätverk. TCP tillät mig att vidarebefordra VPN-serverporten till den hyrda VPS:en med hjälp av SSH. Även om denna metod skapar en betydande omkostnad, eftersom informationen är dubbelkrypterad, ville jag inte integrera VPS:en i mitt privata nätverk, eftersom det fanns en risk att tredje part fick kontroll över den. Därför var det mycket oönskat att ha en sådan enhet i mitt hemnätverk, så jag bestämde mig för att betala en betydande omkostnad för säkerhet.

För att vidarebefordra porten på routern där servern var planerad att distribueras använde jag programmet sshtunnel. Jag kommer inte att gå in på detaljerna kring dess konfiguration – det är ganska enkelt. Jag vill bara notera att dess syfte var att vidarebefordra TCP-port 1194 från routern till VPS:en. Därefter konfigurerade jag servern. OpenVPN På tap0-enheten, som var ansluten till br-lan-bryggan. Efter att ha testat anslutningen till den nyskapade servern från min bärbara dator, blev det tydligt att portvidarebefordran hade fungerat, och min bärbara dator hade blivit medlem i routerns nätverk, trots att den inte fysiskt var en del av det.

Det enda som återstod var att fördela IP-adresser i olika lägenheter så att de inte skulle hamna i konflikt och konfigurera routrarna som OpenVPN-klienter.
Följande router-IP-adresser och DHCP-serverintervall valdes:

192.168.10.1 med räckvidd 192.168.10.2 - 192.168.10.80 för servern
192.168.10.100 med räckvidd 192.168.10.101 - 192.168.10.149 för en router i lägenhet nr 2
192.168.10.150 med räckvidd 192.168.10.151 - 192.168.10.199 för en router i lägenhet nr 3

Det var också nödvändigt att tilldela dessa adresser till klientroutrarna. OpenVPN-server, genom att lägga till följande rad i dess konfiguration:

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

och lägga till följande rader i filen /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

där flat1_id och flat2_id är enhetsnamnen som anges när certifikat skapas för anslutning till OpenVPN

Därefter konfigurerades routrarna OpenVPN- klienter, tap0-enheter på båda lades till i br-lan-bryggan. Vid det här laget verkade allt bra, eftersom alla tre nätverk kunde se varandra och fungera som en enda enhet. En ganska obehaglig detalj framkom dock: ibland fick enheter en IP-adress från fel router, med alla följder. Av någon anledning svarade inte routern i en av lägenheterna på DHCPDISCOVER i tid, och enheten fick fel adress. Jag insåg att jag behövde filtrera sådana förfrågningar i tap0 på varje router, men det visade sig att iptables inte kan fungera med en enhet om den är en del av en brygga, så jag behövde använda ebtables. Tyvärr inkluderade inte min firmware det, så jag var tvungen att bygga om avbildningarna för varje enhet. Efter att ha gjort detta och lagt till följande rader i /etc/rc.local på varje router, löstes problemet:

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

Denna konfiguration varade i tre år.

Del 2: Lär känna WireGuard

På senare tid har det pratats alltmer på internet om WireGuardoch beundrar dess enkla konfiguration, höga överföringshastighet, låga ping och jämförbara säkerhet. En sökning efter ytterligare information om den visade att den inte stöder vare sig bryggmedlemmar eller TCP-protokoll, vilket fick mig att tro att det inte fanns något alternativ. OpenVPN för mig är den fortfarande inte där. Så jag sköt upp att lära känna WireGuard.

För några dagar sedan spreds nyheter genom resurser relaterade till IT på ett eller annat sätt att WireGuard kommer äntligen att inkluderas i kärnan Linux, med början från version 5.6. Nyhetsartiklarna fick, som alltid, beröm. WireGuardJag kastade mig återigen in i att leta efter sätt att ersätta det gamla goda OpenVPNDen här gången sprang jag in i denna artikel. Det talade om att skapa en Ethernet-tunnel över L3 med GRE. Den här artikeln gav mig hopp. Det förblev oklart vad man skulle göra med UDP-protokollet. Sökandet ledde mig till artiklar om att använda socat i samband med en SSH-tunnel för att vidarebefordra en UDP-port, men de noterade att detta tillvägagångssätt bara fungerar i enkel anslutningsläge, vilket innebär att flera VPN-klienter skulle vara omöjliga. Jag kom på idén att sätta upp en VPN-server på en VPS och konfigurera GRE för klienter, men det visade sig att GRE inte stöder kryptering, vilket kommer att leda till att om tredje part får tillgång till servern, all trafik mellan mina nätverk ligger i deras händer vilket inte passade mig alls.

Återigen togs beslutet till förmån för redundant kryptering, genom att använda VPN över VPN enligt följande schema:

Layer XNUMX VPN:
VPS är server med intern adress 192.168.30.1
MS är klient VPS med intern adress 192.168.30.2
MK2 är klient VPS med intern adress 192.168.30.3
MK3 är klient VPS med intern adress 192.168.30.4

Layer XNUMX VPN:
MS är server med extern adress 192.168.30.2 och intern 192.168.31.1
MK2 är klient MS med adressen 192.168.30.2 och har en intern IP på 192.168.31.2
MK3 är klient MS med adressen 192.168.30.2 och har en intern IP på 192.168.31.3

* MS - router-server i lägenhet 1, MK2 - router i lägenhet 2, MK3 - router i lägenhet 3
* Enhetskonfigurationer publiceras i spoilern i slutet av artikeln.

Och så, pingar mellan noderna i nätverket 192.168.31.0/24 go, det är dags att gå vidare till att sätta upp GRE-tunneln. Innan dess, för att inte tappa tillgången till routrar, är det värt att sätta upp SSH-tunnlar för att vidarebefordra port 22 till VPS, så att till exempel en router från lägenhet 10022 kommer att finnas tillgänglig på port 2 i VPS, och en router från lägenhet 11122 kommer att finnas tillgänglig på port 3 på VPS.router från lägenhet XNUMX. Det är bäst att konfigurera vidarebefordran med samma sshtunnel, eftersom den kommer att återställa tunneln om den skulle falla.

Tunneln är konfigurerad, du kan ansluta till SSH via den vidarebefordrade porten:

ssh root@МОЙ_VPS -p 10022

Nästa steg är att inaktivera OpenVPN:

/etc/init.d/openvpn stop

Låt oss nu sätta upp en GRE-tunnel på routern från lägenhet 2:

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

Och lägg till det skapade gränssnittet till bryggan:

brctl addif br-lan grelan0

Låt oss utföra en liknande procedur på serverroutern:

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

Och lägg också till det skapade gränssnittet till bryggan:

brctl addif br-lan grelan0

från och med det här ögonblicket börjar plingar framgångsrikt gå till det nya nätverket och jag, med tillfredsställelse, går för att dricka kaffe. Sedan, för att se hur nätverket i andra änden av tråden fungerar, försöker jag att SSH till en av datorerna i lägenhet 2, men ssh-klienten fryser utan att fråga mig om ett lösenord. Jag försöker ansluta till den här datorn via telnet på port 22 och ser en linje från vilken du kan förstå att anslutningen upprättas, SSH-servern svarar, men av någon anledning erbjuder den mig inte att komma in.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Jag försöker ansluta till den via VNC och jag ser en svart skärm. Jag övertygar mig själv om att saken ligger i fjärrdatorn, eftersom jag enkelt kan ansluta till routern från den här lägenheten med den interna adressen. Jag bestämmer mig dock för att SSH till den här datorn via routern och är förvånad över att upptäcka att anslutningen lyckas och att fjärrdatorn fungerar bra men inte heller kan ansluta till min dator.

Jag tar ut grelan0-enheten ur bryggan och kör den. OpenVPN På routern i lägenhet 2 bekräftade jag att nätverket fungerade korrekt igen och att anslutningarna inte tappade. När jag sökte hittade jag forum där folk klagade på samma problem och där de råddes att höja MTU:n. Sagt och gjort. Men tills MTU:n var tillräckligt hög – 7000 för gretap-enheter – upplevde jag antingen tappade TCP-anslutningar eller låga överföringshastigheter. På grund av den höga MTU:n för gretap, MTU:n för anslutningar WireGuard Den första och andra nivån sattes till 8000 respektive 7500.

Jag gjorde en liknande installation på routern från lägenhet 3, med den enda skillnaden att ett andra gretap-gränssnitt med namnet grelan1 lades till serverroutern, som också lades till br-lan-bryggan.

Allt fungerar. Nu kan du sätta gretap-enheten i autoload. För detta:

Placerade dessa rader i /etc/rc.local på routern i lägenhet 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

Lade till detta i /etc/rc.local på routern i lägenhet 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

Och på serverroutern:

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 att ha startat om klientroutrarna upptäckte jag att de av någon anledning inte anslöt till servern. Efter att ha anslutit till deras SSH (som tur var hade jag tidigare konfigurerat sshtunnel för detta) upptäckte jag att WireGuard Av någon anledning skapar den en rutt för slutpunkten, men den är felaktig. Till exempel, för 192.168.30.2, specificerade routingtabellen en rutt via pppoe-wan-gränssnittet, dvs. via internet, trots att rutten dit borde ha dirigerats via wg0-gränssnittet. Efter att ha tagit bort den här rutten återställdes anslutningen. Kan jag hitta instruktioner någonstans om hur man tvingar fram WireGuard Jag kunde inte undvika att skapa dessa rutter. Dessutom förstod jag inte ens om detta var en funktion i OpenWRT eller i WireGuardUtan att lägga ner mycket tid på att lista ut problemet lade jag helt enkelt till en rad i timer-loop-skriptet på båda routrarna som raderade den här rutten:

route del 192.168.30.2

Summera

Fullständigt avslag OpenVPN Jag har inte lyckats med detta än, eftersom jag ibland behöver ansluta till ett nytt nätverk från en bärbar dator eller telefon, och det är i allmänhet omöjligt att konfigurera en gretap-enhet på dem. Trots detta har jag fått en fördel i dataöverföringshastigheten mellan lägenheter, och att använda VNC är nu problemfritt. Pingen har minskat något men blivit stabilare:

När du använder 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

När du använder 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åverkas mestadels av hög ping till VPS som är cirka 61.5 ms

Hastigheten har dock ökat avsevärt. Så i lägenheten med routern/servern har jag en internetanslutningshastighet på 30 Mbps, och i de andra lägenheterna är den 5 Mbps. Dessutom, under användning OpenVPN Jag kunde inte uppnå en dataöverföringshastighet mellan nätverk på mer än 3,8 Mbps enligt iperf-avläsningar, medan WireGuard "pumpade" upp den till samma 5 Mbit/sek.

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

[Jämlikar]
Offentlig nyckel = <VPN_1_MS_PUBLIC_KEY>
TillåtnaIPs = 192.168.30.2/32

[Jämlikar]
Offentlig nyckel = <VPN_2_MK2_PUBLIC_KEY>
TillåtnaIPs = 192.168.30.3/32

[Jämlikar]
Offentlig nyckel = <VPN_2_MK3_PUBLIC_KEY>
TillåtnaIPs = 192.168.30.4/32

konfiguration WireGuard på MS (tillagd till /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'

konfiguration WireGuard på MK2 (tillagd till /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'

konfiguration WireGuard på MK3 (tillagd till /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 beskrivna konfigurationerna för VPN på andra nivån indikerar jag för klienter WireGuard Port 51821. Detta borde inte vara nödvändigt, eftersom klienten kommer att upprätta en anslutning från vilken ledig, oprivilegierad port som helst, men jag gjorde det på det här sättet så att jag kunde neka alla inkommande anslutningar på wg0-gränssnitten för alla routrar, förutom inkommande UDP-anslutningar till port 51821.

Jag hoppas att artikeln kommer att vara användbar för någon.

PS Jag vill också dela mitt skript som skickar mig ett PUSH-meddelande till min telefon i WirePusher-appen när en ny enhet dyker upp i mitt nätverk. Här är en länk till skriptet: github.com/r0ck3r/device_discover.

UPPDATERING: konfiguration OpenVPN-servrar och 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 # 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

Jag använde easy-rsa för att generera certifikat.

Källa: will.com