ProHoster > Blog > Pangangasiwa > Ang paglipat mula sa OpenVPN patungo sa WireGuard upang pagsamahin ang mga network sa isang L2 network

Ang paglipat mula sa OpenVPN patungo sa WireGuard upang pagsamahin ang mga network sa isang L2 network

Ang paglipat mula sa OpenVPN patungo sa WireGuard upang pagsamahin ang mga network sa isang L2 network

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 OpenVPN ay unang pinili bilang protocol para sa pagpapatupad ng gawaing ito, dahil, una, maaari itong lumikha ng isang tap device na maaaring idagdag sa tulay nang walang anumang mga problema, at pangalawa, sinusuportahan ng OpenVPN ang operasyon sa TCP protocol, na mahalaga din, dahil wala sa mga apartment ang may nakalaang IP address, at hindi ko nagamit ang STUN, dahil sa ilang kadahilanan hinaharangan ng aking ISP ang mga papasok na koneksyon sa UDP mula sa kanilang mga network, habang pinahintulutan ako ng TCP protocol na ipasa ang port ng server ng VPN sa nirentahang VPS gamit ang SSH. Oo, ang diskarte na ito ay nagbibigay ng isang malaking pag-load, dahil ang data ay naka-encrypt ng dalawang beses, ngunit hindi ko nais na ipakilala ang VPS sa aking pribadong network, dahil mayroon pa ring panganib ng mga ikatlong partido na makakuha ng kontrol dito, samakatuwid, ang pagkakaroon ng ganoong aparato sa home network ay lubhang hindi kanais-nais at napagpasyahan na magbayad para sa seguridad na may malaking overhead.

Upang ipasa ang port sa router kung saan ito binalak na i-deploy ang server, ginamit ang sshtunnel program. Hindi ko ilalarawan ang mga intricacies ng configuration nito - ito ay medyo madali, tandaan ko lang na ang gawain nito ay ipasa ang TCP port 1194 mula sa router patungo sa VPS. Susunod, ang OpenVPN server ay na-configure sa tap0 device, na nakakonekta sa br-lan bridge. Matapos suriin ang koneksyon sa bagong nilikha na server mula sa laptop, naging malinaw na ang ideya ng pagpapasa ng port ay nabigyang-katwiran ang sarili nito at ang aking laptop ay naging miyembro ng network ng router, kahit na wala ito sa pisikal.

Ang bagay ay nanatiling maliit: kinakailangan na ipamahagi ang mga IP address sa iba't ibang mga apartment upang hindi sila magkasalungat at i-configure ang mga router bilang mga kliyente ng OpenVPN.
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 eksaktong mga address na ito sa mga client router ng OpenVPN server sa pamamagitan ng pagdaragdag ng linya sa configuration nito:

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

at 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 ay ang mga pangalan ng device na tinukoy kapag bumubuo ng mga certificate para sa pagkonekta sa OpenVPN

Susunod, ang mga kliyente ng OpenVPN ay na-configure sa mga router, ang mga tap0 device sa pareho ay idinagdag sa br-lan bridge. Sa yugtong ito, tila maayos ang lahat, dahil ang lahat ng tatlong network ay nagkikita at gumagana sa kabuuan. Gayunpaman, isang hindi masyadong kaaya-ayang detalye ang lumabas: kung minsan ang mga device ay maaaring makakuha ng isang IP address na hindi mula sa kanilang router, kasama ang lahat ng kasunod na mga kahihinatnan. Para sa ilang kadahilanan, ang router sa isa sa mga apartment ay walang oras upang tumugon sa DHCPDISCOVER sa oras at ang aparato ay nakatanggap ng maling address. Napagtanto ko na kailangan kong i-filter ang mga naturang kahilingan sa tap0 sa bawat isa sa mga router, ngunit sa nangyari, ang mga iptables ay hindi maaaring gumana sa isang aparato kung ito ay bahagi ng isang tulay at ang mga ebtable ay dapat na tumulong sa akin. Sa aking ikinalulungkot, wala ito sa aking firmware at kailangan kong buuin muli ang mga imahe para sa bawat device. Sa pamamagitan ng paggawa nito at pagdaragdag ng mga linyang ito sa /etc/rc.local ng 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: Ipinapakilala ang WireGuard

Kamakailan lamang, ang Internet ay lalong nagsasalita tungkol sa WireGuard, hinahangaan ang pagiging simple ng pagsasaayos nito, mataas na bilis ng paglipat, mababang ping na may maihahambing na seguridad. Ang paghahanap para sa higit pang impormasyon tungkol dito ay naging malinaw na hindi gumagana bilang isang miyembro ng tulay o gumagana sa TCP protocol ay sinusuportahan nito, na nagpaisip sa akin na wala pa ring mga alternatibo sa OpenVPN para sa akin. Kaya ipinagpaliban kong kilalanin ang WireGuard.

