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
Itifaki iliyochaguliwa kutekeleza kazi hii hapo awali ilikuwa OpenVPN, kwa sababu, kwanza, inaweza kuunda kifaa cha kugonga ambacho kinaweza kuongezwa kwenye daraja bila matatizo yoyote, na pili, OpenVPN Inaunga mkono TCP, ambayo pia ilikuwa muhimu, kwani hakuna hata moja ya vyumba vilivyokuwa na anwani maalum ya IP. Sikuweza kutumia STUN kwa sababu Mtoa Huduma wangu wa Intaneti, kwa sababu fulani, huzuia miunganisho inayoingia ya UDP kutoka kwa mitandao yake. TCP iliniruhusu kusambaza lango la seva ya VPN kwenye VPS iliyokodishwa kwa kutumia SSH. Ingawa mbinu hii inaunda gharama kubwa ya uendeshaji, kwani data imesimbwa mara mbili, sikutaka kuunganisha VPS kwenye mtandao wangu wa kibinafsi, kwani kulikuwa na hatari ya watu wengine kupata udhibiti juu yake. Kwa hivyo, kuwa na kifaa kama hicho kwenye mtandao wangu wa nyumbani hakukuwa kuzuri sana, kwa hivyo niliamua kulipa gharama kubwa ya uendeshaji kwa usalama.
Ili kusambaza lango kwenye kipanga njia ambapo seva ilipangwa kusambazwa, nilitumia programu ya sshtunnel. Sitaingia katika maelezo ya usanidi wake—ni rahisi sana. Nitagundua tu kwamba kusudi lake lilikuwa kusambaza lango la TCP 1194 kutoka kipanga njia hadi VPS. Kisha, nilisanidi seva. OpenVPN Kwenye kifaa cha tap0, ambacho kilikuwa kimeunganishwa na daraja la br-lan. Baada ya kujaribu muunganisho wa seva mpya iliyoundwa kutoka kwa kompyuta yangu ya mkononi, ikawa wazi kwamba wazo la kusambaza mlango lilikuwa limefanya kazi, na kompyuta yangu ya mkononi ilikuwa mwanachama wa mtandao wa kipanga njia, ingawa haikuwa sehemu yake kimwili.
Kitu pekee kilichobaki kufanya ni kusambaza anwani za IP katika vyumba tofauti ili zisigongane na kusanidi ruta kama OpenVPN-wateja.
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
Pia ilikuwa muhimu kugawa anwani hizi kwa ruta za mteja. OpenVPN-server, kwa kuongeza mstari ufuatao 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 kuunda vyeti vya kuunganisha kwenye OpenVPN
Kisha, ruta zilisanidiwa OpenVPN- wateja, vifaa vya tap0 kwenye zote mbili viliongezwa kwenye daraja la br-lan. Katika hatua hii, kila kitu kilionekana sawa, kwani mitandao yote mitatu ingeweza kuonana na kufanya kazi kama kitengo kimoja. Hata hivyo, maelezo yasiyofurahisha yaliibuka: wakati mwingine vifaa vingepokea anwani ya IP kutoka kwa kipanga njia kisichofaa, na matokeo yote yaliyofuata. Kwa sababu fulani, kipanga njia katika moja ya vyumba vilishindwa kujibu DHCPDISCOVER kwa wakati, na kifaa kilipokea anwani isiyofaa. Niligundua kuwa nilihitaji kuchuja maombi kama hayo katika tap0 kwenye kila kipanga njia, lakini kama ilivyotokea, iptables haziwezi kufanya kazi na kifaa ikiwa ni sehemu ya daraja, kwa hivyo nilihitaji kutumia ebtables. Kwa bahati mbaya, programu yangu ya kudhibiti haikuijumuisha, kwa hivyo ilinibidi nijenge upya picha za kila kifaa. Baada ya kufanya hivi na kuongeza mistari ifuatayo kwa /etc/rc.local kwenye 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: Kujua WireGuard
Hivi majuzi, kumekuwa na mazungumzo yanayoongezeka kwenye mtandao kuhusu WireGuard, nikivutiwa na urahisi wake wa usanidi, kasi ya juu ya uhamisho, ping ya chini na usalama sawa. Utafutaji wa taarifa zaidi kuihusu ulionyesha kuwa haiungi mkono usaidizi wa mwanachama wa daraja au itifaki ya TCP, jambo ambalo lilinifanya niamini kwamba hakukuwa na njia mbadala. OpenVPN kwangu bado haipo. Kwa hivyo niliacha kujua WireGuard.
Siku chache zilizopita, habari zilienea kupitia rasilimali zinazohusiana na TEHAMA kwa njia moja au nyingine kwamba WireGuard hatimaye itajumuishwa kwenye kiini Linux, kuanzia na toleo la 5.6. Makala za habari, kama kawaida, zilisifiwa WireGuardNilijitosa tena katika kutafuta njia za kuchukua nafasi ya zamani nzuri OpenVPNWakati huu nilikutana na . 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 unapaswa kuzima 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 kutoka darajani na kukiendesha OpenVPN Kwenye kipanga njia katika ghorofa ya 2, nilithibitisha kwamba mtandao ulikuwa unafanya kazi vizuri tena na miunganisho haikuwa ikipungua. Nilipokuwa nikitafuta, nilikutana na majukwaa ambapo watu walikuwa wakilalamika kuhusu masuala yaleyale, na ambapo walishauriwa kuongeza MTU. Muda si mrefu uliopita. Hata hivyo, hadi MTU ilipowekwa juu vya kutosha—7000 kwa vifaa vya gretap—nilipata miunganisho ya TCP iliyopungua au kasi ya chini ya uhamisho. Kwa sababu ya MTU ya juu kwa gretap, MTU ya miunganisho. WireGuard Ngazi ya kwanza na ya pili ziliwekwa katika 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 kuwasha upya vipanga njia vya mteja, niligundua kwamba kwa sababu fulani havikuwa vikiunganishwa kwenye seva. Baada ya kuunganisha kwenye SSH yao (kwa bahati nzuri, hapo awali nilikuwa nimesanidi sshtunnel kwa hili), niligundua hilo WireGuard Kwa sababu fulani, huunda njia ya mwisho, lakini si sahihi. Kwa mfano, kwa 192.168.30.2, jedwali la njia lilibainisha njia kupitia kiolesura cha pppoe-wan, yaani, kupitia mtandao, ingawa njia ya kuelekea huko ilipaswa kuelekezwa kupitia kiolesura cha wg0. Baada ya kufuta njia hii, muunganisho ulirejeshwa. Je, ninaweza kupata maelekezo popote kuhusu jinsi ya kulazimisha? WireGuard Sikuweza kuepuka kuunda njia hizi. Zaidi ya hayo, sikuelewa hata kama hii ilikuwa kipengele cha OpenWRT au cha WireGuardBila kutumia muda mwingi kutafuta tatizo, niliongeza tu mstari kwenye hati ya kitanzi cha kipima muda kwenye ruta zote mbili zilizofuta njia hii:
route del 192.168.30.2
Muhtasari wa
Kukataliwa kabisa OpenVPN Bado sijafanikisha hili, kwani mara kwa mara ninahitaji kuunganisha kwenye mtandao mpya kutoka kwa kompyuta ya mkononi au simu, na kuweka kifaa cha gretap juu yake kwa ujumla haiwezekani. Hata hivyo, licha ya hili, nimepata faida katika kasi ya uhamishaji data kati ya vyumba, na kutumia VNC, kwa mfano, sasa hakuna usumbufu. Ping imepungua kidogo lakini imekuwa imara zaidi:
Wakati wa kutumia 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
Wakati wa kutumia 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 sana. Kwa hivyo, katika ghorofa yenye seva ya kipanga njia, nina kasi ya muunganisho wa intaneti ya 30 Mbps, na katika vyumba vingine ni 5 Mbps. Zaidi ya hayo, wakati wa matumizi OpenVPN Sikuweza kufikia kasi ya uhamishaji data kati ya mitandao zaidi ya 3,8 Mbps kulingana na usomaji wa iperf, huku WireGuard "aliisukuma" hadi Mbit/sekunde 5 sawa.
Usanidi WireGuard kwenye VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Rika]
Ufunguo wa Umma = <VPN_1_MS_PUBLIC_KEY>
RuhusaIPs = 192.168.30.2/32
[Rika]
Ufunguo wa Umma = <VPN_2_MK2_PUBLIC_KEY>
RuhusaIPs = 192.168.30.3/32
[Rika]
Ufunguo wa Umma = <VPN_2_MK3_PUBLIC_KEY>
RuhusaIPs = 192.168.30.4/32
Usanidi WireGuard kwenye MS (imeongezwa kwenye /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 WireGuard kwenye MK2 (imeongezwa kwenye /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 WireGuard kwenye MK3 (imeongezwa kwenye /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 mipangilio iliyoelezwa ya VPN ya kiwango cha pili, ninawaonyesha wateja WireGuard Lango 51821. Hili halipaswi kuwa muhimu, kwani mteja ataanzisha muunganisho kutoka kwa lango lolote lisilo na upendeleo, lakini nilifanya hivi ili niweze kukataa miunganisho yote inayoingia kwenye violesura vya wg0 vya ruta zote, isipokuwa miunganisho ya UDP inayoingia kwenye lango 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: Usanidi OpenVPN-seva na wateja
OpenVPN- seva
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-mteja
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
