Gusto kong ibahagi ang aking karanasan sa pagsasama-sama ng mga network sa tatlong apartment na malayo sa heograpiya, bawat isa ay gumagamit ng mga router na may OpenWRT bilang gateway, sa isang karaniwang network. Kapag pumipili ng isang paraan para sa pagsasama-sama ng mga network sa pagitan ng L3 na may subnet routing at L2 na may bridging, kapag ang lahat ng mga network node ay nasa parehong subnet, ang kagustuhan ay ibinigay sa pangalawang paraan, na mas mahirap i-configure, ngunit nagbibigay ng mas maraming pagkakataon, dahil transparent ang paggamit ng mga teknolohiya ay binalak sa nilikhang network na Wake-on-Lan at DLNA.
Bahagi 1: Background
Ang protokol na pinili upang ipatupad ang gawaing ito ay noong una OpenVPN, dahil, una, makakagawa ito ng tap device na maaaring idagdag sa tulay nang walang anumang problema, at pangalawa, OpenVPN Sinusuportahan nito ang TCP, na mahalaga rin, dahil wala sa mga apartment ang may dedicated IP address. Hindi ko magamit ang STUN dahil sa hindi malamang dahilan, hinaharangan ng aking ISP ang mga papasok na koneksyon ng UDP mula sa mga network nito. Pinayagan ako ng TCP na ipasa ang port ng VPN server sa inuupahang VPS gamit ang SSH. Bagama't lumilikha ang pamamaraang ito ng malaking gastos, dahil ang data ay double-encrypted, ayaw kong i-integrate ang VPS sa aking pribadong network, dahil may panganib na makuha ito ng mga ikatlong partido. Samakatuwid, ang pagkakaroon ng ganitong device sa aking home network ay lubhang hindi kanais-nais, kaya nagpasya akong magbayad ng malaking gastos para sa seguridad.
Para i-forward ang port sa router kung saan planong i-deploy ang server, ginamit ko ang sshtunnel program. Hindi ko na idedetalye ang configuration nito—medyo madali lang ito. Pansinin ko lang na ang layunin nito ay i-forward ang TCP port 1194 mula sa router papunta sa VPS. Sunod, kino-configure ko ang server. OpenVPN Sa tap0 device, na nakakonekta sa br-lan bridge. Matapos subukan ang koneksyon sa bagong gawang server mula sa aking laptop, naging malinaw na gumana ang ideya ng port forwarding, at ang aking laptop ay naging miyembro na ng network ng router, kahit na hindi ito pisikal na bahagi nito.
Ang tanging natitirang gawin ay ipamahagi ang mga IP address sa iba't ibang apartment upang hindi sila magkasalungat at i-configure ang mga router bilang OpenVPN-mga kliyente.
Ang mga sumusunod na router IP address at DHCP server ranges ay pinili:
- 192.168.10.1 may saklaw 192.168.10.2 - 192.168.10.80 para sa server
- 192.168.10.100 may saklaw 192.168.10.101 - 192.168.10.149 para sa isang router sa apartment No. 2
- 192.168.10.150 may saklaw 192.168.10.151 - 192.168.10.199 para sa isang router sa apartment No. 3
Kinailangan ding italaga ang mga adres na ito sa mga router ng kliyente. OpenVPN-server, sa pamamagitan ng pagdaragdag ng sumusunod na linya sa configuration nito:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0at pagdaragdag ng mga sumusunod na linya sa /etc/openvpn/ipp.txt file:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
kung saan ang flat1_id at flat2_id ang mga pangalan ng device na tinukoy kapag lumilikha ng mga sertipiko para sa pagkonekta sa OpenVPN
Susunod, na-configure ang mga router OpenVPN- mga kliyente, tap0 device sa pareho ay idinagdag sa br-lan bridge. Sa puntong ito, tila maayos ang lahat, dahil ang lahat ng tatlong network ay maaaring magkita-kita at gumana bilang isang yunit. Gayunpaman, isang hindi kanais-nais na detalye ang lumitaw: kung minsan ang mga device ay makakatanggap ng IP address mula sa maling router, kasama ang lahat ng mga kasunod na kahihinatnan. Sa ilang kadahilanan, ang router sa isa sa mga apartment ay nabigong tumugon sa DHCPDISCOVER sa oras, at ang device ay nakatanggap ng maling address. Napagtanto ko na kailangan kong i-filter ang mga naturang kahilingan sa tap0 sa bawat router, ngunit ang nangyari, ang mga iptable ay hindi maaaring gumana sa isang device kung ito ay bahagi ng isang bridge, kaya kinailangan kong gumamit ng ebtables. Sa kasamaang palad, hindi ito kasama sa aking firmware, kaya kinailangan kong muling buuin ang mga imahe para sa bawat device. Matapos gawin ito at idagdag ang mga sumusunod na linya sa /etc/rc.local sa bawat router, nalutas ang problema:
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
Ang pagsasaayos na ito ay tumagal ng tatlong taon.
Bahagi 2: Pagkilala WireGuard
Kamakailan lamang, dumarami ang mga usap-usapan sa internet tungkol sa WireGuard, hinahangaan ang kadalian ng pag-configure, mataas na bilis ng paglilipat, mababang ping, at maihahambing na seguridad. Sa paghahanap ng karagdagang impormasyon tungkol dito, natuklasan na hindi nito sinusuportahan ang suporta ng bridge member o TCP protocol, na nagtulak sa akin na maniwala na wala nang alternatibo. OpenVPN para sa akin wala pa rin ito. Kaya ipinagpaliban ko ang pagkilala WireGuard.
Ilang araw na ang nakalipas, kumalat ang balita sa mga mapagkukunang may kaugnayan sa IT sa iba't ibang paraan na WireGuard ay sa wakas ay isasama na sa kernel Linux, simula sa bersyon 5.6. Ang mga artikulo ng balita, gaya ng dati, ay pinuri WireGuardMuli akong humanap ng mga paraan para palitan ang luma OpenVPNSa pagkakataong ito ay nakasalubong ko . Nagsalita ito tungkol sa paglikha ng isang Ethernet tunnel sa L3 gamit ang GRE. Ang artikulong ito ay nagbigay sa akin ng pag-asa. Ito ay nanatiling hindi malinaw kung ano ang gagawin sa UDP protocol. Ang paghahanap ay humantong sa akin sa mga artikulo tungkol sa paggamit ng socat kasabay ng isang SSH tunnel upang ipasa ang isang UDP port, gayunpaman, nabanggit nila na ang diskarte na ito ay gumagana lamang sa isang mode ng koneksyon, na nangangahulugan na ang maraming mga kliyente ng VPN ay magiging imposible. Nakaisip ako ng ideya na mag-set up ng VPN server sa isang VPS, at mag-set up ng GRE para sa mga kliyente, ngunit sa nangyari, hindi sinusuportahan ng GRE ang pag-encrypt, na hahantong sa katotohanan na kung ang mga third party ay makakuha ng access sa server , lahat ng trapiko sa pagitan ng aking mga network ay nasa kanilang mga kamay na hindi nababagay sa akin.
Muli, ang desisyon ay ginawa pabor sa kalabisan na pag-encrypt, sa pamamagitan ng paggamit ng VPN sa VPN ayon sa sumusunod na pamamaraan:
Layer XNUMX VPN:
VPS ay server na may panloob na address 192.168.30.1
MS ay kliyente VPS na may panloob na address 192.168.30.2
MK2 ay kliyente VPS na may panloob na address 192.168.30.3
MK3 ay kliyente VPS na may panloob na address 192.168.30.4
Layer XNUMX VPN:
MS ay server na may panlabas na address na 192.168.30.2 at panloob na 192.168.31.1
MK2 ay kliyente MS na may address na 192.168.30.2 at may panloob na IP na 192.168.31.2
MK3 ay kliyente MS na may address na 192.168.30.2 at may panloob na IP na 192.168.31.3
* MS - router-server sa apartment 1, MK2 - router sa apartment 2, MK3 - router sa apartment 3
* Na-publish ang mga configuration ng device sa spoiler sa dulo ng artikulo.
At kaya, ang mga ping sa pagitan ng mga node ng network 192.168.31.0/24 go, oras na para magpatuloy sa pagse-set up ng GRE tunnel. Bago iyon, upang hindi mawalan ng access sa mga router, sulit na mag-set up ng mga SSH tunnel upang ipasa ang port 22 sa VPS, upang, halimbawa, ang isang router mula sa apartment 10022 ay magagamit sa port 2 ng VPS, at isang ang router mula sa apartment 11122 ay magiging available sa port 3 ng VPS. router mula sa apartment XNUMX. Pinakamainam na i-configure ang pagpapasa gamit ang parehong sshtunnel, dahil ibabalik nito ang tunnel kung sakaling mahulog ito.
Ang tunnel ay na-configure, maaari kang kumonekta sa SSH sa pamamagitan ng ipinasa na port:
ssh root@МОЙ_VPS -p 10022Susunod, dapat mong i-disable OpenVPN:
/etc/init.d/openvpn stopNgayon, mag-set up tayo ng GRE tunnel sa router mula sa apartment 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
At idagdag ang nilikha na interface sa tulay:
brctl addif br-lan grelan0
Magsagawa tayo ng katulad na pamamaraan sa server router:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
At, gayundin, idagdag ang nilikhang interface sa tulay:
brctl addif br-lan grelan0
simula sa sandaling ito, ang mga ping ay nagsisimulang matagumpay na pumunta sa bagong network at ako, nang may kasiyahan, ay pumunta sa pag-inom ng kape. Pagkatapos, upang makita kung paano gumagana ang network sa kabilang dulo ng wire, sinubukan kong mag-SSH sa isa sa mga computer sa Apartment 2, ngunit ang ssh client ay nag-freeze nang hindi sinenyasan ako para sa isang password. Sinusubukan kong kumonekta sa computer na ito sa pamamagitan ng telnet sa port 22 at makita ang isang linya kung saan maaari mong maunawaan na ang koneksyon ay itinatag, ang SSH server ay tumutugon, ngunit sa ilang kadahilanan ay hindi ito nag-aalok sa akin na pumasok.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Sinusubukan kong kumonekta dito sa pamamagitan ng VNC at nakakita ako ng isang itim na screen. Nakumbinsi ko ang aking sarili na ang bagay ay nasa malayong computer, dahil madali akong makakonekta sa router mula sa apartment na ito gamit ang panloob na address. Gayunpaman, nagpasya akong mag-SSH sa computer na ito sa pamamagitan ng router at nagulat ako nang makitang nagtagumpay ang koneksyon at gumagana nang maayos ang remote na computer ngunit nabigo rin itong kumonekta sa aking computer.
Kinukuha ko ang grelan0 device mula sa bridge at pinatakbo ito OpenVPN Sa router sa apartment 2, nakumpirma kong gumagana nang maayos muli ang network at hindi humihina ang mga koneksyon. Habang naghahanap, nakakita ako ng mga forum kung saan nagrereklamo ang mga tao tungkol sa parehong mga isyu, at kung saan pinayuhan silang itaas ang MTU. Agad akong nagsalita. Gayunpaman, hangga't hindi nakatakda nang sapat ang taas ng MTU—7000 para sa mga gretap device—nakaranas ako ng alinman sa pagbaba ng mga koneksyon sa TCP o mababang bilis ng paglilipat. Dahil sa mataas na MTU para sa gretap, ang MTU para sa mga koneksyon WireGuard Ang una at pangalawang antas ay itinakda sa 8000 at 7500 ayon sa pagkakabanggit.
Ginawa ko ang isang katulad na setup sa router mula sa apartment 3, na ang pagkakaiba lamang ay ang pangalawang gretap interface na pinangalanang grelan1 ay idinagdag sa server router, na idinagdag din sa br-lan bridge.
Lahat ay gumagana. Ngayon ay maaari mong ilagay ang gretap assembly sa autoload. Para dito:
Inilagay ang mga linyang ito sa /etc/rc.local sa router sa apartment 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
Idinagdag ito sa /etc/rc.local sa router sa apartment 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
At sa server router:
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
Pagkatapos kong i-reboot ang mga client router, natuklasan ko na sa kung anong dahilan ay hindi sila nakakonekta sa server. Pagkatapos kong kumonekta sa kanilang SSH (buti na lang at na-configure ko na ang sshtunnel para dito), natuklasan ko na WireGuard Sa kung anong dahilan, lumilikha ito ng ruta para sa endpoint, ngunit hindi ito tama. Halimbawa, para sa 192.168.30.2, tinukoy ng route table ang isang ruta sa pamamagitan ng pppoe-wan interface, ibig sabihin, sa pamamagitan ng internet, bagama't dapat sana ay idinirekta ang ruta patungo dito sa pamamagitan ng wg0 interface. Matapos tanggalin ang rutang ito, naibalik ang koneksyon. Makakahanap ba ako ng mga tagubilin kahit saan kung paano pilitin ang... WireGuard Hindi ko maiwasang lumikha ng mga rutang ito. Bukod dito, hindi ko nga maintindihan kung ito ba ay isang tampok ng OpenWRT o ng WireGuardNang hindi gumugol ng maraming oras sa pag-uunawa ng problema, nagdagdag lang ako ng isang linya sa timer-loop script sa parehong router na nagtanggal ng rutang ito:
route del 192.168.30.2
Lagom
Ganap na pagtanggi OpenVPN Hindi ko pa ito nakakamit, dahil paminsan-minsan ay kailangan kong kumonekta sa isang bagong network mula sa isang laptop o telepono, at ang pag-set up ng isang gretap device sa mga ito ay karaniwang imposible. Gayunpaman, sa kabila nito, nakakuha ako ng kalamangan sa bilis ng paglilipat ng data sa pagitan ng mga apartment, at ang paggamit ng VNC, halimbawa, ay ngayon ay walang abala. Bahagyang nabawasan ang Ping ngunit naging mas matatag:
Kapag ginagamit ang 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
Kapag ginagamit ang 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
Ito ay kadalasang apektado ng mataas na ping sa VPS na humigit-kumulang 61.5ms
Gayunpaman, tumaas nang malaki ang bilis. Kaya, sa apartment na may router-server, mayroon akong bilis ng koneksyon sa internet na 30 Mbps, at sa iba pang mga apartment ay 5 Mbps. Bukod dito, habang ginagamit OpenVPN Hindi ko nakamit ang bilis ng paglilipat ng data sa pagitan ng mga network na higit sa 3,8 Mbps ayon sa mga pagbasa ng iperf, habang WireGuard "binago" ito hanggang sa parehong 5 Mbit/seg.
Configuration WireGuard sa VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Kaibigan]
PublicKey = <VPN_1_MS_PUBLIC_KEY>
AllowedIPs = 192.168.30.2/32
[Kaibigan]
PublicKey = <VPN_2_MK2_PUBLIC_KEY>
AllowedIPs = 192.168.30.3/32
[Kaibigan]
PublicKey = <VPN_2_MK3_PUBLIC_KEY>
AllowedIPs = 192.168.30.4/32
Configuration WireGuard sa MS (idinagdag sa /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'
Configuration WireGuard sa MK2 (idinagdag sa /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'
Configuration WireGuard sa MK3 (idinagdag sa /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'
Sa inilarawang mga configuration para sa second level VPN, ipinapahiwatig ko sa mga kliyente WireGuard Port 51821. Hindi ito dapat kailanganin, dahil ang kliyente ay magtatatag ng koneksyon mula sa anumang libre at walang pribilehiyong port, ngunit ginawa ko ito sa ganitong paraan upang ma-deny ko ang lahat ng papasok na koneksyon sa mga interface ng wg0 ng lahat ng router, maliban sa mga papasok na koneksyon ng UDP sa port 51821.
Umaasa ako na ang artikulo ay magiging kapaki-pakinabang sa isang tao.
PS Gayundin, gusto kong ibahagi ang aking script na nagpapadala sa akin ng PUSH notification sa aking telepono sa WirePusher application kapag may lumabas na bagong device sa aking network. Narito ang isang link sa script: .
UPDATE: Configuration OpenVPN-mga server at kliyente
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-kliyente
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 Gumamit ako ng easy-rsa upang makabuo ng mga sertipiko.
Pinagmulan: www.habr.com
