🥇Přechod z OpenVPN na WireGuard sloučit sítě do jedné sítě L2

Rád bych se podělil o své zkušenosti se spojením sítí ve třech geograficky vzdálených bytech, z nichž každý používá routery s OpenWRT jako bránu, do jedné společné sítě. Při výběru metody pro kombinaci sítí mezi L3 se směrováním podsítě a L2 s přemostěním, kdy všechny síťové uzly budou ve stejné podsíti, byla dána přednost druhému způsobu, který je obtížnější na konfiguraci, ale poskytuje více příležitostí, protože transparentní využití technologií bylo plánováno ve vytvořené síti Wake-on-Lan a DLNA.

Část 1: Pozadí

Protokol zvolený pro implementaci tohoto úkolu byl původně OpenVPN, protože zaprvé dokáže vytvořit odbočovací zařízení, které lze bez problémů přidat k můstku, a zadruhé, OpenVPN Podporuje TCP, což bylo také důležité, protože žádný z bytů neměl dedikovanou IP adresu. Nemohl jsem použít STUN, protože můj poskytovatel internetových služeb z nějakého důvodu blokuje příchozí UDP připojení ze svých sítí. TCP mi umožnil přesměrovat port VPN serveru na pronajatý VPS pomocí SSH. I když tento přístup vytváří značné režijní náklady, protože data jsou dvojitě šifrována, nechtěl jsem VPS integrovat do své privátní sítě, protože existovalo riziko, že nad ním získají kontrolu třetí strany. Proto bylo mít takové zařízení v mé domácí síti velmi nežádoucí, a tak jsem se rozhodl zaplatit značnou režii za zabezpečení.

Pro přesměrování portu na routeru, kde měl být server nasazen, jsem použil program sshtunnel. Nebudu zacházet do detailů jeho konfigurace – je to docela snadné. Jen poznamenám, že jeho účelem bylo přesměrovat TCP port 1194 z routeru na VPS. Dále jsem nakonfiguroval server. OpenVPN Na zařízení tap0, které bylo připojeno k mostu br-lan. Po otestování připojení k nově vytvořenému serveru z mého notebooku se ukázalo, že nápad s přesměrováním portů fungoval a můj notebook se stal členem sítě routeru, i když fyzicky nebyl její součástí.

Zbývalo už jen rozdělit IP adresy do různých bytů tak, aby se nekolidovaly, a nakonfigurovat routery dle... OpenVPN-klienti.
Byly vybrány následující adresy IP routeru a rozsahy serverů DHCP:

192.168.10.1 s rozsahem 192.168.10.2 - 192.168.10.80 pro server
192.168.10.100 s rozsahem 192.168.10.101 - 192.168.10.149 pro router v bytě č. 2
192.168.10.150 s rozsahem 192.168.10.151 - 192.168.10.199 pro router v bytě č. 3

Bylo také nutné přiřadit tyto adresy klientským routerům. OpenVPN-server, přidáním následujícího řádku do jeho konfigurace:

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

a přidáním následujících řádků do souboru /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

kde flat1_id a flat2_id jsou názvy zařízení zadané při vytváření certifikátů pro připojení k OpenVPN

Dále byly nakonfigurovány routery OpenVPN- klienti, zařízení tap0 na obou byla přidána do mostu br-lan. V tomto okamžiku se zdálo, že vše je v pořádku, protože všechny tři sítě se mohly vidět a fungovat jako jeden celek. Objevil se však poněkud nepříjemný detail: někdy zařízení dostávala IP adresu ze špatného routeru se všemi z toho vyplývajícími důsledky. Z nějakého důvodu router v jednom z bytů včas nereagoval na DHCPDISCOVER a zařízení dostávalo špatnou adresu. Uvědomil jsem si, že musím takové požadavky filtrovat v tap0 na každém routeru, ale jak se ukázalo, iptables nemůže fungovat se zařízením, pokud je součástí mostu, takže jsem musel použít ebtables. Bohužel můj firmware to neobsahoval, takže jsem musel pro každé zařízení znovu sestavit obrazy. Poté, co jsem to udělal a přidal následující řádky do /etc/rc.local na každém routeru, byl problém vyřeš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

Tato konfigurace vydržela tři roky.

Část 2: Seznámení WireGuard

V poslední době se na internetu stále častěji mluví o WireGuard, obdivoval jeho snadnou konfiguraci, vysokou přenosovou rychlost, nízký ping a srovnatelné zabezpečení. Hledání dalších informací o něm ukázalo, že nepodporuje ani členy mostu, ani protokol TCP, což mě vedlo k domněnce, že neexistuje žádná alternativa. OpenVPN Pro mě to stále není ono. Takže jsem odkládal poznávání WireGuard.

