🥇Transiro de OpenVPN sur WireGuard kombini retojn en unu L2-reton ProHoster

Mi ŝatus kunhavigi mian sperton pri kombinado de retoj en tri geografie malproksimaj apartamentoj, ĉiu el kiuj uzas enkursigilojn kun OpenWRT kiel enirejo, en unu komunan reton. Elektinte metodon por kombini retojn inter L3 kun subreta vojigo kaj L2 kun ponto, kiam ĉiuj retaj nodoj estos en la sama subreto, oni preferas la duan metodon, kiu estas pli malfacila agordi, sed provizas pli da ŝancoj, ĉar travidebla. uzo de teknologioj estis planita en la kreita reto Wake-on-Lan kaj DLNA.

Parto 1: Fono

La protokolo elektita por efektivigi ĉi tiun taskon estis komence OpenVPN, ĉar, unue, ĝi povas krei frapetilon, kiu povas esti aldonita al la ponto senprobleme, kaj due, OpenVPN Ĝi subtenas TCP, kio ankaŭ estis grava, ĉar neniu el la apartamentoj havis dediĉitan IP-adreson. Mi ne povis uzi STUN ĉar mia provizanto de interreto (ISP), pro iu kialo, blokas alvenantajn UDP-konektojn de siaj retoj. TCP permesis al mi plusendi la VPN-servilan pordon al la luita VPS uzante SSH. Kvankam ĉi tiu aliro kreas signifan koston, ĉar la datumoj estas duoble ĉifritaj, mi ne volis integri la VPS en mian privatan reton, ĉar ekzistis risko ke triaj partioj akiru kontrolon super ĝi. Tial, havi tian aparaton en mia hejma reto estis tre nedezirinda, do mi decidis pagi signifan koston por sekureco.

Por plusendi la pordon sur la enkursigilo, kie la servilo estis planita esti deplojita, mi uzis la programon sshtunnel. Mi ne eniros en la detalojn de ĝia agordo — ĝi estas sufiĉe facila. Mi nur rimarkigos, ke ĝia celo estis plusendi TCP-pordon 1194 de la enkursigilo al la VPS. Poste, mi agordis la servilon. OpenVPN Sur la aparato tap0, kiu estis konektita al la ponto br-lan. Post testado de la konekto al la nove kreita servilo de mia tekokomputilo, evidentiĝis, ke la ideo pri plusendado de havenoj funkciis, kaj mia tekokomputilo fariĝis membro de la reto de la enkursigilo, kvankam ĝi ne estis fizike parto de ĝi.

La sola restanta afero estis distribui IP-adresojn en malsamaj apartamentoj por ke ili ne konfliktu kaj agordi la enkursigilojn kiel OpenVPN-klientoj.
La sekvaj enkursigiloj IP-adresoj kaj DHCP-servilaj intervaloj estis elektitaj:

192.168.10.1 kun gamo 192.168.10.2 - 192.168.10.80 por la servilo
192.168.10.100 kun gamo 192.168.10.101 - 192.168.10.149 por enkursigilo en apartamento n-ro 2
192.168.10.150 kun gamo 192.168.10.151 - 192.168.10.199 por enkursigilo en apartamento n-ro 3

Ankaŭ necesis asigni ĉi tiujn adresojn al la klientaj enkursigiloj. OpenVPN-servilo, aldonante la jenan linion al ĝia agordo:

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

kaj aldonante la sekvajn liniojn al la /etc/openvpn/ipp.txt dosiero:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

kie flat1_id kaj flat2_id estas la aparatnomoj specifitaj dum kreado de atestiloj por konekto al OpenVPN

