Ik wol myn ûnderfining diele fan it kombinearjen fan netwurken yn trije geografysk ôfstân apparteminten, elk fan dat brûkt routers mei OpenWRT as poarte, yn ien mienskiplik netwurk. By it kiezen fan in metoade foar it kombinearjen fan netwurken tusken L3 mei subnetrouting en L2 mei brêgen, as alle netwurkknooppunten yn itselde subnet sille wêze, waard de foarkar jûn oan de twadde metoade, dy't dreger te konfigurearjen is, mar gruttere kânsen biedt, om't de transparant gebrûk fan technologyen waard pland yn it netwurk wurdt makke Wake-on-Lan en DLNA.
Diel 1: Eftergrûn
OpenVPN waard ynearsten keazen as it protokol foar it útfieren fan dizze taak, om't it as earste in tapapparaat kin oanmeitsje dat sûnder problemen oan 'e brêge kin wurde tafoege, en twad stipet OpenVPN operaasje oer it TCP-protokol, wat ek wichtich wie, om't gjinien fan de apparteminten hie in tawijd IP-adres, en ik wie net by steat om te brûken STUN, sûnt myn provider foar guon reden blokkearret ynkommende UDP ferbinings út harren netwurken, wylst it TCP protokol tastien my in trochstjoere de VPN tsjinner haven oan hierd VPS mei help SSH. Ja, dizze oanpak jout in grutte lading, om't de gegevens twa kear fersifere binne, mar ik woe gjin VPS yn myn privee netwurk ynfiere, om't d'r noch in risiko wie dat tredden dêr kontrôle oer krije, dêrom hawwe sa'n apparaat op myn thús netwurk wie ekstreem net winske en it waard besletten beteljen foar feiligens mei in grutte overhead.
Om de poarte op 'e router troch te stjoeren wêrop it plan wie om de tsjinner yn te setten, waard it programma sshtunnel brûkt. Ik sil de intricacies fan syn konfiguraasje net beskriuwe - it is frij maklik dien, ik sil gewoan opmerke dat syn taak wie om TCP-poarte 1194 troch te stjoeren fan 'e router nei de VPS. Dêrnei waard de OpenVPN-tsjinner konfigureare op it tap0-apparaat, dat ferbûn wie mei de br-lan-brêge. Nei it kontrolearjen fan de ferbining mei de nij oanmakke tsjinner fan 'e laptop, waard it dúdlik dat it idee fan poarte trochstjoere rjochtfeardige wie en myn laptop waard lid fan it routernetwurk, hoewol it der net fysyk yn siet.
D'r wie mar ien lyts ding te dwaan: it wie nedich om IP-adressen yn ferskate apparteminten te fersprieden, sadat se net konflikten en de routers as OpenVPN-kliïnten konfigurearje.
De folgjende IP-adressen fan 'e router en DHCP-tsjinnerberik binne selektearre:
- 192.168.10.1 mei berik 192.168.10.2 - 192.168.10.80 foar de tsjinner
- 192.168.10.100 mei berik 192.168.10.101 - 192.168.10.149 foar de router yn appartemint nr. 2
- 192.168.10.150 mei berik 192.168.10.151 - 192.168.10.199 foar de router yn appartemint nr. 3
It wie ek nedich om dizze adressen krekt te jaan oan 'e client-routers fan' e OpenVPN-tsjinner troch de line ta te foegjen oan syn konfiguraasje:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0en de folgjende rigels tafoegje oan it /etc/openvpn/ipp.txt-bestân:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
wêr't flat1_id en flat2_id de apparaatnammen binne oantsjutte by it meitsjen fan sertifikaten foar ferbining mei OpenVPN
Dêrnei waarden OpenVPN-kliïnten konfigureare op 'e routers, tap0-apparaten op beide waarden tafoege oan' e br-lan-brêge. Op dit stadium like alles goed te wêzen, om't alle trije netwurken inoar koene sjen en as ien wurkje. Der kaam lykwols in net heul noflik detail nei foaren: soms koene apparaten in IP-adres krije dat net fan har router wie, mei alle gefolgen dy't derop komme. Om ien of oare reden hie de router yn ien fan 'e apparteminten gjin tiid om op tiid te reagearjen op DHCPDISCOVER en it apparaat krige in adres dat net bedoeld wie. Ik realisearre dat ik moat filterje sokke fersiken yn tap0 op elk fan 'e routers, mar sa die bliken, iptables kinne net wurkje mei it apparaat as it is in part fan in brêge en ebtables moatte komme ta myn help. Ta myn spyt wie it net yn myn firmware en ik moast de ôfbyldings foar elk apparaat opnij opbouwe. Troch dit te dwaan en dizze rigels ta te foegjen oan /etc/rc.local fan elke router, waard it probleem oplost:
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
Dizze konfiguraasje duorre foar trije jier.
Diel 2: Yntroduksje fan WireGuard
Koartlyn binne minsken op it ynternet hieltyd mear begon te praten oer WireGuard, en bewûnderje de ienfâld fan syn konfiguraasje, hege transmissiesnelheid, lege ping mei fergelykbere feiligens. It sykjen nei mear ynformaasje dêroer makke dúdlik dat noch wurkjen as brêgelid noch wurkjen oer it TCP-protokol der troch stipe waard, wat my tinkt dat d'r noch gjin alternativen foar OpenVPN foar my wiene. Dat ik sette it út om WireGuard te kennen.
In pear dagen lyn ferspraat nijs oer boarnen op ien of oare manier relatearre oan IT dat WireGuard einlings soe wurde opnommen yn 'e Linux kernel, begjinnend mei ferzje 5.6. Nijsartikels, lykas altyd, priizgen WireGuard. Ik dûkte wer yn it sykjen nei manieren om de goede âlde OpenVPN te ferfangen. Dizze kear rûn ik tsjin . It praat oer it meitsjen fan in Ethernet-tunnel oer L3 mei GRE. Dit artikel joech my hope. It bleau ûndúdlik wat te dwaan mei it UDP-protokol. It sykjen late my nei artikels oer it brûken fan socat yn kombinaasje mei in SSH-tunnel om in UDP-poarte troch te stjoeren, lykwols, se merkten op dat dizze oanpak allinich wurket yn ienige ferbiningsmodus, dat is, it wurk fan ferskate VPN-kliïnten soe ûnmooglik wêze. Ik kaam op it idee om in VPN-tsjinner op in VPS te ynstallearjen en GRE foar kliïnten yn te stellen, mar sa die bliken, stipet GRE gjin fersifering, wat sil liede ta it feit dat as tredden tagong krije ta de tsjinner , alle ferkear tusken myn netwurken sil yn har hannen wêze, wat my hielendal net paste.
Nochris waard it beslút makke yn it foardiel fan oerstallige fersifering, troch VPN oer VPN te brûken mei it folgjende skema:
Level 1 VPN:
VPS it is tsjinner mei ynterne adres 192.168.30.1
MS it is kliïnt VPS mei ynterne adres 192.168.30.2
MK2 it is kliïnt VPS mei ynterne adres 192.168.30.3
MK3 it is kliïnt VPS mei ynterne adres 192.168.30.4
Twadde nivo VPN:
MS it is tsjinner mei ekstern adres 192.168.30.2 en ynterne 192.168.31.1
MK2 it is kliïnt MS mei it adres 192.168.30.2 en hat in ynterne IP 192.168.31.2
MK3 it is kliïnt MS mei it adres 192.168.30.2 en hat in ynterne IP 192.168.31.3
* MS - router-tsjinner yn appartemint 1, MK2 - router yn appartemint 2, MK3 - router yn appartemint 3
* Apparaatkonfiguraasjes wurde publisearre yn 'e spoiler oan' e ein fan it artikel.
En sa rinne pings tusken netwurkknooppunten 192.168.31.0/24, it is tiid om troch te gean nei it ynstellen fan in GRE-tunnel. Foardat dit, om de tagong ta routers net te ferliezen, is it de muoite wurdich om SSH-tunnels yn te stellen om poarte 22 troch te stjoeren nei de VPS, sadat bygelyks de router fan appartemint 10022 tagonklik is op haven 2 fan 'e VPS, en de router út appartemint 11122 sil wêze tagonklik op haven 3 router út appartemint XNUMX. It is it bêste om te konfigurearjen trochstjoere mei help fan deselde sshtunnel, sûnt it sil weromsette de tunnel as it mislearret.
De tunnel is konfigureare, jo kinne ferbine mei SSH fia de trochstjoerde poarte:
ssh root@МОЙ_VPS -p 10022Folgjende moatte jo OpenVPN útskeakelje:
/etc/init.d/openvpn stopLitte wy no in GRE-tunnel ynstelle op 'e router fan appartemint 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
En foegje de oanmakke ynterface ta oan 'e brêge:
brctl addif br-lan grelan0
Litte wy in ferlykbere proseduere útfiere op 'e serverrouter:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
En foegje ek de oanmakke ynterface ta oan 'e brêge:
brctl addif br-lan grelan0
fanôf dit momint begjinne pings mei súkses nei it nije netwurk te gean en ik, mei tefredenheid, gean nei kofje drinke. Dan, om te evaluearjen hoe't it netwurk wurket oan 'e oare ein fan' e line, besykje ik SSH yn ien fan 'e kompjûters yn appartemint 2, mar de ssh-kliïnt befriest sûnder in wachtwurd te freegjen. Ik besykje te ferbinen mei dizze kompjûter fia telnet op poarte 22 en ik sjoch in line wêrfan ik kin begripe dat de ferbining wurdt oprjochte, de SSH-tsjinner reagearret, mar om ien of oare reden freget it my gewoan net om oan te melden yn.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Ik besykje te ferbinen mei it fia VNC en sjoch in swarte skerm. Ik oertsjûgje mysels dat it probleem is mei de kompjûter op ôfstân, want ik kin maklik ferbine mei de router fan dit appartemint mei it ynterne adres. Ik beslút lykwols om te ferbinen mei de SSH fan dizze kompjûter fia de router en bin ferrast om te finen dat de ferbining suksesfol is, en de kompjûter op ôfstân wurket frij normaal, mar it kin ek net ferbine mei myn kompjûter.
Ik fuortsmite de grelan0 apparaat út de brêge en rinne OpenVPN op de router yn appartemint 2 en soargje derfoar dat it netwurk wurket as ferwachte wer en de ferbinings wurde net falle. Troch te sykjen kom ik foarums tsjin wêr't minsken kleie oer deselde problemen, wêr't se advisearre wurde om de MTU te ferheegjen. Net earder sein as dien. Lykwols, oant de MTU heech genôch waard ynsteld - 7000 foar gretap-apparaten, waarden TCP-ferbiningen falle of lege oerdrachtsraten waarnommen. Fanwegen de hege MTU foar gretap waarden de MTU's foar Layer 8000 en Layer 7500 WireGuard-ferbiningen ynsteld op respektivelik XNUMX en XNUMX.
Ik útfierd in ferlykbere opset op de router út appartemint 3, mei it ienige ferskil is dat in twadde gretap ynterface neamd grelan1 waard tafoege oan de tsjinner router, dat waard ek tafoege oan de br-lan brêge.
Alles wurket. No kinne jo de gretap-assemblage yn opstarten sette. Foar dit:
Ik pleatste dizze rigels yn /etc/rc.local op 'e router yn appartemint 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
Dit tafoege oan /etc/rc.local op 'e router yn appartemint 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
En op de serverrouter:
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
Nei it herstarten fan de client-routers, ûntduts ik dat se om ien of oare reden gjin ferbining makken mei de tsjinner. Nei't ik ferbûn wie mei har SSH (gelokkich hie ik earder sshtunnel foar dit konfigureare), waard ûntdutsen dat WireGuard om ien of oare reden in rûte foar it einpunt makke, mar it wie ferkeard. Dus, foar 192.168.30.2 hat de rûtetabel in rûte oanjûn troch de pppoe-wan-ynterface, dat wol sizze fia it ynternet, hoewol de rûte dêrta troch de wg0-ynterface soe moatte wurde stjoerd. Nei it wiskjen fan dizze rûte is de ferbining wersteld. Ik koe oeral gjin ynstruksjes fine oer hoe't ik WireGuard kin twinge om dizze rûtes net te meitsjen. Boppedat begriep ik net iens oft dit in funksje fan OpenWRT of WireGuard sels wie. Sûnder dit probleem foar in lange tiid te hawwen, haw ik gewoan in rigel tafoege oan beide routers yn in timed skript dat dizze rûte wiske:
route del 192.168.30.2
Omheech op
Ik haw noch net in folsleine ferlitten fan OpenVPN berikt, om't ik soms moatte ferbine mei in nij netwurk fan in laptop of tillefoan, en it opsetten fan in gretap-apparaat op har is oer it algemien ûnmooglik, mar nettsjinsteande dit krige ik in foardiel yn 'e snelheid fan gegevens oerdracht tusken apparteminten en, bygelyks, mei help fan VNC is net langer ûngemaklik. Ping fermindere wat, mar waard stabiler:
By it brûken fan 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
By it brûken fan 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
It wurdt mear beynfloede troch de hege ping nei de VPS, dy't sawat 61.5 ms is
De snelheid is lykwols flink tanommen. Dus, yn in appartemint mei in serverrouter haw ik in ynternetferbiningsnelheid fan 30 Mbit / sek, en yn oare apparteminten is it 5 Mbit / sek. Tagelyk, by it brûken fan OpenVPN, koe ik gjin gegevensferfiersnelheid berikke tusken netwurken fan mear as 3,8 Mbit / sek neffens iperf-lêzingen, wylst WireGuard it "fersterke" nei deselde 5 Mbit / sek.
WireGuard-konfiguraasje op VPS[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-konfiguraasje op MS (tafoege oan /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-konfiguraasje op MK2 (tafoege oan /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-konfiguraasje op MK3 (tafoege oan /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'
Yn de beskreaune konfiguraasjes foar twadde-nivo VPN, ik wiis WireGuard kliïnten oan haven 51821. Yn teory, dit is net nedich, sûnt de kliïnt sil meitsje in ferbining út eltse frije unprivileged haven, mar ik makke it sa dat it wie mooglik om te ferbieden alle ynkommende ferbiningen op 'e wg0-ynterfaces fan alle routers útsein ynkommende UDP-ferbiningen nei haven 51821.
Ik hoopje dat it artikel nuttich sil wêze foar ien.
PS Ek wol ik myn skript diele dat my in PUSH-notifikaasje nei myn tillefoan stjoert yn 'e WirePusher-applikaasje as in nij apparaat op myn netwurk ferskynt. Hjir is de link nei it skript: .
UPDATE: Konfiguraasje fan OpenVPN-tsjinner en kliïnten
OpenVPN-tsjinner
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 client
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
Ik brûkte easy-rsa om sertifikaten te generearjen
Boarne: www.habr.com