Před pár dny se prostřednictvím zdrojů souvisejících s IT šířila zpráva, že WireGuard bude konečně zahrnuto do jádra Linux, počínaje verzí 5.6. Novinové články byly jako vždy chváleny WireGuardZnovu jsem se ponořil do hledání způsobů, jak nahradit staré dobré OpenVPNTentokrát jsem narazil/a na tento článek. Mluvilo se o vytvoření ethernetového tunelu přes L3 pomocí GRE. Tento článek mi dal naději. Zůstalo nejasné, co dělat s protokolem UDP. Hledání mě přivedlo k článkům o použití socatu ve spojení s tunelem SSH k předávání portu UDP, ale poznamenali, že tento přístup funguje pouze v režimu jednoho připojení, což znamená, že více klientů VPN by nebylo možné. Přišel jsem s nápadem nastavit VPN server na VPS a nakonfigurovat GRE pro klienty, ale jak se ukázalo, GRE nepodporuje šifrování, což povede k tomu, že pokud třetí strany získají přístup k serveru, veškerý provoz mezi mými sítěmi je v jejich rukou, což mi vůbec nevyhovovalo.

Opět bylo rozhodnuto ve prospěch redundantního šifrování pomocí VPN přes VPN podle následujícího schématu:

VPN vrstvy XNUMX:
VPS to je server s interní adresou 192.168.30.1
MS to je klient VPS s interní adresou 192.168.30.2
MK2 to je klient VPS s interní adresou 192.168.30.3
MK3 to je klient VPS s interní adresou 192.168.30.4

Vrstva XNUMX VPN:
MS to je server s externí adresou 192.168.30.2 a vnitřní 192.168.31.1
MK2 to je klient MS s adresou 192.168.30.2 a má vnitřní IP 192.168.31.2
MK3 to je klient MS s adresou 192.168.30.2 a má vnitřní IP 192.168.31.3

* MS - router-server v bytě 1, MK2 - router v bytě 2, MK3 - router v bytě 3
* Konfigurace zařízení jsou zveřejněny ve spoileru na konci článku.

A tak, pingy mezi uzly sítě 192.168.31.0/24 probíhají, je čas přejít k nastavení GRE tunelu. Předtím, aby nedošlo ke ztrátě přístupu k routerům, se vyplatí nastavit SSH tunely pro předávání portu 22 na VPS, takže např. router z bytu 10022 bude dostupný na portu 2 VPS a router z bytu 11122 bude dostupný na portu 3 routeru VPS z bytu XNUMX. Nejlepší je nakonfigurovat přesměrování se stejným sshtunelem, protože v případě pádu tunel obnoví.

Tunel je nakonfigurován, můžete se připojit k SSH přes přesměrovaný port:

ssh root@МОЙ_VPS -p 10022

Dále byste měli deaktivovat OpenVPN:

/etc/init.d/openvpn stop

Nyní nastavíme GRE tunel na routeru z bytu 2:

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

A přidejte vytvořené rozhraní do mostu:

brctl addif br-lan grelan0

Provedeme podobný postup na routeru serveru:

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

A také přidejte vytvořené rozhraní do mostu:

brctl addif br-lan grelan0

od tohoto okamžiku začínají pingy úspěšně odcházet do nové sítě a já spokojeně jdu pít kávu. Poté, abych zjistil, jak funguje síť na druhém konci drátu, se pokusím připojit SSH do jednoho z počítačů v bytě 2, ale klient ssh zamrzne, aniž by mě požádal o heslo. Zkouším se připojit k tomuto počítači přes telnet na portu 22 a vidím řádek, ze kterého můžete pochopit, že se navazuje spojení, SSH server odpovídá, ale z nějakého důvodu mi nenabízí vstup.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Zkouším se k němu připojit přes VNC a vidím černou obrazovku. Přesvědčuji sám sebe, že věc je ve vzdáleném počítači, protože z tohoto bytu se mohu snadno připojit k routeru pomocí interní adresy. Rozhodnu se však pro SSH do tohoto počítače přes router a jsem překvapen, když zjišťuji, že připojení je úspěšné a vzdálený počítač funguje dobře, ale nepřipojuje se ani k mému počítači.

