Ningependa kushiriki uzoefu wangu wa kuchanganya mitandao katika vyumba vitatu vya mbali kijiografia, ambavyo kila moja hutumia ruta zilizo na OpenWRT kama lango, kwenye mtandao mmoja wa kawaida. Wakati wa kuchagua njia ya kuchanganya mitandao kati ya L3 na uelekezaji wa subnet na L2 na madaraja, wakati nodi zote za mtandao zitakuwa kwenye subnet moja, upendeleo ulipewa njia ya pili, ambayo ni ngumu zaidi kusanidi, lakini inatoa fursa zaidi, kwa kuwa uwazi. matumizi ya teknolojia yalipangwa katika mtandao iliyoundwa Wake-on-Lan na DLNA.
Sehemu ya 1: Usuli
OpenVPN ilichaguliwa hapo awali kama itifaki ya kutekeleza kazi hii, kwani, kwanza, inaweza kuunda kifaa cha bomba ambacho kinaweza kuongezwa kwenye daraja bila shida yoyote, na pili, OpenVPN inasaidia operesheni juu ya itifaki ya TCP, ambayo pia ilikuwa muhimu, kwa sababu. hakuna vyumba vilivyokuwa na anwani maalum ya IP, na sikuweza kutumia STUN, kwa sababu kwa sababu fulani ISP yangu inazuia miunganisho ya UDP inayoingia kutoka kwa mitandao yao, wakati itifaki ya TCP iliniruhusu kusambaza bandari ya seva ya VPN kwenye VPS iliyokodishwa kwa kutumia SSH. Ndio, njia hii inatoa mzigo mkubwa, kwani data imesimbwa mara mbili, lakini sikutaka kuanzisha VPS kwenye mtandao wangu wa kibinafsi, kwani bado kulikuwa na hatari ya watu wengine kupata udhibiti juu yake, kwa hivyo, kuwa na kifaa kama hicho. kwenye mtandao wa nyumbani ilikuwa mbaya sana na iliamuliwa kulipa kwa ajili ya usalama na uendeshaji mkubwa.
Ili kusambaza bandari kwenye router ambayo ilipangwa kupeleka seva, programu ya sshtunnel ilitumiwa. Sitaelezea ugumu wa usanidi wake - hii inafanywa kwa urahisi kabisa, ninaona tu kuwa kazi yake ilikuwa kusambaza bandari ya TCP 1194 kutoka kwa router hadi VPS. Kisha, seva ya OpenVPN ilisanidiwa kwenye kifaa cha tap0, ambacho kiliunganishwa kwenye daraja la br-lan. Baada ya kuangalia unganisho kwa seva mpya iliyoundwa kutoka kwa kompyuta ndogo, ikawa wazi kuwa wazo la usambazaji wa bandari lilijihalalisha na kompyuta yangu ndogo ikawa mwanachama wa mtandao wa router, ingawa haikuwa ndani yake.
Jambo hilo lilibaki kuwa dogo: ilihitajika kusambaza anwani za IP katika vyumba tofauti ili zisipingane na kusanidi ruta kama wateja wa OpenVPN.
Anwani zifuatazo za IP za kipanga njia na safu za seva za DHCP zilichaguliwa:
- 192.168.10.1 na masafa 192.168.10.2 - 192.168.10.80 kwa seva
- 192.168.10.100 na masafa 192.168.10.101 - 192.168.10.149 kwa router katika ghorofa No
- 192.168.10.150 na masafa 192.168.10.151 - 192.168.10.199 kwa router katika ghorofa No
Ilihitajika pia kupeana anwani hizi haswa kwa vipanga njia vya mteja vya seva ya OpenVPN kwa kuongeza laini kwenye usanidi wake:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0na kuongeza mistari ifuatayo kwa /etc/openvpn/ipp.txt faili:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
ambapo flat1_id na flat2_id ni majina ya kifaa yaliyobainishwa wakati wa kuzalisha vyeti vya kuunganisha kwa OpenVPN
Kisha, wateja wa OpenVPN walisanidiwa kwenye vipanga njia, vifaa vya tap0 kwenye zote mbili viliongezwa kwenye daraja la br-lan. Katika hatua hii, kila kitu kilionekana kuwa sawa, kwani mitandao yote mitatu inaonana na inafanya kazi kwa ujumla. Hata hivyo, maelezo yasiyo ya kupendeza sana yaligeuka: wakati mwingine vifaa vinaweza kupata anwani ya IP si kutoka kwa router yao, na matokeo yote yanayofuata. Kwa sababu fulani, router katika moja ya vyumba hakuwa na muda wa kujibu DHCPDISCOVER kwa wakati na kifaa kilipokea anwani isiyo sahihi. Niligundua kuwa ninahitaji kuchuja maombi kama haya kwenye tap0 kwenye kila ruta, lakini kama ilivyotokea, iptables haziwezi kufanya kazi na kifaa ikiwa ni sehemu ya daraja na ebtables inapaswa kuniokoa. Kwa majuto yangu, haikuwa kwenye firmware yangu na ilibidi nijenge tena picha kwa kila kifaa. Kwa kufanya hivyo na kuongeza mistari hii kwa /etc/rc.local ya kila kipanga njia, tatizo lilitatuliwa:
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
Usanidi huu ulidumu kwa miaka mitatu.
Sehemu ya 2: Kuanzisha WireGuard
Hivi majuzi, Mtandao umekuwa ukizungumza zaidi juu ya WireGuard, ikivutia unyenyekevu wa usanidi wake, kasi ya juu ya uhamishaji, ping ya chini na usalama sawa. Kutafuta habari zaidi kuihusu kulifanya iwe wazi kuwa hakuna kazi kama mshiriki wa daraja au kufanya kazi kwenye itifaki ya TCP inayoungwa mkono nayo, ambayo ilinifanya nifikirie kuwa bado hakuna njia mbadala za OpenVPN kwangu. Kwa hivyo niliahirisha kufahamiana na WireGuard.
Siku chache zilizopita, habari zilienea kupitia nyenzo kwa njia moja au nyingine zinazohusiana na IT kwamba WireGuard hatimaye itajumuishwa kwenye kinu cha Linux, kuanzia toleo la 5.6. Nakala za habari, kama kawaida, zilisifu WireGuard. Nilijiingiza tena katika utaftaji wa njia za kuchukua nafasi ya OpenVPN nzuri ya zamani. Wakati huu nilikimbilia . Ilizungumza juu ya kuunda handaki ya Ethernet juu ya L3 kwa kutumia GRE. Makala hii ilinipa tumaini. Ilibakia haijulikani nini cha kufanya na itifaki ya UDP. Kutafuta kuliniongoza kwa nakala kuhusu kutumia socat kwa kushirikiana na handaki ya SSH kusambaza bandari ya UDP, hata hivyo, walibaini kuwa njia hii inafanya kazi tu katika hali ya unganisho moja, ambayo inamaanisha kuwa wateja wengi wa VPN hawatawezekana. Nilikuja na wazo la kusanidi seva ya VPN kwenye VPS, na kusanidi GRE kwa wateja, lakini kama ilivyotokea, GRE haiungi mkono usimbuaji, ambayo itasababisha ukweli kwamba ikiwa watu wa tatu wanapata seva, trafiki yote kati ya mitandao yangu iko mikononi mwao ambayo haikunifaa hata kidogo.
Tena, uamuzi ulifanywa kwa niaba ya usimbuaji tena, kwa kutumia VPN juu ya VPN kulingana na mpango ufuatao:
Tabaka la XNUMX VPN:
VPS ni seva na anwani ya ndani 192.168.30.1
MC ni mteja VPS yenye anwani ya ndani 192.168.30.2
MK2 ni mteja VPS yenye anwani ya ndani 192.168.30.3
MK3 ni mteja VPS yenye anwani ya ndani 192.168.30.4
Tabaka la XNUMX VPN:
MC ni seva yenye anwani ya nje 192.168.30.2 na ya ndani 192.168.31.1
MK2 ni mteja MC yenye anwani 192.168.30.2 na ina IP ya ndani ya 192.168.31.2
MK3 ni mteja MC yenye anwani 192.168.30.2 na ina IP ya ndani ya 192.168.31.3
* MC - seva ya router katika ghorofa 1, MK2 - router katika ghorofa 2, MK3 - router katika ghorofa 3
* Mipangilio ya kifaa huchapishwa kwenye kiharibu mwishoni mwa kifungu.
Na hivyo, pings kati ya nodes ya mtandao 192.168.31.0/24 kwenda, ni wakati wa kuendelea na kuanzisha GRE handaki. Kabla ya hapo, ili usipoteze ufikiaji wa ruta, inafaa kusanidi vichungi vya SSH kupeleka bandari 22 kwa VPS, ili, kwa mfano, router kutoka ghorofa 10022 itapatikana kwenye bandari 2 ya VPS, na a. router kutoka ghorofa 11122 itapatikana kwenye bandari 3 ya VPS router kutoka ghorofa XNUMX. Ni bora kusanidi usambazaji na sshtunnel sawa, kwa kuwa itarejesha handaki ikiwa itaanguka.
Mtaro umesanidiwa, unaweza kuunganisha kwa SSH kupitia lango iliyosambazwa:
ssh root@МОЙ_VPS -p 10022Ifuatayo, zima OpenVPN:
/etc/init.d/openvpn stopSasa wacha tuanzishe handaki ya GRE kwenye kipanga njia kutoka ghorofa ya 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Na ongeza kiolesura kilichoundwa kwenye daraja:
brctl addif br-lan grelan0
Wacha tufanye utaratibu kama huo kwenye kipanga njia cha seva:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Na, pia, ongeza kiolesura kilichoundwa kwenye daraja:
brctl addif br-lan grelan0
kuanzia wakati huu, pings huanza kufanikiwa kwenda kwenye mtandao mpya na mimi, kwa kuridhika, kwenda kunywa kahawa. Halafu, ili kuona jinsi mtandao upande wa pili wa waya unavyofanya kazi, ninajaribu SSH kwenye moja ya kompyuta kwenye ghorofa 2, lakini mteja wa ssh hufungia bila kuniuliza nywila. Ninajaribu kuunganisha kwenye kompyuta hii kupitia telnet kwenye bandari 22 na kuona mstari ambao unaweza kuelewa kuwa uunganisho unaanzishwa, seva ya SSH inajibu, lakini kwa sababu fulani hainipi kuingia.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Ninajaribu kuunganishwa nayo kupitia VNC na naona skrini nyeusi. Ninajihakikishia kuwa jambo hilo liko kwenye kompyuta ya mbali, kwa sababu ninaweza kuunganisha kwa urahisi kwenye router kutoka ghorofa hii kwa kutumia anwani ya ndani. Walakini, ninaamua kuingiza SSH kwenye kompyuta hii kupitia kipanga njia na ninashangaa kupata kwamba muunganisho unafanikiwa na kompyuta ya mbali inafanya kazi vizuri lakini inashindwa kuunganishwa na kompyuta yangu pia.
Ninatoa kifaa cha grelan0 nje ya daraja na kuanza OpenVPN kwenye kipanga njia katika ghorofa ya 2 na hakikisha kuwa mtandao unafanya kazi vizuri tena na viunganisho havipunguki. Kutafuta nakutana na vikao ambapo watu wanalalamika kuhusu matatizo sawa, ambapo wanashauriwa kuinua MTU. Hakuna mapema kusema kuliko kufanya. Hata hivyo, hadi MTU ilipowekwa kwa thamani kubwa ya kutosha ya 7000 kwa vifaa vya gretap, miunganisho ya TCP iliyoshuka au uwasilishaji wa polepole ulionekana. Kwa sababu ya MTU ya juu ya gretap, MTU za miunganisho ya WireGuard ya ngazi ya kwanza na ya pili iliwekwa kuwa 8000 na 7500, mtawalia.
Nilifanya usanidi sawa kwenye kipanga njia kutoka ghorofa ya 3, na tofauti pekee ni kwamba kiolesura cha pili cha gretap kinachoitwa grelan1 kiliongezwa kwenye kipanga njia cha seva, ambacho pia kiliongezwa kwenye daraja la br-lan.
Kila kitu kinafanya kazi. Sasa unaweza kuweka mkusanyiko wa gretap kwenye upakiaji otomatiki. Kwa hii; kwa hili:
Imewekwa mistari hii ndani /etc/rc.local kwenye kipanga njia katika ghorofa ya 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
Imeongeza hii kwa /etc/rc.local kwenye kipanga njia katika ghorofa ya 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
Na kwenye kipanga njia cha seva:
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
Baada ya kuanzisha upya ruta za mteja, niligundua kuwa kwa sababu fulani hawakuunganisha kwenye seva. Kuunganisha kwa SSH yao (kwa bahati nzuri, hapo awali nilikuwa nimesanidi sshtunnel kwa hili), iligunduliwa kuwa WireGuard kwa sababu fulani huunda njia ya mwisho, wakati sio sahihi. Kwa hivyo, kwa 192.168.30.2, jedwali la njia lilibainishwa kwenye jedwali la njia kupitia kiolesura cha pppoe-wan, yaani, kupitia mtandao, ingawa njia ya kuelekea humo inapaswa kuelekezwa kupitia kiolesura cha wg0. Baada ya kufuta njia hii, muunganisho ulirejeshwa. Sikuweza kupata maagizo popote juu ya jinsi ya kulazimisha WireGuard kutounda njia hizi. Kwa kuongezea, sikuelewa hata ikiwa hii ni huduma ya OpenWRT, au ya WireGuard yenyewe. Bila kulazimika kushughulika na shida hii kwa muda mrefu, niliongeza tu kwa ruta zote mbili kwenye hati iliyofungwa na kipima saa, mstari ambao ulifuta njia hii:
route del 192.168.30.2
Muhtasari wa
Bado sijafanikiwa kukataliwa kabisa kwa OpenVPN, kwani wakati mwingine ninahitaji kuunganishwa na mtandao mpya kutoka kwa kompyuta ndogo au simu, na kuanzisha kifaa cha gretap juu yao kwa ujumla haiwezekani, lakini licha ya hili, nilipata faida katika uhamishaji wa data. kasi kati ya vyumba na, kwa mfano, kutumia VNC sio usumbufu tena. Ping ilipungua kidogo, lakini ikawa thabiti zaidi:
Unapotumia 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
Unapotumia 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
Inaathiriwa zaidi na ping ya juu kwa VPS ambayo ni takriban 61.5ms
Hata hivyo, kasi imeongezeka kwa kiasi kikubwa. Kwa hiyo, katika ghorofa yenye seva ya router, nina kasi ya uunganisho wa Mtandao wa 30 Mbps, na katika vyumba vingine, 5 Mbps. Wakati huo huo, nilipokuwa nikitumia OpenVPN, sikuweza kufikia kiwango cha uhamisho wa data kati ya mitandao ya zaidi ya 3,8 Mbps kulingana na iperf, wakati WireGuard "ilisukuma" hadi 5 Mbps sawa.
Usanidi wa WireGuard kwenye 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
Usanidi wa WireGuard kwenye MS (umeongezwa kwa /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'
Usanidi wa WireGuard kwenye MK2 (imeongezwa kwa /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'
Usanidi wa WireGuard kwenye MK3 (imeongezwa kwa /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'
Katika usanidi ulioelezewa wa VPN ya kiwango cha pili, ninataja bandari 51821 kwa wateja wa WireGuard. Kwa nadharia, hii sio lazima, kwa kuwa mteja ataanzisha muunganisho kutoka kwa bandari yoyote ya bure isiyo ya upendeleo, lakini niliifanya ili miunganisho yote inayoingia. inaweza kukataliwa kwenye miingiliano ya wg0 ya vipanga njia vyote, isipokuwa miunganisho ya UDP inayoingia kwenye bandari 51821.
Natumaini kwamba makala hiyo itakuwa na manufaa kwa mtu.
PS Pia, ninataka kushiriki hati yangu ambayo hunitumia arifa ya PUSH kwa simu yangu katika programu ya WirePusher wakati kifaa kipya kinapoonekana kwenye mtandao wangu. Hapa kuna kiunga cha hati: .
UPDATE: Seva ya OpenVPN na usanidi wa wateja
Seva ya OpenVPN
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-lzoMteja wa 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
Nilitumia rahisi-rsa kutoa vyeti.
Chanzo: mapenzi.com