Ilang araw na ang nakalipas, kumalat ang balita sa pamamagitan ng mga mapagkukunan sa isang paraan o iba pang nauugnay sa IT na sa wakas ay isasama na ang WireGuard sa Linux kernel, simula sa bersyon 5.6. Ang mga artikulo ng balita, gaya ng dati, ay pinuri ang WireGuard. Muli akong bumulusok sa paghahanap ng mga paraan upang palitan ang magandang lumang OpenVPN. This time nasagasaan ko artikulong ito. 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 10022

Susunod, huwag paganahin ang OpenVPN:

/etc/init.d/openvpn stop

Ngayon, 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.

Inalis ko ang grelan0 device sa tulay at sinimulan ang OpenVPN sa router sa apartment 2 at siguraduhing gumagana muli ang network nang maayos at hindi bumabagsak ang mga koneksyon. Paghahanap Nakatagpo ako ng mga forum kung saan nagrereklamo ang mga tao tungkol sa parehong mga problema, kung saan pinapayuhan silang itaas ang MTU. Wala pang sinabi at tapos na. Gayunpaman, hanggang sa maitakda ang MTU sa sapat na malaking halaga na 7000 para sa mga gretap device, naobserbahan ang alinman sa mga bumabagsak na koneksyon sa TCP o mabagal na pagpapadala. Dahil sa mataas na MTU para sa gretap, ang mga MTU para sa mga koneksyon ng WireGuard ng 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

Matapos i-reboot ang mga router ng kliyente, nalaman ko na sa ilang kadahilanan ay hindi sila kumonekta sa server. Ang pagkonekta sa kanilang SSH (sa kabutihang palad, dati kong na-configure ang sshtunnel para dito), natuklasan na ang WireGuard sa ilang kadahilanan ay lumilikha ng ruta para sa endpoint, habang hindi tama. Kaya, para sa 192.168.30.2, ang talahanayan ng ruta ay tinukoy sa talahanayan ng ruta sa pamamagitan ng interface ng pppoe-wan, iyon ay, sa pamamagitan ng Internet, kahit na ang ruta patungo dito ay dapat na nakadirekta sa pamamagitan ng interface ng wg0. Matapos tanggalin ang rutang ito, naibalik ang koneksyon. Wala akong mahanap na mga tagubilin kahit saan kung paano pilitin ang WireGuard na huwag gawin ang mga rutang ito. Bukod dito, hindi ko man lang naintindihan kung feature ba ito ng OpenWRT, o ng WireGuard mismo. Nang hindi na kailangang harapin ang problemang ito sa mahabang panahon, idinagdag ko lang ang parehong mga router sa isang script na na-loop ng isang timer, isang linya na nagtanggal ng rutang ito: 

route del 192.168.30.2

Lagom

Hindi ko pa nakakamit ang isang kumpletong pagtanggi sa OpenVPN, dahil minsan kailangan kong kumonekta sa isang bagong network mula sa isang laptop o telepono, at ang pag-set up ng isang gretap device sa kanila ay karaniwang imposible, ngunit sa kabila nito, nakakuha ako ng isang kalamangan sa paglipat ng data bilis sa pagitan ng mga apartment at, halimbawa, ang paggamit ng VNC ay hindi na maginhawa. Bahagyang bumaba ang ping, ngunit naging mas matatag:

Kapag gumagamit ng 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 gumagamit ng 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, ang bilis ay tumaas nang malaki. Kaya, sa isang apartment na may router-server, mayroon akong bilis ng koneksyon sa Internet na 30 Mbps, at sa iba pang mga apartment, 5 Mbps. Kasabay nito, habang ginagamit ang OpenVPN, hindi ko maabot ang rate ng paglilipat ng data sa pagitan ng mga network na higit sa 3,8 Mbps ayon sa iperf, habang ang WireGuard ay "pump" ito hanggang sa parehong 5 Mbps.

WireGuard configuration sa 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

WireGuard configuration 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'

WireGuard configuration 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'

WireGuard configuration 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 inilarawan na mga pagsasaayos para sa pangalawang antas ng VPN, tinukoy ko ang port 51821 sa mga kliyente ng WireGuard. Sa teorya, hindi ito kinakailangan, dahil ang kliyente ay magtatatag ng isang koneksyon mula sa anumang libreng hindi privileged na port, ngunit ginawa ko ito upang ang lahat ng mga papasok na koneksyon maaaring tanggihan sa mga interface ng wg0 ng lahat ng mga router, maliban sa mga papasok na koneksyon sa 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: github.com/r0ck3r/device_discover.

UPDATE: OpenVPN server at configuration ng mga 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-lzo

OpenVPN client

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

Magdagdag ng komento