Poste, la enkursigiloj estis agorditaj OpenVPN- klientoj, tap0-aparatoj sur ambaŭ estis aldonitaj al la br-lan-ponto. Je ĉi tiu punkto, ĉio ŝajnis en ordo, ĉar ĉiuj tri retoj povis vidi unu la alian kaj funkcii kiel unu sola unuo. Tamen, aperis sufiĉe malagrabla detalo: kelkfoje aparatoj ricevis IP-adreson de la malĝusta enkursigilo, kun ĉiuj sekvaj konsekvencoj. Pro iu kialo, la enkursigilo en unu el la apartamentoj ne respondis al DHCPDISCOVER ĝustatempe, kaj la aparato ricevis la malĝustan adreson. Mi rimarkis, ke mi devis filtri tiajn petojn en tap0 sur ĉiu enkursigilo, sed montriĝis, ke iptables ne povas funkcii kun aparato se ĝi estas parto de ponto, do mi devis uzi ebtables. Bedaŭrinde, mia firmvaro ne inkluzivis ĝin, do mi devis rekonstrui la bildojn por ĉiu aparato. Post fari tion kaj aldoni la jenajn linioj al /etc/rc.local sur ĉiu enkursigilo, la problemo estis solvita:

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

Ĉi tiu agordo daŭris tri jarojn.

Parto 2: Konatiĝo WireGuard

Lastatempe, en la interreto oni pli kaj pli ofte parolas pri WireGuard, admirante ĝian facilecon de agordo, altan transigan rapidon, malaltan ping-on kaj kompareblan sekurecon. Serĉo por pliaj informoj pri ĝi rivelis, ke ĝi ne subtenas nek pontmembro- nek TCP-protokolon, kio igis min kredi, ke ne ekzistas alternativo. OpenVPN por mi ĝi ankoraŭ ne estas tie. Do mi prokrastis konatiĝon WireGuard.

Antaŭ kelkaj tagoj, novaĵoj disvastiĝis tra rimedoj rilataj al IT tiel aŭ alie, ke WireGuard finfine estos inkludita en la kernon Linux, komencante kun versio 5.6. Novaĵartikoloj, kiel ĉiam, estis laŭdataj WireGuardMi denove plonĝis en serĉadon de manieroj anstataŭigi la bonan malnovan OpenVPNĈi-foje mi renkontis ĉi tiu artikolo. Ĝi parolis pri kreado de Ethernet tunelo super L3 uzante GRE. Ĉi tiu artikolo donis al mi esperon. Restis neklare kion fari kun la UDP-protokolo. Serĉado kondukis min al artikoloj pri uzado de socat kune kun SSH-tunelo por plusendi UDP-havenon, tamen ili rimarkis, ke ĉi tiu aliro nur funkcias en ununura koneksa reĝimo, kio signifas, ke pluraj VPN-klientoj estus neeblaj. Mi elpensis la ideon agordi VPN-servilon sur VPS, kaj agordi GRE por klientoj, sed kiel montriĝis, GRE ne subtenas ĉifradon, kio kondukos al tio, ke se triaj akiros aliron al la servilo, la tuta trafiko inter miaj retoj estas en iliaj manoj, kio tute ne konvenis al mi.

Denove, la decido estis farita en favoro de redunda ĉifrado, uzante VPN super VPN laŭ la sekva skemo:

Tavolo XNUMX VPN:
VPS Estas servilo kun interna adreso 192.168.30.1
MS Estas kliento VPS kun interna adreso 192.168.30.2
MK2 Estas kliento VPS kun interna adreso 192.168.30.3
MK3 Estas kliento VPS kun interna adreso 192.168.30.4

Tavolo XNUMX VPN:
MS Estas servilo kun ekstera adreso 192.168.30.2 kaj interna 192.168.31.1
MK2 Estas kliento MS kun la adreso 192.168.30.2 kaj havas internan IP de 192.168.31.2
MK3 Estas kliento MS kun la adreso 192.168.30.2 kaj havas internan IP de 192.168.31.3

* MS - enkursigilo-servilo en apartamento 1, MK2 - router en apartamento 2, MK3 - router en apartamento 3
* Aparataj agordoj estas publikigitaj en la spoiler ĉe la fino de la artikolo.