Vyndávám zařízení grelan0 z mostu a spouštím ho. OpenVPN Na routeru v bytě 2 jsem se ujistil, že síť opět funguje správně a připojení se nerozpadá. Při hledání jsem narazil na fóra, kde si lidé stěžovali na stejné problémy a kde jim bylo doporučeno zvýšit MTU. Co se dělo, to se dělo. Dokud však nebyla hodnota MTU nastavena dostatečně vysoko – 7000 pro zařízení gretap – docházelo buď k výpadkům TCP připojení, nebo k nízkým přenosovým rychlostem. Kvůli vysoké hodnotě MTU pro gretap, tedy MTU pro připojení... WireGuard První a druhá úroveň byly stanoveny na 8000 a 7500.

Udělal jsem podobné nastavení na routeru z bytu 3, jen s tím rozdílem, že k routeru serveru bylo přidáno druhé rozhraní gretap s názvem grelan1, které bylo také přidáno do br-lan bridge.

Všechno funguje. Nyní můžete dát sestavu gretap do automatického načítání. Pro tohle:

Umístěte tyto řádky do /etc/rc.local na routeru v bytě 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

Toto bylo přidáno do /etc/rc.local na routeru v bytě 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

A na routeru serveru:

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 restartu klientských routerů jsem zjistil, že se z nějakého důvodu nepřipojují k serveru. Po připojení k jejich SSH (naštěstí jsem pro to předem nakonfiguroval sshtunnel) jsem zjistil, že WireGuard Z nějakého důvodu se sice vytvoří trasa pro koncový bod, ale ta je nesprávná. Například pro adresu 192.168.30.2 směrovací tabulka specifikovala trasu přes rozhraní pppoe-wan, tj. přes internet, ačkoliv trasa k němu měla vést přes rozhraní wg0. Po smazání této trasy bylo připojení obnoveno. Mohu někde najít návod, jak to vynutit? WireGuard Nemohl jsem se vyhnout vytváření těchto tras. Navíc jsem ani nechápal, jestli je to vlastnost OpenWRT nebo... WireGuardAniž bych trávil mnoho času hledáním příčiny problému, jednoduše jsem do skriptu timer-loop na obou routerech přidal řádek, který tuto trasu smazal:

route del 192.168.30.2

Shrnutí

Úplné odmítnutí OpenVPN Toho se mi zatím nepodařilo, protože se občas potřebuji připojit k nové síti z notebooku nebo telefonu a nastavení zařízení gretap na nich je obecně nemožné. I přes to jsem ale získal výhodu v rychlosti přenosu dat mezi byty a například používání VNC je nyní bezproblémové. Ping se sice mírně snížil, ale stal se stabilnějším:

Při použití 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

Při použití 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

Nejvíce je ovlivněno vysokým pingem na VPS, který je přibližně 61.5 ms

Rychlost se ale výrazně zvýšila. Takže v bytě s routerem-serverem mám rychlost internetového připojení 30 Mbps a v ostatních bytech je to 5 Mbps. Navíc během používání OpenVPN Podle údajů z iperfu se mi nepodařilo dosáhnout rychlosti přenosu dat mezi sítěmi vyšší než 3,8 Mbps, zatímco WireGuard "napumpoval" to na stejných 5 Mbit/s.

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

[Peer]
Veřejný klíč = <VPN_1_MS_PUBLIC_KEY>
PovolenéIPs = 192.168.30.2/32

[Peer]
VeřejnýKlíč = <VPN_2_MK2_VEŘEJNÝ_KLÍČ>
PovolenéIPs = 192.168.30.3/32

[Peer]
VeřejnýKlíč = <VPN_2_MK3_VEŘEJNÝ_KLÍČ>
PovolenéIPs = 192.168.30.4/32

Konfigurace WireGuard na MS (přidáno do /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'

Konfigurace WireGuard na MK2 (přidáno do /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'

Konfigurace WireGuard na MK3 (přidáno do /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 popsaných konfiguracích pro VPN druhé úrovně klientům uvádím WireGuard Port 51821. To by nemělo být nutné, protože klient naváže spojení z jakéhokoli volného, neprivilegovaného portu, ale já jsem to udělal takto, abych mohl odmítnout všechna příchozí připojení na rozhraních wg0 všech routerů, s výjimkou příchozích UDP připojení na port 51821.

Doufám, že článek bude pro někoho užitečný.

PS Také chci sdílet svůj skript, který mi v aplikaci WirePusher posílá PUSH upozornění na můj telefon, když se v mé síti objeví nové zařízení. Zde je odkaz na skript: github.com/r0ck3r/device_discover.

AKTUALIZOVAT: Konfigurace OpenVPN-servery a klienty

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

Ke generování certifikátů jsem použil easy-rsa.

Zdroj: www.habr.com