Gustaríame compartir a miña experiencia de combinar redes en tres apartamentos xeograficamente distantes, cada un dos cales usa enrutadores con OpenWRT como pasarela, nunha rede común. Ao elixir un método para combinar redes entre L3 con enrutamento de subrede e L2 con ponte, cando todos os nodos da rede estarán na mesma subrede, deuse preferencia ao segundo método, que é máis difícil de configurar, pero ofrece máis oportunidades, xa que é transparente. planificouse o uso de tecnoloxías na rede creada Wake-on-Lan e DLNA.
Parte 1: Antecedentes
O protocolo escollido inicialmente para levar a cabo esta tarefa foi OpenVPN, porque, en primeiro lugar, pode crear un dispositivo de toque que se pode engadir á ponte sen ningún problema e, en segundo lugar, OpenVPN É compatible con TCP, o que tamén era importante, xa que ningún dos apartamentos tiña un enderezo IP dedicado. Non puiden usar STUN porque o meu ISP, por algún motivo, bloquea as conexións UDP entrantes das súas redes. TCP permitiume reenviar o porto do servidor VPN ao VPS alugado mediante SSH. Aínda que este enfoque crea unha sobrecarga significativa, xa que os datos están dobremente cifrados, non quería integrar o VPS na miña rede privada, xa que había o risco de que terceiros obtivesen o control sobre el. Polo tanto, ter un dispositivo deste tipo na miña rede doméstica era moi indesexable, polo que decidín pagar unha sobrecarga significativa pola seguridade.
Para reenviar o porto do enrutador onde se planeaba despregar o servidor, empreguei o programa sshtunnel. Non vou entrar nos detalles da súa configuración; é bastante sinxela. Só sinalarei que o seu propósito era reenviar o porto TCP 1194 do enrutador ao VPS. A continuación, configurei o servidor. OpenVPN No dispositivo tap0, que estaba conectado á ponte br-lan. Despois de probar a conexión co servidor recentemente creado desde o meu portátil, quedou claro que a idea do reenvío de portos funcionara e que o meu portátil converterase en membro da rede do enrutador, aínda que non formaba parte dela fisicamente.
O único que quedaba por facer era distribuír os enderezos IP en diferentes apartamentos para que non entrasen en conflito e configurar os enrutadores como OpenVPN-clientes.
Seleccionáronse os seguintes enderezos IP do enrutador e intervalos de servidor DHCP:
- 192.168.10.1 con alcance 192.168.10.2 - 192.168.10.80 para o servidor
- 192.168.10.100 con alcance 192.168.10.101 - 192.168.10.149 para un router no apartamento no 2
- 192.168.10.150 con alcance 192.168.10.151 - 192.168.10.199 para un router no apartamento no 3
Tamén foi necesario asignar estes enderezos aos enrutadores cliente. OpenVPN-server, engadindo a seguinte liña á súa configuración:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0e engadindo as seguintes liñas ao ficheiro /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
onde flat1_id e flat2_id son os nomes de dispositivos especificados ao crear certificados para conectarse a OpenVPN
A continuación, configuráronse os enrutadores OpenVPN- clientes, engadíronse dispositivos tap0 en ambos á ponte br-lan. Neste punto, todo parecía estar ben, xa que as tres redes podían verse entre si e funcionar como unha soa unidade. Non obstante, xurdiu un detalle bastante desagradable: ás veces os dispositivos recibían un enderezo IP do enrutador incorrecto, con todas as consecuencias derivadas. Por algunha razón, o enrutador dun dos apartamentos non respondeu a DHCPDISCOVER a tempo e o dispositivo recibiu o enderezo incorrecto. Deime conta de que necesitaba filtrar tales solicitudes en tap0 en cada enrutador, pero resultou que iptables non pode funcionar cun dispositivo se forma parte dunha ponte, polo que necesitaba usar ebtables. Desafortunadamente, o meu firmware non o incluía, polo que tiven que reconstruír as imaxes para cada dispositivo. Despois de facer isto e engadir as seguintes liñas a /etc/rc.local en cada enrutador, o problema resolveuse:
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
Esta configuración durou tres anos.
Parte 2: Coñecendo WireGuard
Ultimamente, en Internet fálase cada vez máis sobre WireGuard, admirando a súa facilidade de configuración, alta velocidade de transferencia, baixo ping e seguridade comparable. Unha busca de información adicional ao respecto revelou que non admite nin os protocolos membro da ponte nin os protocolos TCP, o que me levou a crer que non había alternativa. OpenVPN para min aínda non está aí. Así que aprazei coñecer WireGuard.
Hai uns días, difundiuse a noticia a través de recursos relacionados coas TI dun xeito ou doutro que WireGuard finalmente incluirase no núcleo Linux, comezando pola versión 5.6. Os artigos de noticias, como sempre, foron eloxiados WireGuardUnha vez máis mergulleime na procura de xeitos de substituír o bo e vello OpenVPNEsta vez atopei . Falaba de crear un túnel Ethernet sobre L3 usando GRE. Este artigo deume esperanza. Non estaba claro que facer co protocolo UDP. A busca levoume a artigos sobre o uso de socat xunto cun túnel SSH para reenviar un porto UDP, non obstante, observaron que este enfoque só funciona en modo de conexión única, o que significa que sería imposible varios clientes VPN. Ocorréuseme configurar un servidor VPN nun VPS e configurar GRE para os clientes, pero resultou que GRE non admite o cifrado, o que provocará que se terceiros acceden ao servidor, todo o tráfico entre as miñas redes está nas súas mans, o que non me convenía nada.
De novo, a decisión tomouse a favor do cifrado redundante, usando VPN sobre VPN segundo o seguinte esquema:
VPN de capa XNUMX:
Estudantes é servidor con enderezo interno 192.168.30.1
MS é clienta VPS con enderezo interno 192.168.30.2
MK2 é clienta VPS con enderezo interno 192.168.30.3
MK3 é clienta VPS con enderezo interno 192.168.30.4
VPN de capa XNUMX:
MS é servidor con enderezo externo 192.168.30.2 e interno 192.168.31.1
MK2 é clienta MS co enderezo 192.168.30.2 e ten unha IP interna de 192.168.31.2
MK3 é clienta MS co enderezo 192.168.30.2 e ten unha IP interna de 192.168.31.3
* MS - router-servidor no apartamento 1, MK2 - router no apartamento 2, MK3 - router no apartamento 3
* As configuracións do dispositivo publícanse no spoiler ao final do artigo.
E así, os pings entre os nodos da rede 192.168.31.0/24 van, é hora de pasar á configuración do túnel GRE. Antes diso, para non perder o acceso aos enrutadores, paga a pena configurar túneles SSH para reenviar o porto 22 ao VPS, de xeito que, por exemplo, un enrutador do apartamento 10022 estará dispoñible no porto 2 do VPS, e un o enrutador do apartamento 11122 estará dispoñible no porto 3 do VPS, o enrutador do apartamento XNUMX. É mellor configurar o reenvío co mesmo sshtunnel, xa que restaurará o túnel no caso de que caia.
O túnel está configurado, pode conectarse a SSH a través do porto reenviado:
ssh root@МОЙ_VPS -p 10022A continuación, deberías desactivar OpenVPN:
/etc/init.d/openvpn stopAgora imos configurar un túnel GRE no router do apartamento 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
E engade a interface creada á ponte:
brctl addif br-lan grelan0
Imos realizar un procedemento similar no router do servidor:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
E, ademais, engade a interface creada á ponte:
brctl addif br-lan grelan0
a partir deste momento, os pings comezan a ir con éxito á nova rede e eu, satisfeito, vou tomar café. Entón, para ver como funciona a rede do outro extremo do cable, intento conectar un SSH a un dos ordenadores do apartamento 2, pero o cliente ssh conxélase sen pedirme un contrasinal. Intento conectarme a este ordenador a través de telnet no porto 22 e vexo unha liña dende a que podes entender que se está a establecer a conexión, o servidor SSH responde, pero por algún motivo non me ofrece entrar.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Estou tentando conectar a el a través de VNC e vexo unha pantalla negra. Convénzome de que o asunto está no ordenador remoto, porque podo conectarme facilmente ao router desde este apartamento usando o enderezo interno. Non obstante, decido facer SSH neste ordenador a través do enrutador e sorpréndeme ao descubrir que a conexión se realiza correctamente e que o ordenador remoto funciona ben, pero tampouco se conecta ao meu ordenador.
Saco o dispositivo grelan0 da ponte e execútoo OpenVPN No enrutador do apartamento 2, confirmei que a rede volvía funcionar correctamente e que as conexións non se caían. Buscando, atopei foros onde a xente se queixaba dos mesmos problemas e onde lles aconsellaban aumentar o MTU. Dito e feito. Non obstante, ata que o MTU se estableceu o suficientemente alto (7000 para dispositivos gretap), experimentei conexións TCP perdidas ou baixas velocidades de transferencia. Debido ao alto MTU para gretap, o MTU para conexións WireGuard O primeiro e o segundo nivel establecéronse en 8000 e 7500 respectivamente.
Fixen unha configuración similar no enrutador do apartamento 3, coa única diferenza de que se engadiu unha segunda interface gretap chamada grelan1 ao enrutador do servidor, que tamén se engadiu á ponte br-lan.
Todo está funcionando. Agora podes poñer o conxunto gretap na carga automática. Para isto:
Colocou estas liñas en /etc/rc.local no router do 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
Engadido isto a /etc/rc.local no router no 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
E no router do servidor:
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
Despois de reiniciar os routers dos clientes, descubrín que, por algún motivo, non se estaban conectando ao servidor. Despois de conectar ao seu SSH (afortunadamente, xa configurara previamente o sshtunnel para isto), descubrín que WireGuard Por algunha razón, crea unha ruta para o punto final, pero é incorrecta. Por exemplo, para 192.168.30.2, a táboa de rutas especificaba unha ruta a través da interface pppoe-wan, é dicir, a través de internet, aínda que a ruta cara a ela debería terse dirixido a través da interface wg0. Despois de eliminar esta ruta, restaurouse a conexión. Podo atopar instrucións nalgún lugar sobre como forzar WireGuard Non puiden evitar crear estas rutas. Ademais, nin sequera entendía se esta era unha característica de OpenWRT ou de WireGuardSen perder moito tempo a descubrir o problema, simplemente engadín unha liña ao script do bucle do temporizador en ambos os enrutadores que eliminou esta ruta:
route del 192.168.30.2
Resumindo
Rexeitamento completo OpenVPN Aínda non o conseguín, xa que ás veces necesito conectarme a unha rede nova desde un portátil ou un teléfono, e configurar un dispositivo gretap neles xeralmente é imposible. Non obstante, a pesar disto, obtiven unha vantaxe na velocidade de transferencia de datos entre apartamentos, e usar VNC, por exemplo, agora é sinxelo. O ping diminuíu lixeiramente pero volveuse máis estable:
Ao usar 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
Ao usar 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
Está afectado principalmente por un ping alto a VPS, que é de aproximadamente 61.5 ms
Non obstante, a velocidade aumentou significativamente. Así, no apartamento co servidor-router, teño unha velocidade de conexión a internet de 30 Mbps e nos outros apartamentos é de 5 Mbps. Ademais, durante o uso OpenVPN Non puiden acadar unha velocidade de transferencia de datos entre redes superior a 3,8 Mbps segundo as lecturas de iperf, mentres WireGuard "bombeouno" ata os mesmos 5 Mbit/seg.
Configuración WireGuard en VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Iguais]
Clave pública = <VPN_1_MS_CHAVE_PÚBLICA>
IP permitidas = 192.168.30.2/32
[Iguais]
Clave pública = <VPN_2_MK2_CHAVE_PÚBLICA>
IP permitidas = 192.168.30.3/32
[Iguais]
Clave pública = <VPN_2_MK3_CHAVE_PÚBLICA>
IP permitidas = 192.168.30.4/32
Configuración WireGuard en MS (engadido a /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'
Configuración WireGuard en MK2 (engadido a /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'
Configuración WireGuard en MK3 (engadido a /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'
Nas configuracións descritas para a VPN de segundo nivel, indico aos clientes WireGuard Porto 51821. Isto non debería ser necesario, xa que o cliente establecerá unha conexión desde calquera porto libre e sen privilexios, pero eu fixeno deste xeito para poder denegar todas as conexións entrantes nas interfaces wg0 de todos os enrutadores, agás as conexións UDP entrantes ao porto 51821.
Espero que o artigo sexa útil para alguén.
PS Ademais, quero compartir o meu script que me envía unha notificación PUSH ao meu teléfono na aplicación WirePusher cando aparece un dispositivo novo na miña rede. Aquí tedes unha ligazón ao guión: .
Update: Configuración OpenVPN-servidores e clientes
OpenVPN-servidor
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-cliente
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 Usei easy-rsa para xerar certificados.
Fonte: www.habr.com
