Szeretném megosztani tapasztalataimat három földrajzilag távoli lakásban, amelyek mindegyike OpenWRT routereket használnak átjáróként, egy közös hálózatba. Az alhálózati útválasztással rendelkező L3 és az L2 közötti hálózatok kombinálásának módszerének kiválasztásakor, amikor minden hálózati csomópont ugyanabban az alhálózatban lesz, a második módszert részesítettük előnyben, amely nehezebben konfigurálható, de nagyobb lehetőségeket biztosít, mivel a A létrejövő Wake-on-Lan és DLNA hálózatban a technológiák átlátható felhasználását tervezték.
1. rész: Háttér
Eredetileg az OpenVPN-t választották ennek a feladatnak a megvalósításához protokollnak, mivel egyrészt egy olyan tapadó eszközt tud létrehozni, amely probléma nélkül adható a hídhoz, másrészt az OpenVPN támogatja a TCP protokollon keresztüli működést, ami szintén fontos volt, mert egyik sem a lakások közül dedikált IP-cím volt, és nem tudtam használni a STUN-t, mivel a szolgáltatóm valamiért blokkolja a bejövő UDP kapcsolatokat a hálózataikról, míg a TCP protokoll lehetővé tette, hogy a VPN szerver portját SSH segítségével továbbítsam a bérelt VPS-hez. Igen, ez a megközelítés nagy terhelést ad, mivel az adatok kétszer titkosítva vannak, de nem akartam VPS-t bevezetni a privát hálózatomba, mivel továbbra is fennáll a veszélye, hogy harmadik felek átvehetik az irányítást, ezért ilyen eszközzel rendelkezik. az otthoni hálózatomon rendkívül nemkívánatos volt, és úgy döntöttem, hogy a biztonságért nagy rezsivel fizetek.
Az sshtunnel programot használták annak az útválasztónak a portjának továbbításához, amelyen a kiszolgálót telepíteni tervezték. Nem írom le a konfiguráció bonyolultságát - ez meglehetősen egyszerűen megtörténik, csak megjegyzem, hogy a feladata az 1194-es TCP-port továbbítása volt az útválasztóról a VPS-re. Ezután az OpenVPN szervert konfigurálták a tap0 eszközön, amely a br-lan hídhoz volt csatlakoztatva. A laptopról ellenőrizve az újonnan létrehozott szerverrel való kapcsolatot, világossá vált, hogy a port továbbítás ötlete indokolt, és a laptopom a router hálózatának tagja lett, bár fizikailag nem volt benne.
Már csak egy apróság maradt hátra: el kellett osztani az IP-címeket a különböző lakásokban, hogy ne ütközzenek, és a routereket OpenVPN-kliensként kell beállítani.
A következő útválasztó IP-címek és DHCP-kiszolgáló tartományok lettek kiválasztva:
- 192.168.10.1 hatótávolsággal 192.168.10.2 - 192.168.10.80 a szerver számára
- 192.168.10.100 hatótávolsággal 192.168.10.101 - 192.168.10.149 2. számú lakás routeréhez
- 192.168.10.150 hatótávolsággal 192.168.10.151 - 192.168.10.199 3. számú lakás routeréhez
Pontosan ezeket a címeket kellett hozzárendelni az OpenVPN szerver kliens útválasztóihoz is úgy, hogy hozzá kell adni a sort a konfigurációjához:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0és adja hozzá a következő sorokat az /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 OpenVPN-hez való csatlakozáshoz szükséges tanúsítványok létrehozásakor megadott eszköznevek
Ezután az OpenVPN klienseket konfigurálták az útválasztókon, és mindkettőn a tap0 eszközöket hozzáadták a br-lan hídhoz. Ebben a szakaszban úgy tűnt, hogy minden rendben van, mivel mindhárom hálózat látta egymást, és egyként működött. Kiderült azonban egy nem túl kellemes részlet: előfordulhat, hogy a készülékek nem a routerüktől kaptak IP-címet, ennek minden következményével együtt. Valamilyen oknál fogva az egyik lakás routerének nem volt ideje időben válaszolni a DHCPDISCOVER-re, és az eszköz olyan címet kapott, amelyet nem szántak. Rájöttem, hogy minden routeren a tap0-ban kell szűrni az ilyen kéréseket, de mint kiderült, az iptables nem tud működni az eszközzel, ha az egy híd része, és az ebtablesnak a segítségemre kell lennie. Sajnálatomra nem volt benne a firmware-emben, és minden egyes eszközhöz újra kellett építenem a képeket. Ha ezt megtette, és ezeket a sorokat hozzáadta minden útválasztó /etc/rc.local fájljához, 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 tartott.
2. rész: A WireGuard bemutatása
A közelmúltban az emberek az interneten egyre gyakrabban kezdtek beszélni a WireGuard-ról, csodálva a konfiguráció egyszerűségét, a nagy átviteli sebességet, az alacsony ping és hasonló biztonságot. Az ezzel kapcsolatos további információk keresése során világossá vált, hogy sem a hídtagként, sem a TCP protokollon keresztüli munkavégzést nem támogatja, ezért arra gondoltam, hogy számomra továbbra sincs alternatívája az OpenVPN-nek. Így hát halogattam a WireGuard megismerését.
Néhány napja az informatikához kapcsolódó források között terjedt a hír, hogy a WireGuard végre bekerül a Linux kernelbe, az 5.6-os verziótól kezdve. A hírcikkek, mint mindig, a WireGuardot dicsérték. Ismét belevetettem magam a régi jó OpenVPN lecserélésének módjainak keresésébe. Ezúttal belefutottam . Egy Ethernet alagút létrehozásáról volt szó L3-on a GRE használatával. Ez a cikk reményt adott. Továbbra sem világos, hogy mi legyen az UDP protokollal. A keresés olyan cikkekhez vezetett, amelyek a socat SSH-alagúttal együtt történő használatáról szóltak UDP-port továbbítására, azonban megjegyezték, hogy ez a megközelítés csak egyetlen csatlakozási módban működik, vagyis több VPN-kliens munkája lehetetlen lenne. Eszembe jutott, hogy telepítek egy VPN-kiszolgálót egy VPS-re, és beállítom a GRE-t az ügyfelek számára, de mint kiderült, a GRE nem támogatja a titkosítást, ami ahhoz vezet, hogy ha harmadik felek hozzáférnek a szerverhez. , minden forgalom a hálózataim között az ő kezükben lesz, ami nekem egyáltalán nem jött be.
Ismét a redundáns titkosítás mellett döntöttünk a VPN over VPN használatával a következő séma szerint:
XNUMX. szintű VPN:
VPS a szerver 192.168.30.1 belső címmel
MS a ügyfél VPS 192.168.30.2 belső címmel
MK2 a ügyfél VPS 192.168.30.3 belső címmel
MK3 a ügyfél VPS 192.168.30.4 belső címmel
Második szintű VPN:
MS a szerver külső címmel 192.168.30.2 és belső 192.168.31.1
MK2 a ügyfél MS 192.168.30.2 címmel és 192.168.31.2 belső IP-vel
MK3 a ügyfél MS 192.168.30.2 címmel és 192.168.31.3 belső IP-vel
* MS - router-szerver az 1-es lakásban, MK2 - router a 2-es lakásban, MK3 - router a 3-as lakásban
* Az eszközkonfigurációkat a cikk végén található spoilerben tesszük közzé.
Így a pingek futnak a 192.168.31.0/24 hálózati csomópontok között, ideje továbblépni a GRE alagút létrehozására. Ezt megelőzően, hogy ne veszítsék el a routerek elérését, érdemes SSH-alagutakat felállítani, amelyek a 22-es portot továbbítják a VPS-nek, így például a 10022-es lakás routere elérhető lesz a VPS 2-es portján, és a a 11122. lakás útválasztója az 3-es porton érhető el a XNUMX. lakás útválasztója. A legjobb, ha a továbbítást ugyanazzal az sshtunnel-lal konfigurálja, mivel ez visszaállítja az alagutat, ha meghiúsul.
Az alagút be van állítva, a továbbított porton keresztül csatlakozhat az SSH-hoz:
ssh root@МОЙ_VPS -p 10022Ezután le kell tiltania az OpenVPN-t:
/etc/init.d/openvpn stopMost állítsunk fel egy GRE alagutat a 2. lakás útválasztóján:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
És add hozzá a létrehozott felületet a hídhoz:
brctl addif br-lan grelan0
Végezzünk el egy hasonló eljárást a kiszolgáló útválasztóján:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
És add hozzá a létrehozott felületet a hídhoz:
brctl addif br-lan grelan0
ettől a pillanattól kezdve a pingek sikeresen átmennek az új hálózatra, én pedig elégedetten megyek kávézni. Ezután, hogy kiértékeljem, hogyan működik a hálózat a vonal másik végén, megpróbálok SSH-t küldeni a 2. lakás egyik számítógépére, de az ssh-kliens lefagy anélkül, hogy jelszót kérne. Próbálok csatlakozni ehhez a számítógéphez telneten keresztül a 22-es porton, és látok egy sort, amelyből megértem, hogy a kapcsolat létrejön, az SSH-szerver válaszol, de valamiért nem kéri a bejelentkezésre ban ben.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Megpróbálok VNC-n keresztül csatlakozni hozzá, és fekete képernyőt látok. Meggyőzöm magam, hogy a probléma a távoli számítógéppel van, mert ebből a lakásból könnyen tudok csatlakozni a routerhez a belső cím segítségével. Azonban úgy döntök, hogy az útválasztón keresztül csatlakozom a számítógép SSH-jához, és meglepődve tapasztalom, hogy a kapcsolat sikeres volt, és a távoli számítógép teljesen normálisan működik, de nem tud csatlakozni a számítógépemhez.
Eltávolítom a grelan0 eszközt a hídról, és elindítom az OpenVPN-t a 2. lakás útválasztóján, és meggyőződöm arról, hogy a hálózat ismét a várt módon működik, és a kapcsolatok nem szakadnak meg. Keresgélve olyan fórumokra bukkanok, ahol az emberek ugyanazokról a problémákról panaszkodnak, ahol azt tanácsolják, hogy emeljék meg az MTU-t. Alig van szó, mint kész. Amíg azonban az MTU-t nem állítottuk be elég magasra – 7000-re a gretap-eszközök esetében, addig vagy megszakadtak a TCP-kapcsolatok, vagy alacsony az átviteli sebesség. A gretap magas MTU-ja miatt az 8000. és 7500. rétegű WireGuard kapcsolatok MTU-ja XNUMX-re, illetve XNUMX-ra lett beállítva.
Hasonló beállítást végeztem a 3-as lakás routeren is, azzal a különbséggel, hogy a szerver routerhez egy második grelan1 nevű gretap interfész került, ami szintén a br-lan hídhoz került.
Minden működik. Most már elindíthatja a gretap szerelvényt. Ezért:
Ezeket a sorokat az /etc/rc.local könyvtárba helyeztem a 2. lakás útválasztójá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 hozzáadta a /etc/rc.local fájlhoz a 3. lakás útválasztóján:
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 szerver routeren:
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 útválasztók újraindítása után felfedeztem, hogy valamiért nem csatlakoznak a szerverhez. Miután csatlakoztak az SSH-jukhoz (szerencsére korábban az sshtunnelt konfiguráltam ehhez), kiderült, hogy a WireGuard valamilyen okból útvonalat hoz létre a végponthoz, de ez hibás volt. Tehát a 192.168.30.2 esetében az útvonaltábla a pppoe-wan interfészen, azaz az interneten keresztül jelzett útvonalat, bár a hozzá vezető útvonalat a wg0 interfészen keresztül kellett volna irányítani. Az útvonal törlése után a kapcsolat helyreállt. Sehol nem találtam utasítást arra vonatkozóan, hogyan kényszeríthetném ki a WireGuard-ot, hogy ne hozza létre ezeket az útvonalakat. Sőt, azt sem értettem, hogy ez az OpenWRT vagy magának a WireGuardnak a jellemzője. Anélkül, hogy sokáig foglalkoznom kellett volna ezzel a problémával, egyszerűen hozzáadtam egy sort mindkét útválasztóhoz egy időzített szkriptben, amely törölte ezt az útvonalat:
route del 192.168.30.2
Összegezve
Még nem sikerült teljesen elhagynom az OpenVPN-t, mivel időnként új hálózathoz kell csatlakoznom laptopról vagy telefonról, és a gretap eszköz beállítása általában lehetetlen, de ennek ellenére előnyt kaptam a sebességben. a lakások közötti adatátvitel és például a VNC használata már nem kényelmetlen. A ping kissé 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) 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
A WireGuard használatakor:
[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
Jobban befolyásolja a VPS magas pingje, amely körülbelül 61.5 ms
A sebesség azonban jelentősen megnőtt. Tehát egy szerverrouterrel felszerelt lakásban 30 Mbit/sec, a többi lakásban 5 Mbit/sec az internetkapcsolat sebessége. Ugyanakkor az OpenVPN használata során az iperf leolvasások alapján nem tudtam elérni 3,8 Mbit/sec-nél nagyobb adatátviteli sebességet a hálózatok között, míg a WireGuard ugyanerre az 5 Mbit/sec-re „bosszírozta”.
WireGuard konfiguráció VPS-en[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 konfiguráció MS-en (hozzáadva az /etc/config/network fájlhoz)
#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ó az MK2-n (hozzáadva az /etc/config/network fájlhoz)
#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ó az MK3-n (hozzáadva az /etc/config/network fájlhoz)
#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 leírt konfigurációkban a második szintű VPN-hez a WireGuard klienseket az 51821-es portra irányítom. Elméletileg erre nincs szükség, mivel a kliens bármely szabad, privilegizált portról létesít kapcsolatot, de én úgy csináltam, hogy tiltható legyen. az összes útválasztó wg0 interfészén lévő összes bejövő kapcsolat, kivéve az 51821-es port bejövő UDP-kapcsolatait.
Remélem, hogy a cikk hasznos lesz valakinek.
PS Ezenkívül szeretném megosztani a szkriptemet, amely PUSH értesítést küld a telefonomra a WirePusher alkalmazásban, amikor új eszköz jelenik meg a hálózatomon. Itt a link a scripthez: .
UPDATE: Az OpenVPN szerver és az ügyfelek konfigurálása
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 # 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
A tanúsítványok generálásához easy-rsa-t használtam
Forrás: will.com