Kaj do, pings inter la nodoj de la reto 192.168.31.0/24 iru, estas tempo pluiri al agordo de la GRE-tunelo. Antaŭ tio, por ne perdi aliron al enkursigiloj, indas agordi SSH-tunelojn por plusendi la havenon 22 al la VPS, tiel ke, ekzemple, enkursigilo de la apartamento 10022 estos disponebla ĉe la haveno 2 de la VPS, kaj router de apartamento 11122 estos disponebla sur haveno 3 de la VPS. router de apartamento XNUMX. Plej bone estas agordi la plusendon per la sama sshtunnel, ĉar ĝi restarigos la tunelon se ĝi falos.

La tunelo estas agordita, vi povas konekti al SSH per la plusendita haveno:

ssh root@МОЙ_VPS -p 10022

Poste vi devus malŝalti OpenVPN:

/etc/init.d/openvpn stop

Nun ni agordu GRE-tunelon sur la enkursigilo de apartamento 2:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

Kaj aldonu la kreitan interfacon al la ponto:

brctl addif br-lan grelan0

Ni faru similan proceduron sur la servila enkursigilo:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

Kaj ankaŭ aldonu la kreitan interfacon al la ponto:

brctl addif br-lan grelan0

ekde ĉi tiu momento, pingoj komencas sukcese iri al la nova reto kaj mi, kontente, iras trinki kafon. Poste, por vidi kiel funkcias la reto ĉe la alia fino de la drato, mi provas SSH en unu el la komputiloj en la apartamento 2, sed la ssh-kliento frostas sen peti min pri pasvorto. Mi provas konektiĝi al ĉi tiu komputilo per telnet ĉe la haveno 22 kaj vidas linion, el kiu vi povas kompreni, ke la konekto estas establita, la SSH-servilo respondas, sed ial ĝi ne proponas al mi eniri.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Mi provas konekti al ĝi per VNC kaj mi vidas nigran ekranon. Mi konvinkas min, ke la afero estas en la fora komputilo, ĉar mi povas facile konektiĝi al la enkursigilo de ĉi tiu apartamento per la interna adreso. Tamen, mi decidas SSH en ĉi tiun komputilon per la enkursigilo kaj mi surprizas konstati, ke la konekto sukcesas kaj la fora komputilo funkcias bone, sed ankaŭ ne sukcesas konekti al mia komputilo.

Mi elprenas la aparaton grelan0 el la ponto kaj ruligas ĝin OpenVPN Sur la rutero en apartamento 2, mi konfirmis, ke la reto denove funkciis ĝuste kaj la konektoj ne ĉesis funkcii. Serĉante, mi trovis forumojn, kie homoj plendis pri la samaj problemoj, kaj kie oni konsilis altigi la MTU-on. Tuj dirite, tuj farite. Tamen, ĝis la MTU estis sufiĉe alta — 7000 por gretap-aparatoj — mi spertis aŭ ĉesigitajn TCP-konektojn aŭ malaltajn transigajn rapidojn. Pro la alta MTU por gretap, la MTU por konektoj... WireGuard La unua kaj dua niveloj estis fiksitaj je 8000 kaj 7500 respektive.

Mi faris similan aranĝon ĉe la enkursigilo de apartamento 3, kun la nura diferenco, ke dua gretap-interfaco nomita grelan1 estis aldonita al la servila enkursigilo, kiu ankaŭ estis aldonita al la br-lan-ponto.

Ĉio funkcias. Nun vi povas meti la gretap-asembleon en aŭtomatan ŝarĝon. Por ĉi tio:

Metu ĉi tiujn liniojn en /etc/rc.local sur la enkursigilon en apartamento 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

Aldonis ĉi tion al /etc/rc.local sur la enkursigilo en apartamento 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

Kaj sur la servila enkursigilo:

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

