Me gustaría compartir mi experiencia de combinar redes en tres apartamentos geográficamente distantes, cada uno de los cuales usa enrutadores con OpenWRT como puerta de enlace, en una red común. Al elegir un método para combinar redes entre L3 con enrutamiento de subred y L2 con puente, cuando todos los nodos de la red estarán en la misma subred, se dio preferencia al segundo método, que es más difícil de configurar, pero brinda más oportunidades, ya que transparente Se planeó el uso de tecnologías en la red creada Wake-on-Lan y DLNA.
Parte 1: Antecedentes
El protocolo elegido para implementar esta tarea fue inicialmente OpenVPN, porque, en primer lugar, puede crear un dispositivo de tap que se puede agregar al puente sin ningún problema, y en segundo lugar, OpenVPN Admite TCP, lo cual también era importante, ya que ninguno de los apartamentos tenía una dirección IP dedicada. No pude usar STUN porque mi proveedor de internet, por alguna razón, bloquea las conexiones UDP entrantes desde sus redes. TCP me permitió redirigir el puerto del servidor VPN al VPS alquilado mediante SSH. Si bien este método genera una sobrecarga considerable, ya que los datos están doblemente cifrados, no quería integrar el VPS en mi red privada, puesto que existía el riesgo de que terceros tomaran el control. Por lo tanto, tener un dispositivo de este tipo en mi red doméstica era muy indeseable, así que decidí asumir una sobrecarga considerable a cambio de seguridad.
Para reenviar el puerto del router donde se planeaba desplegar el servidor, utilicé el programa sshtunnel. No entraré en detalles sobre su configuración, ya que es bastante sencilla. Simplemente mencionaré que su propósito era reenviar el puerto TCP 1194 del router al VPS. A continuación, configuré el servidor. OpenVPN En el dispositivo tap0, que estaba conectado al puente br-lan. Tras probar la conexión al servidor recién creado desde mi portátil, quedó claro que la idea del reenvío de puertos había funcionado y que mi portátil se había convertido en miembro de la red del router, aunque no formaba parte físicamente de ella.
Lo único que quedaba por hacer era distribuir las direcciones IP en los diferentes apartamentos para que no entraran en conflicto y configurar los enrutadores como OpenVPN-clientela.
Se seleccionaron las siguientes direcciones IP de enrutadores y rangos de servidores DHCP:
- 192.168.10.1 con una gama 192.168.10.2 - 192.168.10.80 para servidor
- 192.168.10.100 con una gama 192.168.10.101 - 192.168.10.149 para un enrutador en el apartamento No. 2
- 192.168.10.150 con una gama 192.168.10.151 - 192.168.10.199 para un enrutador en el apartamento No. 3
También fue necesario asignar estas direcciones a los enrutadores cliente. OpenVPN-servidor, agregando la siguiente línea a su configuración:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0y agregando las siguientes líneas al archivo /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
donde flat1_id y flat2_id son los nombres de los dispositivos especificados al crear certificados para conectarse a OpenVPN
A continuación, se configuraron los enrutadores. OpenVPN- Los clientes y los dispositivos tap0 de ambos se agregaron al puente br-lan. En este punto, todo parecía correcto, ya que las tres redes podían verse entre sí y funcionar como una sola unidad. Sin embargo, surgió un detalle bastante desagradable: a veces, los dispositivos recibían una dirección IP del enrutador incorrecto, con todas las consecuencias que ello conlleva. Por alguna razón, el enrutador de uno de los apartamentos no respondió a tiempo a DHCPDISCOVER, y el dispositivo recibió la dirección incorrecta. Me di cuenta de que necesitaba filtrar dichas solicitudes en tap0 en cada enrutador, pero resultó que iptables no puede funcionar con un dispositivo si forma parte de un puente, así que tuve que usar ebtables. Desafortunadamente, mi firmware no lo incluía, así que tuve que reconstruir las imágenes para cada dispositivo. Después de hacerlo y agregar las siguientes líneas a /etc/rc.local en cada enrutador, el problema se solucionó:
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 duró tres años.
Parte 2: Conociéndonos WireGuard
Últimamente, se ha hablado cada vez más en Internet sobre WireGuardAdmiraba su facilidad de configuración, alta velocidad de transferencia, baja latencia y seguridad comparable. Una búsqueda de información adicional reveló que no admite ni miembros de puente ni protocolo TCP, lo que me llevó a creer que no existía ninguna alternativa. OpenVPN Para mí todavía no está ahí. Así que pospuse el momento de conocerlo. WireGuard.
Hace unos días, se difundió la noticia a través de recursos relacionados con la informática de una u otra forma de que WireGuard finalmente se incluirá en el kernel Linux, comenzando con la versión 5.6. Los artículos de noticias, como siempre, fueron elogiados. WireGuardUna vez más me sumergí en la búsqueda de formas de reemplazar el viejo y bueno OpenVPNEsta vez me encontré con . Hablaba sobre la creación de un túnel Ethernet sobre L3 usando GRE. Este artículo me dio esperanza. No quedó claro qué hacer con el protocolo UDP. La búsqueda me llevó a artículos sobre el uso de socat junto con un túnel SSH para reenviar un puerto UDP; sin embargo, notaron que este enfoque solo funciona en modo de conexión única, lo que significa que varios clientes VPN serían imposibles. Se me ocurrió la idea de configurar un servidor VPN en un VPS y configurar GRE para los clientes, pero resultó que GRE no admite el cifrado, lo que conducirá al hecho de que si terceros obtienen acceso al servidor , todo el tráfico entre mis redes está en sus manos, lo que no me convenía en absoluto.
Nuevamente, se tomó la decisión a favor del cifrado redundante, utilizando VPN sobre VPN de acuerdo con el siguiente esquema:
VPN de capa XNUMX:
VPS es servidor con dirección interna 192.168.30.1
MS es por cliente VPS con dirección interna 192.168.30.2
MK2 es por cliente VPS con dirección interna 192.168.30.3
MK3 es por cliente VPS con dirección interna 192.168.30.4
VPN de capa XNUMX:
MS es servidor con dirección externa 192.168.30.2 e interna 192.168.31.1
MK2 es por cliente MS con la dirección 192.168.30.2 y tiene una IP interna de 192.168.31.2
MK3 es por cliente MS con la dirección 192.168.30.2 y tiene una IP interna de 192.168.31.3
* MS - enrutador-servidor en el apartamento 1, MK2 - enrutador en el apartamento 2, MK3 - enrutador en el apartamento 3
* Las configuraciones de dispositivos se publican en el spoiler al final del artículo.
Y así, los pings entre los nodos de la red 192.168.31.0/24 van, es hora de pasar a configurar el túnel GRE. Antes de eso, para no perder el acceso a los enrutadores, vale la pena configurar túneles SSH para reenviar el puerto 22 al VPS, de modo que, por ejemplo, un enrutador del apartamento 10022 estará disponible en el puerto 2 del VPS, y un el router del apartamento 11122 estará disponible en el puerto 3 del VPS router del apartamento XNUMX. Lo mejor es configurar el reenvío con el mismo sshtunnel, ya que restaurará el túnel en caso de que se caiga.
El túnel está configurado, puede conectarse a SSH a través del puerto reenviado:
ssh root@МОЙ_VPS -p 10022A continuación, debes deshabilitar OpenVPN:
/etc/init.d/openvpn stopAhora configuremos un túnel GRE en el enrutador del apartamento 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Y agregue la interfaz creada al puente:
brctl addif br-lan grelan0
Realicemos un procedimiento similar en el enrutador del servidor:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Y, además, agregue la interfaz creada al puente:
brctl addif br-lan grelan0
a partir de este momento, los pings comienzan a ir con éxito a la nueva red y yo, con satisfacción, voy a tomar un café. Luego, para ver cómo funciona la red en el otro extremo del cable, trato de SSH en una de las computadoras en el apartamento 2, pero el cliente ssh se congela sin pedirme una contraseña. Intento conectarme a esta computadora a través de telnet en el puerto 22 y veo una línea desde la cual se puede entender que se está estableciendo la conexión, el servidor SSH está respondiendo, pero por alguna razón no me ofrece ingresar.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Estoy tratando de conectarme a través de VNC y veo una pantalla negra. Me convenzo de que el problema está en la computadora remota, porque puedo conectarme fácilmente al enrutador desde este apartamento usando la dirección interna. Sin embargo, decido usar SSH en esta computadora a través del enrutador y me sorprende descubrir que la conexión se realiza correctamente y que la computadora remota funciona bien, pero tampoco se conecta a mi computadora.
Saco el dispositivo grelan0 del puente y lo ejecuto. OpenVPN En el router del apartamento 2, confirmé que la red volvía a funcionar correctamente y que las conexiones no se caían. Buscando, encontré foros donde la gente se quejaba de los mismos problemas y donde se les aconsejaba aumentar la MTU. Dicho y hecho. Sin embargo, hasta que la MTU se configuró lo suficientemente alta (7000 para dispositivos gretap), experimenté caídas de conexiones TCP o bajas velocidades de transferencia. Debido a la alta MTU para gretap, la MTU para conexiones WireGuard El primer y el segundo nivel se fijaron en 8000 y 7500 respectivamente.
Hice una configuración similar en el enrutador del apartamento 3, con la única diferencia de que se agregó una segunda interfaz gretap llamada grelan1 al enrutador del servidor, que también se agregó al puente br-lan.
Todo está funcionando. Ahora puede poner el ensamblado gretap en carga automática. Para esto:
Coloque estas líneas en /etc/rc.local en el enrutador en el 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
Agregué esto a /etc/rc.local en el enrutador en el 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
Y en el enrutador del 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
Después de reiniciar los routers cliente, descubrí que por alguna razón no se conectaban al servidor. Después de conectarme a su SSH (afortunadamente, había configurado previamente sshtunnel para esto), descubrí que WireGuard Por alguna razón, crea una ruta para el punto final, pero es incorrecta. Por ejemplo, para 192.168.30.2, la tabla de rutas especificaba una ruta a través de la interfaz pppoe-wan, es decir, a través de Internet, aunque la ruta hacia ella debería haber sido dirigida a través de la interfaz wg0. Después de eliminar esta ruta, la conexión se restableció. ¿Puedo encontrar instrucciones en algún lugar sobre cómo forzar WireGuard No pude evitar crear estas rutas. Además, ni siquiera entendía si esto era una característica de OpenWRT o de la WireGuardSin dedicar mucho tiempo a averiguar el problema, simplemente añadí una línea al script basado en temporizador en ambos enrutadores que eliminaba esta ruta:
route del 192.168.30.2
En resumen
Rechazo total OpenVPN Todavía no lo he conseguido, ya que ocasionalmente necesito conectarme a una nueva red desde un portátil o un teléfono, y configurar un dispositivo gretap en ellos suele ser imposible. Sin embargo, a pesar de esto, he mejorado la velocidad de transferencia de datos entre apartamentos y usar VNC, por ejemplo, ahora es mucho más sencillo. El ping ha disminuido ligeramente, pero se ha vuelto más estable.
Cuando se utiliza el 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
Cuando se utiliza el 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
Se ve afectado principalmente por un ping alto a VPS, que es de aproximadamente 61.5 ms.
Sin embargo, la velocidad ha aumentado significativamente. Así, en el apartamento con el router-servidor, tengo una velocidad de conexión a Internet de 30 Mbps, y en los otros apartamentos es de 5 Mbps. Además, durante el uso OpenVPN No pude lograr una velocidad de transferencia de datos entre redes superior a 3,8 Mbps según las lecturas de iperf, mientras que WireGuard Lo "aumentó" hasta los mismos 5 Mbit/seg.
Configuración WireGuard en VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Mirar]
Clave pública = <VPN_1_MS_PUBLIC_KEY>
IP permitidas = 192.168.30.2/32
[Mirar]
Clave pública = <VPN_2_MK2_CLAVE_PÚBLICA>
IP permitidas = 192.168.30.3/32
[Mirar]
Clave pública = <VPN_2_MK3_CLAVE_PÚBLICA>
IP permitidas = 192.168.30.4/32
Configuración WireGuard En MS (añadido 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 (añadido 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 (añadido 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'
En las configuraciones descritas para la VPN de segundo nivel, indico a los clientes WireGuard Puerto 51821. Esto no debería ser necesario, ya que el cliente establecerá una conexión desde cualquier puerto libre y no privilegiado, pero lo hice de esta manera para poder denegar todas las conexiones entrantes en las interfaces wg0 de todos los enrutadores, excepto las conexiones UDP entrantes al puerto 51821.
Espero que el artículo sea útil para alguien.
PS Además, quiero compartir mi script que me envía una notificación PUSH a mi teléfono en la aplicación WirePusher cuando aparece un nuevo dispositivo en mi red. Aquí hay un enlace al guión: .
ACTUALIZACIÓN: Configuración OpenVPN-servidores y 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 Usé easy-rsa para generar certificados.
Fuente: habr.com
