
Soovin jagada kogemust kolme geograafiliselt eraldi korteri võrgu ühendamisel, kus igaühes kasutatakse OpenWRT ruutereid väravana, üheks ühineks võrguks. Võrkude ühendamise meetodi valimisel L3 marsruutimise alamsüsteemide ja L2 sildamise vahel, kus kõik võrgu sõlmed asuvad ühes alamsüsteemis, eelistati teist meetodit, mis on keerulisem seadistada, kuid pakub suuremaid võimalusi, kuna loodud võrgus plaaniti sujuvat Wake-on-Lan ja DLNA tehnoloogiate kasutamist.
Osa 1: Taust
Edasi selle ülesande rakendamiseks valiti algselt protokollina OpenVPN, kuna esiteks suudab see luua tap-seadmeks, mis liidetakse probleemideta silda, ja teiseks toetab OpenVPN TCP protokolli, mis oli samuti oluline, kuna üheski korteris ei olnud staatilist IP-aadressi ning STUN-i kasutamine ei osutunud võimalikuks, kuna minu teenusepakkuja blokib kummalisel kombel sisse tulevad UDP-protokolli ühendused oma võrkudest, samas kui TCP-protokoll võimaldas mul avada VPN-serveri sadama renditud VPS-i kaudu SSH abil. Jah, selline lähenemine toob kaasa suure koormuse, kuna andmed krüpteeritakse kaks korda, kuid ma ei soovinud VPS-i oma kohalikku võrku tuua, kuna oli oht, et kolmandad osalised saavad sellele kontrolli, seega oli sellise seadme omamine koduvõrgus äärmiselt ebasoovitav ja otsustasin maksta suuremate kulude eest turvalisuse nimel.
Ruuteri, kus plaaniti serverit juurutada, sadama edastamiseks kasutati programmi sshtunnel. Ei hakka kirjeldama selle konfigureerimise peensusi – see on piisavalt lihtne, lihtsalt mainin, et selle ülesanne oli edastada TCP-pord 1194 ruuterilt VPS-ile. Edasi seadistati OpenVPN server seadmel tap0, mis ühendati sillaga br-lan. Kontrollides, kas ühendus värskelt loodud serveriga töötas, sai selgeks, et portide edastamise idee toimis ja minu sülearvuti sai ruuteri võrgu liikmeks, ehkki füüsiliselt seal ei viibinud.
Edasi oli jäänud vaid väike asi: oli vajalik jagada IP-aadresse erinevates korterites nii, et need ei oleks konfliktis, ning seadistada ruuterid OpenVPN kliendina.
Valiti järgmised ruuterite IP-aadressid ja DHCP-serverite vahemikud:
- 192.168.10.1 vahemikuga 192.168.10.2 — 192.168.10.80 serveri jaoks
- 192.168.10.100 vahemikuga 192.168.10.101 — 192.168.10.149 korteri marsruuter number 2
- 192.168.10.150 vahemikuga 192.168.10.151 — 192.168.10.199 korteri marsruuter number 3
Samuti tuli määrata just need aadressid OpenVPN-serveri kliendi marsruutidele, lisades oma konfiguratsiooni järgmise rea:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0ja lisades järgmised read faili /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
kus flat1_id ja flat2_id on seadmete nimed, mis määratakse sertifikaatide loomisel OpenVPN-iga ühendamiseks
Seejärel seadistati marsruuterites OpenVPN-klientide seadmed, tap0 seadmed mõlemasse silda br-lan. Sel hetkel näis kõik olevat korras, kuna kõik kolm võrku nägid üksteist ja töötasid koos kui tervik. Kuid selgus, et esines mitte eriti meeldiv detail: mõnikord said seadmed IP-aadressi mitte oma marsruuterilt, koos kõigi tagajärgedega. Mingi põhjusel ei suutnud marsruuter ühes korteris õigel ajal DHCPDISCOVER'ile vastata ja seade sai mittesobiva aadressi. Mõistsin, et pean sellised päringud tap0-l igas marsruuteris filterdama, kuid nagu selgus, ei saa iptables töötada seadmega, kui see kuulub silda ja abi pidi tulema ebtables'ist. Kahjuks ei olnud mu püsivaramutes seda ning pidin iga seadme jaoks kujundama uued pildid. Pärast seda, kui olin seda teinud ja lisanud sellised read /etc/rc.local iga marsruuteri juurde, probleem lahendati:
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
Selline konfiguratsioon püsis kolm aastat.
Osa 2: Tutvumine WireGuardiga
Viimase ajal on internetis järjest enam räägitud WireGuardist, kiites selle konfiguratsiooni lihtsust, kõrget edastuskiirus ja madalat latentsust võrreldes sarnase turvalisusega. Täiendava teabe otsimine näitas, et ei sildana töötamine ega TCP protokolli kasutamine ei ole selle poolt toetatud, mis pani mind mõtlema, et OpenVPN-i alternatiive ei ole mul ikka veel. Seetõttu olen WireGuard'iga tutvumist edasi lükanud.
Mõned päevad tagasi levis IT-ga seotud allikates uudis sellest, et WireGuard lisatakse lõpuks Linuxi tuuma, alates versioonist 5.6. Uudisteartiklid kiitsid nagu alati WireGuardi. Sukeldusin taas vanade head OpenVPN asendamise võimaluste otsingusse. Seekord sattusin artiklile, kus räägiti Etherneti tunnelist L3 üle GRE abil. See artikkel andis mulle lootust. Ebaselgeks jäi, mida teha UDP-protokolliga. Otsingud viisid mind artikliteni, mis käsitlesid socati kasutamist koos SSH-tunneliga UDP-portide suunamiseks, kuid seal märkisid, et selline lähenemine töötab ainult ühe ühenduse režiimis, mis tähendab, et mitme VPN-kliendi töö ei oleks võimalik. Mul tuli mõte tõsta VPS-is VPN-server ja seadistada klientide jaoks GRE, kuid nagu selgus, GRE ei toeta krüpteerimist, mis tähendaks, et kolmandate isikute juurdepääsu korral oleks kogu mu võrkude vaheline liiklus nende kätes, mis mind põhimõtteliselt ei rahuldanud.
Otsustasin jälle liialdada krüpteerimisega, kasutades VPN-i VPN-i peal järgmise skeemi järgi:
Esimese taseme VPN:
VPS on serverilt siseaadressiga 192.168.30.1
MS on kliendi VPS siseaadressiga 192.168.30.2
МК2 on kliendi VPS siseaadressiga 192.168.30.3
МК3 on kliendi VPS siseaadressiga 192.168.30.4
Teise taseme VPN:
MS on serverilt välisaadressiga 192.168.30.2 ja siseaadressiga 192.168.31.1
МК2 on kliendi MS aadressiga 192.168.30.2 ja sise-IP-ga 192.168.31.2
МК3 on kliendi MS aadressiga 192.168.30.2 ja sise-IP-ga 192.168.31.3
* MS — marsruuter-server korteris 1, МК2 — marsruuter korteris 2, МК3 — marsruuter korteris 3
* Seadmete konfiguratsioonid on artikli lõpus spoileris avaldatud.
Nii et, pingid võrkude 192.168.31.0/24 vahel liiguvad, on aeg liikuda GRE-tunneli seadistamise juurde. Enne seda, et mitte kaotada juurdepääsu marsruuteritele, on soovitatav seadistada SSH-tunnelid 22. portaali suunamiseks VPS-is, nii et näiteks 10022. port on VPS-is saadaval korteri 2 marsruuterile, ja 11122. port on VPS-is saadaval korteri 3 marsruuterile. Parim on suunamine teostada sshtunneliga, kuna see taastab tunnelid, kui need peaksid kokku kukkuma.
Tunnel on seadistatud, nüüd saab SSH-sse ühenduda suunatud porti kaudu:
ssh root@MINU_VPS -p 10022Seejärel tuleb OpenVPN välja lülitada:
/etc/init.d/openvpn stopNüüd seadistame GRE-tunneli korteri 2 marsruuteri peal:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Ja lisame loodud liidese silda:
brctl addif br-lan grelan0
Teeme sarnase protseduuri serveriga ruuteri juures:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Ja lisame samuti loodud liidese silda:
brctl addif br-lan grelan0
Alates sellest hetkest hakkavad pingid uuesti edukalt uude võrku liikuma ja mina, rahulolevalt, suundun kohvi jooma. Seejärel, et hinnata, kuidas võrk teisel pool kaablit töötab, üritan SSH kaudu ühendada oma ühte arvutisse korteris 2, kuid ssh-klient "hangub", mitte pakkudes parooli sisestamiseks. Proovin sellele arvutile telneti kaudu 22. porti ühenduda ja näen rida, millest saab aru, et ühendus on loomisel, SSH-server vastab, kuid mingil põhjusel ei luba mind sisse.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Püüan temaga VNC kaudu ühendust võtta ja näen musta ekraani. Veenan end, et probleem on eemalolevas arvutis, kuna selle korteri ruuteriga saan ilma probleemideta ühendust sisemise aadressi kaudu. Otsustan siiski ühenduda selle arvuti SSH-ga ruuteri kaudu ja avastan üllatusega, et ühendus õnnestub, kuid eemalolev arvuti ei saa ka minu arvutiga ühendust.
Eemaldan seadme grelan0 sillast ja käivitan OpenVPN ruuteri korteris 2 ja veendun, et võrk töötab taas korralikult ning ühendused ei katke. Otsimisel satun foorumitesse, kus inimesed kaebavad sarnaste probleemide üle ning neile soovitatakse MTU suurendada. Öeldud — tehtud. Kuid seni, kuni MTU ei olnud piisavalt suur — 7000 gretap seadmetele, täheldati kas TCP ühenduste katkestusi või madalat andmeedastuskiirus. Gretap jaoks kõrge MTU tõttu — WireGuardi esimese ja teise taseme ühenduste MTU olid vastavalt seatud 8000 ja 7500.
Teostasin sarnase seadistuse ka korteris 3 asuvas ruuteris, ainsa erinevusega, et serveri ruuteris lisandus teine gretap liides nimega grelan1, mis lisati samuti silda br-lan.
Kõik töötab. Nüüd saab gretap kogumi paigaldada autolaadimisele. Selleks:
Paigaldasin need read /etc/rc.local ruuterisse korteris 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
Lisatud see /etc/rc.local marsruuterisse korteris 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
Ja marsruuter-serveris:
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 kliendirouteri taaskäivitamist avastasin, et nad mingil põhjusel ei ühendu serveriga. Ühendudes nende SSH-iga (õnneks olin ma eelnevalt seadistanud sshtunnel'i selleks) avastasin, et WireGuard loob millegipärast marsuudi endpoint'i jaoks, samas vale. Nii et 192.168.30.2 korral oli marsruudi tabelis näidatud marsruut pppoe-wan liidese kaudu, teisisõnu kaudu interneti, kuigi marsruut selle juurde peaks olema suunatud wg0 liidese kaudu. Pärast selle marsruudi eemaldamist taastati ühendus. Ei leidnud ma kuskilt juhiseid, kuidas sundida WireGuard mitte looma neid marsruute. Veelgi enam, ma ei saanud aru, kas see on OpenWRT omadus või WireGuard'i enda. Ilma probleemi süvitsi uurimata, lisasin lihtsalt mõlemale routerile skripti, mis oli ajakava järgi suletud, real, mis eemaldas selle marsruudi:
route del 192.168.30.2
Kokkuvõtteks
Ma ei ole täielikku loobumist OpenVPN-ist veel saavutanud, kuna mul on aeg-ajalt vaja juurdepääsu uuele võrgule oma sülearvutist või telefonist, ja nendele gretap seadistamine on üldiselt võimatu, kuid sellest hoolimata olen saanud kiirusel eelise andmete edastamise vahel korterite vahel ja näiteks VNC kasutamine ei põhjusta enam ebamugavusi. Ping on vaid vähe vähenenud, kuid on muutunud stabiilsemaks:
OpenVPN-i kasutades:
[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) baitide andmeid.
64 baiti 192.168.10.110: icmp_seq=1 ttl=64 aeg=133 ms
...
64 baiti 192.168.10.110: icmp_seq=20 ttl=64 aeg=125 ms
--- 192.168.10.110 ping statistika ---
20 paketti edastatud, 20 vastu võetud, 0% paketi kaotus, aeg 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms
WireGuard'i kasutades:
[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) baitide andmeid.
64 baiti 192.168.10.110: icmp_seq=1 ttl=64 aeg=124 ms
...
64 baiti 192.168.10.110: icmp_seq=20 ttl=64 aeg=124 ms
--- 192.168.10.110 ping statistika ---
20 paketti edastatud, 20 vastu võetud, 0% paketi kaotus, aeg 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms
Sellele mõjutab enamasti kõrge ping VPS-i, mis on umbes 61.5 ms
Kuid kiirus on tõeliselt suurenenud. Nii on mul korteris, kus on marsruuter-server, Interneti-ühendus kiirus 30 Mbit/s, samas kui teistes korterites on see 5 Mbit/s. Samuti ei ole mul OpenVPN-i kasutamisel õnnestunud andmeedastuse kiirusest üle 3,8 Mbit/s iperf-i näidatud, samas kui WireGuard suudab selle tõsta samadele 5 Mbit/s.
WireGuardi konfiguratsioon VPS-is[Interface]
Aadress = 192.168.30.1/24
Kuulamisport = 51820
Privaatvõti =
[Peer]
PublicKey =
AllowedIPs = 192.168.30.2/32
[Peer]
PublicKey =
AllowedIPs = 192.168.30.3/32
[Peer]
PublicKey =
AllowedIPs = 192.168.30.4/32
WireGuardi konfiguratsioon MS-is (lisatakse /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'
WireGuardi konfiguratsioon MK2-s (lisatakse /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'
WireGuardi konfiguratsioon MK3-s (lisatakse /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'
Kirjeldatud konfiguratsioonides teisel tasemel VPN-is annan klientidele WireGuardi pordi 51821. Idee on see, et see pole vajalik, kuna klient ühendub igalt vabalt privileegivabalt pordilt, kuid tegin nii, et oleks võimalik keelata kõik sissetulevad ühendused kõikide marsruutorite wg0 liidesele, välja arvatud sissetulevad UDP-ühendused pordile 51821.
Loodan, et artikkel on kellelegi kasulik.
P.S. Samuti tahan jagada oma skripti, mis saadab mulle PUSH-teate telefoni WirePusheri rakenduses, kui minu võrgus ilmub uus seade. Siin on lingi skriptile: .
UUENDUS: OpenVPN-serveri ja klientide konfiguratsioon
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 # Muuda oma ruuteri välise IP-ga
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
Allikas: habr.com