Post restartiĝo de la klientaj enkursigiloj, mi malkovris, ke pro iu kialo ili ne konektiĝis al la servilo. Post konekto al ilia SSH (feliĉe, mi antaŭe agordis sshtunelon por tio), mi malkovris, ke WireGuard Pro iu kialo, ĝi kreas itineron por la finpunkto, sed ĝi estas malĝusta. Ekzemple, por 192.168.30.2, la itinertabelo specifis itineron tra la pppoe-wan interfaco, t.e., tra la interreto, kvankam la itinero al ĝi devus esti direktita tra la wg0 interfaco. Post forigo de ĉi tiu itinero, la konekto estis restarigita. Ĉu mi povas trovi instrukciojn ie ajn pri kiel devigi WireGuard Mi ne povis eviti krei ĉi tiujn itinerojn. Krome, mi eĉ ne komprenis ĉu tio estis trajto de OpenWRT aŭ de la WireGuardSen elspezi multan tempon por eltrovi la problemon, mi simple aldonis linion al la skripto "timer-loop" sur ambaŭ enkursigiloj, kiu forigis ĉi tiun itineron:

route del 192.168.30.2

Supre

Kompleta malakcepto OpenVPN Mi ankoraŭ ne atingis tion, ĉar mi foje bezonas konektiĝi al nova reto per tekokomputilo aŭ telefono, kaj agordi gretap-aparaton sur ili ĝenerale ne eblas. Tamen, malgraŭ tio, mi akiris avantaĝon en datumtransiga rapido inter apartamentoj, kaj uzi VNC, ekzemple, nun estas senĝena. Ping iomete malpliiĝis sed fariĝis pli stabila:

Kiam vi uzas 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

Kiam vi uzas 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

Ĝi estas plejparte tuŝita de alta ping al VPS kiu estas proksimume 61.5ms

Tamen, la rapido signife pliiĝis. Do, en la apartamento kun la enkursigilo-servilo, mi havas retkonekton de 30 Mbps, kaj en la aliaj apartamentoj ĝi estas 5 Mbps. Krome, dum uzado OpenVPN Mi ne sukcesis atingi datumtransigan rapidon inter retoj pli grandan ol 3,8 Mbps laŭ iperf-valoroj, dum WireGuard "pumpis" ĝin ĝis la samaj 5 Mbit/sek.

Agordo WireGuard sur VPS[Interface] Address = 192.168.30.1/24 ListenPort = 51820 PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[Kunulo]
Publika Ŝlosilo = <VPN_1_MS_PUBLIC_KEY>
Permesitaj IP-oj = 192.168.30.2/32

[Kunulo]
Publika Ŝlosilo = <VPN_2_MK2_PUBLIKA_ŜLOSILO>
Permesitaj IP-oj = 192.168.30.3/32

[Kunulo]
Publika Ŝlosilo = <VPN_2_MK3_PUBLIKA_ŜLOSILO>
Permesitaj IP-oj = 192.168.30.4/32

Agordo WireGuard sur MS (aldonita al /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'

Agordo WireGuard sur MK2 (aldonita al /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'

Agordo WireGuard sur MK3 (aldonita al /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'

En la priskribitaj konfiguracioj por la dua nivelo de VPN, mi indikas al klientoj WireGuard Pordo 51821. Ĉi tio ne devus esti necesa, ĉar la kliento establos konekton de iu ajn libera, neprivilegia pordo, sed mi faris ĝin tiel por ke mi povu nei ĉiujn alvenantajn konektojn sur la wg0-interfacoj de ĉiuj enkursigiloj, krom alvenantaj UDP-konektoj al pordo 51821.

Mi esperas, ke la artikolo estos utila al iu.

PS Ankaŭ mi volas kunhavigi mian skripton, kiu sendas al mi PUSH-sciigon al mia telefono en la aplikaĵo WirePusher kiam nova aparato aperas en mia reto. Jen ligo al la skripto: github.com/r0ck3r/device_discover.

UPDATE: Agordo OpenVPN-serviloj kaj klientoj

OpenVPN-servilo

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-kliento

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

Mi uzis easy-rsa por generi atestojn.

fonto: www.habr.com