Cómo construir un backbone de router/VPN flexible con VyOS, de cero a la edición VPS
El networking puede parecer intimidante al principio, pero con el enfoque adecuado puedes convertir un simple servidor virtual en un backbone de enrutamiento capaz que se extiende desde tu laboratorio doméstico hasta un VPS en la nube. Esta guía explica cómo construir esa topología con VyOS. Al final tendrás un router doméstico, un router VPS público, un túnel seguro entre ambos, y enrutamiento para múltiples subredes internas.
Loading...
Por qué VyOS
VyOS es un sistema operativo de red de código abierto basado en Debian que ofrece funciones de enrutamiento, firewall y VPN de nivel empresarial sobre hardware estándar. Te da la flexibilidad que los appliances de hardware tradicionales suelen limitar, y permite tratar tu router como cualquier otro componente versionado y reproducible de tu infraestructura.
Qué vamos a construir
Un sistema de enrutamiento completo que incluye:
- Una instancia de VyOS en casa, incluso si está detrás de NAT o CGNAT.
- Una instancia de VyOS en un VPS con una IP pública real.
- Un túnel entre ambos mediante WireGuard.
- Múltiples subredes internas detrás del router doméstico.
- Enrutamiento desde el VPS hacia todas las subredes internas.
- La opción de ampliar más adelante hacia enrutamiento dinámico.
El resultado es una ruta estable y predecible entre tu entorno cloud y tu laboratorio doméstico, sin depender de un port forwarding poco fiable ni exponer superficies innecesarias.
Direccionamiento y diseño
Un diseño práctico se ve así:
- Redes internas domésticas bajo
10.42.0.0/16 - Subredes individuales como
10.42.0.0/24y10.42.1.0/24 - Un túnel WireGuard punto a punto como
172.24.32.0/31 - Una IP pública en el VPS más la puerta de enlace que asigne el proveedor
- Ruta por defecto en el router doméstico vía la WAN local
- Ruta por defecto en el VPS vía la puerta de enlace del datacenter
La topología es deliberadamente simple. El túnel se convierte en el backbone, y el VPS actúa como el punto de control accesible externamente.
Configuración del router doméstico (VyOS detrás de NAT)
set interfaces ethernet eth0 address '10.21.21.10/24'
set interfaces ethernet eth0 description 'WAN'
set interfaces ethernet eth1 address '10.42.0.1/24'
set interfaces ethernet eth1 description 'LAB1'
set interfaces ethernet eth2 address '10.42.1.1/24'
set interfaces ethernet eth2 description 'LAB2'
set nat source rule 10 description 'Outgoing NAT'
set nat source rule 10 outbound-interface 'eth0'
set nat source rule 10 source address '10.42.0.0/16'
set nat source rule 10 translation address 'masquerade'
set interfaces wireguard wg0 address '172.24.32.1/31'
set interfaces wireguard wg0 description 'home-to-vps'
set interfaces wireguard wg0 peer VPS allowed-ips '172.24.32.0/31,10.42.0.0/16'
set interfaces wireguard wg0 peer VPS persistent-keepalive '15'
set interfaces wireguard wg0 peer VPS port '8765'
set interfaces wireguard wg0 peer VPS pubkey '<VPS_PUBLIC_KEY>'
set interfaces wireguard wg0 private-key '<HOME_PRIVATE_KEY>'
set protocols static route 0.0.0.0/0 next-hop '10.21.21.1'
set system host-name 'vyos-home-edge'
set service ssh port '22'
commit
save
Configuración del router VPS (VyOS con IP pública)
set interfaces ethernet eth0 address '<VPS_PUBLIC_IP>/23'
set interfaces wireguard wg0 address '172.24.32.0/31'
set interfaces wireguard wg0 description 'vps-to-home'
set interfaces wireguard wg0 peer Home allowed-ips '172.24.32.0/31,10.42.0.0/16'
set interfaces wireguard wg0 peer Home pubkey '<HOME_PUBLIC_KEY>'
set interfaces wireguard wg0 port '8765'
set protocols static route 0.0.0.0/0 next-hop '<VPS_PROVIDER_GATEWAY>'
set system host-name 'vyos-vps'
set service ssh port '22'
commit
save
Una vez configurados ambos extremos y con el handshake de WireGuard funcionando, tienes un backbone privado operativo entre tu laboratorio doméstico y la nube.
Generar claves WireGuard con los comandos PKI integrados
Puedes crear pares de claves directamente con el comando generate pki wireguard key-pair. Este método devuelve la clave privada y la pública en un solo paso, y evita el pipeline manual innecesario o los archivos intermedios que exigiría algo como wg genkey
El comando se puede ejecutar desde el modo operativo.
generate pki wireguard key-pair
Una salida típica se ve así:
Private key: 0NLc86fck3qtkBA133fh6K8sGckgQzHR2rBypr+LgHk=
Public key: H6iVTlr44l6Z+DaGKD3aYr7QZXjG1rpdUYhbm2NjnQQ=
Pegas la clave privada directamente en la configuración de la interfaz.
set interfaces wireguard wg0 private-key '0NLc86fck3qtkBA133fh6K8sGckgQzHR2rBypr+LgHk='
La clave pública se comparte con el router par, y es seguro transmitirla porque no revela ninguna información sensible.
Configuración del servidor DHCP para subredes internas
En comparación con versiones anteriores de VyOS, la 1.5 incluye un modelo de servicio DHCP muy renovado, que abandona la antigua implementación de ISC DHCP en favor de un backend basado en Kea. La estructura de configuración es más clara y permite opciones por subred sin repetición excesiva. Si tu router doméstico sirve a varias redes internas, cada VLAN o interfaz física puede ejecutar su propio pool DHCP con rangos de lease, ajustes DNS y asignaciones de puerta de enlace independientes.
El siguiente ejemplo crea pools DHCP para dos redes internas, 10.42.0.0/24 y 10.42.1.0/24, coincidiendo con la topología anterior. Cada pool define la puerta de enlace por defecto, los servidores DNS y un rango de direcciones dinámico. VyOS vincula automáticamente un pool DHCP a la interfaz que contiene la red correspondiente.
# Enable the DHCP service
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 default-router '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 dns-server '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 lease '86400'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 range 1 start '10.42.0.100'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 range 1 stop '10.42.0.200'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 default-router '10.42.1.1'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 dns-server '10.42.1.1'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 lease '86400'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 range 1 start '10.42.1.100'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 range 1 stop '10.42.1.200'
commit
save
Si necesitas opciones DHCP adicionales como servidores NTP, parámetros de arranque PXE o listas de búsqueda de dominio, VyOS 1.5 las permite a nivel de subred. Por ejemplo:
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 ntp-server '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 domain-name 'lab.internal'
También se pueden configurar reservas estáticas para que direcciones MAC específicas reciban asignaciones IP deterministas. Esto es útil para servidores, hipervisores o dispositivos embebidos que requieren un direccionamiento consistente.
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 static-mapping web01 ip-address '10.42.0.10'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 static-mapping web01 mac-address 'aa:bb:cc:dd:ee:ff'
VyOS reconfigura Kea automáticamente al hacer commit de los cambios, y los leases se registran en los archivos de estado habituales bajo /run/kea. Para redes más grandes puedes integrar Kea con un backend de base de datos, pero para la mayoría de entornos domésticos o de laboratorio la configuración integrada es suficiente y fiable.
Enrutamiento dinámico entre el hogar y el VPS
Las rutas estáticas funcionan bien para redes pequeñas o fijas, pero se convierten en una carga de mantenimiento a medida que tu entorno crece. Si esperas introducir subredes adicionales, más extremos de túnel o conectividad multisitio, el enrutamiento dinámico permite que los routers compartan información de accesibilidad automáticamente. VyOS 1.5 admite múltiples protocolos de enrutamiento dinámico usando FRR como backend. En esta topología, las dos opciones más relevantes son BGP y OSPF.
El enrutamiento dinámico no sustituye tu túnel WireGuard ni el direccionamiento punto a punto. Simplemente automatiza lo que antes definías manualmente. El túnel sigue transportando el tráfico, pero los prefijos ahora se aprenden en lugar de configurarse de forma estática.
Usar BGP para el intercambio de prefijos
BGP es muy adecuado para situaciones en las que controlas múltiples dominios de enrutamiento o donde las redes están repartidas en sedes geográficamente distintas. Un router doméstico que anuncia subredes de laboratorio a un router VPS encaja perfectamente en este modelo. BGP también es agnóstico respecto al transporte subyacente, así que ejecutarlo sobre WireGuard es sencillo.
El siguiente ejemplo usa números de sistema autónomo privados. Cada router usa un loopback como identificador de router BGP. El router doméstico origina las subredes internas bajo 10.42.0.0/16, y el VPS las aprende automáticamente.
Configuración del router doméstico
set interfaces loopback lo address '10.255.255.1/32'
set protocols bgp 65010 neighbor 172.24.32.0 remote-as '65020'
set protocols bgp 65010 neighbor 172.24.32.0 update-source 'wg0'
set protocols bgp 65010 network '10.42.0.0/24'
set protocols bgp 65010 network '10.42.1.0/24'
set protocols bgp 65010 parameters router-id '10.255.255.1'
commit
save
Configuración del router VPS
set interfaces loopback lo address '10.255.255.2/32'
set protocols bgp 65020 neighbor 172.24.32.1 remote-as '65010'
set protocols bgp 65020 neighbor 172.24.32.1 update-source 'wg0'
set protocols bgp 65020 parameters router-id '10.255.255.2'
commit
save
Después del commit, cada router instala los prefijos aprendidos en su tabla de enrutamiento. Cualquier subred nueva añadida en el lado doméstico puede anunciarse simplemente agregando otra sentencia network en BGP, sin tocar la configuración del VPS.
Filtrado de rutas y expansión futura
Incluso en dominios de enrutamiento privados es buena práctica controlar qué prefijos se intercambian. VyOS admite route maps, prefix lists y communities para filtrar o etiquetar rutas. Para una topología de dos sedes el filtrado es opcional, pero en cuanto se añaden routers adicionales o saltos intermedios, estas herramientas aportan estabilidad y control.
Las prefix lists, por ejemplo, pueden usarse para evitar anuncios accidentales de rangos internos que no quieres exponer a través del túnel.
Usar OSPF para entornos multisubred más simples
Si ambos routers participan en un único dominio de enrutamiento compartido y quieres descubrimiento automático de vecinos, OSPF es una alternativa más simple. OSPF exige que las interfaces sean alcanzables en la capa 3, lo cual satisface la red de enlace de WireGuard. OSPF es muy adecuado para entornos de laboratorio donde la simplicidad pesa más que una política de enrutamiento estricta.
Configuración OSPF del router doméstico
set protocols ospf parameters router-id '10.255.255.1'
set protocols ospf area 0 network '172.24.32.0/31'
set protocols ospf area 0 network '10.42.0.0/24'
set protocols ospf area 0 network '10.42.1.0/24'
commit
save
Configuración OSPF del router VPS
set protocols ospf parameters router-id '10.255.255.2'
set protocols ospf area 0 network '172.24.32.0/31'
commit
save
OSPF descubre vecinos a través del enlace WireGuard e intercambia LSA que describen cada subred interna. Cualquier red nueva añadida al router doméstico se integra simplemente agregándola a la configuración del área OSPF.
Elegir entre BGP y OSPF
Ambos protocolos logran enrutamiento dinámico, pero resuelven necesidades operativas ligeramente distintas.
- BGP da control preciso sobre lo que anuncias y aceptas, lo cual se vuelve importante en cuanto la red crece más allá de dos sedes.
- OSPF ofrece enrutamiento de estado de enlace sencillo dentro de un dominio compartido y suele requerir menos configuración inicial.
- BGP es preferible cuando tu VPS actúa como punto de agregación central para múltiples sedes remotas.
- OSPF es ideal cuando quieres descubrimiento automático con una sobrecarga de políticas mínima.
Estas opciones siguen siendo compatibles con la topología WireGuard subyacente, y ambos enfoques eliminan la necesidad de rutas estáticas por subred en el VPS. Si quieres, puedo añadir ejemplos de route maps, prefix lists, o de ejecutar ambos protocolos a la vez en VRF segmentadas.
Enrutamiento estático, el enfoque simple
Si prefieres la previsibilidad y no esperas muchos cambios en las subredes internas, las rutas estáticas son el método más simple.
set protocols static route 10.42.0.0/24 next-hop 172.24.32.1
set protocols static route 10.42.1.0/24 next-hop 172.24.32.1
commit
save
Esto garantiza que el VPS sepa a dónde enviar el tráfico de cada red interna.
Enrutamiento dinámico para topologías más grandes
Si tienes previsto añadir varios routers o escalar la arquitectura, el enrutamiento dinámico como BGP se vuelve útil. VyOS puede anunciar subredes desde tu router doméstico hasta el VPS, eliminando la necesidad de añadir rutas manualmente. Esto no es necesario para la configuración simple, pero se vuelve valioso a medida que tu topología crece.
Por qué esta arquitectura funciona bien
Este modelo ofrece varias ventajas:
- Evita el CGNAT y el port forwarding poco fiable usando un túnel estable.
- Todo el tráfico saliente puede opcionalmente salir a través del VPS, centralizando el filtrado o la monitorización.
- Admite con claridad múltiples subredes domésticas aisladas.
- VyOS te da control total sin atarte a hardware propietario.
- Puedes crecer hacia enrutamiento dinámico, VRRP, extremos VPN adicionales o conectividad multisitio sin rediseñar la base.
Aspectos a tener en cuenta
- Las rutas estáticas deben actualizarse manualmente cuando aparecen nuevas subredes.
- WireGuard, en este patrón, funciona mejor cuando las conexiones se originan desde el lado doméstico, porque el VPS tiene un extremo público fijo.
- La seguridad es intencionadamente mínima en esta guía. En producción deberías añadir políticas de firewall, restringir el acceso de administración, y auditar los servicios.
- Las redes privadas nunca atraviesan la Internet pública, así que el túnel debe estar siempre activo para que el enrutamiento funcione.
Posibles próximos pasos
Puedes ampliar este tutorial hacia una columna vertebral de infraestructura más completa. Algunas extensiones naturales incluyen:
- Introducir BGP para el anuncio automático de subredes.
- Añadir grupos de firewall, enrutamiento basado en políticas y segmentación.
- Dar soporte a clientes WireGuard «road warrior», algo que un plano de control VPN mesh facilita mucho.
- Usar cloud init para desplegar imágenes de VyOS de forma programática.
- Añadir redundancia con VRRP.
Conclusión
Combinando VyOS en un router doméstico con VyOS en un VPS público y uniéndolos con un túnel, obtienes un backbone flexible que funciona sin importar el NAT, las restricciones del ISP o la complejidad del laboratorio. Este patrón escala, es fácil de automatizar, y te da control total sobre cómo se comunican tus redes internas y externas.

Escrito por
Network Engineer, Serverside.com
Lachlan is a network engineer at Serverside.com, where he works on the Arista backbone, public IPv4/IPv6 address space and real-time gNMI network telemetry. He also operates his own autonomous system (AS25735) and writes hands-on guides on routing, VPNs and network automation on bare metal.
Seguir leyendo
Ver todos los artículos¿Te ha gustado este artículo?
Recibe nuevas guías y artículos técnicos en tu correo. Sin spam, cancela cuando quieras.


