Geografikoki urrun dauden hiru apartamentutan sareak konbinatzearen esperientzia partekatu nahiko nuke, eta horietako bakoitzak OpenWRT bideratzaileak atebide gisa erabiltzen ditu sare komun batean. L3 azpisareen bideraketarekin eta L2 zubiarekin sareak konbinatzeko metodo bat aukeratzerakoan, sareko nodo guztiak azpisare berean egongo direnean, bigarren metodoari lehentasuna eman zitzaion, konfiguratzeko zailagoa dena, baina aukera handiagoak ematen baititu. Wake-on-Lan eta DLNA sortzen ari diren sarean teknologien erabilera gardena aurreikusi zen.
1. zatia: Aurrekariak
Hasieran zeregin hau gauzatzeko aukeratu zen protokoloa OpenVPN, lehenik eta behin, zubira arazorik gabe gehi daitekeen txorrota-gailu bat sor dezakeelako, eta bigarrenik, OpenVPN TCP onartzen du, eta hori ere garrantzitsua zen, apartamentuetako batek ere ez baitzuen IP helbide dedikaturik. Ezin nuen STUN erabili, nire ISPak, arrazoiren batengatik, bere sareetatik sartzen diren UDP konexioak blokeatzen baititu. TCPk VPN zerbitzariaren portua alokatutako VPSra SSH erabiliz birbidaltzeko aukera eman zidan. Ikuspegi honek gainkarga handia sortzen duen arren, datuak bikoitzki enkriptatuta daudenez, ez nuen VPSa nire sare pribatuan integratu nahi, hirugarrenek haren gaineko kontrola lortzeko arriskua baitzegoen. Beraz, etxeko sarean horrelako gailu bat edukitzea oso desiragarria ez zen, beraz, segurtasunagatik gainkarga handia ordaintzea erabaki nuen.
Zerbitzaria zabaltzeko asmoa nuen bideratzailearen portua birbidaltzeko, sshtunnel programa erabili nuen. Ez dut bere konfigurazioaren xehetasunetan sartuko, nahiko erraza baita. Bere helburua bideratzailetik VPSra 1194 TCP portua birbidaltzea zela aipatuko dut. Ondoren, zerbitzaria konfiguratu nuen. OpenVPN tap0 gailuan, br-lan zubira konektatuta zegoena. Nire ordenagailu eramangarritik sortu berri zen zerbitzarirako konexioa probatu ondoren, argi geratu zen portuen birbidaltze ideiak funtzionatu zuela, eta nire ordenagailu eramangarria bideratzailearen sareko kide bihurtu zela, fisikoki sareko parte ez izan arren.
Geratzen zen gauza bakarra IP helbideak apartamentu ezberdinetan banatzea zen, gatazkarik egon ez zedin, eta bideratzaileak konfiguratzea bezala... OpenVPN-bezeroak.
Bideratzaileen IP helbide eta DHCP zerbitzari barruti hauek hautatu dira:
- 192.168.10.1 sortarekin 192.168.10.2 - 192.168.10.80 zerbitzariarentzat
- 192.168.10.100 sortarekin 192.168.10.101 - 192.168.10.149 2. zenbakiko apartamentuko bideratzailearentzat
- 192.168.10.150 sortarekin 192.168.10.151 - 192.168.10.199 3. zenbakiko apartamentuko bideratzailearentzat
Helbide hauek bezeroen bideratzaileei esleitzea ere beharrezkoa zen. OpenVPN-zerbitzaria, lerro hau bere konfigurazioari gehituz:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0eta lerro hauek gehituz /etc/openvpn/ipp.txt fitxategian:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
non flat1_id eta flat2_id konektatzeko ziurtagiriak sortzerakoan zehaztutako gailu-izenak diren OpenVPN
Ondoren, bideratzaileak konfiguratu ziren OpenVPN- bezeroak, bietako tap0 gailuak br-lan zubira gehitu ziren. Une horretan, dena ondo zirudien, hiru sareek elkar ikusi eta unitate bakar gisa funtziona baitezakete. Hala ere, xehetasun desatsegin bat agertu zen: batzuetan gailuek IP helbide bat jasotzen zuten bideratzaile okerretik, eta horrek dakartzan ondorio guztiekin. Arrazoiren batengatik, apartamentu bateko bideratzaileak ez zuen DHCPDISCOVER-i garaiz erantzuten, eta gailuak helbide okerra jaso zuen. Konturatu nintzen eskaera horiek bideratzaile bakoitzeko tap0-n iragazi behar nituela, baina azkenean, iptables-ek ezin du gailu batekin funtzionatu zubi baten parte bada, beraz, ebtables erabili behar izan nuen. Zoritxarrez, nire firmwareak ez zuen barne hartzen, beraz, gailu bakoitzerako irudiak berreraiki behar izan nituen. Hori egin eta lerro hauek /etc/rc.local fitxategian gehitu ondoren bideratzaile bakoitzean, arazoa konpondu zen:
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
Konfigurazio honek hiru urte iraun zuen.
2. zatia: Ezagutzen WireGuard
Azkenaldian, gero eta gehiago hitz egiten da Interneten honi buruz WireGuard, konfigurazio erraztasuna, transferentzia abiadura handia, ping baxua eta segurtasun konparagarria miresten. Informazio gehiago bilatu ondoren, ez du ez zubi kideen ez TCP protokoloen euskarririk onartzen, eta horrek alternatibarik ez zegoela pentsarazi zidan. OpenVPN niretzat oraindik ez dago hor. Beraz, ezagutzea atzeratu dut WireGuard.
Duela egun batzuk, ITrekin lotutako baliabideen bidez zabaldu zen berria, modu batera edo bestera, WireGuard azkenean kernelean sartuko da Linux, 5.6 bertsiotik hasita. Albiste artikuluak, beti bezala, goraipatu ziren WireGuardBerriro ere murgildu nintzen zahar ona ordezkatzeko moduak bilatzen OpenVPNOraingoan topo egin dut . GRE erabiliz L3n Ethernet tunel bat sortzeari buruz hitz egin zuen. Artikulu honek itxaropena eman zidan. Ez zegoen argi zer egin UDP protokoloarekin. Bilaketak SSH tunel batekin batera UDP ataka birbidaltzeko socat erabiltzeari buruzko artikuluetara eraman ninduen, hala ere, ikuspegi honek konexio bakarrean soilik funtzionatzen duela adierazi zuten, hau da, hainbat VPN bezeroren lana ezinezkoa izango zela. VPN zerbitzari bat VPS batean instalatzea eta bezeroentzako GRE konfiguratzea bururatu zitzaidan, baina ondorioztatu zenez, GREk ez du enkriptatzea onartzen, eta horrek hirugarrenek zerbitzarirako sarbidea lortzen badute. , nire sareen arteko trafiko guztia haien esku egongo da, eta hori ez zitzaidan batere komeni.
Berriro ere, enkriptazio erredundantearen aldeko erabakia hartu zen, VPN bidez VPN bidez erabiliz eskema hau erabiliz:
XNUMX. mailako VPN:
VPS da zerbitzaria 192.168.30.1 barne helbidea duena
MS da bezeroa Barne helbidea 192.168.30.2 duen VPS
MK2 da bezeroa Barne helbidea 192.168.30.3 duen VPS
MK3 da bezeroa Barne helbidea 192.168.30.4 duen VPS
Bigarren mailako VPN:
MS da zerbitzaria kanpoko helbidearekin 192.168.30.2 eta barneko 192.168.31.1
MK2 da bezeroa MS 192.168.30.2 helbidearekin eta barne IP 192.168.31.2 du
MK3 da bezeroa MS 192.168.30.2 helbidearekin eta barne IP 192.168.31.3 du
* MS - bideratzaile-zerbitzaria 1. apartamentuan, MK2 - bideratzailea 2 apartamentuan, MK3 - bideratzailea 3. apartamentuan
* Gailuaren konfigurazioak artikuluaren amaierako spoiler-ean argitaratzen dira.
Beraz, ping-ak 192.168.31.0/24 sareko nodoen artean exekutatzen ari dira, GRE tunel bat konfiguratzera pasatzeko garaia da. Horren aurretik, bideratzaileetarako sarbidea ez galtzeko, merezi du SSH tunelak ezartzea 22. ataka VPSra birbidaltzeko, horrela, adibidez, 10022. apartamentuko bideratzailea VPSaren 2 atakan eskuragarri egongo da, eta 11122 apartamentuko bideratzailea 3 atakan XNUMX. apartamentuko bideratzailean eskuragarri egongo da. Hobe da birbidaltzea sshtunnel bera erabiliz konfiguratzea, tunela berreskuratuko baitu huts egiten badu.
Tunela konfiguratuta dago, birbidaltutako atakaren bidez SSHra konekta zaitezke:
ssh root@МОЙ_VPS -p 10022Ondoren, desgaitu beharko zenuke OpenVPN:
/etc/init.d/openvpn stopOrain konfigura dezagun GRE tunel bat 2 apartamentuko bideratzailean:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Eta gehitu sortutako interfazea zubian:
brctl addif br-lan grelan0
Egin dezagun antzeko prozedura bat zerbitzariaren bideratzailean:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Era berean, gehitu sortutako interfazea zubiari:
brctl addif br-lan grelan0
une honetatik hasita, ping-ak arrakastaz joaten hasten dira sare berrira eta ni, pozik, kafea edatera joaten naiz. Ondoren, sarearen beste muturrean nola funtzionatzen duen ebaluatzeko, 2. apartamentuko ordenagailuetako batean SSH egiten saiatzen naiz, baina ssh bezeroa izoztu egiten da pasahitzik eskatu gabe. Ordenagailu honekin 22 atakan telnet bidez konektatzen saiatzen ari naiz eta konexioa ezartzen ari dela uler dezakedan lerro bat ikusten dut, SSH zerbitzariak erantzuten ari dela, baina arrazoiren batengatik ez dit saioa hasteko eskatzen. urtean.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
VNC bidez konektatzen saiatzen ari naiz eta pantaila beltz bat ikusten ari naiz. Nire burua konbentzitzen dut arazoa urruneko ordenagailuarekin dagoela, apartamentu honetatik bideratzailera erraz konektatu naitekeelako barne helbidea erabiliz. Hala ere, ordenagailu honen SSHra bideratzailearen bidez konektatzea erabakitzen dut eta harrituta nago konexioa arrakastatsua dela eta urruneko ordenagailuak nahiko normal funtzionatzen duela, baina ezin da nire ordenagailura konektatu.
Grelan0 gailua zubitik atera eta exekutatzen dut OpenVPN 2. apartamentuko bideratzailean, sareak berriro behar bezala funtzionatzen zuela eta konexioak ez zirela eten baieztatu nuen. Bilatzen ari nintzela, jendea arazo berdinez kexatzen ari zen foroetan aurkitu nuen, eta MTUa igotzeko aholkatzen zieten. Esan bezain laster eginda. Hala ere, MTUa nahikoa altu ezarri arte —7000 gretap gailuetarako—, TCP konexioak galdu edo transferentzia-abiadura baxuak izan nituen. Gretap-erako MTU handia denez, konexioetarako MTUa... WireGuard Lehenengo eta bigarren mailak 8000 eta 7500ean ezarri ziren, hurrenez hurren.
3. apartamentuko bideratzailean antzeko konfigurazio bat egin nuen, desberdintasun bakarra zerbitzariaren bideratzaileari grelan1 izeneko bigarren gretap interfazea gehitu zitzaiola, br-lan zubiari ere gehitu zitzaiola.
Dena dabil. Orain gretap muntaia abiaraztean jar dezakezu. Honetarako:
Lerro hauek /etc/rc.local-en jarri ditut 2. apartamentuko bideratzailean:
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
Hau gehitu da /etc/rc.local 3. apartamentuko bideratzailean:
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
Eta zerbitzariaren bideratzailean:
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
Bezeroen bideratzaileak berrabiarazi ondoren, arrazoiren batengatik ez zirela zerbitzarira konektatzen konturatu nintzen. Haien SSHra konektatu ondoren (eskerrak, aurretik sshtunnel konfiguratu nuen horretarako), konturatu nintzen... WireGuard Arrazoiren batengatik, amaierako punturako ibilbide bat sortzen du, baina okerra da. Adibidez, 192.168.30.2 helbiderako, ibilbide-taulak pppoe-wan interfazearen bidezko ibilbide bat zehaztu zuen, hau da, interneten bidez, nahiz eta bertara iristeko ibilbidea wg0 interfazearen bidez zuzendu behar zen. Ibilbide hau ezabatu ondoren, konexioa berrezarri zen. Aurki al ditzaket inon argibideak nola behartu jakiteko? WireGuard Ezin izan nituen ibilbide hauek sortzea saihestu. Gainera, ez nuen ulertzen ea hau OpenWRT-ren edo -ren ezaugarri bat zen. WireGuardArazoa ulertzen denbora askorik eman gabe, bi bideratzaileetako tenporizadorean oinarritutako script-ari lerro bat gehitu nion ibilbide hau ezabatuz:
route del 192.168.30.2
Laburbiltzea
Erabateko ukapena OpenVPN Oraindik ez dut hau lortu, noizean behin sare berri batera konektatu behar izaten baitut ordenagailu eramangarri edo telefono batetik, eta normalean ezinezkoa baita gretap gailu bat horietan konfiguratzea. Hala ere, hori gorabehera, abantaila bat lortu dut apartamentuen arteko datuen transferentzia abiaduran, eta VNC erabiltzea, adibidez, orain arazorik gabea da. Ping-a apur bat jaitsi da, baina egonkorragoa bihurtu da:
Noiz erabiliz 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
Noiz erabiliz 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
VPSaren ping altuak eragin handiagoa du, hau da, 61.5 ms gutxi gorabehera
Hala ere, abiadura nabarmen handitu da. Beraz, router-zerbitzaria duen apartamentuan, 30 Mbps-ko internet konexio abiadura dut, eta beste apartamentuetan 5 Mbps-koa. Gainera, erabiltzean... OpenVPN iperf irakurketen arabera, ezin izan dut sareen arteko 3,8 Mbps baino handiagoa den datu-transferentzia abiadura lortu, bitartean WireGuard 5 Mbit/seg-ko abiadura berera "ponpatu" zuen.
konfigurazioa WireGuard VPS-n[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Parekidea]
Giltza Publikoa = <VPN_1_MS_GILTZA_PUBLIKOA>
Baimendutako IPak = 192.168.30.2/32
[Parekidea]
Giltza Publikoa = <VPN_2_MK2_GILTZA_PUBLIKOA>
Baimendutako IPak = 192.168.30.3/32
[Parekidea]
Giltza Publikoa = <VPN_2_MK3_GILTZA_PUBLIKOA>
Baimendutako IPak = 192.168.30.4/32
konfigurazioa WireGuard MS-n (/etc/config/network-era gehituta)
#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'
konfigurazioa WireGuard MK2-n (/etc/config/network-era gehituta)
#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'
konfigurazioa WireGuard MK3-n (/etc/config/network-era gehituta)
#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'
Bigarren mailako VPNrako deskribatutako konfigurazioetan, bezeroei adierazten diet WireGuard 51821 portua. Hau ez luke beharrezkoa izan behar, bezeroak edozein portu libre eta pribilegiorik gabekotik konexioa ezarriko baitu, baina horrela egin nuen bideratzaile guztien wg0 interfazeetan sartzen diren konexio guztiak ukatu ahal izateko, 51821 porturako sarrerako UDP konexioak izan ezik.
Espero dut artikulua norbaitentzat erabilgarria izatea.
PS Gainera, nire telefonora PUSH jakinarazpena bidaltzen didan gidoia partekatu nahi dut WirePusher aplikazioan nire sarean gailu berri bat agertzen denean. Hona hemen gidoiaren esteka: .
UPDATE: konfigurazioa OpenVPN-zerbitzariak eta bezeroak
OpenVPN-zerbitzaria
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-bezeroa
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 Ziurtagiriak sortzeko easy-rsa erabili dut
Iturria: www.habr.com
