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
A feladat végrehajtásához kezdetben a választott protokoll OpenVPN, mert egyrészt létrehozhat egy olyan csapolóeszközt, amely gond nélkül hozzáadható a hídhoz, másrészt pedig, OpenVPN Támogatja a TCP-t, ami szintén fontos volt, mivel egyik lakásnak sem volt dedikált IP-címe. Nem tudtam használni a STUN-t, mert az internetszolgáltatóm valamilyen oknál fogva blokkolja a bejövő UDP-kapcsolatokat a hálózataiból. A TCP lehetővé tette számomra, hogy SSH-n keresztül továbbítsam a VPN-kiszolgáló portját a bérelt VPS-re. Bár ez a megközelítés jelentős többletterhelést okoz, mivel az adatok duplán titkosítottak, nem akartam integrálni a VPS-t a privát hálózatomba, mivel fennállt a veszélye annak, hogy harmadik felek átveszik az irányítást felette. Ezért egy ilyen eszköz jelenléte az otthoni hálózatomon rendkívül nemkívánatos volt, ezért úgy döntöttem, hogy jelentős többletköltséget fizetek a biztonságért.
A routeren lévő port továbbításához, ahová a szervert telepíteni terveztem, az sshtunnel programot használtam. Nem fogok belemenni a konfiguráció részleteibe – elég egyszerű. Csak annyit jegyzek meg, hogy a célja a 1194-es TCP port továbbítása volt a routerről a VPS-re. Ezután konfiguráltam a szervert. OpenVPN A tap0 eszközön, ami a br-lan hídhoz csatlakozott. Miután teszteltem a laptopomról az újonnan létrehozott szerverhez való csatlakozást, világossá vált, hogy a porttovábbítás ötlete bevált, és a laptopom a router hálózatának tagja lett, annak ellenére, hogy fizikailag nem volt része annak.
Már csak az maradt hátra, hogy elosszák az IP-címeket a különböző lakásokban, hogy ne ütközzenek, és a routereket a következőképpen konfigurálják: OpenVPN-ügyfelek.
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
Ezeket a címeket a kliens routerekhez is hozzá kellett rendelni. OpenVPN-server, a következő sor hozzáadásával 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 a flat2_id az eszköznevek, amelyeket a csatlakozáshoz szükséges tanúsítványok létrehozásakor adnak meg. OpenVPN
Ezután a routereket konfigurálták OpenVPN- kliensek, mindkét hálózaton tap0 eszközöket adtak a br-lan hídhoz. Ezen a ponton minden rendben lévőnek tűnt, mivel mindhárom hálózat látta egymást és egyetlen egységként működött. Azonban egy meglehetősen kellemetlen részlet merült fel: néha az eszközök rossz routertől kaptak IP-címet, ennek minden következményével együtt. Valamiért az egyik lakásban lévő router nem válaszolt időben a DHCPDISCOVER parancsra, és az eszköz rossz címet kapott. Rájöttem, hogy minden routeren szűrnöm kell az ilyen kéréseket a tap0-ban, de kiderült, hogy az iptables nem tud működni egy eszközzel, ha az egy híd része, ezért az ebtables-t kellett használnom. Sajnos a firmware-em nem tartalmazta, így újra kellett építenem az egyes eszközök képfájljait. Miután ezt megtettem, és a következő sorokat hozzáadtam 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 tartott.
2. rész: Ismerkedés WireGuard
Az utóbbi időben egyre több szó esik az interneten arról, hogy WireGuard, csodálva a könnyű konfigurálhatóságát, a nagy átviteli sebességét, az alacsony pingjét és az összehasonlítható biztonságát. További információk keresése során kiderült, hogy sem a hídtagokat, sem a TCP protokollt nem támogatja, ami arra engedett következtetni, hogy nincs alternatíva. OpenVPN számomra még mindig nincs ott. Szóval halogattam a megismerést WireGuard.
Néhány nappal ezelőtt olyan hírek terjedtek el az informatikához kapcsolódó forrásokon keresztül, hogy WireGuard végre bekerül a kernelbe Linux, az 5.6-os verziótól kezdődően. A híreket, mint mindig, dicsérték WireGuardIsmét belemerültem a jó öreg helyettesítésének módjainak keresésébe OpenVPNEzú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 tiltani OpenVPN:
/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.
Kiveszem a grelan0 eszközt a hídból és futtatom. OpenVPN A 2. lakásban lévő routeren megerősítettem, hogy a hálózat ismét megfelelően működik, és a kapcsolatok nem szakadnak meg. Keresés közben olyan fórumokra bukkantam, ahol az emberek ugyanezekre a problémákra panaszkodtak, és ahol azt tanácsolták nekik, hogy emeljék az MTU-t. Alig mondtam, megtettem. Azonban amíg az MTU-t elég magasra nem állítottam – 7000-re a gretap eszközöknél –, vagy megszakadt TCP-kapcsolatokat, vagy alacsony átviteli sebességet tapasztaltam. A gretap magas MTU-ja miatt a kapcsolatok MTU-ja... WireGuard Az első és a második szintet 8000-re, illetve 7500-ra állították be.
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
Miután újraindítottam a kliens routerek, rájöttem, hogy valamilyen oknál fogva nem csatlakoznak a szerverhez. Miután csatlakoztam az SSH-jukhoz (szerencsére korábban beállítottam az sshtunnelt erre), rájöttem, hogy WireGuard Valamiért létrehoz egy útvonalat a végponthoz, de az helytelen. Például a 192.168.30.2 esetében az útvonaltábla a pppoe-wan interfészen keresztül, azaz az interneten keresztül adott meg útvonalat, holott az oda vezető útvonalnak a wg0 interfészen keresztül kellett volna lennie. Az útvonal törlése után a kapcsolat helyreállt. Találok valahol utasításokat arra vonatkozóan, hogyan lehet kényszeríteni a... WireGuard Nem tudtam elkerülni ezeknek az útvonalaknak a létrehozását. Sőt, azt sem értettem, hogy ez az OpenWRT vagy a WireGuardAnélkül, hogy sok időt töltöttem volna a probléma kiderítésével, egyszerűen hozzáadtam egy sort a timer-loop szkripthez mindkét routeren, amely törölte ezt az útvonalat:
route del 192.168.30.2
Összegezve
Teljes elutasítás OpenVPN Ezt még nem sikerült elérnem, mivel időnként új hálózathoz kell csatlakoznom egy laptopról vagy telefonról, és általában lehetetlen rajtuk gretap eszközt beállítani. Ennek ellenére azonban előnyre tettem szert az apartmanok közötti adatátviteli sebességben, és például a VNC használata most már gondmentes. A ping kissé csökkent, de stabilabbá vált:
Ha a 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
Ha a 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
Jobban befolyásolja a VPS magas pingje, amely körülbelül 61.5 ms
A sebesség azonban jelentősen megnőtt. Így a router-szerverrel rendelkező lakásban 30 Mbps az internetkapcsolatom sebessége, a többi lakásban pedig 5 Mbps. Ráadásul használat közben... OpenVPN Az iperf értékek szerint nem tudtam 3,8 Mbps-nál nagyobb hálózatok közötti adatátviteli sebességet elérni, miközben WireGuard "felpumpálta" ugyanarra az 5 Mbit/sec-re.
Configuration WireGuard VPS-en[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Peer]
Nyilvános kulcs = <VPN_1_MS_NYILVÁNOS_KULCS>
Engedélyezett IP-k = 192.168.30.2/32
[Peer]
Nyilvános kulcs = <VPN_2_MK2_NYILVÁNOS_KULCS>
Engedélyezett IP-k = 192.168.30.3/32
[Peer]
Nyilvános kulcs = <VPN_2_MK3_NYILVÁNOS_KULCS>
Engedélyezett IP-k = 192.168.30.4/32
Configuration WireGuard MS rendszeren (hozzáadva a /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'
Configuration WireGuard MK2-n (hozzáadva a /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'
Configuration WireGuard MK3-n (hozzáadva a /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 második szintű VPN leírt konfigurációiban jelezem az ügyfeleknek WireGuard 51821-es port. Erre nem lenne szabad szükség, mivel a kliens bármelyik szabad, nem privilégiumozott portról kapcsolatot létesít, de én így csináltam, hogy minden bejövő kapcsolatot le tudjak tiltani az összes router wg0 interfészén, kivéve az 51821-es portra bejövő UDP kapcsolatokat.
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: Configuration OpenVPN-szerverek és kliensek
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-ügyfél
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
