Haluaisin jakaa kokemukseni verkkojen yhdistämisestä kolmessa maantieteellisesti erillään olevassa asunnossa, joista jokainen käyttää reitittimiä OpenWRT-yhdyskäytävänä, yhdeksi yhteiseksi verkkoksi. Valittaessa menetelmää verkkojen yhdistämiseksi aliverkon reitityksellä varustetun L3:n ja siltauksen L2:n välillä, kun kaikki verkkosolmut ovat samassa aliverkossa, etusija annettiin toiselle menetelmälle, joka on vaikeampi konfiguroida, mutta tarjoaa enemmän mahdollisuuksia, koska läpinäkyvä. Teknologioiden käyttö suunniteltiin luodussa Wake-on-Lan- ja DLNA-verkossa.
Osa 1: Tausta
Tämän tehtävän toteuttamiseen valittu protokolla oli alun perin OpenVPN, koska ensinnäkin se voi luoda hanalaitteen, joka voidaan lisätä sillalle ongelmitta, ja toiseksi, OpenVPN Se tukee TCP:tä, mikä oli myös tärkeää, koska missään asunnossa ei ollut erillistä IP-osoitetta. En voinut käyttää STUNia, koska internet-palveluntarjoajani jostain syystä estää saapuvat UDP-yhteydet verkoistaan. TCP mahdollisti VPN-palvelimen portin välittämisen vuokratulle VPS:lle SSH:n kautta. Vaikka tämä lähestymistapa aiheuttaa merkittävää lisäkuluja, koska tiedot salataan kahdesti, en halunnut integroida VPS:ää yksityisverkkooni, koska oli olemassa riski, että kolmannet osapuolet saisivat sen hallintaansa. Siksi tällaisen laitteen pitäminen kotiverkossani oli erittäin ei-toivottavaa, joten päätin maksaa merkittävän lisäkulun turvallisuudesta.
Käytin sshtunnel-ohjelmaa ohjatakseni reitittimen portin, jolle palvelin oli tarkoitus sijoittaa. En mene sen konfiguroinnin yksityiskohtiin – se on melko helppoa. Huomautan vain, että sen tarkoituksena oli ohjata TCP-portti 1194 reitittimestä VPS:ään. Seuraavaksi konfiguroin palvelimen. OpenVPN BR-LAN-siltaan kytketyssä tap0-laitteessa testasin yhteyttä juuri luotuun palvelimeen kannettavastani ja kävi selväksi, että porttiohjaus oli toiminut. Kannettavastani oli tullut osa reitittimen verkkoa, vaikka se ei fyysisesti ollutkaan osa sitä.
Jäljelle jäi enää IP-osoitteiden jakaminen eri asuntoihin, jotta ne eivät olisi ristiriidassa keskenään, ja reitittimien konfigurointi siten, että ne OpenVPN-asiakkaita.
Seuraavat reitittimen IP-osoitteet ja DHCP-palvelinalueet valittiin:
- 192.168.10.1 kantaman kanssa 192.168.10.2 - 192.168.10.80 palvelimelle
- 192.168.10.100 kantaman kanssa 192.168.10.101 - 192.168.10.149 reitittimelle asunnossa nro 2
- 192.168.10.150 kantaman kanssa 192.168.10.151 - 192.168.10.199 reitittimelle asunnossa nro 3
Nämä osoitteet oli myös tarpeen antaa asiakasreitittimille. OpenVPN-server lisäämällä seuraavan rivin sen kokoonpanoon:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0ja lisäämällä seuraavat rivit /etc/openvpn/ipp.txt-tiedostoon:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
jossa flat1_id ja flat2_id ovat laitteiden nimet, jotka määritetään luotaessa varmenteita yhteyden muodostamista varten OpenVPN
Seuraavaksi reitittimet konfiguroitiin OpenVPN- asiakkaat, molempien tap0-laitteet lisättiin br-lan-siltaan. Tässä vaiheessa kaikki näytti olevan kunnossa, koska kaikki kolme verkkoa pystyivät näkemään toisensa ja toimimaan yhtenä yksikkönä. Kuitenkin ilmeni melko epämiellyttävä yksityiskohta: joskus laitteet saivat IP-osoitteen väärältä reitittimeltä kaikkine seurauksineen. Jostain syystä yhden asunnon reititin ei vastannut DHCPDISCOVER-komentoon ajoissa, ja laite sai väärän osoitteen. Tajusin, että minun piti suodattaa tällaiset pyynnöt tap0:ssa jokaisella reitittimellä, mutta kuten kävi ilmi, iptables ei voi toimia laitteen kanssa, jos se on osa siltaa, joten minun piti käyttää ebtablesia. Valitettavasti laiteohjelmistoni ei sisältänyt sitä, joten minun piti rakentaa levykuvat uudelleen jokaiselle laitteelle. Tämän jälkeen ja lisättyään seuraavat rivit /etc/rc.local-tiedostoon jokaisella reitittimellä, ongelma ratkesi:
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
Tämä kokoonpano kesti kolme vuotta.
Osa 2: Tutustuminen WireGuard
Viime aikoina internetissä on puhuttu yhä enemmän siitä, WireGuard, ihaillen sen helppokäyttöistä konfigurointia, suurta siirtonopeutta, alhaista pingiä ja vertailukelpoista turvallisuutta. Lisätietojen etsiminen paljasti, ettei se tue sillan jäsen- tai TCP-protokollaa, mikä sai minut uskomaan, ettei vaihtoehtoa ole. OpenVPN minulle se ei vieläkään ole siellä. Joten lykkäsin tutustumista WireGuard.
Muutama päivä sitten uutinen levisi IT-alan resurssien kautta tavalla tai toisella, että WireGuard sisällytetään vihdoin ytimeen Linuxversiosta 5.6 alkaen. Uutisartikkeleita, kuten aina, ylistettiin WireGuardSyöksyin jälleen etsimään tapoja korvata vanha hyvä OpenVPNTällä kertaa törmäsin . Siinä puhuttiin Ethernet-tunnelin luomisesta L3:n yli GRE:n avulla. Tämä artikkeli antoi minulle toivoa. Jäi epäselväksi, mitä tehdä UDP-protokollan kanssa. Haku johti artikkeleihin socatin käyttämisestä yhdessä SSH-tunnelin kanssa UDP-portin välittämiseen, mutta he huomasivat, että tämä lähestymistapa toimii vain yhden yhteyden tilassa, mikä tarkoittaa, että useita VPN-asiakkaita olisi mahdotonta. Keksin idean perustaa VPN-palvelin VPS:ään ja asettaa GRE asiakkaille, mutta kuten kävi ilmi, GRE ei tue salausta, mikä johtaa siihen, että jos kolmannet osapuolet pääsevät palvelimelle , kaikki verkkojeni välinen liikenne on heidän käsissään, mikä ei sopinut minulle ollenkaan.
Jälleen päätettiin käyttää redundanttia salausta käyttämällä VPN:n yli VPN:ää seuraavan kaavan mukaan:
Layer XNUMX VPN:
VPS on palvelin sisäisellä osoitteella 192.168.30.1
MS on asiakas VPS, jonka sisäinen osoite on 192.168.30.2
MK2 on asiakas VPS, jonka sisäinen osoite on 192.168.30.3
MK3 on asiakas VPS, jonka sisäinen osoite on 192.168.30.4
Layer XNUMX VPN:
MS on palvelin ulkoisella osoitteella 192.168.30.2 ja sisäisellä 192.168.31.1
MK2 on asiakas MS jonka osoite on 192.168.30.2 ja sen sisäinen IP on 192.168.31.2
MK3 on asiakas MS jonka osoite on 192.168.30.2 ja sen sisäinen IP on 192.168.31.3
* MS - reititin-palvelin huoneistossa 1, MK2 - reititin huoneistossa 2, MK3 - reititin huoneistossa 3
* Laitekokoonpanot julkaistaan artikkelin lopussa olevassa spoilerissa.
Ja niin, pingit verkon 192.168.31.0/24 solmujen välillä menevät, on aika siirtyä GRE-tunnelin asettamiseen. Ennen sitä, jotta pääsy reitittimiin ei menetä, kannattaa perustaa SSH-tunneleita portin 22 välittämiseksi VPS:lle, jotta esimerkiksi asunnon 10022 reititin on käytettävissä VPS:n portissa 2 ja reititin asunnosta 11122 on käytettävissä VPS:n portissa 3. reititin asunnosta XNUMX. On parasta konfiguroida edelleenlähetys samalla sshtunnelilla, koska se palauttaa tunnelin putoamisen varalta.
Tunneli on määritetty, voit muodostaa yhteyden SSH:hon edelleenlähetetyn portin kautta:
ssh root@МОЙ_VPS -p 10022Seuraavaksi sinun pitäisi poistaa käytöstä OpenVPN:
/etc/init.d/openvpn stopPerustetaan nyt GRE-tunneli asunnon 2 reitittimeen:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Ja lisää luotu käyttöliittymä siltaan:
brctl addif br-lan grelan0
Suoritetaan samanlainen toimenpide palvelimen reitittimessä:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Ja lisää myös luotu käyttöliittymä siltaan:
brctl addif br-lan grelan0
tästä hetkestä lähtien pingit alkavat mennä onnistuneesti uuteen verkkoon ja tyytyväisenä menen juomaan kahvia. Sitten nähdäkseni kuinka verkko toimii johdon toisessa päässä, yritän SSH:ta yhteen asunnon 2 tietokoneista, mutta ssh-asiakas jumiutuu pyytämättä minua salasanaa. Yritän muodostaa yhteyden tähän tietokoneeseen telnetin kautta portissa 22 ja näen rivin, josta voit ymmärtää, että yhteyttä muodostetaan, SSH-palvelin vastaa, mutta jostain syystä se ei tarjoa minulle pääsyä.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Yritän muodostaa yhteyden siihen VNC:n kautta ja näen mustan näytön. Vakuutan itseni, että asia on etätietokoneessa, koska voin helposti muodostaa yhteyden reitittimeen tästä asunnosta sisäisen osoitteen avulla. Päätän kuitenkin SSH:ta tähän tietokoneeseen reitittimen kautta ja olen yllättynyt siitä, että yhteys onnistuu ja etätietokone toimii hyvin, mutta ei myöskään saa yhteyttä tietokoneeseeni.
Otan grelan0-laitteen pois sillasta ja suoritan sen OpenVPN Asunnon 2 reitittimellä varmistin, että verkko toimi taas kunnolla ja yhteydet eivät katkenneet. Etsinnässäni törmäsin foorumeihin, joilla ihmiset valittivat samoista ongelmista ja joissa heitä kehotettiin nostamaan MTU:ta. Sanottu ja tehty. Kuitenkin, kunnes MTU oli asetettu riittävän korkeaksi – 7000 gretap-laitteille – TCP-yhteydet katkesivat tai siirtonopeudet olivat hitaita. Gretapin korkean MTU:n vuoksi yhteyksien MTU... WireGuard Ensimmäinen ja toinen taso asetettiin vastaavasti 8000:een ja 7500:een.
Tein samanlaisen asennuksen asunnon 3 reitittimelle, sillä ainoa ero on, että palvelinreitittimeen lisättiin toinen grelan1-niminen gretap-liitäntä, joka lisättiin myös br-lan-sillalle.
Kaikki toimii. Nyt voit laittaa gretap-kokoonpanon automaattiseen lataustilaan. Tätä varten:
Sijoitti nämä rivit asunnon 2 reitittimen kansioon /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
Lisäsi tämän asunnon 3 reitittimen /etc/rc.local-kansioon:
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 palvelimen reitittimessä:
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
Käynnistettyäni asiakasreitittimet uudelleen huomasin, että ne eivät jostain syystä muodostaneet yhteyttä palvelimeen. Yhdistettyäni heidän SSH-yhteyteensä (onneksi olin aiemmin määrittänyt sshtunnelin tätä varten) huomasin, että WireGuard Jostain syystä se luo reitin päätepisteelle, mutta se on virheellinen. Esimerkiksi osoitteelle 192.168.30.2 reittitaulukko määritti reitin pppoe-wan-rajapinnan kautta eli internetin kautta, vaikka reitin siihen olisi pitänyt ohjata wg0-rajapinnan kautta. Tämän reitin poistamisen jälkeen yhteys palautui. Voinko löytää mistään ohjeita pakottaakseni... WireGuard En voinut välttää näiden reittien luomista. Lisäksi en edes ymmärtänyt, oliko tämä OpenWRT:n vai... WireGuardKäyttämättä paljoa aikaa ongelman selvittämiseen, lisäsin yksinkertaisesti rivin molempien reitittimien ajastinpohjaiseen komentosarjaan, joka poisti tämän reitin:
route del 192.168.30.2
Yhteenveto
Täydellinen hylkääminen OpenVPN En ole vielä saavuttanut tätä, koska minun täytyy silloin tällöin muodostaa yhteys uuteen verkkoon kannettavalta tietokoneelta tai puhelimelta, ja gretap-laitteen asentaminen niille on yleensä mahdotonta. Tästä huolimatta olen kuitenkin saanut etulyöntiaseman tiedonsiirtonopeudessa asuntojen välillä, ja esimerkiksi VNC:n käyttö on nyt vaivatonta. Ping on hieman laskenut, mutta siitä on tullut vakaampi:
Käytettäessä 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
Käytettäessä 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
Siihen vaikuttaa eniten korkea ping VPS:ään, joka on noin 61.5 ms
Nopeus on kuitenkin noussut merkittävästi. Joten reititinpalvelimen omaavassa asunnossa internet-yhteyden nopeus on 30 Mbps ja muissa asunnoissa 5 Mbps. Lisäksi käytön aikana OpenVPN En pystynyt saavuttamaan iperf-lukemien mukaan yli 3,8 Mbps:n tiedonsiirtonopeutta verkkojen välillä, vaikka WireGuard "pumppasi" sen samaan 5 Mbit/s nopeuteen.
kokoonpano WireGuard VPS:llä[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Tähyillä]
Julkinen avain = <VPN_1_MS_JULKINEN_AVAIN>
SallitutIP: t = 192.168.30.2/32
[Tähyillä]
Julkinen avain = <VPN_2_MK2_JULKINEN_AVAIN>
SallitutIP: t = 192.168.30.3/32
[Tähyillä]
Julkinen avain = <VPN_2_MK3_JULKINEN_AVAIN>
SallitutIP: t = 192.168.30.4/32
kokoonpano WireGuard MS:ssä (lisätty tiedostoon /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'
kokoonpano WireGuard MK2:lla (lisätty tiedostoon /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'
kokoonpano WireGuard MK3:lla (lisätty tiedostoon /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'
Toisen tason VPN:n kuvatuissa kokoonpanoissa ilmoitan asiakkaille WireGuard Portti 51821. Tämän ei pitäisi olla tarpeen, koska asiakas muodostaa yhteyden mistä tahansa vapaasta, etuoikeuttamattomasta portista, mutta tein sen tällä tavalla, jotta voisin estää kaikki saapuvat yhteydet kaikkien reitittimien wg0-rajapintoihin, lukuun ottamatta saapuvia UDP-yhteyksiä porttiin 51821.
Toivon, että artikkelista on hyötyä jollekin.
PS. Haluan myös jakaa skriptini, joka lähettää minulle PUSH-ilmoituksen puhelimeeni WirePusher-sovelluksessa, kun verkkooni ilmestyy uusi laite. Tässä linkki käsikirjoitukseen: .
PÄIVITTÄÄ: kokoonpano OpenVPN-palvelimet ja asiakkaat
OpenVPN-palvelin
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-asiakas
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 Käytin easy-rsaa varmenteiden luomiseen.
Lähde: will.com
