Tahaksin jagada oma kogemust võrkude ühendamisest kolmes geograafiliselt kaugel asuvas korteris, millest igaüks kasutab lüüsina OpenWRT-ga ruutereid, üheks ühiseks võrguks. Alamvõrgu marsruutimisega L3 ja sillaga L2 võrkude ühendamise meetodi valimisel, kui kõik võrgusõlmed on samas alamvõrgus, eelistati teist meetodit, mida on keerulisem konfigureerida, kuid mis pakub rohkem võimalusi, kuna on läbipaistev. tehnoloogiate kasutamine kavandati loodud võrgus Wake-on-Lan ja DLNA.
1. osa: Taust
Selle ülesande täitmiseks valitud protokoll oli algselt OpenVPN, sest esiteks saab sellega luua kraaniseadme, mida saab sillale probleemideta lisada, ja teiseks, OpenVPN See toetab TCP-d, mis oli samuti oluline, kuna ühelgi korteril polnud spetsiaalset IP-aadressi. Ma ei saanud STUN-i kasutada, sest minu internetiteenuse pakkuja blokeerib mingil põhjusel oma võrkudest sissetulevad UDP-ühendused. TCP lubas mul VPN-serveri pordi SSH kaudu üüritud VPS-ile edastada. Kuigi see lähenemisviis tekitab märkimisväärse lisakulu, kuna andmed on topeltkrüptitud, ei tahtnud ma VPS-i oma privaatvõrku integreerida, kuna oli oht, et kolmandad osapooled saavad selle üle kontrolli. Seetõttu oli sellise seadme omamine minu koduvõrgus äärmiselt ebasoovitav ja otsustasin turvalisuse eest märkimisväärse lisakulu maksta.
Ruuteri pordi edastamiseks, kuhu server plaaniti paigutada, kasutasin programmi sshtunnel. Ma ei hakka selle konfigureerimise üksikasjadesse laskuma – see on üsna lihtne. Märgin lihtsalt, et selle eesmärk oli edastada TCP-port 1194 ruuterilt VPS-ile. Järgmisena konfigureerisin serveri. OpenVPN BR-LAN sillaga ühendatud tap0 seadmel. Pärast seda, kui olin oma sülearvutist äsjaloodud serveriga ühendust testinud, selgus, et pordi edastamise idee oli toiminud ja mu sülearvutist oli saanud ruuteri võrgu liige, kuigi see polnud füüsiliselt selle osa.
Ainuke, mis järele jäi, oli IP-aadresside jaotamine eri korterites nii, et need konflikti ei satuks, ja ruuterite seadistamine vastavalt OpenVPN-kliendid.
Valiti järgmised ruuteri IP-aadressid ja DHCP-serveri vahemikud:
- 192.168.10.1 ulatusega 192.168.10.2 - 192.168.10.80 serveri jaoks
- 192.168.10.100 ulatusega 192.168.10.101 - 192.168.10.149 ruuterile korteris nr 2
- 192.168.10.150 ulatusega 192.168.10.151 - 192.168.10.199 ruuterile korteris nr 3
Samuti oli vaja need aadressid kliendiruuteritele määrata. OpenVPN-server, lisades selle konfiguratsioonile järgmise rea:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0ja järgmiste ridade lisamine faili /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
kus flat1_id ja flat2_id on seadme nimed, mis määratakse ühenduse loomiseks sertifikaatide loomisel OpenVPN
Järgmisena konfigureeriti ruuterid OpenVPN- kliendid, mõlema seadme tap0 seadmed lisati br-lan sillale. Sel hetkel tundus kõik korras olevat, kuna kõik kolm võrku nägid üksteist ja toimisid ühtse üksusena. Siiski ilmnes üsna ebameeldiv detail: mõnikord said seadmed IP-aadressi valelt ruuterilt koos kõigi sellest tulenevate tagajärgedega. Mingil põhjusel ei vastanud ühe korteri ruuter DHCPDISCOVERile õigeaegselt ja seade sai vale aadressi. Sain aru, et pean selliseid päringuid iga ruuteri tap0-s filtreerima, aga nagu selgus, ei saa iptables seadmega töötada, kui see on silla osa, seega pidin kasutama ebtables'i. Kahjuks minu püsivara seda ei sisaldanud, seega pidin iga seadme jaoks uuesti pildid looma. Pärast seda ja järgmiste ridade lisamist iga ruuteri faili /etc/rc.local oli probleem lahendatud:
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
See konfiguratsioon kestis kolm aastat.
2. osa: Tutvumine WireGuard
Viimasel ajal on internetis üha rohkem juttu olnud sellest, WireGuard, imetledes selle seadistamise lihtsust, suurt edastuskiirust, madalat pingi ja võrreldavat turvalisust. Lisateabe otsimine näitas, et see ei toeta ei sillaliikme ega TCP protokolli tuge, mis pani mind uskuma, et alternatiivi pole. OpenVPN minu jaoks see ikka veel pole. Seega lükkasin tutvumise edasi WireGuard.
Mõni päev tagasi levis IT-ga seotud ressursside kaudu ühel või teisel moel uudis, et WireGuard lisatakse lõpuks kerneli Linux, alates versioonist 5.6. Nagu ikka, kiideti uudisteartikleid WireGuardSukeldusin taas kord otsima võimalusi vana hea asendamiseks OpenVPNSeekord põrkasin kokku . See rääkis Etherneti tunneli loomisest L3 kaudu GRE abil. See artikkel andis mulle lootust. Ebaselgeks jäi, mida UDP-protokolliga peale hakata. Otsing viis mind artikliteni, mis käsitlevad socati kasutamist koos SSH-tunneliga UDP-pordi edastamiseks, kuid nad märkisid, et see lähenemisviis töötab ainult ühe ühenduse režiimis, mis tähendab, et mitu VPN-klienti oleks võimatu. Tulin ideele seadistada VPN-server VPS-is ja seadistada klientide jaoks GRE, kuid nagu selgus, ei toeta GRE krüptimist, mis toob kaasa asjaolu, et kui kolmandad osapooled saavad serverile juurdepääsu , kogu liiklus minu võrkude vahel on nende kätes, mis mulle üldse ei sobinud.
Jällegi otsustati üleliigse krüptimise kasuks, kasutades VPN-i üle VPN-i vastavalt järgmisele skeemile:
XNUMX. kihi VPN:
VPS see on server siseaadressiga 192.168.30.1
MS see on klient VPS siseaadressiga 192.168.30.2
MK2 see on klient VPS siseaadressiga 192.168.30.3
MK3 see on klient VPS siseaadressiga 192.168.30.4
XNUMX. kihi VPN:
MS see on server välise aadressiga 192.168.30.2 ja sisemisega 192.168.31.1
MK2 see on klient MS aadressiga 192.168.30.2 ja selle sisemine IP on 192.168.31.2
MK3 see on klient MS aadressiga 192.168.30.2 ja selle sisemine IP on 192.168.31.3
* MS - ruuter-server korteris 1, MK2 - ruuter korteris 2, MK3 - ruuter korteris 3
* Seadme konfiguratsioonid on avaldatud artikli lõpus olevas spoileris.
Ja nii, pingid võrgu 192.168.31.0/24 sõlmede vahel lähevad, on aeg liikuda edasi GRE tunneli seadistamise juurde. Enne seda, et mitte kaotada juurdepääsu ruuteritele, tasub seadistada SSH tunnelid pordi 22 suunamiseks VPS-ile, et näiteks korteri 10022 ruuter oleks saadaval VPS-i pordis 2 ja ruuter korterist 11122 on saadaval VPS-i pordis 3. Ruuter korterist XNUMX. Kõige parem on konfigureerida suunamine sama sshtunneliga, kuna see taastab tunneli, kui see kukkub.
Tunnel on konfigureeritud, saate SSH-ga ühenduse luua edastatud pordi kaudu:
ssh root@МОЙ_VPS -p 10022Järgmisena peaksite keelama OpenVPN:
/etc/init.d/openvpn stopNüüd paneme 2. korteri ruuterile üles GRE tunneli:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Ja lisage loodud liides sillale:
brctl addif br-lan grelan0
Teeme sarnase protseduuri serveri ruuteris:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Ja lisaks lisage loodud liides sillale:
brctl addif br-lan grelan0
sellest hetkest alates hakkavad pingid edukalt uude võrku minema ja mina lähen rahulolevalt kohvi jooma. Seejärel, et näha, kuidas juhtme teises otsas olev võrk töötab, proovin SSH-i sisestada ühte korteri 2 arvutisse, kuid ssh-klient hangub ilma parooli küsimata. Üritan selle arvutiga 22. pordi kaudu telneti kaudu ühendust saada ja näen rida, kust saab aru, et ühendus luuakse, SSH server vastab, aga millegipärast ei paku sisenemist.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Proovin sellega VNC kaudu ühendust luua ja näen musta ekraani. Veen ennast, et asi on kaugarvutis, sest saan sellest korterist siseaadressi abil lihtsalt ruuteriga ühenduse luua. Siiski otsustan sellesse arvutisse ruuteri kaudu SSH-i sisestada ja olen üllatunud, kui avastan, et ühendus õnnestub ja kaugarvuti töötab hästi, kuid ei saa ka minu arvutiga ühendust.
Võtan grelan0 seadme sillalt välja ja käivitan selle. OpenVPN Korteri 2 ruuteril kontrollisin, et võrk töötab jälle korralikult ja ühendused ei katke. Otsides sattusin foorumitele, kus inimesed kurtsid samade probleemide üle ja kus neil soovitati MTU-d tõsta. Niipea kui öeldud, tehtigi. Kuni aga MTU piisavalt kõrgeks seati – gretap-seadmete puhul 7000 –, tekkisid kas TCP-ühenduste katkemised või madalad edastuskiirused. Gretapi kõrge MTU tõttu oli ühenduste MTU... WireGuard Esimene ja teine tase määrati vastavalt 8000 ja 7500 peale.
Sarnase seadistuse tegin ka 3. korteri ruuteris, ainsa erinevusega, et serveri ruuterile lisati teine gretapi liides nimega grelan1, mis lisati ka br-lani sillale.
Kõik töötab. Nüüd saate gretapi komplekti automaatlaadimisse panna. Selle jaoks:
Need read paigutati korteri 2 ruuteri kausta /etc/rc.local:
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
Lisas selle korteri 3 ruuteri faili /etc/rc.local:
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
Ja serveri ruuteris:
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
Pärast kliendiruuterite taaskäivitamist avastasin, et mingil põhjusel ei loonud nad serveriga ühendust. Pärast nende SSH-ga ühenduse loomist (õnneks olin selleks eelnevalt sshtunneli seadistanud) avastasin, et WireGuard Mingil põhjusel loob see lõpp-punkti jaoks marsruudi, aga see on vale. Näiteks aadressi 192.168.30.2 puhul määras marsruuditabel marsruudi läbi pppoe-wan liidese, st läbi interneti, kuigi marsruut sinna oleks pidanud olema suunatud läbi wg0 liidese. Pärast selle marsruudi kustutamist ühendus taastati. Kas ma leian kusagilt juhiseid, kuidas sundida... WireGuard Ma ei saanud nende marsruutide loomist vältida. Pealegi ei saanud ma isegi aru, kas see oli OpenWRT või ... funktsioon. WireGuardIlma probleemi lahendamisele palju aega kulutamata lisasin lihtsalt mõlema ruuteri taimeripõhisele skriptile rea, mis selle marsruudi kustutas:
route del 192.168.30.2
Kokkuvõtteks
Täielik tagasilükkamine OpenVPN Ma pole seda veel saavutanud, kuna mul on aeg-ajalt vaja sülearvutist või telefonist uue võrguga ühenduda ja gretap-seadme seadistamine neil on üldiselt võimatu. Sellest hoolimata olen aga korterite vahelise andmeedastuskiiruse osas eelise saanud ja näiteks VNC kasutamine on nüüd probleemivaba. Ping on veidi vähenenud, kuid muutunud stabiilsemaks:
Kui kasutate 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
Kui kasutate 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
Seda mõjutab enamasti kõrge VPS-i ping, mis on ligikaudu 61.5 ms
Kiirus on aga märkimisväärselt suurenenud. Seega on mul ruuteri-serveriga korteris internetiühenduse kiirus 30 Mbps ja teistes korterites 5 Mbps. Lisaks on kasutamise ajal OpenVPN IPerf-i näitude kohaselt ei suutnud ma saavutada võrkude vahelist andmeedastuskiirust, mis oleks suurem kui 3,8 Mbps, samal ajal kui WireGuard "pumbas" selle sama 5 Mbit/sek peale.
Konfiguratsioon WireGuard VPS-il[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Kaaslane]
Avalik võti = <VPN_1_MS_AVALDUSKÄEV>
Lubatud IP-d = 192.168.30.2/32
[Kaaslane]
Avalik võti = <VPN_2_MK2_AVALDUSVÕTI>
Lubatud IP-d = 192.168.30.3/32
[Kaaslane]
Avalik võti = <VPN_2_MK3_AVALDUSVÕTI>
Lubatud IP-d = 192.168.30.4/32
Konfiguratsioon WireGuard MS-is (lisatud faili /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'
Konfiguratsioon WireGuard MK2 peal (lisatud faili /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'
Konfiguratsioon WireGuard MK3 peal (lisatud faili /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'
Teise taseme VPN-i kirjeldatud konfiguratsioonides osutan klientidele WireGuard Port 51821. See ei tohiks olla vajalik, kuna klient loob ühenduse igast vabast ja privilegeerimata pordist, aga mina tegin seda nii, et saaksin keelata kõik sissetulevad ühendused kõigi ruuterite wg0 liidestel, välja arvatud sissetulevad UDP-ühendused pordi 51821 kaudu.
Loodan, et artikkel on kellelegi kasulik.
PS Samuti soovin jagada oma skripti, mis saadab mulle rakenduses WirePusher mu telefoni PUSH-teate, kui minu võrku ilmub uus seade. Siin on link skriptile: .
UPDATE: Konfiguratsioon OpenVPN-serverid ja kliendid
OpenVPN-server
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-klient
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 Sertifikaatide genereerimiseks kasutasin easy-rsa-d.
Allikas: www.habr.com
