Rad bi delil svojo izkušnjo združevanja omrežij v treh geografsko oddaljenih stanovanjih, od katerih vsako uporablja usmerjevalnike z OpenWRT kot prehodom, v eno skupno omrežje. Pri izbiri načina združevanja omrežij med L3 z usmerjanjem v podomrežju in L2 s premoščanjem, ko bodo vsa omrežna vozlišča v istem podomrežju, je bila dana prednost drugemu načinu, ki je težji za konfiguracijo, vendar ponuja več možnosti, saj pregleden Uporaba tehnologij je bila načrtovana v ustvarjenem omrežju Wake-on-Lan in DLNA.
1. del: Ozadje
Kot protokol za izvedbo te naloge je bil sprva izbran OpenVPN, saj lahko po eni strani ustvari pipo napravo, ki jo lahko brez težav dodamo na most, po drugi strani pa OpenVPN podpira delovanje preko protokola TCP, kar je bilo tudi pomembno, ker nobeno stanovanje ni imelo namenskega naslova IP in nisem mogel uporabljati STUN-a, ker iz neznanega razloga moj ponudnik internetnih storitev blokira dohodne povezave UDP iz njihovih omrežij, medtem ko mi je protokol TCP omogočil posredovanje vrat strežnika VPN na najetem VPS s pomočjo SSH. Da, ta pristop predstavlja veliko obremenitev, saj so podatki šifrirani dvakrat, vendar nisem želel vnesti VPS v svoje zasebno omrežje, saj je še vedno obstajala nevarnost, da bodo tretje osebe prevzele nadzor nad njim, zato sem imel tako Naprava v domačem omrežju je bila skrajno nezaželena in odločili so se, da bodo varnost plačali z velikimi režijskimi stroški.
Za posredovanje vrat na usmerjevalniku, na katerem je bilo načrtovano namestiti strežnik, je bil uporabljen program sshtunnel. Ne bom opisoval zapletenosti njegove konfiguracije - to se naredi precej enostavno, ugotavljam le, da je bila njegova naloga posredovati vrata TCP 1194 od usmerjevalnika do VPS. Nato je bil strežnik OpenVPN konfiguriran na napravi tap0, ki je bila povezana z br-lan mostom. Po preverjanju povezave z novo ustvarjenim strežnikom iz prenosnega računalnika je postalo jasno, da je ideja o posredovanju vrat upravičena in moj prenosni računalnik je postal član omrežja usmerjevalnika, čeprav fizično ni bil v njem.
Zadeva je ostala majhna: bilo je treba razdeliti naslove IP v različnih stanovanjih, da niso bili v nasprotju in konfigurirati usmerjevalnike kot odjemalce OpenVPN.
Izbrani so bili naslednji naslovi IP usmerjevalnika in obsegi strežnikov DHCP:
- 192.168.10.1 z razponom 192.168.10.2 - 192.168.10.80 za strežnik
- 192.168.10.100 z razponom 192.168.10.101 - 192.168.10.149 za usmerjevalnik v stanovanju št. 2
- 192.168.10.150 z razponom 192.168.10.151 - 192.168.10.199 za usmerjevalnik v stanovanju št. 3
Prav tako je bilo treba odjemalskim usmerjevalnikom strežnika OpenVPN dodeliti točno te naslove z dodajanjem vrstice v njegovo konfiguracijo:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0in dodajanje naslednjih vrstic v datoteko /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
kjer sta flat1_id in flat2_id imeni naprav, določeni pri generiranju potrdil za povezavo z OpenVPN
Nato so bili na usmerjevalnikih konfigurirani odjemalci OpenVPN, naprave tap0 na obeh so bile dodane mostu br-lan. Na tej stopnji je bilo videti vse v redu, saj se vsa tri omrežja vidijo in delujejo kot celota. Vendar se je izkazala ne preveč prijetna podrobnost: včasih so naprave lahko dobile naslov IP ne iz svojega usmerjevalnika z vsemi posledicami. Iz nekega razloga usmerjevalnik v enem od stanovanj ni imel časa, da bi se pravočasno odzval na DHCPDISCOVER in naprava je prejela napačen naslov. Ugotovil sem, da moram takšne zahteve filtrirati v tap0 na vsakem od usmerjevalnikov, vendar se je izkazalo, da iptables ne more delovati z napravo, če je del mostu, in ebtables bi mi moral priskočiti na pomoč. Na mojo žalost ga ni bilo v moji vdelani programski opremi in sem moral znova sestaviti slike za vsako napravo. S tem in dodajanjem teh vrstic v /etc/rc.local vsakega usmerjevalnika je bila težava rešena:
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
Ta konfiguracija je trajala tri leta.
2. del: Predstavitev WireGuard
V zadnjem času internet vse pogosteje govori o WireGuardu in občuduje preprostost njegove konfiguracije, visoko hitrost prenosa, nizek ping ob primerljivi varnosti. Pri iskanju več informacij o njem je postalo jasno, da ne podpira niti dela kot član mosta niti dela prek protokola TCP, zaradi česar sem pomislil, da zame še vedno ni druge alternative za OpenVPN. Zato sem odložil spoznavanje WireGuarda.
Pred dnevi se je po virih, tako ali drugače povezanih z IT, razširila novica, da bo WireGuard končno vključen v jedro Linuxa, začenši z različico 5.6. Novičarski članki so kot vedno hvalili WireGuard. Ponovno sem se potopil v iskanje načinov, kako nadomestiti dobri stari OpenVPN. Tokrat sem naletela . Govorilo je o ustvarjanju ethernetnega tunela prek L3 z uporabo GRE. Ta članek mi je dal upanje. Ostalo je nejasno, kaj storiti s protokolom UDP. Iskanje me je pripeljalo do člankov o uporabi socat v povezavi s tunelom SSH za posredovanje vrat UDP, vendar so opazili, da ta pristop deluje samo v načinu ene povezave, kar pomeni, da bi bilo več odjemalcev VPN nemogoče. Prišel sem na idejo, da bi nastavil strežnik VPN na VPS in nastavil GRE za odjemalce, vendar se je izkazalo, da GRE ne podpira šifriranja, kar bo privedlo do dejstva, da če tretje osebe dobijo dostop do strežnika , ves promet med mojimi omrežji je v njihovih rokah, kar mi ni prav nič ustrezalo.
Ponovno se je odločilo za redundantno šifriranje z uporabo VPN prek VPN po naslednji shemi:
Layer XNUMX VPN:
VPS je strežnik z internim naslovom 192.168.30.1
DČ je stranko VPS z internim naslovom 192.168.30.2
MK2 je stranko VPS z internim naslovom 192.168.30.3
MK3 je stranko VPS z internim naslovom 192.168.30.4
VPN sloja XNUMX:
DČ je strežnik z zunanjim naslovom 192.168.30.2 in notranjim 192.168.31.1
MK2 je stranko DČ z naslovom 192.168.30.2 in ima notranji IP 192.168.31.2
MK3 je stranko DČ z naslovom 192.168.30.2 in ima notranji IP 192.168.31.3
* DČ - usmerjevalnik-strežnik v apartmaju 1, MK2 - router v stanovanju 2, MK3 - router v stanovanju 3
* Konfiguracije naprav so objavljene v spojlerju na koncu članka.
In tako, pingi med vozlišči omrežja 192.168.31.0/24 gredo, čas je, da nadaljujemo z nastavitvijo tunela GRE. Pred tem, da ne izgubite dostopa do usmerjevalnikov, je vredno nastaviti SSH tunele za posredovanje vrat 22 v VPS, tako da bo na primer usmerjevalnik iz stanovanja 10022 na voljo na vratih 2 VPS in usmerjevalnik iz apartmaja 11122 bo na voljo na vratih 3 VPS usmerjevalnik iz apartmaja XNUMX. Najbolje je konfigurirati posredovanje z istim sshtunnelom, saj bo obnovil tunel v primeru padca.
Predor je konfiguriran, na SSH se lahko povežete prek posredovanih vrat:
ssh root@МОЙ_VPS -p 10022Nato onemogočite OpenVPN:
/etc/init.d/openvpn stopZdaj pa nastavimo tunel GRE na usmerjevalniku iz stanovanja 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
In dodajte ustvarjeni vmesnik v most:
brctl addif br-lan grelan0
Izvedimo podoben postopek na strežniškem usmerjevalniku:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
In tudi dodajte ustvarjeni vmesnik v most:
brctl addif br-lan grelan0
od tega trenutka začnejo pingi uspešno iti v novo omrežje in z zadovoljstvom grem piti kavo. Nato, da vidim, kako deluje omrežje na drugi strani žice, poskušam vzpostaviti SSH v enega od računalnikov v stanovanju 2, vendar odjemalec ssh zamrzne, ne da bi me pozval k vnosu gesla. Poskušam se povezati s tem računalnikom prek telneta na vratih 22 in vidim vrstico, iz katere lahko razumete, da se povezava vzpostavlja, strežnik SSH se odziva, vendar mi iz neznanega razloga ne ponudi vstopa.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Poskušam se povezati z njim prek VNC in vidim črn zaslon. Prepričujem se, da je zadeva v oddaljenem računalniku, saj se iz tega stanovanja zlahka povežem na router po internem naslovu. Vendar se odločim za SSH v ta računalnik prek usmerjevalnika in presenečen ugotovim, da je povezava uspešna in da oddaljeni računalnik deluje dobro, vendar se tudi ne more povezati z mojim računalnikom.
Napravo grelan0 vzamem iz mostu in zaženem OpenVPN na usmerjevalniku v stanovanju 2 ter se prepričam, da omrežje spet pravilno deluje in povezave ne prekinjajo. Pri iskanju naletim na forume, kjer se ljudje pritožujejo o enakih težavah, kjer jim svetujejo dvig MTU. Nič prej rečeno kot storjeno. Dokler pa MTU ni bil nastavljen na dovolj visoko vrednost 7000 za naprave gretap, so bile opažene bodisi prekinjene povezave TCP bodisi počasni prenosi. Zaradi visokega MTU za gretap so bili MTU za povezave WireGuard prve in druge ravni nastavljeni na 8000 oziroma 7500.
Podobno sem nastavil na usmerjevalniku iz stanovanja 3, z edino razliko, da je bil strežniškemu usmerjevalniku dodan drugi vmesnik gretap z imenom grelan1, ki je bil dodan tudi mostu br-lan.
Vse dela. Zdaj lahko sklop gretap postavite v samodejno nalaganje. Za to:
Te vrstice sem postavil v /etc/rc.local na usmerjevalniku v stanovanju 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
To dodano v /etc/rc.local na usmerjevalniku v stanovanju 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
In na strežniškem usmerjevalniku:
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
Po ponovnem zagonu odjemalskih usmerjevalnikov sem ugotovil, da se iz nekega razloga niso povezali s strežnikom. Pri povezovanju z njihovim SSH (na srečo sem predhodno konfiguriral sshtunnel za to) je bilo ugotovljeno, da WireGuard iz nekega razloga ustvari pot za končno točko, čeprav je napačna. Torej, za 192.168.30.2 je bila tabela poti določena v tabeli poti prek vmesnika pppoe-wan, to je prek interneta, čeprav bi morala biti pot do njega usmerjena prek vmesnika wg0. Po brisanju te poti je bila povezava vzpostavljena. Nikjer nisem našel navodil, kako prisiliti WireGuard, da ne ustvarja teh poti. Poleg tega sploh nisem razumel, ali je to funkcija OpenWRT ali samega WireGuarda. Ne da bi se moral dolgo ukvarjati s to težavo, sem obema usmerjevalnikoma v skriptu, ki ga zanaša časovnik, preprosto dodal vrstico, ki je izbrisala to pot:
route del 192.168.30.2
Povzema
Nisem še dosegel popolne zavrnitve OpenVPN, saj se včasih moram povezati z novim omrežjem iz prenosnika ali telefona in nastavitev naprave gretap na njih je na splošno nemogoča, a kljub temu sem dobil prednost pri prenosu podatkov hitrost med stanovanji in na primer uporaba VNC ni več neprijetna. Ping se je nekoliko zmanjšal, vendar je postal bolj stabilen:
Pri uporabi 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
Ko uporabljate 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
Nanj večinoma vpliva visok ping do VPS, ki znaša približno 61.5 ms
Vendar se je hitrost znatno povečala. Torej imam v stanovanju z usmerjevalnikom-strežnikom hitrost internetne povezave 30 Mbps, v ostalih stanovanjih pa 5 Mbps. Hkrati pri uporabi OpenVPN nisem mogel doseči hitrosti prenosa podatkov med omrežji več kot 3,8 Mbps po iperfu, medtem ko jo je WireGuard "napumpal" na istih 5 Mbps.
Konfiguracija WireGuard na 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
Konfiguracija WireGuard na MS (dodano v /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'
Konfiguracija WireGuard na MK2 (dodano v /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'
Konfiguracija WireGuard na MK3 (dodano v /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'
V opisanih konfiguracijah za drugo raven VPN odjemalcem WireGuard podajam vrata 51821. Teoretično to ni potrebno, saj bo odjemalec vzpostavil povezavo s poljubnih prostih neprivilegiranih vrat, naredil pa sem tako, da so vse dohodne povezave je mogoče zavrniti na vmesnikih wg0 vseh usmerjevalnikov, razen dohodnih povezav UDP na vratih 51821.
Upam, da bo članek komu koristen.
PS Prav tako želim deliti svoj skript, ki mi v aplikaciji WirePusher pošlje PUSH obvestilo na moj telefon, ko se v mojem omrežju pojavi nova naprava. Tukaj je povezava do skripta: .
UPDATE: Konfiguracija strežnika OpenVPN in odjemalcev
OpenVPN strežnik
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-lzoOdjemalec OpenVPN
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
Za ustvarjanje potrdil sem uporabil easy-rsa.
Vir: www.habr.com