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
It protokol dat keazen waard om dizze taak út te fieren wie yn earste ynstânsje OpenVPN, om't it, earst, in tapapparaat meitsje kin dat sûnder problemen oan 'e brêge tafoege wurde kin, en twadde, OpenVPN It stipet TCP, wat ek wichtich wie, om't gjin fan 'e apparteminten in tawijd IP-adres hie. Ik koe STUN net brûke, om't myn ynternetprovider, om ien of oare reden, ynkommende UDP-ferbiningen fan har netwurken blokkearret. TCP liet my de VPN-tsjinnerpoarte trochstjoere nei de hierde VPS mei SSH. Hoewol dizze oanpak in flinke overhead makket, om't de gegevens dûbeld fersifere binne, woe ik de VPS net yntegrearje yn myn privee netwurk, om't der in risiko wie dat tredden der kontrôle oer krigen. Dêrom wie it tige ûnwinsklik om sa'n apparaat op myn thúsnetwurk te hawwen, dus besleat ik in flinke overhead te beteljen foar feiligens.
Om de poarte op 'e router troch te stjoeren dêr't de tsjinner ynset wurde soe, haw ik it programma sshtunnel brûkt. Ik sil net yngean op 'e details fan 'e konfiguraasje - it is frij maklik. Ik sil allinich opmerke dat it doel wie om TCP-poarte 1194 fan 'e router nei de VPS troch te stjoeren. Dêrnei haw ik de tsjinner konfigurearre. OpenVPN Op it tap0-apparaat, dat ferbûn wie mei de br-lan-brêge. Nei it testen fan 'e ferbining mei de nij oanmakke server fan myn laptop, waard dúdlik dat it idee fan port forwarding wurke hie, en myn laptop wie lid wurden fan it netwurk fan 'e router, ek al wie it der gjin fysyk ûnderdiel fan.
It iennige dat oerbleau wie om IP-adressen yn ferskate apparteminten te fersprieden, sadat se net yn konflikt komme soene en de routers te konfigurearjen as OpenVPN-kliïnten.
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 ta te wizen oan de kliïntrouters. OpenVPN-server, troch de folgjende rigel 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êrby't flat1_id en flat2_id de apparaatnammen binne dy't oantsjutte binne by it oanmeitsjen fan sertifikaten foar it ferbinen mei OpenVPN
Folgjende waarden de routers konfigurearre OpenVPN- kliïnten, tap0-apparaten op beide waarden tafoege oan 'e br-lan-brêge. Op dit punt like alles goed, om't alle trije netwurken inoar sjen koene en as ien ienheid funksjonearje koene. In frij ûnnoflik detail kaam lykwols nei foaren: soms krigen apparaten in IP-adres fan 'e ferkearde router, mei alle gefolgen fan dy. Om ien of oare reden reagearre de router yn ien fan 'e apparteminten net op 'e tiid op DHCPDISCOVER, en krige it apparaat it ferkearde adres. Ik realisearre my dat ik sokke oanfragen yn tap0 op elke router filterje moast, mar it die bliken dat iptables net kinne wurkje mei in apparaat as it diel útmakket fan in brêge, dus ik moast ebtables brûke. Spitigernôch befette myn firmware it net, dus ik moast de ôfbyldings foar elk apparaat opnij bouwe. Nei't ik dit dien hie en de folgjende rigels tafoege hie oan /etc/rc.local op elke router, wie 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: Kennis krije WireGuard
De lêste tiid wurdt der op it ynternet hieltyd mear praat oer WireGuard, en bewûnderje de maklike konfiguraasje, hege oerdrachtsnelheid, lege ping en fergelykbere feiligens. In syktocht nei ekstra ynformaasje oer it liet sjen dat it gjin stipe foar brêgeleden of TCP-protokollen stipet, wat my liede ta de konklúzje dat der gjin alternatyf wie. OpenVPN foar my is it der noch net. Dat ik stel it kennen learen út WireGuard.
In pear dagen lyn ferspraat nijs him op ien of oare manier fia boarnen yn ferbân mei IT dat WireGuard sil úteinlik opnommen wurde yn 'e kernel Linux, begjinnend mei ferzje 5.6. Nijsartikels waarden, lykas altyd, priizge WireGuardIk haw my wer ris ûnderdompele yn it sykjen nei manieren om it goede âlde te ferfangen OpenVPNDizze 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 útskeakelje OpenVPN:
/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 nim it grelan0-apparaat út 'e brêge en lit it rinne OpenVPN Op de router yn appartemint 2 befêstige ik dat it netwurk wer goed wurke en dat de ferbiningen net útfoelen. By it sykjen kaam ik foarums tsjin dêr't minsken oer deselde problemen kleiden, en dêr't har advisearre waard om de MTU te ferheegjen. Net earder sein as dien. Oant de MTU lykwols heech genôch ynsteld wie - 7000 foar gretap-apparaten - ûnderfûn ik of fallen TCP-ferbiningen of lege oerdrachtsnelheden. Fanwegen de hege MTU foar gretap, de MTU foar ferbiningen WireGuard It earste en twadde nivo waarden ynsteld op respektivelik 8000 en 7500.
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 opnij starte fan 'e kliïntrouters, ûntduts ik dat se om ien of oare reden gjin ferbining makken mei de server. Nei it ferbinen mei harren SSH (gelokkich hie ik earder sshtunnel hjirfoar konfigurearre), ûntduts ik dat WireGuard Om ien of oare reden makket it in rûte foar it einpunt, mar it is net korrekt. Bygelyks, foar 192.168.30.2 hat de rûtetabel in rûte oantsjutte fia de pppoe-wan-ynterface, d.w.s. fia it ynternet, hoewol de rûte dêrhinne fia de wg0-ynterface rjochte wurde moatten hie. Nei it wiskjen fan dizze rûte waard de ferbining weromset. Kin ik earne ynstruksjes fine oer hoe't ik twongen wurde kin WireGuard Ik koe it net foarkomme om dizze rûtes te meitsjen. Boppedat begreep ik net iens oft dit in funksje fan OpenWRT wie of fan 'e WireGuardSûnder folle tiid te besteegjen oan it útfine fan it probleem, haw ik gewoan in rigel tafoege oan it timer-basearre skript op beide routers dy't dizze rûte wiske hawwe:
route del 192.168.30.2
Omheech op
Folsleine ôfwizing OpenVPN Ik haw dit noch net berikt, om't ik sa no en dan ferbining meitsje moat mei in nij netwurk fan in laptop of tillefoan, en it ynstellen fan in gretap-apparaat op har is oer it algemien ûnmooglik. Nettsjinsteande dit haw ik lykwols in foardiel krigen yn gegevensoerdrachtsnelheid tusken apparteminten, en it brûken fan bygelyks VNC is no sûnder problemen. Ping is wat ôfnommen, mar is stabiler wurden:
By it brûken 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 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 it appartemint mei de router-tsjinner haw ik in ynternetferbiningssnelheid fan 30 Mbps, en yn 'e oare apparteminten is it 5 Mbps. Boppedat, tidens gebrûk OpenVPN Ik koe gjin gegevensoerdrachtsnelheid tusken netwurken berikke fan mear as 3,8 Mbps neffens iperf-lêzingen, wylst WireGuard "pompte" it omheech nei deselde 5 Mbit/sek.
Konfiguraasje WireGuard op VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Peer]
Iepenbiere kaai = <VPN_1_MS_PUBLIC_KEY>
AllowedIPs = 192.168.30.2/32
[Peer]
Iepenbiere kaai = <VPN_2_MK2_PUBLIC_KEY>
AllowedIPs = 192.168.30.3/32
[Peer]
Iepenbiere kaai = <VPN_2_MK3_PUBLIC_KEY>
AllowedIPs = 192.168.30.4/32
Konfiguraasje WireGuard 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'
Konfiguraasje WireGuard 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'
Konfiguraasje WireGuard 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 'e beskreaune konfiguraasjes foar de VPN op it twadde nivo, jou ik kliïnten oan WireGuard Poart 51821. Dit moat net nedich wêze, om't de kliïnt in ferbining sil oprjochtsje fan elke frije, net-privileezjearre poarte, mar ik haw it op dizze manier dien, sadat ik alle ynkommende ferbiningen op 'e wg0-ynterfaces fan alle routers koe wegerje, útsein ynkommende UDP-ferbiningen nei poarte 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 OpenVPN-servers 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-kliïnt
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
