Szeretném megosztani tapasztalataimat három földrajzilag távoli lakás hálózatának egyesítéséről, ahol az OpenWRT-hez csatlakozó routerek szolgálnak átjáróként, egy közös hálózat létrehozásához. A hálózatok egyesítési módjának kiválasztásakor az L3-as, alhálózati irányítással rendelkező és az L2-es, hídként működő megoldás között a másodikat választottuk, mivel bonyolultabb volt beállítani, de nagyobb lehetőségeket kínált, mivel a létrehozott hálózatban a Wake-on-Lan és a DLNA technológiák átlátható használatát terveztük.
1. rész: Háttér
E feladat megvalósításához kezdetben az OpenVPN protokollt választottuk, mivel egyrészt képes tap eszköz létrehozására, amely problémamentesen hozzáadható a hídhoz, másrészt az OpenVPN támogatja a TCP protokollon való működést, ami szintén fontos volt, mivel egyik lakásban sem volt dedikált IP-cím, és a STUN használatára nem tudtam rábírni, mivel a szolgáltatóm valami okból blokkolja a bejövő UDP csatlakozásokat a saját hálózataiból, míg a TCP protokoll lehetővé tette számomra a VPN-szerver portjának továbbítását a bérelt VPS-en SSH-n keresztül. Igen, ez a megközelítés nagyobb terhelést jelent, mivel az adatokat kétszer titkosítják, de nem akartam a VPS-t a saját hálózatomba bevonni, mivel fennállt a kockázata, hogy harmadik felek ellenőrzés alá vonják, ezért egy ilyen eszköznek a helyi hálózatban való jelenléte rendkívül nemkívánatos volt, és úgy döntöttem, hogy a biztonság érdekében megfizetem a nagyobb overheadet.
A routeren, ahol a szervert terveztük telepíteni, az sshtunnel programot használtuk a port továbbítására. Nem szeretném részletezni a konfiguráció finomságait - ez viszonylag könnyen megvalósítható, csak megjegyzem, hogy a feladata a TCP 1194-es portnak a routerről a VPS-re való továbbítása volt. Ezt követően az OpenVPN szervert beállítottuk a tap0 eszközön, amelyet a br-lan hídhoz csatlakoztattunk. Miután ellenőriztem a frissen létrehozott szerverhez való kapcsolódást a laptopommal, világossá vált, hogy a porttovábbítás ötlete bevált, és a laptopom a router hálózatának tagjává vált, bár fizikailag nem tartózkodott abban.
A kérdés csak az volt, hogy a különböző lakások IP-címeit úgy kell elosztani, hogy azok ne ütközzenek, és a routereket OpenVPN-kliensekként be kell állítani.
A következő IP-címeket és DHCP-szerverek tartományait választottuk ki:
- 192.168.10.1 a tartománnyal 192.168.10.2 — 192.168.10.80 a szerver számára
- 192.168.10.100 a tartománnyal 192.168.10.101 — 192.168.10.149 a 2. számú lakásban lévő routerhez
- 192.168.10.150 a tartománnyal 192.168.10.151 — 192.168.10.199 a 3. számú lakásban lévő routerhez
Ezen címeket az OpenVPN-szerver kliens routerei számára is szükséges volt hozzárendelni, a konfigurációjához a következő sor hozzáadásával:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0és a következő sorok hozzáadásával a /etc/openvpn/ipp.txt fájlhoz:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
ahol a flat1_id és flat2_id az eszközök nevei, amelyeket az OpenVPN csatlakozásához készített tanúsítványok létrehozásakor adunk meg
Ezután a routereken OpenVPN-klienseket állítottak be, a tap0 eszközök mindkettőn be lettek állítva a br-lan hídba. Ezen a ponton úgy tűnt, hogy minden rendben van, mivel mindhárom hálózat látja egymást és egy egységet alkotnak. Aztán kiderült, hogy van egy nem túl kellemes részlet: néha az eszközök nem a saját routerüktől kapták az IP-címet, ami mindennel járó következményeket okozott. Valamilyen oknál fogva az egyik lakásban lévő router nem tudta időben megválaszolni a DHCPDISCOVER-t, és az eszköz nem a saját címét kapta. Rájöttem, hogy ki kell szűrni az ilyen kéréseket a tap0-n minden routeren, de mint kiderült, az iptables nem működik olyan eszközökkel, amelyek híd részei, ezért az ebtables-re volt szükségem. Sajnos a firmware-emben nem volt benne, így minden eszközhöz újra kellett összeraknom a képeket. Miután ezt megtettem, és hozzáadtam a következő sorokat az /etc/rc.local fájlhoz minden routeren, a probléma megoldódott:
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
Ez a konfiguráció három évig működött.
2. rész: Ismerkedés a WireGuard-dal
Ut最近, a WireGuardról egyre több beszéd folyik az interneten, dicsérve a konfigurálás egyszerűségét, a magas átviteli sebességet, valamint az alacsony pinget összehasonlítható biztonság mellett. További információ keresése közben kiderült, hogy sem hídtagként, sem TCP protokollal nem támogatott, ami arra engedett következtetni, hogy az OpenVPN alternatívái számomra még mindig nem állnak rendelkezésre. Így halogattam a WireGuard megismerését.
Néhány nappal ezelőtt az IT-hez kapcsolódó forrásokban felröppent a hír, miszerint a WireGuard végre bekerül a Linux kernelébe, az 5.6-os verziótól kezdve. A hírek, mint mindig, dicsérték a WireGuard-ot. Újra elkezdtem keresni a régi jó OpenVPN helyettesítőit. Ezúttal rábukkantam . Egy Ethernet-alagút létrehozásáról volt szó L3 felett GRE használatával. Ez a cikk reményt adott nekem. Nem volt világos, hogy mit kezdjek az UDP protokollal. A keresés olyan cikkekhez vezetett, amelyek a socat SSH-alag úttal történő használatáról szóltak az UDP-port átirányítására, de megjegyezték, hogy ez a megközelítés csak egy kapcsolat módjában működik, tehát több VPN-kliens használata lehetetlenné válna. Az ötlet, hogy VPN-t állítsak be egy VPS-en, és GRE-t konfiguráljak a klienseknek, jött, de kiderült, hogy a GRE nem támogatja a titkosítást, ami azt jelenti, hogy ha harmadik felek hozzájutnak a szerverhez, a forgalom közöttem és a hálózataim között mind a kezükben lesz, ami alapvetően nem volt megfelelő számomra.
Újra a felesleges titkosítás mellett döntöttem, VPN fölötti VPN használatával a következő séma szerint:
Első szintű VPN:
VPS egy szerverrel 192.168.30.1 belső címmel
MS egy ügyfél VPS 192.168.30.2 belső címmel
MK2 egy ügyfél VPS 192.168.30.3 belső címmel
MK3 egy ügyfél VPS 192.168.30.4 belső címmel
Második szintű VPN:
MS egy szerverrel 192.168.30.2 külső címmel és 192.168.31.1 belsővel
MK2 egy ügyfél MS 192.168.30.2 címmel, belső IP-val 192.168.31.2-vel
MK3 egy ügyfél MS 192.168.30.2 címmel, belső IP-val 192.168.31.3-mal
* MS — router-szerver az 1. lakásban, MK2 — router a 2. lakásban, MK3 — router a 3. lakásban
* Az eszközök konfigurációi a cikk végén található spoilerben kerültek publikálásra.
Tehát, az 192.168.31.0/24 hálózati csomópontok közötti pingek elérik egymást, ideje áttérni a GRE-alagút beállítására. Előtte, hogy ne veszítsem el a hozzáférést a routerekhez, be kell állítani az SSH-alagutakat a 22-es port átirányítására a VPS-en, így például a 10022-es porton a VPS elérheti a 2. lakás routerét, míg a 11122-es porton a 3. lakás routerét. A portátirányítás beállítását legjobban az sshtunnel végzi, mivel helyreállítja az alagutat, ha az megszakad.
Az alagút beállítva, csatlakozhatunk SSH-hoz az átirányított porton keresztül:
ssh root@A_SAJÁT_VPS -p 10022Ezután az OpenVPN-t ki kell kapcsolni:
/etc/init.d/openvpn stopMost állítsuk be a GRE-alagutat a 2. lakás routerén:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
És hozzáadjuk a létrehozott interfészt a hídhoz:
brctl addif br-lan grelan0
Ugyanezt a folyamatot elvégezzük a szerver routeren:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
És szintén hozzáadjuk a létrehozott interfészt a hídhoz:
brctl addif br-lan grelan0
Ettől a pillanattól a pingek sikeresen működnek az új hálózaton, és elégedetten megyek kávézni. Ezután, hogy felmérjem, hogyan működik a hálózat a másik oldalon, megpróbálok SSH-n keresztül csatlakozni az egyik számítógéphez a 2-es apartmanban, de az ssh kliens "megreked", nem kínálva fel a jelszó megadását. Megpróbálok csatlakozni ehhez a számítógéphez telnet-en keresztül a 22-es porton, és látom a sort, amelyből kiderül, hogy a kapcsolat létrejön, az SSH szerver válaszol, csak valamilyen okból nem kínálja fel a bejelentkezést.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Megpróbálok csatlakozni ehhez VNC-n, és fekete képernyőt látok. Megnyugtatom magam, hogy a hiba a távoli számítógépnél van, hiszen a routerhez ebből a lakásból be tudok jelentkezni a helyi IP-n. Ekkor azonban úgy döntök, hogy SSH-n keresztül csatlakozom ehhez a számítógéphez a routeren, és meglepetésre felfedezem, hogy a kapcsolat sikerül, a távoli számítógép pedig teljesen normálisan működik, de nem tud csatlakozni a számítógépemhez.
Kivonom a grelan0 eszközt a hídból, és elindítom az OpenVPN-t a 2-es apartman routerén, és meggyőződöm arról, hogy a hálózat újra normálisan működik, és a kapcsolatok nem szakadnak meg. Fórumokba botlom, ahol az emberek hasonló problémákról panaszkodnak, ahol azt javasolják nekik, hogy állítsák be az MTU-t. Megoldva, ahogy mondták. Azonban, amíg az MTU nem volt elég nagy — 7000 gretap eszközök számára — TCP kapcsolat megszakításokkal vagy alacsony adatátviteli sebességgel találkoztam. A magas MTU miatt a gretap — az első és második szintű WireGuard kapcsolatok MTU-ját 8000 és 7500-ra állítottam be.
Hasonló beállítást végeztem a 3-as apartman routerén is, azzal a különbséggel, hogy a szerver routeren egy második gretap interfész is hozzáadásra került grelan1 néven, amely szintén hozzá lett adva a br-lan hídhoz.
Minden működik. Most a gretap beállításokat a rendszer indítópultjába helyezhetjük. Ehhez:
Ezeket a sorokat az /etc/rc.local fájlba helyeztem a 2-es apartman routerén:
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
Ezt a /etc/rc.local fájlba adtam a lakásomban lévő routeren:
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
És a router-szerveren:
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
A kliens routerek újraindítása után észrevettem, hogy valamiért nem csatlakoznak a szerverhez. Amikor SSH-n keresztül csatlakoztam hozzájuk (szerencsére előre beállítottam az sshtunnel-t ehhez), kiderült, hogy a WireGuard valamiért létrehoz egy útvonalat az endpoint számára, amely hibás. Így a 192.168.30.2 esetében az útvonal a pppoe-wan interfészen keresztül szerepelt a routing táblában, azaz az interneten keresztül, holott az útvonalnak a wg0 interfészen keresztül kellett volna haladnia. Miután töröltem ezt az útvonalat, a kapcsolat helyreállt. Nem találtam sehol utasítást arra, hogyan lehet megakadályozni, hogy a WireGuard létrehozza ezeket az útvonalakat. Sőt, még azt sem értettem, hogy ez az OpenWRT vagy a WireGuard sajátossága-e. Hogy ne vesztegessem az időmet a probléma megoldásával, egyszerűen hozzáadtam mindkét routerhez egy olyan sort a timerekkel ciklikusan futó scriptben, amely törli ezt az útvonalat:
route del 192.168.30.2
Összefoglalva
A OpenVPN teljes elhagyására eddig nem jutottam el, mivel néha csatlakoznom kell egy új hálózatra a laptopomról vagy a telefonomról, és a gretap eszköz beállítása ezekre általában lehetetlen, de ennek ellenére előnyt szereztem az adatok átvitelének sebességében a lakások között, és például a VNC használata már nem okoz kényelmetlenséget. A ping enyhén csökkent, de stabilabbá vált:
OpenVPN használatakor:
[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bájt adat.
64 bájt 192.168.10.110-tól: icmp_seq=1 ttl=64 idő=133 ms
...
64 bájt 192.168.10.110-tól: icmp_seq=20 ttl=64 idő=125 ms
--- 192.168.10.110 ping statisztika ---
20 csomag küldve, 20 megérkezett, 0% csomagveszteség, idő 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms
WireGuard használatakor:
[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bájt adat.
64 bájt 192.168.10.110-tól: icmp_seq=1 ttl=64 idő=124 ms
...
64 bájt 192.168.10.110-tól: icmp_seq=20 ttl=64 idő=124 ms
--- 192.168.10.110 ping statisztika ---
20 csomag küldve, 20 megérkezett, 0% csomagveszteség, idő 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms
Erre jobban hat a VPS-hez vezető magas ping, amely körülbelül 61,5 ms.
A sebesség azonban jelentősen megnőtt. Így a router-szerveremmel rendelkező lakásomban 30 Mbit/s internetkapcsolatot érek el, míg a többi lakásban 5 Mbit/s van. Ezen kívül az OpenVPN használata során nem tudtam elérni a hálózatok közötti adatátviteli sebességet 3,8 Mbit/s-nál nagyobbra az iperf alapján, míg a WireGuard ezt a sebességet 5 Mbit/s-ra növelte.
WireGuard konfiguráció VPS-en[Interface]
Cím = 192.168.30.1/24
ListenPort = 51820
PrivateKey =
[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 konfiguráció MA (hozzáadva: /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 konfiguráció MK2 (hozzáadva: /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 konfiguráció MK3 (hozzáadva: /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'
A második szintű VPN-k konfigurációiban a WireGuard ügyfeleknek 51821-es portot adok meg. Elvileg erre nincs szükség, mivel az ügyfél bármelyik szabad, nem privilegizált portra csatlakozva létrehozhatja a kapcsolatot, de így be tudom tiltani a belépő kapcsolatokat a wg0 interfészen lévő routereken, kivéve a 51821-es UDP bejövő kapcsolatokat.
Remélem, hogy a cikk hasznos lesz valakinek.
P.S. Ezen kívül szeretném megosztani a skriptemet, amely PUSH-értesítést küld a telefonos WirePusher alkalmazásomba, amikor egy új eszköz jelenik meg a hálózatomban. Íme a skript linkje: .
FRISSÍTÉS: OpenVPN szerver és kliens konfiguráció
OpenVPN szerver
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-lzoOpenVPN kliens
client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Cseréld ki a routered külső IP-jére
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 A tanúsítványok generálásához easy-rsát használtam.
Forrás: habr.com
