Muchas aplicaciones y servicios precisan de una infraestructura de red formada por varios equipos conectados entre sí. Esto puede suceder tanto cuando trabajamos en producción como para pruebas de calidad o en el ámbito académico. A veces no nos resulta interesante o no compensa económicamente hacerlo con hardware y cableado real. Es por eso por lo que disponemos de la posibilidad de crear redes complejas de forma virtual, donde administraremos diferentes equipos virtuales desde un solo equipo anfitrión.
En este apartado vamos a aprender a crear redes virtuales, ya sea para instalar servidores aislados, entornos de prueba y escenarios profesionales de forma más flexible, económica y segura.
¿Qué es una Red Virtual?
En una red virtual no solo tenemos virtualizados los equipos con sistemas operativos, sino que además virtualizamos todos los elementos de la infraestructura como tarjetas de red, cables, switches y routers.
En otras palabras, una red virtual reproduce una red real, pero lo hace dentro de un entorno virtualizado.
Por ejemplo, vamos a imaginar que tenemos que montar un pequeño laboratorio para simular la red de una empresa, en esta red queremos configurar un servidor, comprobar que los clientes pueden acceder a las aplicaciones y servicios, detectar errores y vulnerabilidades.
Al hacerlo mediante una red virtual podremos trabajar con un caso de uso muy próximo a la realidad, pero en un entorno más accesible y seguro para el aprendizaje.
VLANs y Redes Virtuales
Aunque no son exactamente lo mismo, las VLAN están muy relacionadas con la virtualización de redes. Una VLAN permite organizar la red física en varias redes independientes. En entornos virtuales podemos integrar máquinas virtuales en redes segmentadas reales o crear nuevas redes.
Vamos a hacer una comparativa entre crear una VLAN física frente a una en Red virtual
Ventajas
Ventaja
Descripción
Flexibilidad
Permiten levantar sistemas y redes en poco tiempo.
Ahorro de costes
Reducen la necesidad de hardware físico.
Escalabilidad
Es fácil ampliar el número de máquinas o segmentos de red.
Aislamiento
Se pueden crear entornos seguros y separados del resto.
Reutilización
Un mismo host puede albergar múltiples laboratorios o servicios. Duplicarlos, clonarlos…
Rapidez de despliegue
Los cambios se aplican mucho más rápido que en infraestructuras físicas y no tenemos que desplazarnos.
Desventajas
Desventajas
Descripción
Dependencia del host
Si el equipo anfitrión falla, pueden caer varias máquinas y redes a la vez.
Posibles cuellos de botella
Todos los sistemas virtuales comparten recursos de la máquina anfitrión.
Riesgo de mala segmentación
Una mala configuración puede mezclar redes o exponer servicios sin querer.
Falsa sensación de aislamiento
Si no se diseña bien, una red supuestamente privada, puede terminar conectada al exterior.
Tipos de Conexiones en Redes Virtuales
Cuando utilizamos hipervisores como, VirtualBox, VMware, Hyper-V, Proxmox, KVM/QEMU, etc. al crear las máquinas virtuales disponemos de una o varias interfaces de red virtuales, que se comportan como tarjetas de red físicas y también Switch y routers para que interactúen entre sí.
De tal modo que podemos simular cualquier topología de red que deseemos implementar. Existen varios tipos de red al utilizar hipervisores, las cuatro más comunes son:
NAT: Esta opción permite que una máquina virtual pueda acceder a internet utilizando el equipo anfitrión como router. Como ya hemos utilizado anteriormente, sirve para aislar un solo sistema de nuestra red manteniendo un acceso a internet.
Red NAT: Mantiene las restricciones del caso anterior NAT, pero nos permite simular más de un dispositivo pudiendo crear infraestructuras de Red complejas con acceso a internet, pero que no tengan comunicación con la red principal. Muy útiles para realizar pruebas de implantaciones que precisen de varios equipos para realizar pruebas de seguridad o calidad.
Adaptador puente o Bridged: Las máquinas virtuales se integran en la red física como equipos reales, son totalmente visibles al resto de la red. Conectarlas en este modo resulta útil cuando queremos ampliar algún servicio en nuestra red sin tener que implementar nuevo hardware a nuestra red.
Red Interna: La opción de Red Interna actúa de forma muy similar a las redes NAT donde podemos crear nuevas redes, pero en este caso sin acceso a internet. Este tipo es muy útil para laboratorios de ciberseguridad, dado que tiene un aislamiento absoluto.
Host-only: Esta opción es la menos versátil, pues solo permite comunicación creando un canal privado con el host o equipo anfitrión.
Caso de Uso Para entender todo esto mucho mejor, vamos a realizar un caso de uso paso a paso. Desde el departamento de desarrollo nos han pedido que creemos una subred con tres equipos aislados del resto de la red de la empresa, pero con conexión a internet. La red contendrá dos dispositivos clientes y un servidor web Ubuntu Server con Apache2 y conexión vía SSH, para que los desarrolladores puedan realizar pruebas de funcionamiento y en encontrar posibles errores del proyecto que están realizado antes de subirlo a producción. Nos solicitan que los equipos clientes tengan diferentes sistemas operativos, uno con Ubuntu Desktop y otro con Windows.
Para resolver la petición del departamento de desarrolladores, vamos a crear una red virtual que permita la comunicación entre tres máquinas, manteniéndolas aisladas de la red principal de la empresa, pero con acceso a Internet. Para ello utilizaremos un hipervisor como VirtualBox, aunque se podría realizar en otras plataformas de virtualización como VMWare.
Diseño de la topología
El primer paso será definir el tipo de red que queremos implantar. En este caso, la opción más adecuada es utilizar una Red NAT dentro de VirtualBox. Este tipo de red cumple con los requerimientos solicitados permitiendo que varias máquinas virtuales compartan una misma subred privada, puedan comunicarse entre sí y, además, tengan salida a Internet a través del equipo anfitrión.
Equipo
Dirección IP
Máscara
Puerta de enlace
Ubuntu Desktop
10.0.2.10
255.255.255.0
10.0.2.1
Windows
10.0.2.11
255.255.255.0
10.0.2.1
Ubuntu Server
10.0.2.12
255.255.255.0
10.0.2.1
Dentro de VirtualBox, debemos acceder al apartado de herramientas de red y crear una Red NAT nueva para las tres máquinas virtuales. Por ejemplo, podemos crear una red con estas características:
Nombre de la red: RedDesarrollo
Rango de red: 10.0.2.0/24
Panel de configuración de Red NAT en VirtualBox
Es importante que todas estén conectadas a la misma red virtual; de lo contrario, no podrán comunicarse entre sí.
Partiendo de tres máquinas ya creadas y procederemos a configurar la red de cada una de ellas.
Seleccionamos la máquina Ubuntu Desktop y en la configuración de VirtualBox. En el campo conectado a, elegimos la opción Red NAT y en el nombre de la red seleccionamos RedDesarrollo. Guardamos los cambios y pasamos a la siguiente máquina.
Panel de configuración de adaptador de red en VirtualBox
Repetimos el mismo procedimiento con la máquina Windows y la de Ubuntu Server poniendo en todas el tipo de Red NAT y nombre de la red RedDesarrollo.
Ahora ya tenemos los equipos en una única red, el siguiente paso es realizar la configuración de las direcciones IPs según la tabla de la topología y realizar las pruebas para ver que todo funciona.
Si la red NAT está funcionando correctamente, cada máquina debería obtener una dirección IP perteneciente a la misma subred.
Por ejemplo, en los sistemas Linux podemos utilizar en la terminal el comando:
ip a
Y comprobamos que los equipos pertenecen a la red de redDesarrollo al tener una IP con la dirección 10.0.2.X.
Captura de terminal Linux mostrando la IP asignada al dispositivo.
El último paso que debemos realizar antes de entregar el despliegue sería ver si las máquinas tienen conexión entre sí y acceso a internet. Para ello desde la terminal de las diferentes máquinas realizaremos un “ping” a los dispositivos y a una IP de un servicio de internet.
Captura de terminal Linux con resultados de la conexión
Conclusión
Gracias a las redes virtuales es posible segmentar servicios, aislar entornos, conectar servidores, automatizar despliegues y administrar infraestructuras complejas de forma rápida y segura. Por ello, comprender cómo se implantan y configuran no solo resulta útil para el aprendizaje, sino que constituye también una competencia esencial para trabajar en administración de sistemas, virtualización, cloud y redes empresariales modernas, para organizar entornos mucho más grandes en plataformas como Proxmox, centros de datos virtualizados o servicios en la nube como AWS.
La siguiente tabla muestra una propuesta de ordenadores bien montados y representativos de cada época, desde 1980 hasta 2015, pensados para recrearlos en entornos como PCem, 86Box, VirtualBox o simplemente para entender cómo era un PC equilibrado y potente en cada momento histórico.
🎧 Audio del tema Escucha este breve audio para repasar las ideas principales este proyecto.
Nota: no se trata siempre del equipo más caro del mercado, sino de una configuración realista, potente y coherente para su año.
Año
Microprocesador
RAM
Almacenamiento
Gráfica
Sonido
Unidad óptica / disquete
Sistema operativo recomendado
Uso típico
1980
Intel 8088 a 4.77 MHz
64 KB – 256 KB
Sin disco duro, 1 o 2 disqueteras de 5,25″
MDA o CGA
Altavoz interno
Disquetera 5,25″
PC DOS 1.0
Ofimática básica, programación, primeros juegos de PC
1985
Intel 80286 a 6–12 MHz
512 KB – 1 MB
Disco duro de 20–40 MB
EGA
Altavoz interno o tarjeta muy básica
Disquetera 5,25″ 1.2 MB
MS-DOS 3.1 / 3.2
Software profesional, bases de datos, juegos más avanzados
1990
Intel 80386DX a 33 MHz
4 MB
Disco duro de 80–120 MB
VGA
Sound Blaster 1.5 / Pro
Disquetera 3,5″ 1.44 MB
MS-DOS 5.0 + Windows 3.0 opcional
Juegos DOS, productividad, primeros entornos gráficos serios
1995
Intel Pentium 100 / 133 MHz
16 MB
Disco duro de 850 MB – 1.6 GB
SVGA PCI (1–2 MB VRAM)
Sound Blaster 16 / AWE32
Disquetera 3,5″ + CD-ROM 4x / 8x
MS-DOS 6.22 + Windows 95
Multimedia, CD-ROM, juegos DOS avanzados y primeros juegos Windows 95
2000
Pentium III 733 MHz o AMD Athlon 700–900 MHz
128 MB
Disco duro de 20–30 GB
NVIDIA GeForce 2 GTS o 3dfx Voodoo3 3000
Sound Blaster Live!
CD-ROM / DVD-ROM / CD-RW
Windows 98 SE o Windows 2000
Juegos 3D, internet, música MP3, software multimedia
2005
Pentium 4 3.0 GHz o Athlon 64 3200+
1 GB
Disco duro de 120–200 GB
GeForce 6600 GT / 6800 GT o Radeon 9800 Pro / X800
AC’97 o Sound Blaster Audigy
DVD-RW
Windows XP SP2
Juegos DirectX 8/9, internet, multimedia, grabación DVD
2010
Intel Core i5 750 o i7 860
4 GB
Disco duro de 500 GB
GeForce GTX 460 o Radeon HD 5850
HD Audio integrado
DVD-RW
Windows 7
Juegos modernos de la época, Steam, multimedia HD
2015
Intel Core i5 4690K o i7 4790K
8–16 GB
SSD de 250 GB + HDD de 1 TB
GTX 970 o Radeon R9 390
HD Audio integrado
DVD-RW opcional
Windows 10
Gaming moderno, productividad, edición, streaming
Comentarios por época
Año
Comentario histórico
1980
Ordenadores muy básicos, centrados en texto, programación y software profesional simple. Los juegos aún eran muy limitados.
1985
El PC empieza a consolidarse como herramienta seria de trabajo. El disco duro ya marca una gran diferencia.
1990
La época dorada del DOS empieza a despegar con fuerza. Aparecen mejores juegos, mejor sonido y los primeros entornos gráficos realmente utilizables.
1995
Uno de los momentos más interesantes del PC: convivencia entre DOS y Windows 95, explosión del CD-ROM y auge del PC multimedia.
2000
El 3D ya está plenamente asentado. Es una gran época para juegos clásicos de finales de los 90 y principios de los 2000.
2005
Windows XP domina claramente. Se consolida internet, los DVDs, el audio integrado y los juegos DirectX 9.
2010
El PC ya entra en una etapa muy moderna, con Windows 7 como sistema de referencia y el auge del juego digital.
2015
SSD, tarjetas gráficas potentes y Windows 10 marcan una plataforma ya completamente actual en muchos aspectos.
Configuraciones más recomendables para montar máquinas virtuales retro
Pentium II / III, 64–128 MB RAM, Voodoo3 o GeForce 2, Sound Blaster Live!, Windows 98 SE
VirtualBox
2005
1 GB RAM, 20–40 GB de disco virtual, Windows XP SP2 / SP3
VirtualBox
2010
2–4 GB RAM, disco virtual moderno, Windows 7
Selección ideal para un proyecto retro equilibrado
Si quieres montar varias máquinas para cubrir bien la evolución del PC, una selección muy buena sería esta:
Máquina
Representa
Sistema
1985
PC clásico de trabajo y primeros juegos avanzados
MS-DOS 3.x
1990
Época fuerte de DOS y primeros Windows
MS-DOS 5.0 + Windows 3.0
1995
Transición DOS / Windows 95 y explosión multimedia
Windows 95
2000
Auge del 3D y de los grandes clásicos de PC
Windows 98 SE
2005
Dominio absoluto de Windows XP
Windows XP SP2/SP3
Conclusión
Montar varias máquinas virtuales siguiendo esta evolución permite recrear de forma bastante fiel la historia del PC doméstico y del PC de juegos. Cada época tiene una personalidad muy marcada:
1980–1985: primeros PCs y software muy básico
1990–1995: gran crecimiento del DOS, sonido y multimedia
2000–2005: consolidación total del 3D y de Windows
PCem es un emulador de ordenadores PC antiguos. Su objetivo es reproducir el comportamiento de hardware real de distintas épocas. Esto permite instalar sistemas operativos antiguos y ejecutar software que, en máquinas modernas, podría no funcionar correctamente.
PCem puede emular diferentes familias de equipos, desde sistemas 8086/286 hasta máquinas Pentium, Pentium II o configuraciones más avanzadas según la versión y ROM disponibles. La lista de máquinas compatibles depende de los ficheros ROM colocados en la carpeta adecuada. La documentación pública de PCem muestra que cada modelo necesita uno o varios archivos ROM concretos dentro de subcarpetas específicas de roms.
7. Diferencia entre PCem y VirtualBox
Característica
PCem
VirtualBox / VMware / Proxmox
Enfoque principal
Emulación de PCs antiguos
Virtualización de sistemas modernos
Hardware
Emula placas, BIOS, tarjetas y CPUs antiguas
Usa hardware virtual moderno
Rendimiento
Más lento, pero más fiel al hardware antiguo
Más rápido
Uso típico
MS-DOS, Windows 3.11, Windows 95, Windows 98, juegos antiguos
Linux, Windows moderno, servidores
BIOS
Depende de ROMs específicas
BIOS/UEFI integrada en el hipervisor
Aprendizaje histórico
Muy alto
Medio
Compatibilidad con juegos antiguos
Muy buena si se configura bien
Variable
Parte 1: instalación de PCem
1. Instalación en Windows
Paso 1. Descargar PCem
El alumno debe descargar PCem desde una fuente fiable. Según la versión usada, puede venir como programa ya compilado o como código fuente.
Si PCem no encuentra ninguna BIOS válida, puede abrirse sin máquinas disponibles o mostrar errores relacionados con ROMs ausentes.
Esto es normal: antes de crear la máquina hay que colocar las BIOS en la carpeta correcta.
Parte 2: preparación de BIOS y ROMs
1. ¿Qué es la BIOS?
La BIOS es el firmware básico de un PC clásico. Se ejecuta al encender el equipo y realiza tareas como:
Inicializar la placa base.
Comprobar la memoria RAM.
Detectar unidades de disco.
Inicializar teclado y pantalla.
Permitir entrar en la configuración del sistema.
Buscar un dispositivo de arranque.
Cargar el sistema operativo.
En ordenadores antiguos, la BIOS era mucho más visible para el usuario. Configurar mal el disco duro, el orden de arranque o la disquetera podía impedir que el sistema arrancase.
PCem no se limita a simular “un PC genérico”. Emula modelos concretos de placa o chipsets. Muchas de esas máquinas necesitan su BIOS original o una BIOS compatible.
Por ejemplo, la documentación pública del proyecto muestra modelos que requieren rutas y nombres concretos de ROM, como máquinas IBM AT, Compaq, placas Socket 7 o placas Slot 1.
La estructura exacta depende de la máquina seleccionada. PCem suele esperar nombres concretos. Si el nombre del archivo no coincide, la máquina puede no aparecer o puede fallar al arrancar.
4. Comprobación de BIOS detectadas
Una vez copiadas las ROMs:
Abrir PCem.
Crear una nueva máquina.
Abrir la lista de modelos disponibles.
Comprobar si aparecen nuevas placas o equipos.
Si no aparece la máquina deseada, revisar:
Nombre exacto del archivo.
Carpeta correcta.
Mayúsculas y minúsculas.
Si falta alguna ROM adicional.
Si la ROM está comprimida dentro de un .zip.
Si PCem está buscando las ROMs en otra carpeta.
Parte 3: creación de una máquina virtual de ejemplo
Máquina propuesta
Vamos a crear una máquina tipo PC 486 con MS-DOS / FreeDOS.
Esta opción es ideal para una primera práctica porque:
Es más sencilla que Windows 95/98.
Permite entender bien la BIOS.
Obliga a trabajar con disquetes, particiones y formateo.
Consume pocos recursos.
Es perfecta para explicar hardware clásico.
1. Configuración objetivo
Elemento
Configuración propuesta
Tipo de máquina
486 compatible
CPU
Intel 486DX2 a 66 MHz
RAM
16 MB
Tarjeta gráfica
VGA o SVGA compatible
Sonido
Sound Blaster 16
Disco duro
IDE de 512 MB
Disquetera
3.5” 1.44 MB
CD-ROM
Opcional
Sistema operativo
FreeDOS o MS-DOS
Ratón
Serial o PS/2, según disponibilidad
Red
No necesaria en esta primera práctica
Parte 4: crear la configuración en PCem
Paso 1. Abrir PCem
Abrir el programa PCem.
Seleccionar:
New machine
o la opción equivalente para crear una nueva configuración.
Paso 2. Asignar nombre a la máquina
Nombre recomendado:
PC_486_DOS_Practica
El alumno debe usar un nombre claro. Por ejemplo:
NombreAlumno_PC486_DOS
Paso 3. Seleccionar la placa base
Seleccionar una placa compatible con 486.
Ejemplos posibles, dependiendo de las ROM disponibles:
AMI 486 Award 486 Socket 3 compatible
Nota para el profesor: El nombre exacto dependerá de las ROM instaladas. Si se quiere evitar confusión, conviene preparar previamente un paquete de trabajo con una máquina concreta ya verificada en el aula.
Paso 4. Seleccionar CPU
Elegir:
Intel 486DX2/66
Si no aparece exactamente esa CPU, elegir una parecida:
486DX/33 486DX2/50 486DX2/66
Paso 5. Configurar memoria RAM
Asignar:
16 MB
Para MS-DOS es más que suficiente.
No conviene asignar cantidades absurdamente altas, porque una parte del objetivo es comprender las limitaciones reales de la época.
Paso 6. Configurar vídeo
Seleccionar una tarjeta gráfica compatible.
Opciones recomendadas:
VGA SVGA S3 Trio Cirrus Logic
Para una primera práctica con DOS, una VGA sencilla es suficiente.
Paso 7. Configurar sonido
Seleccionar:
Sound Blaster 16
Configuración típica:
Parámetro
Valor habitual
Dirección I/O
220
IRQ
5 o 7
DMA
1
High DMA
5
Esta parte será útil más adelante si se instalan juegos o programas multimedia.
Paso 8. Configurar disquetera
Añadir una disquetera:
3.5" 1.44 MB
Será necesaria para arrancar con un disquete de instalación o de arranque.
Paso 9. Crear disco duro virtual
Crear un disco duro nuevo.
Tamaño recomendado:
512 MB
Nombre del archivo:
discos/pc486_dos_512mb.img
Tipo:
IDE
En PCs antiguos, el disco duro se identificaba mediante geometría CHS:
Cylinders
Heads
Sectors
Muchas BIOS antiguas permiten autodetección, pero otras exigen introducir manualmente los datos.
Parte 5: primera arrancada y entrada en BIOS
Paso 1. Iniciar la máquina
Arrancar la máquina creada.
Es posible que aparezca un mensaje similar a:
No boot device Disk boot failure Insert system disk CMOS checksum error Press F1 to continue Press DEL to enter Setup
Esto es normal. Todavía no hemos configurado la BIOS ni instalado ningún sistema operativo.
Paso 2. Entrar en la BIOS
Durante el arranque, pulsar la tecla correspondiente.
Las teclas más habituales son:
Tecla
Uso habitual
DEL / Supr
Entrar en BIOS Award/AMI
F1
Continuar o entrar en configuración
F2
Setup en algunas BIOS
ESC
Menú o salida
F10
Guardar y salir
En muchas BIOS antiguas, la tecla más habitual es:
Supr / DEL
Paso 3. Configurar fecha y hora
Dentro de la BIOS:
Ir a la pantalla principal.
Configurar fecha.
Configurar hora.
Ejemplo:
Date: 05/04/1995 Time: 12:00:00
Se puede usar una fecha histórica para contextualizar la práctica.
Copiar un driver de ratón compatible, por ejemplo:
MOUSE.COM
Guardar en:
C:\DRIVERS\MOUSE
Modificar AUTOEXEC.BAT:
C:\DRIVERS\MOUSE\MOUSE.COM
2. Driver de CD-ROM
Para usar CD-ROM en DOS se necesitan normalmente dos elementos:
Un controlador en CONFIG.SYS.
El programa MSCDEX.EXE en AUTOEXEC.BAT.
Ejemplo de CONFIG.SYS:
DEVICE=C:\DRIVERS\CDROM\OAKCDROM.SYS /D:MSCD001
Ejemplo de AUTOEXEC.BAT:
C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D
Después de reiniciar, el CD-ROM debería aparecer como:
D:
3. Configuración de Sound Blaster
Añadir al AUTOEXEC.BAT:
SET BLASTER=A220 I5 D1 H5 T6 SET SOUND=C:\SB16
Explicación:
Parámetro
Significado
A220
Dirección base 220h
I5
IRQ 5
D1
DMA 1
H5
DMA alta 5
T6
Tipo Sound Blaster 16
Parte 9: ejemplo de máquina virtual alternativa con Windows 95
Una vez terminada la práctica con DOS, se puede hacer una segunda máquina más avanzada.
Configuración recomendada
Elemento
Configuración
Máquina
Socket 7 / Pentium
CPU
Pentium 133 MHz
RAM
32 MB o 64 MB
Disco duro
2 GB
Gráfica
S3 Trio64 / S3 ViRGE
Sonido
Sound Blaster 16
CD-ROM
IDE
Sistema operativo
Windows 95 OSR2
Disquetera
3.5” 1.44 MB
PCem incluye o ha incluido soporte para muchas máquinas de los años 90, incluyendo placas Socket 7 y Slot 1, dependiendo de la versión y de las ROM instaladas. Por ejemplo, la documentación pública lista configuraciones como FIC VA-503+ o Gigabyte GA-686BX con CPUs Pentium, AMD K6 o Pentium II, siempre que estén disponibles las ROM correspondientes.
Pasos resumidos para Windows 95
Crear máquina Pentium.
Asignar 32 o 64 MB de RAM.
Crear disco duro de 2 GB.
Activar CD-ROM.
Montar disquete de arranque de Windows 95/98 con soporte CD-ROM.
Arrancar desde disquete.
Ejecutar fdisk.
Crear partición primaria.
Reiniciar.
Formatear:
format c: /s
Entrar en la unidad de CD-ROM:
D:
Ejecutar:
setup
Seguir el instalador de Windows 95.
Instalar drivers de vídeo y sonido si es necesario.
Documentar problemas encontrados.
Problemas frecuentes y soluciones
Problema 1: la máquina no aparece en PCem
Causa probable: faltan ROMs o están mal colocadas.
Solución:
Revisar carpeta roms.
Revisar nombres exactos.
Revisar mayúsculas/minúsculas.
Comprobar si la ROM debe ir dentro de una subcarpeta concreta.
Problema 2: aparece “CMOS checksum error”
Causa: la BIOS no tiene configuración guardada todavía.
Solución:
Entrar en BIOS.
Configurar fecha, hora, disco y disquetera.
Guardar cambios.
Reiniciar.
Problema 3: no arranca desde disquete
Causa: orden de arranque incorrecto o imagen mal montada.
Solución:
Configurar Boot Sequence como A, C.
Comprobar que la imagen de disquete está montada.
Comprobar que la imagen es arrancable.
Problema 4: no detecta el disco duro
Causa: disco no creado, no conectado o no detectado en BIOS.
Solución:
Revisar configuración IDE.
Entrar en BIOS.
Usar IDE HDD Auto Detection.
Guardar cambios.
Problema 5: después de FDISK sigue sin arrancar
Causa: falta formatear con archivos de sistema o partición no activa.
Solución:
Ejecutar:
fdisk
Comprobar que la partición primaria está activa.
Después:
format c: /s
Problema 6: el CD-ROM no aparece en DOS
Causa: faltan drivers de CD-ROM.
Solución:
Revisar CONFIG.SYS:
DEVICE=C:\DRIVERS\CDROM\OAKCDROM.SYS /D:MSCD001
Revisar AUTOEXEC.BAT:
C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D
Problema 7: el sonido no funciona
Causa: configuración incorrecta de Sound Blaster.
Solución:
Comprobar que los valores de PCem coinciden con la variable BLASTER:
n esta práctica vamos a trabajar con 86Box, un emulador de ordenadores compatibles x86 pensado para recrear equipos antiguos con bastante fidelidad. A diferencia de VirtualBox, VMware o Proxmox, que están orientados principalmente a virtualizar sistemas modernos, 86Box intenta reproducir el comportamiento de hardware real de distintas épocas: placas base, BIOS, procesadores 286, 386, 486, Pentium, tarjetas gráficas, tarjetas de sonido, controladoras IDE, disqueteras, CD-ROM y otros componentes clásicos.
Este proyecto tiene como objetivo que el alumno no solo “instale un sistema operativo antiguo”, sino que entienda cómo arrancaba y se configuraba un PC clásico: qué papel tenía la BIOS, cómo se detectaban los discos, cómo se configuraba el orden de arranque y por qué era necesario cargar controladores manualmente.
86Box necesita un conjunto de ROMs para emular correctamente muchos equipos. Estas ROMs incluyen BIOS de sistema y ROMs opcionales de tarjetas de expansión, organizadas en carpetas según el tipo de dispositivo o modelo emulado. La propia documentación de 86Box indica que, sin un conjunto de ROMs válido, el programa no podrá iniciar correctamente determinadas máquinas.
¿Qué es 86Box?
86Box es un emulador de ordenadores compatibles x86. Su finalidad es reproducir el comportamiento de PCs antiguos de forma más fiel que una máquina virtual moderna.
Con 86Box podemos emular equipos de distintas generaciones:
8086 / 8088.
Pentium.
Pentium MMX.
Pentium II.
Otros sistemas compatibles, según la versión y las ROMs disponibles.
La versión estable más reciente publicada en la página oficial de 86Box es la v5.3, lanzada el 21 de diciembre de 2025. Esta versión incluye mejoras de rendimiento, correcciones y nuevo hardware soportado.
Diferencia entre 86Box y PCem
86Box nació como una continuación o evolución del trabajo realizado alrededor de PCem, pero actualmente se mantiene como un proyecto propio y con desarrollo activo.
Característica
PCem
86Box
Tipo de programa
Emulador de PCs antiguos
Emulador de PCs antiguos
Estado actual
Proyecto histórico muy usado
Proyecto activo y actualizado
Uso principal
Emular hardware retro
Emular hardware retro con más hardware soportado
BIOS/ROMs
Necesita ROMs específicas
Necesita ROMs específicas
Configuración
Manual, algo más clásica
Incluye gestor de máquinas virtuales en versiones recientes
Ideal para
DOS, Windows 3.x, Windows 95/98
DOS, Windows 3.x, Windows 95/98 y más configuraciones
Dificultad
Media
Media
86Box incluye actualmente un gestor de máquinas virtuales que permite crear, administrar, arrancar y controlar varias configuraciones desde una misma interfaz. La documentación oficial indica que, al abrir 86Box, se inicia este gestor de máquinas virtuales, aunque sigue considerándose una función en evolución.
Material necesario
Para realizar la práctica necesitaremos:
86Box instalado.
Conjunto de ROMs/BIOS compatible con 86Box.
Imagen de instalación de un sistema operativo retro.
Imagen de disquete de arranque, si es necesaria.
Drivers de CD-ROM, ratón, sonido o vídeo, según el sistema elegido.
Espacio en disco para crear discos duros virtuales.
Capturador de pantalla para documentar el proceso.
Las BIOS y ROMs son ficheros que pertenecen al firmware de equipos y tarjetas reales. En muchos casos pueden estar protegidas por derechos de autor.
Para una práctica educativa, lo correcto es:
Usar ROMs obtenidas de forma legítima.
No redistribuir BIOS propietarias sin permiso.
Documentar qué ROMs se han usado.
No mezclar ROMs aleatorias sin saber para qué máquina sirven.
86Box dispone de documentación específica sobre el conjunto de ROMs y explica que estas ROMs incluyen BIOS de sistema y ROMs de tarjetas de expansión. También indica que el conjunto de ROMs se organiza por directorios según el tipo de dispositivo o modelo.
Instalación de 86Box
1. Descarga del programa
El primer paso es descargar 86Box desde su página oficial o desde su repositorio de GitHub.
Conviene usar una versión estable, especialmente en clase. Las versiones experimentales pueden incluir funciones nuevas, pero también más errores.
2. Organización de carpetas
Antes de empezar, crearemos una carpeta de trabajo.
Ejemplo en Windows:
C:\Emuladores\86Box
Dentro de esa carpeta podemos organizar el material así:
Ahí es donde colocaremos el conjunto de BIOS y ROMs que usará el emulador.
7. Carga de BIOS y ROMs en 86Box
1. ¿Para qué sirven las ROMs?
86Box necesita ROMs para poder emular determinados equipos y tarjetas. Estas ROMs pueden incluir:
BIOS de la placa base.
BIOS de tarjetas gráficas.
ROMs de controladoras.
ROMs de tarjetas de red.
ROMs de tarjetas de sonido.
Otros firmwares necesarios para hardware concreto.
Sin estas ROMs, algunas máquinas no aparecerán como disponibles o no arrancarán correctamente.
2. Carpeta de ROMs
La documentación de 86Box explica que el conjunto de ROMs debe extraerse en una ubicación soportada por el emulador. En algunos sistemas se puede colocar la carpeta roms junto al ejecutable. También existen diferencias según versión y sistema operativo, por lo que conviene comprobar la ruta concreta en la documentación o en la propia interfaz del programa.
No debemos dejar las ROMs comprimidas si la documentación indica que deben estar extraídas.
Comprobación de ROMs
Una vez colocadas las ROMs:
Abrimos 86Box.
Entramos en el gestor de máquinas.
Creamos una nueva máquina.
Revisamos la lista de placas base disponibles.
Comprobamos que aparecen modelos de máquinas.
Si no aparece ninguna máquina o aparece un error de ROMs, debemos revisar:
Si la carpeta se llama exactamente roms.
Si está en la ruta correcta.
Si las ROMs están extraídas y no dentro de un .zip.
Si se ha descargado un conjunto de ROMs compatible con la versión usada.
Si se está usando una versión experimental de 86Box que requiere ROMs más recientes.
Primer arranque de 86Box
Al abrir 86Box veremos el gestor de máquinas virtuales.
Desde ahí podremos:
Crear una máquina nueva.
Editar una máquina existente.
Arrancar una máquina.
Eliminar una configuración.
Duplicar configuraciones.
Gestionar discos e imágenes.
En versiones actuales, 86Box abre directamente este gestor de máquinas, que sirve para administrar varias configuraciones emuladas.
Máquina de ejemplo para la práctica
Para esta práctica crearemos una máquina sencilla y estable:
Máquina propuesta
PC 486 con FreeDOS o MS-DOS
Esta máquina es ideal para empezar porque permite trabajar con:
BIOS.
Disquetera.
Disco duro IDE.
FDISK.
Formateo.
Arranque desde disco.
Archivos AUTOEXEC.BAT y CONFIG.SYS.
Configuración recomendada
Elemento
Configuración
Tipo de máquina
486 compatible
CPU
Intel 486DX2/66
RAM
16 MB
Tarjeta gráfica
VGA / SVGA
Tarjeta de sonido
Sound Blaster 16
Disco duro
IDE de 512 MB
Disquetera
3.5” 1.44 MB
CD-ROM
Opcional
Sistema operativo
FreeDOS o MS-DOS
Red
No necesaria
Creación de la máquina virtual en 86Box
Paso 1. Crear una nueva máquina
Abrimos 86Box y seleccionamos la opción para crear una nueva máquina.
Nombre recomendado:
PC_486_DOS_Alumno
También podemos usar un nombre más descriptivo:
NombreAlumno_86Box_486_DOS
Paso 2. Seleccionar la placa base
En el apartado de máquina o placa base seleccionaremos una placa compatible con 486.
El nombre exacto dependerá de las ROMs disponibles.
Ejemplos posibles:
AMI 486 Award 486 Socket 3 486 PCI 486 ISA/VLB/PCI
No todos los modelos aparecerán en todas las instalaciones. Si una placa no aparece, normalmente significa que faltan ROMs o que no están bien colocadas.
Paso 3. Seleccionar el procesador
Elegimos una CPU de la familia 486.
Configuración recomendada:
Intel 486DX2/66
Si no aparece exactamente esa opción, podemos usar otra parecida:
No conviene asignar demasiada RAM porque perderíamos parte del sentido histórico de la práctica. Un PC 486 real normalmente trabajaba con cantidades mucho más modestas que un equipo actual.
Paso 5. Configurar la tarjeta gráfica
Elegimos una tarjeta sencilla y compatible.
Opciones habituales:
VGA SVGA Cirrus Logic S3 Trio Tseng ET4000
Para DOS, una tarjeta VGA o SVGA básica es suficiente.
Paso 6. Configurar la tarjeta de sonido
Seleccionamos una tarjeta compatible con muchos juegos y programas de la época.
Recomendación:
Sound Blaster 16
Valores típicos:
Parámetro
Valor
Dirección I/O
220
IRQ
5 o 7
DMA
1
High DMA
5
Más adelante estos valores se usarán en la variable BLASTER.
Paso 7. Configurar la disquetera
Añadimos una disquetera:
3.5" 1.44 MB
Esta unidad será la unidad A: dentro de DOS.
Paso 8. Crear el disco duro virtual
Creamos un disco duro nuevo.
Tamaño recomendado:
512 MB
Nombre del archivo:
discos/pc486_dos_512mb.img
Tipo de conexión:
IDE
Este disco aparecerá como disco principal de la máquina.
Paso 9. Configurar CD-ROM
Este paso es opcional para la primera práctica, pero recomendable si queremos instalar software desde ISO.
Configuración:
CD-ROM IDE
En DOS, para que el CD-ROM funcione, normalmente necesitaremos cargar un driver en CONFIG.SYS y MSCDEX.EXE en AUTOEXEC.BAT.
Primera arrancada de la máquina
Una vez creada la máquina, la arrancamos.
Es normal que aparezcan mensajes como:
CMOS checksum error No boot device Disk boot failure Insert system disk Press DEL to enter Setup
Esto no significa que la práctica esté mal. Significa que la máquina todavía no tiene BIOS configurada ni sistema operativo instalado.
Entrada en BIOS
Paso 1. Pulsar la tecla de acceso
Durante el arranque, pulsamos la tecla correspondiente para entrar en la BIOS.
Las más habituales son:
Tecla
Uso
DEL / Supr
BIOS AMI o Award
F1
Continuar o entrar en configuración
F2
Setup en algunas BIOS
ESC
Menú o salida
F10
Guardar y salir
En muchas máquinas antiguas lo normal será:
Supr / DEL
Paso 2. Configurar fecha y hora
Dentro de la BIOS, buscamos la pantalla principal.
Ejemplo:
Date: 05/04/1995 Time: 12:00:00
Podemos usar una fecha histórica para que la práctica tenga más contexto.
Paso 3. Configurar la disquetera
En el apartado de configuración básica o Standard CMOS Setup, configuramos:
Para clase recomiendo usar FreeDOS, porque es libre y evita problemas de licencias. Si se dispone de una licencia legítima de MS-DOS, también se puede usar.
Paso 1. Montar el disquete o ISO de instalación
Desde el menú de 86Box montamos la imagen correspondiente.
Ejemplo con disquete:
freedos_boot.img
Ejemplo con CD-ROM:
freedos.iso
Paso 2. Arrancar desde el medio de instalación
Arrancamos la máquina.
Si todo está bien configurado, debería aparecer un instalador o un prompt parecido a:
A:\>
Paso 3. Crear partición con FDISK
Ejecutamos:
fdisk
Seleccionamos las opciones:
Create DOS partition Create Primary DOS Partition Use maximum available size Set partition active
Después reiniciamos la máquina.
Paso 4. Formatear el disco duro
Volvemos a arrancar desde el disquete o medio de instalación.
Ejecutamos:
format c: /s
El parámetro /s copia los archivos básicos del sistema para que el disco duro pueda arrancar.
Paso 5. Arrancar desde el disco duro
Apagamos la máquina.
Quitamos el disquete o ISO de arranque.
Arrancamos de nuevo.
Si todo está correcto, veremos:
C:\>
La máquina ya arranca desde su propio disco duro virtual.
En esta práctica el alumnado diseñará e implantará un pequeño laboratorio informático capaz de recrear distintas generaciones de ordenadores personales, desde equipos antiguos basados en MS-DOS y Windows 3.x / 95 / 98, hasta sistemas más modernos como Windows XP y Windows 7.
Para ello se utilizarán dos tipos de herramientas:
Emulación, para recrear equipos antiguos con un hardware similar al de su época.
Virtualización, para instalar sistemas más recientes de forma rápida y controlada.
El objetivo no es únicamente “ver sistemas antiguos”, sino analizar la evolución del hardware y del software, comprender las diferencias entre emular y virtualizar, y documentar técnicamente todo el proceso.
Contexto de la práctica
Una pequeña aula de tecnología quiere montar un laboratorio didáctico para mostrar a futuros estudiantes cómo ha evolucionado el PC a lo largo de varias décadas.
El laboratorio debe permitir:
recrear distintas épocas de la informática personal,
instalar sistemas operativos representativos,
probar software y utilidades de cada momento,
comparar tecnologías,
documentar problemas de compatibilidad y configuración.
El equipo técnico encargado de este trabajo sois vosotros.
Objetivos
Al finalizar esta práctica, el alumno deberá ser capaz de:
comprender la evolución del hardware del PC entre diferentes generaciones,
diferenciar entre emulación y virtualización,
instalar y configurar sistemas operativos antiguos y modernos en entornos virtuales,
seleccionar una configuración coherente para cada época,
documentar incidencias técnicas,
realizar pruebas de funcionamiento,
elaborar una memoria técnica del laboratorio montado.
Resultados de aprendizaje que se trabajan
Con esta práctica se trabajan, entre otros, aspectos relacionados con:
implantación de sistemas operativos,
administración básica de sistemas,
virtualización,
análisis de hardware,
documentación técnica,
resolución de incidencias,
planificación y validación de entornos informáticos.
Materiales y herramientas necesarias
Cada grupo o alumno deberá disponer de lo siguiente:
un ordenador anfitrión con recursos suficientes,
software de emulación: PCem o 86Box,
software de virtualización: VirtualBox,
imágenes ISO o disquetes de instalación de los sistemas operativos a utilizar,
utilidades o programas representativos de cada época,
carpeta de trabajo para guardar capturas, configuraciones y documentación.
Sistemas y generaciones propuestas
Se recomienda recrear al menos cuatro generaciones diferentes. Como referencia, se propone esta selección:
Generación
Tipo de entorno
Sistema propuesto
1990
Emulación
MS-DOS 5.0 + Windows 3.0 o 3.1
1995
Emulación
Windows 95
2000
Emulación
Windows 98 SE
2005
Virtualización
Windows XP
2010
Virtualización
Windows 7
El profesor podrá ajustar esta lista según el material disponible.
Desarrollo de la práctica
Paso 1. Crear la estructura del proyecto
Antes de empezar, cada alumno o grupo deberá crear una carpeta principal para organizar todo el trabajo.
Cuando hoy hablamos de un “PC”, normalmente pensamos en un ordenador con Windows, Linux, conexión a Internet, discos SSD, varios gigabytes de memoria RAM y una potencia que hace unas décadas habría sido impensable. Sin embargo, el concepto de PC compatible tiene un origen mucho más humilde y, al mismo tiempo, enormemente importante: el IBM PC 5150 y su evolución, el IBM PC XT.
En esta práctica vamos a viajar al comienzo de la informática personal moderna. No se trata únicamente de “probar un ordenador antiguo”, sino de entender cómo funcionaban los primeros PCs, cómo arrancaban, cómo se gestionaban los discos, qué papel tenía la BIOS y cómo se trabajaba con sistemas operativos como PC DOS o MS-DOS.
Este tipo de práctica es especialmente interesante porque nos permite ver, de forma muy clara, la base sobre la que se construyó gran parte de la informática actual.
¿Qué fue el IBM PC 5150?
El IBM PC 5150 fue presentado por IBM en 1981 y se convirtió en uno de los ordenadores más influyentes de la historia. Aunque no fue el primer ordenador personal, sí fue el que ayudó a establecer el estándar de lo que durante años se conocería como PC compatible.
Su arquitectura era relativamente abierta en comparación con otros sistemas de la época. Esto permitió que otras empresas fabricaran componentes, tarjetas de expansión, periféricos y, con el tiempo, ordenadores compatibles con el diseño original de IBM.
Esta decisión tuvo una consecuencia enorme: el ecosistema del PC creció rápidamente y terminó convirtiéndose en el modelo dominante en oficinas, centros educativos, empresas y hogares.
¿Por qué emular un IBM PC o un IBM PC XT?
A primera vista, emular un ordenador de los años 80 puede parecer solo una actividad nostálgica. Pero en realidad es una práctica muy potente desde el punto de vista educativo.
Con una máquina moderna, muchos procesos quedan ocultos. El sistema operativo arranca automáticamente, los discos se detectan solos, los controladores se instalan en segundo plano y el usuario apenas ve qué ocurre por debajo.
En cambio, al trabajar con un IBM PC o un PC XT, todo es mucho más visible:
la BIOS tiene un papel fundamental;
el arranque se entiende paso a paso;
el sistema operativo se carga desde disquete o disco duro;
las unidades tienen letras como A:, B: y C:;
los comandos se escriben manualmente;
los recursos del sistema son muy limitados;
cada componente de hardware debe estar bien configurado.
Esta sencillez aparente nos ayuda a comprender conceptos que siguen siendo importantes hoy en día.
Configuración 86Box
Arranque sin sistema operativo (BASIC)
Instalar MS-DOS 3.3
Con la máquina apagada o desde el menú de 86Box:
Ve a Media.
Entra en Floppy 1.
Selecciona Existing image.
Carga una imagen .img o .ima de MS-DOS. (Es importante que el medio coincida, en este caso discos de 5 1/4 de 360)
🎧 Audio del tema Escucha este breve audio para repasar las ideas principales este proyecto.
Dentro del proyecto de PC retro vamos a trabajar con una máquina muy interesante: el IBM PS/ValuePoint. No es tan mítico como un IBM PC XT, ni tan recordado como los PS/2, pero representa un momento muy importante de la historia del PC: el momento en el que IBM tuvo que aceptar que el mercado ya no giraba solo alrededor de sus estándares propietarios.
El IBM PS/ValuePoint fue una familia de ordenadores lanzada a comienzos de los años 90. Su objetivo era claro: ofrecer equipos IBM más competitivos, más parecidos a los PC compatibles del mercado y menos cerrados que la gama PS/2. La línea PS/ValuePoint apareció alrededor de 1992 y estuvo activa hasta mediados de los años 90, antes de ser sustituida por otras familias como IBM PC Series.
Para nuestro proyecto retro es una máquina ideal porque nos coloca justo en la época dorada del 486, de MS-DOS, de Windows 3.1, de los primeros entornos multimedia y de juegos como Doom, Monkey Island 2, Alone in the Dark, SimCity 2000, Wolfenstein 3D o Indiana Jones and the Fate of Atlantis.
¿Qué era el IBM PS/ValuePoint?
El IBM PS/ValuePoint fue una gama de ordenadores personales de IBM orientada a empresas, educación y usuarios que querían un PC fiable sin pagar el precio ni asumir las limitaciones de algunas decisiones propietarias de IBM.
Venía de una época complicada para IBM. La empresa había creado el estándar PC original, pero después intentó recuperar control con la gama PS/2, que utilizaba tecnologías como el bus Micro Channel Architecture, más cerrado y menos compatible con las tarjetas habituales del mercado. El problema es que el mundo del PC compatible ya iba por libre: placas base clónicas, tarjetas ISA, discos IDE, tarjetas VGA/SVGA y componentes más económicos.
El PS/ValuePoint fue una respuesta a esa situación. Era un IBM, sí, pero mucho más cercano al PC estándar que podía montar cualquier fabricante. En lugar de apostar por un ecosistema cerrado, estos equipos usaban componentes más comunes en el mercado, como buses ISA/VLB/PCI según modelo, discos IDE y tarjetas de expansión más convencionales.
Dicho de forma sencilla: el PS/ValuePoint fue IBM bajando a la tierra del PC compatible.
Modelos y formatos
La familia PS/ValuePoint tuvo varios formatos físicos. Entre los más representativos estaban:
Formato
Ejemplo de tipo
Descripción
Space saving desktop
6382 /S
Caja horizontal compacta, menos ranuras y bahías
Desktop
6384 /D
Sobremesa horizontal más grande
Mini Tower
6387 /T
Torre pequeña, más ampliable
Algunos documentos de mantenimiento de IBM mencionan modelos como 425SX, 433SX, 433DX, 466DX2 y variantes en formato /S, /D y /T. Estos nombres suelen indicar el tipo de procesador: por ejemplo, un 466DX2 hace referencia a un 486DX2 a 66 MHz.
Para emulación en 86Box, una configuración muy interesante es un IBM PS/ValuePoint 433DX o 466DX2, porque representa muy bien un PC de mediados de los 90 sin irnos todavía a la era Pentium.
Especificaciones típicas
Las configuraciones variaban mucho según modelo, pero una máquina representativa podía tener algo parecido a esto:
Componente
Configuración típica
Procesador
Intel 486SX, 486DX, 486DX2 o incluso DX4 en algunos modelos
Frecuencia
25, 33, 50, 66 o 100 MHz según versión
Memoria RAM
4 MB, 8 MB, 16 MB o más
Disco duro
IDE, normalmente entre 120 MB y 500 MB en configuraciones habituales
Disquetera
3.5” de 1.44 MB
Vídeo
VGA/SVGA, a menudo integrado en placa
Sonido
No siempre incluido; se podía añadir Sound Blaster u otra ISA
Sistema operativo
PC DOS, MS-DOS, Windows 3.1, OS/2 o posteriormente Windows 95
Algunas referencias de IBM para modelos ValuePoint muestran configuraciones con procesadores 486SX-25, 486DX-33, 486DX2-50 y 486DX2-66, memoria de 4 u 8 MB, discos de 120 MB o 170 MB y PC DOS 5.02 con Windows 3.1 en ciertos modelos.
¿Por qué es interesante para un proyecto retro?
El IBM PS/ValuePoint es perfecto para un proyecto de PC retro por varias razones.
Primero, porque representa una época muy concreta: el salto desde los PC puramente de oficina hacia los PC multimedia. Es la etapa en la que todavía se trabaja mucho con MS-DOS, pero Windows empieza a ganar protagonismo.
Segundo, porque es una máquina suficientemente potente para ejecutar muchos juegos clásicos de DOS, pero no tan moderna como para perder la sensación retro. Un 486DX2 a 66 MHz sigue teniendo limitaciones, y eso es parte de la gracia.
Tercero, porque permite explicar conceptos históricos muy útiles:
Diferencias entre IBM PC, PS/2 y PS/ValuePoint.
Evolución de ISA, VLB y PCI.
Importancia del disco IDE.
Papel de MS-DOS y Windows 3.1.
Primeros pasos del PC multimedia.
Tarjetas de sonido compatibles Sound Blaster.
Configuración manual de memoria convencional, EMS y XMS.
Y cuarto, porque en 86Box podemos recrearlo sin necesidad de tener el hardware real.
Programas recomendados
Además de juegos, podemos instalar software de la época para darle más sentido al proyecto.
Programa
Uso
MS-DOS 6.22
Sistema base clásico
Windows 3.11
Entorno gráfico de la época
Norton Commander
Gestión de archivos
Microsoft Works
Ofimática ligera
WordPerfect
Procesador de textos clásico
Paintbrush
Dibujo básico en Windows
WinZip antiguo
Compresión de archivos
QBasic
Programación básica en DOS
Turbo Pascal
Programación clásica
Borland C++
Desarrollo en C/C++
Doom Setup
Configuración de sonido, teclado y vídeo
Configurar un IBM PS/ValuePoint en 86Box
En esta práctica vamos a crear una máquina virtual en 86Box que simule un IBM PS/ValuePoint basado en 486. Después prepararemos el disco duro, instalaremos MS-DOS, añadiremos soporte para CD-ROM, configuraremos una tarjeta de sonido y dejaremos el sistema listo para instalar juegos y programas clásicos.
Material necesario
Antes de empezar necesitamos:
Elemento
Uso
86Box instalado
Emulador de PC clásico
ROMs de 86Box
Necesarias para arrancar las máquinas
Imagen de disquete de MS-DOS 6.22
Instalación del sistema operativo
Imagen ISO o carpeta con juegos/programas
Software para instalar
Imagen de drivers de Sound Blaster
Para configurar sonido
Imagen o driver de CD-ROM
Por ejemplo OAKCDROM.SYS
Tiempo y paciencia
Muy necesario en informática retro
Importante: 86Box emula hardware de forma más realista que otros emuladores. Eso significa que a veces hay que configurar BIOS, discos, controladoras y drivers como se hacía en los años 90.
Configuración recomendada
Para empezar, recomiendo una configuración equilibrada:
Apartado
Valor recomendado
Máquina
IBM PS/ValuePoint 433DX o 466DX2, si está disponible
CPU
Intel 486DX2 a 66 MHz
RAM
16 MB
Vídeo
SVGA integrado o compatible
Disco duro
IDE de 504 MB
Disquetera
3.5” 1.44 MB
CD-ROM
IDE ATAPI
Sonido
Sound Blaster 16 ISA
Sistema operativo
MS-DOS 6.22 + Windows 3.11
Alternativa
Windows 95 si se quiere probar algo más moderno
86Box sigue actualizándose y ha recibido correcciones relacionadas con modelos IBM PS/ValuePoint, por ejemplo en versiones recientes se mencionan ajustes sobre el vídeo integrado del IBM PS/ValuePoint 433DX/Si.
Paso 1. Crear una nueva máquina en 86Box
Abrimos 86Box y creamos una nueva configuración.
Abrimos 86Box.
Creamos una nueva máquina.
Elegimos una categoría de equipos 486.
Buscamos un modelo relacionado con IBM PS/ValuePoint.
Seleccionamos un modelo como:
IBM PS/ValuePoint 433DX
IBM PS/ValuePoint 466DX2
IBM PS/ValuePoint P60, si queremos probar una configuración más moderna tipo Pentium.
Para este post recomiendo trabajar con un 486DX2, porque es más representativo de la época DOS/Windows 3.1.
Paso 2. Configurar el procesador
En la sección de CPU seleccionamos:
Opción
Valor
Procesador
Intel 486DX2
Velocidad
66 MHz
FPU
Integrada, si usamos DX/DX2
Modo dinámico
Activado si 86Box lo permite
Un 486DX2 a 66 MHz es una configuración excelente para juegos de 1992-1994.
Paso 3. Configurar la memoria RAM
Configuramos la memoria en:
Uso
RAM recomendada
Solo MS-DOS
4 MB u 8 MB
MS-DOS + Windows 3.1
8 MB o 16 MB
Windows 95
16 MB o 32 MB
Para esta práctica usaremos:
16 MB de RAM
Es suficiente para DOS, Windows 3.11 y una buena cantidad de juegos.
Paso 4. Configurar el disco duro
Creamos un disco duro IDE.
Recomendación:
Parámetro
Valor
Tipo
IDE
Tamaño
504 MB
Formato
Imagen nueva
Uso
Sistema operativo + juegos
¿Por qué 504 MB? Porque muchos equipos antiguos tenían limitaciones de BIOS con discos grandes. Para evitar problemas, es mejor empezar con un disco pequeño y compatible. En conversaciones de usuarios reales sobre PS/ValuePoint se mencionan límites prácticos cercanos a 500 MB en algunos modelos 6382.
Paso 5. Añadir disquetera
Configuramos una disquetera:
Opción
Valor
Unidad A:
3.5” 1.44 MB
Imagen inicial
Disco 1 de MS-DOS 6.22
Esto nos permitirá arrancar el instalador de MS-DOS.
Paso 6. Añadir CD-ROM
Añadimos una unidad de CD-ROM IDE/ATAPI.
Opción
Valor recomendado
Tipo
IDE ATAPI CD-ROM
Canal
Secundario maestro, si está disponible
Uso
Instalar juegos, drivers y Windows
Si el CD-ROM no aparece dentro de DOS, no es un fallo raro. En MS-DOS hay que cargar un driver en CONFIG.SYS y después MSCDEX.EXE en AUTOEXEC.BAT.
Paso 7. Configurar tarjeta de sonido
Añadimos una tarjeta de sonido compatible.
Recomendación:
Opción
Valor
Tarjeta
Sound Blaster 16
Puerto
220
IRQ
5 o 7
DMA
1
High DMA
5
MPU-401
330
Configuración típica:
BLASTER=A220 I5 D1 H5 P330 T6
Esta configuración será importante para juegos como Doom, Duke Nukem II o Monkey Island 2.
Paso 8. Primer arranque
Montamos el primer disquete de MS-DOS 6.22 y arrancamos la máquina.
Si todo va bien, aparecerá el instalador de MS-DOS.
Si aparece un error del tipo “no boot disk” o “no system disk”, revisamos:
Que el disquete esté montado en la unidad A:
Que el orden de arranque permita arrancar desde disquete.
Que la imagen del disquete sea arrancable.
Que la máquina tenga una disquetera configurada.
Crear partición con FDISK
Si el disco está vacío, MS-DOS necesitará crear una partición.
Desde el disquete de arranque podemos ejecutar:
FDISK
Dentro de FDISK:
Crear partición primaria DOS.
Usar todo el tamaño del disco.
Marcar la partición como activa.
Salir de FDISK.
Reiniciar la máquina.
Importante: después de crear la partición hay que reiniciar. Si no reiniciamos, DOS puede no reconocer correctamente el disco.
Formatear el disco duro
Después de reiniciar con el disquete de DOS, ejecutamos:
FORMAT C: /S
Esto formatea el disco C: y copia los archivos básicos del sistema para que pueda arrancar.
Cuando termine, podemos poner una etiqueta al disco, por ejemplo:
VALUEPOINT
Instalar MS-DOS
Ejecutamos el instalador desde el disquete:
A: SETUP
Seguimos los pasos del instalador e iremos cambiando los disquetes cuando nos lo pida.
Al finalizar, quitamos el disquete y reiniciamos.
Si todo ha ido bien, el sistema arrancará desde el disco duro C:.
Configurar el CD-ROM en MS-DOS
Para que MS-DOS detecte el CD-ROM necesitamos un driver. Uno de los más habituales es:
OAKCDROM.SYS
Podemos copiarlo a una carpeta, por ejemplo:
C:\CDROM
Creamos la carpeta:
MD C:\CDROM
Copiamos el driver:
COPY A:\OAKCDROM.SYS C:\CDROM
Editamos CONFIG.SYS:
EDIT C:\CONFIG.SYS
Añadimos:
DEVICE=C:\CDROM\OAKCDROM.SYS /D:MSCD001
Ahora editamos AUTOEXEC.BAT:
EDIT C:\AUTOEXEC.BAT
Añadimos:
C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D
Reiniciamos.
Si todo va bien, el CD-ROM aparecerá como unidad D:.
Configurar memoria para juegos
Muchos juegos de DOS necesitan memoria convencional libre. Podemos mejorar la configuración usando HIMEM.SYS y EMM386.EXE.
Una de las formas más cómodas de pasar archivos desde nuestro equipo moderno a una máquina emulada en 86Box es crear una imagen ISO. Esta imagen se comportará como si fuera un CD-ROM real dentro del ordenador emulado.
Para hacerlo podemos utilizar ImgBurn, una herramienta clásica para crear y grabar imágenes de disco. Aunque su interfaz tiene un aspecto algo antiguo, sigue siendo muy útil para este tipo de tareas retro.
La idea es sencilla: primero preparamos una carpeta en nuestro ordenador con todos los archivos que queremos llevar a MS-DOS o Windows 9x, y después convertimos esa carpeta en un archivo .iso.
Por ejemplo, podemos crear una carpeta llamada:
C:\CD_86BOX
Dentro de esa carpeta podemos meter juegos, drivers, utilidades, instaladores o cualquier archivo que queramos usar dentro de la máquina virtual:
Una vez preparada la carpeta, abrimos ImgBurn y seleccionamos la opción:
Create image file from files/folders
Esta opción permite crear una imagen ISO a partir de una carpeta de nuestro disco duro.
Después añadimos la carpeta que hemos preparado, elegimos dónde queremos guardar la imagen ISO resultante y pulsamos el botón para crearla. Por ejemplo, podemos guardar el archivo como:
C:\ISOS\cd_86box.iso
Cuando termine el proceso, ya tendremos un CD-ROM virtual listo para usar en 86Box.
Instalación de Windows 3.11 desde una ISO de CD-ROM
Una vez que el IBM PS/ValuePoint ya tiene MS-DOS instalado, el siguiente paso lógico es añadir un entorno gráfico clásico. Para este proyecto vamos a instalar Windows 3.11 desde una imagen ISO montada como CD-ROM en 86Box.
Aunque Windows 3.11 se distribuía normalmente en disquetes, para trabajar de forma más cómoda en el emulador podemos preparar una ISO con los archivos de instalación. Esto facilita mucho el proceso, evita tener que cambiar disquetes constantemente y nos permite tener en un único CD virtual tanto Windows como drivers, utilidades y pequeños programas de la época.
Requisitos previos
Antes de empezar, el sistema debe tener:
Elemento
Estado necesario
MS-DOS
Instalado y arrancando desde C:
CD-ROM
Detectado como unidad D:
Driver CD-ROM
OAKCDROM.SYS cargado en CONFIG.SYS
MSCDEX
Cargado en AUTOEXEC.BAT
Ratón
Recomendable, aunque no imprescindible
RAM
Mínimo 4 MB, recomendado 8 MB o 16 MB
Para comprobar que el CD-ROM funciona, desde DOS podemos escribir:
D: DIR
Si aparece el contenido del CD, ya podemos continuar con la instalación.
Durante la instalación de Windows para Trabajo en Grupo 3.11, Microsoft solicitaba un nombre de usuario, una organización y un número de producto. Este número venía normalmente en la tarjeta de registro, en la documentación original o en el material incluido con la licencia del programa.
A diferencia de las versiones modernas de Windows, este número no funcionaba como una activación online. En aquella época no existía todavía el sistema de validación por Internet que asociamos a Windows XP, Windows 10 o Windows 11. El instalador simplemente pedía el dato como parte del proceso de registro e identificación del producto.
Esto refleja muy bien cómo era el software comercial de principios de los años 90: el control de licencia dependía mucho más de la documentación física, los manuales, los certificados de autenticidad, las etiquetas y los disquetes o CD originales. El número de producto servía para identificar la copia instalada y facilitar el soporte técnico, pero el sistema no se conectaba a ningún servidor para comprobarlo.
En nuestro caso, dentro del laboratorio retro con 86Box, esta pantalla resulta curiosa porque nos recuerda una época en la que instalar Windows era también un pequeño ritual: escribir el nombre, la empresa, el número del producto, elegir componentes, seleccionar el tipo de pantalla, configurar impresoras y terminar arrancando el clásico Administrador de programas.
Una vez instalado ponemos en la terminal:
win
Instalar DOOM desde una imagen de CD
Para instalar DOOM en nuestro IBM PS/ValuePoint emulado con 86Box, he optado por un método sencillo y bastante cómodo: crear una imagen ISO con los archivos del juego y montarla como si fuera un CD-ROM dentro de la máquina virtual.
Una vez creada la ISO y configurado correctamente el lector de CD-ROM en MS-DOS, el sistema detecta la unidad como D:. Desde ahí podemos comprobar el contenido del disco con:
D: DIR
En este caso, la imagen contiene directamente los archivos del juego, así que no necesitamos un instalador complejo. Basta con crear una carpeta en el disco duro de la máquina y copiar allí el contenido del CD.
Por ejemplo:
C: CD \ MD DOOM COPY D:\*.* C:\DOOM
Si el juego está dentro de una carpeta del CD, por ejemplo D:\DOOM, usaríamos:
C: CD \ MD DOOM COPY D:\DOOM\*.* C:\DOOM
Después entramos en la carpeta del juego:
CD \DOOM DIR
Y buscamos el ejecutable principal. Normalmente encontraremos archivos como:
DOOM.EXE SETUP.EXE README.TXT
Antes de jugar conviene ejecutar el programa de configuración:
SETUP
Desde ahí podemos ajustar el sonido, la música y los controles. En una máquina emulada es habitual tener que probar varias opciones de sonido hasta encontrar la que mejor funciona.
Finalmente, para ejecutar el juego:
DOOM
Si el juego arranca pero no reconoce el ratón, no es un fallo de DOOM: MS-DOS necesita tener cargado previamente un controlador de ratón, como CTMOUSE.EXE o MOUSE.COM. Que el ratón funcione en Windows 3.11 no significa necesariamente que esté disponible también para los juegos de DOS.
Este método de instalación es muy práctico porque nos permite preparar los archivos cómodamente desde nuestro ordenador actual, crear una ISO y usarla en 86Box como si fuera un CD real. Para un proyecto retro, además, mantiene bastante bien la sensación de estar trabajando con hardware y software de la época.
En este primer módulo vamos a sentar las bases del curso. Antes de aprender a hacer README, manuales, esquemas o documentación profesional, es importante entender qué es realmente la documentación técnica, por qué es tan importante y por qué en tantos proyectos termina siendo un desastre o directamente no existe.
La idea de esta unidad es que el alumno comprenda que documentar no es “rellenar papel”, sino una parte fundamental del trabajo técnico. Un proyecto mal documentado puede convertirse en un problema incluso aunque técnicamente esté bien hecho.
En este módulo se trabajará:
qué es la documentación técnica
por qué suele fallar la documentación en proyectos reales
diferencias entre documentar para uno mismo, para un equipo y para un cliente
tipos de documentación en informática
¿Qué es la documentación técnica?
La documentación técnica es el conjunto de textos, esquemas, instrucciones, referencias y evidencias que explican cómo funciona un sistema, cómo se instala, cómo se usa, cómo se mantiene o cómo se ha construido.
Dicho de forma sencilla: la documentación técnica sirve para que una persona pueda entender, usar, mantener, revisar o continuar un trabajo técnico sin depender totalmente de quien lo creó.
Ejemplos de documentación técnica
En informática, documentación técnica puede ser por ejemplo:
un README de un proyecto en GitHub
un manual de instalación de un servidor
una guía de despliegue de una aplicación
un documento con la arquitectura de una red
un procedimiento para hacer copias de seguridad
una memoria técnica de un proyecto
un informe de auditoría o de incidencia
una wiki interna con procesos y configuraciones
¿Por qué es tan importante documentar?
Porque en el mundo real los proyectos no viven solo el día que se crean.
Un proyecto técnico normalmente pasa por varias fases:
se diseña
se implementa
se prueba
se entrega
se mantiene
se modifica
se corrige
se reutiliza o amplía
Si no existe documentación, todo depende de la memoria de una persona. Y eso provoca errores, pérdida de tiempo, dependencia del autor original y muchos problemas cuando hay que revisar o retomar el trabajo.
Una idea clave
Un proyecto sin documentación puede funcionar hoy, pero convertirse en un problema mañana.
¿Qué suele pasar en los proyectos reales?
En muchísimos proyectos la documentación falla por motivos muy parecidos.
Problemas habituales
no se documenta desde el principio
se deja “para el final”
se escribe deprisa y sin estructura
se da por hecho que cosas importantes “ya se entienden”
se documenta pensando solo en quien lo ha hecho
la documentación se queda desactualizada
no se distingue entre tipos de documento
se mezcla información técnica, organizativa y personal sin orden
no se incluyen evidencias, validaciones ni contexto
Resultado de todo esto
Al final aparecen documentos que:
no sirven para instalar nada
no explican bien el proyecto
no ayudan a otra persona
no permiten reproducir el trabajo
quedan abandonados
generan confusión en lugar de ayudar
Documentar no es escribir mucho
Uno de los errores más frecuentes es pensar que “más texto” significa “mejor documentación”.
No siempre es así.
Una buena documentación no tiene por qué ser enorme. Tiene que ser:
clara
ordenada
útil
precisa
fácil de consultar
pensada para quien la va a leer
Hay documentación breve que funciona muy bien, y documentación larguísima que no sirve para nada.
¿Para quién se documenta?
Esta es una de las preguntas más importantes del módulo.
No se documenta igual para todos los destinatarios. La forma de documentar cambia mucho según quién va a leer el documento.
Documentar para uno mismo
Cuando una persona documenta para sí misma, normalmente busca:
recordar pasos
guardar comandos
anotar configuraciones
dejar registro de errores y soluciones
construir una base de conocimiento personal
Características habituales
más libertad en el formato
lenguaje más directo
menos contexto general
más valor práctico inmediato
organización pensada para el propio autor
Ejemplo
Una nota en Obsidian con comandos para configurar Apache y MySQL en Ubuntu.
Documentar para un equipo
Cuando se documenta para un equipo, la documentación debe ser más clara, más ordenada y más estandarizada.
Aquí ya no basta con que “yo lo entienda”. Tiene que entenderlo otra persona que quizá no estuvo presente durante el proceso.
Características habituales
lenguaje más claro y neutral
estructura estable
pasos reproducibles
mayor precisión
contexto suficiente
convenciones compartidas
mantenimiento continuo
Ejemplo
Una guía interna para desplegar una aplicación web en un servidor de pruebas.
Documentar para un cliente o para una entrega formal
Aquí la documentación debe tener además una presentación más cuidada y una explicación más completa del contexto, objetivos y resultados.
Características habituales
tono más profesional
mejor presentación visual
organización muy clara
explicación de objetivos, alcance y resultados
vocabulario comprensible para perfiles no tan técnicos
formato más formal: Word, PDF, memoria, informe, etc.
Ejemplo
La memoria técnica de un proyecto final, con portada, índice, imágenes, fases, decisiones técnicas y conclusiones.
Comparativa rápida
Tipo de documentación
Destinatario
Objetivo principal
Estilo habitual
Personal
Uno mismo
Recordar y reutilizar
Directo y práctico
De equipo
Compañeros o técnicos
Compartir conocimiento y mantener procesos
Claro, estructurado y reproducible
Formal o de cliente
Profesorado, cliente, responsables, tribunal
Explicar, justificar y entregar
Profesional, completo y bien presentado
Tipos de documentación en informática
En informática no existe un solo tipo de documentación. Hay varias categorías, y cada una cumple una función diferente.
Entender esto es muy importante porque muchos errores vienen de mezclarlo todo en un solo documento.
1. Documentación de producto
Es la documentación que explica un producto, una aplicación, un sistema o una herramienta concreta.
Suele incluir
qué es
para qué sirve
cómo se instala
cómo se configura
cómo se usa
qué requisitos tiene
qué estructura interna presenta
Ejemplos
README de una aplicación
manual de usuario técnico
documentación de API
guía de instalación de software
2. Documentación de proceso
Explica cómo se realiza una tarea o un conjunto de tareas.
No se centra tanto en “qué es el producto”, sino en qué pasos hay que seguir para hacer algo correctamente.
Suele incluir
objetivo del proceso
requisitos previos
secuencia de pasos
validación
problemas frecuentes
resultado esperado
Ejemplos
procedimiento de despliegue
guía de copia de seguridad
proceso de alta de usuarios
checklist de hardening
guía de restauración de servicios
3. Documentación operativa
Es la documentación que sirve para operar, administrar o mantener sistemas en funcionamiento.
Está muy relacionada con ASIR, sistemas, administración, redes y explotación técnica.
Suele incluir
configuraciones
servicios
puertos
rutas
comandos
validaciones
acciones de mantenimiento
actuación ante fallos
Ejemplos
runbook de administración
guía de reinicio de servicios
procedimientos de monitorización
documentación de una infraestructura de red
inventario técnico de máquinas o servicios
4. Documentación de soporte
Es la documentación pensada para resolver dudas, incidencias o problemas recurrentes.
Suele incluir
preguntas frecuentes
errores comunes
pasos de comprobación
diagnósticos básicos
soluciones conocidas
Ejemplos
FAQ técnica
base de conocimiento
guía de resolución de incidencias
documentación de errores frecuentes
5. Documentación académica y de entrega
Es muy habitual en entornos educativos, proyectos fin de ciclo, memorias, prácticas guiadas y entregas técnicas.
Aquí no solo importa el funcionamiento, sino también explicar el proceso, justificar decisiones y demostrar el trabajo realizado.
Suele incluir
introducción
objetivos
análisis
requisitos
diseño
implementación
capturas
pruebas
conclusiones
bibliografía o referencias
Ejemplos
memoria de TFG o TFM
entrega de una práctica técnica
informe de laboratorio
documentación de un proyecto de clase
6. Documentación viva vs. documentación abandonada
Este punto es especialmente importante.
Documentación viva
Es la que se mantiene actualizada y sigue siendo útil con el paso del tiempo.
Características
se revisa
se corrige
se adapta a cambios
refleja el estado real del proyecto
acompaña al trabajo técnico
Documentación abandonada
Es la que se escribió una vez y nunca más se revisó.
Problemas típicos
comandos que ya no sirven
capturas antiguas
rutas que han cambiado
versiones desactualizadas
información incompleta o engañosa
Idea importante
Una documentación antigua puede ser peor que no tener documentación, porque da una falsa sensación de confianza.
Ejemplo sencillo para entenderlo
Imagina una práctica donde un alumno monta un servidor web con Apache, PHP y MySQL.
Si documenta bien:
explica requisitos
indica comandos
organiza pasos
muestra validaciones
añade errores encontrados
incluye estructura del proyecto
deja claro cómo reproducirlo
Si documenta mal:
pone cuatro comandos sueltos
no indica orden
no explica qué instaló realmente
no muestra resultado
no aclara versiones ni rutas
no se entiende qué hizo ni cómo repetirlo
Técnicamente puede haber hecho lo mismo, pero el valor del trabajo cambia muchísimo.
Errores muy frecuentes al empezar a documentar
Estos errores conviene enseñarlos desde el principio:
escribir pensando “ya me acordaré”
no poner títulos claros
mezclar teoría y práctica sin orden
usar frases ambiguas
copiar comandos sin explicar para qué sirven
no validar resultados
no anotar problemas reales
no diferenciar entre borrador y versión final
documentar solo el resultado y no el proceso
Ejemplos
Caso
Tipo de documentación
Destinatario
Observación
README de instalación
Documentación de producto
Usuario técnico o desarrollador
Explica qué es y cómo usarlo
Documento en Word con memoria
Documentación académica y de entrega
Profesorado, cliente o tribunal
Presentación formal
Nota de Obsidian con comandos
Documentación personal u operativa
Uno mismo
Uso interno y práctico
Guía de despliegue en Apache
Documentación de proceso u operativa
Equipo técnico
Procedimiento reproducible
Lista de errores frecuentes
Documentación de soporte
Usuarios o técnicos
Ayuda a resolver incidencias
Documento obsoleto
Documentación abandonada
Puede confundir a cualquiera
No refleja la realidad actual
Ideas clave para recordar
Documentar no es decorar un proyecto: es hacerlo comprensible y mantenible.
Una buena documentación ayuda a repetir, mantener, explicar y mejorar un trabajo técnico.
No toda la documentación sirve para lo mismo: hay que elegir bien el tipo de documento.
La documentación útil está pensada para quien la va a leer.
Una documentación sin mantenimiento termina perdiendo valor.
Caso de uso: despliegue de una aplicación web interna para gestión de incidencias
Una pequeña empresa llamada NetSecure Solutions necesita una aplicación web interna para que el equipo técnico pueda registrar incidencias informáticas, asignarlas a distintos técnicos y hacer seguimiento de su resolución.
Un desarrollador del equipo ha creado una primera versión de la aplicación usando:
PHP
MySQL
Apache
JavaScript
HTML y CSS
La aplicación funciona, pero ahora surge un problema habitual en muchos proyectos técnicos:
el sistema debe instalarse también en otro servidor
otros técnicos tienen que poder mantenerlo
un responsable debe entender qué incluye el proyecto
si aparece un error, alguien debe saber cómo revisarlo
si el desarrollador original no está, el trabajo debe poder continuar
Para evitar depender únicamente de la memoria del autor, el equipo decide crear una documentación técnica completa del proyecto.
¿Qué documentación necesitarían?
En este caso podrían necesitar, por ejemplo:
un README principal para explicar el proyecto
una guía de instalación para desplegarlo en otro equipo
una guía de configuración de la base de datos
una documentación de estructura del proyecto
una guía operativa para revisar logs y reiniciar servicios
una base de incidencias frecuentes
una memoria técnica para presentar el proyecto a dirección o a un cliente
¿Por qué este caso de uso es bueno para el módulo?
Porque permite ver claramente que:
no toda la documentación sirve para lo mismo
un único documento no siempre es suficiente
el destinatario cambia según el documento
un proyecto técnico necesita más de un tipo de documentación
Ejemplo de índice
A continuación tienes un índice de ejemplo para la documentación de este proyecto ficticio. Te puede servir para enseñar a los alumnos cómo se organiza un documento técnico amplio.
Índice de ejemplo: Documentación técnica del proyecto “NetSecure Tickets”
1. Introducción
1.1. Descripción general del proyecto 1.2. Objetivo de la aplicación 1.3. Alcance del sistema 1.4. Público al que va dirigida esta documentación
2. Visión general del proyecto
2.1. Problema que resuelve 2.2. Funcionalidades principales 2.3. Tecnologías utilizadas 2.4. Estructura general de funcionamiento
3. Requisitos previos
3.1. Requisitos de hardware 3.2. Requisitos de software 3.3. Versiones recomendadas 3.4. Dependencias necesarias
4. Instalación del entorno
4.1. Instalación de Apache 4.2. Instalación de PHP 4.3. Instalación de MySQL 4.4. Configuración inicial del servidor 4.5. Verificación del entorno
5. Despliegue de la aplicación
5.1. Copia de archivos del proyecto 5.2. Estructura de carpetas 5.3. Configuración de conexión a base de datos 5.4. Importación de la base de datos 5.5. Prueba inicial de funcionamiento
6. Uso básico de la aplicación
6.1. Pantalla principal 6.2. Registro de incidencias 6.3. Consulta de incidencias 6.4. Asignación a técnicos 6.5. Cierre de incidencias
7. Estructura técnica del proyecto
7.1. Organización de archivos 7.2. Archivos principales 7.3. Relación entre frontend y backend 7.4. Base de datos y tablas utilizadas
8. Procedimientos operativos
8.1. Reinicio de servicios 8.2. Revisión de logs 8.3. Copia de seguridad de la base de datos 8.4. Restauración básica 8.5. Comprobaciones de estado
9. Incidencias frecuentes
9.1. Error de conexión a MySQL 9.2. Error 403 o 404 en Apache 9.3. Problemas con permisos de archivos 9.4. Fallos al cargar estilos o scripts 9.5. Errores comunes y solución
10. Mejoras futuras
10.1. Autenticación de usuarios 10.2. Panel de administración 10.3. Exportación de incidencias 10.4. Sistema de avisos por correo
11. Conclusiones
11.1. Resultado obtenido 11.2. Valor del sistema 11.3. Posibles ampliaciones
En el módulo anterior vimos qué es la documentación técnica, por qué es importante y qué tipos de documentación existen en informática. Ahora toca dar un paso más: entender qué hace que una documentación sea realmente buena.
Porque no basta con documentar. También hay que documentar bien.
En este módulo el alumno aprenderá cuáles son los principios que convierten un documento técnico en algo útil, claro y profesional. También verá errores muy frecuentes al redactar documentación y aprenderá a detectarlos y corregirlos.
En esta unidad se trabajará:
claridad
precisión
estructura
consistencia
legibilidad
errores comunes al redactar documentos técnicos
¿Qué significa documentar bien?
Documentar bien significa crear un documento que otra persona pueda leer y usar sin perder tiempo, sin interpretar cosas ambiguas y sin tener que preguntarle constantemente al autor.
Una buena documentación técnica debe ayudar a responder preguntas como estas:
¿qué es esto?
¿para qué sirve?
¿cómo se instala?
¿cómo se usa?
¿qué pasos hay que seguir?
¿qué requisitos tiene?
¿cómo sé si funciona?
¿qué hago si falla?
Si el documento no ayuda a responder este tipo de preguntas, entonces probablemente está incompleto o mal planteado.
Idea clave del módulo
Una documentación técnica no se valora por lo mucho que ocupa, sino por lo útil que resulta.
1. Claridad
La claridad es uno de los pilares más importantes de cualquier documentación técnica.
Un documento claro permite que el lector entienda rápido lo que se le está explicando. No obliga a releer varias veces una frase ni a deducir lo que el autor quería decir.
Una documentación clara:
usa frases directas
evita rodeos innecesarios
explica cada paso de forma comprensible
separa bien las ideas
no mezcla demasiadas cosas en el mismo apartado
Ejemplo poco claro
Aquí habría que configurar el servidor para que funcione correctamente según lo que se necesite.
Ejemplo más claro
Edita el archivo de configuración de Apache y cambia el puerto de escucha a 8080. Después reinicia el servicio con systemctl restart apache2.
En el segundo caso, el lector sabe exactamente qué hacer.
2. Precisión
La claridad no basta si el documento no es preciso.
La precisión consiste en explicar las cosas de forma concreta, exacta y verificable.
Una documentación precisa:
indica rutas reales
usa nombres correctos
menciona versiones cuando importa
diferencia comandos parecidos
evita expresiones vagas como “lo normal”, “más o menos”, “si hace falta”, “como siempre”
Ejemplo impreciso
Instala la base de datos y configura el usuario.
Ejemplo preciso
Instala MySQL Server, crea la base de datos inventario, y después crea el usuario appuser con permisos sobre esa base de datos.
La segunda versión reduce dudas y mejora la reproducibilidad.
3. Estructura
Muchas veces un documento falla no porque su contenido sea malo, sino porque está mal organizado.
Un texto técnico necesita una estructura lógica. El lector debe saber dónde empieza una idea, dónde están los pasos, dónde están los requisitos y dónde están los problemas frecuentes.
Una buena estructura suele separar:
introducción o contexto
objetivo
requisitos previos
pasos a realizar
validación
errores frecuentes
conclusiones o siguientes pasos
Problema muy común
Hay documentación donde se mezclan:
teoría
comandos
capturas
opiniones
errores
resultados
…todo ello sin ningún orden.
Eso hace que el lector tenga que “buscar” la información en lugar de encontrarla de forma natural.
Ejemplo de estructura básica útil
1. Objetivo
Qué se va a hacer.
2. Requisitos previos
Qué hace falta antes de empezar.
3. Procedimiento
Pasos ordenados.
4. Validación
Cómo comprobar que ha salido bien.
5. Problemas frecuentes
Qué errores pueden aparecer.
6. Resultado final
Qué se ha conseguido.
4. Consistencia
La consistencia significa mantener el mismo criterio a lo largo de todo el documento.
Por ejemplo:
usar siempre los mismos nombres para las mismas cosas
no cambiar de estilo en cada apartado
seguir la misma lógica en títulos y subtítulos
mantener el mismo formato para comandos, rutas, tablas y notas
Ejemplo de falta de consistencia
En una parte del documento escribes:
Base de datos
Usuario administrador
Carpeta del proyecto
Y más adelante escribes:
BD
admin
directorio principal
Aunque no parezca grave, este tipo de cambios genera confusión.
También afecta al formato
Por ejemplo, no conviene que en una parte los comandos estén así:
sudo apt update
y más adelante aparezcan mezclados dentro del texto sin destacar, o que unas rutas lleven formato y otras no.
La consistencia da sensación de orden y profesionalidad.
5. Legibilidad
La legibilidad tiene que ver con lo fácil que resulta leer y recorrer el documento.
No solo importa lo que se dice, sino cómo se presenta.
Mejora la legibilidad:
usar títulos claros
crear apartados cortos
usar listas cuando conviene
separar bloques de código
dejar espacio entre secciones
usar tablas si ayudan a resumir
destacar notas importantes
no escribir párrafos gigantescos
Ejemplo de mala legibilidad
Un texto largo, sin subtítulos, con comandos mezclados dentro de frases muy extensas.
Ejemplo de buena legibilidad
Un documento con:
apartados definidos
comandos en bloques
pasos numerados
advertencias visibles
ejemplos separados del texto principal
La legibilidad es especialmente importante en documentación técnica porque muchas veces no se lee de principio a fin: se consulta por partes.
6. Orientación al lector
Una documentación técnica no debe escribirse pensando solo en quien la redacta. Debe escribirse pensando en quien la va a usar.
Eso significa que el documento debe adaptarse al perfil del lector.
No es lo mismo escribir para:
uno mismo
un compañero técnico
un profesor
un cliente
un usuario final
Ejemplo
Si documentas una práctica para alumnos principiantes, probablemente debas incluir:
más contexto
pasos más detallados
explicaciones de comandos
ejemplos visuales
Si documentas para un equipo técnico experto, quizá puedas ser más directo y conciso.
7. Reproducibilidad
Una de las mejores formas de medir la calidad de una documentación técnica es esta:
¿Otra persona podría repetir el proceso con ese documento?
Si la respuesta es no, entonces la documentación no está cumpliendo bien su función.
Para que un documento sea reproducible debe incluir:
requisitos previos
pasos en orden
comandos completos
rutas correctas
parámetros importantes
validación de resultado
contexto mínimo
Ejemplo
No basta con poner:
Configura Apache para el proyecto.
Eso no es reproducible.
Es mejor algo como:
Copia el proyecto a /var/www/html/app.
Edita el archivo de virtual host.
Define DocumentRoot /var/www/html/app.
Activa el sitio.
Reinicia Apache.
Comprueba el acceso desde el navegador.
8. Mantenibilidad
Una buena documentación no debe servir solo hoy. También debe poder mantenerse con cierta facilidad.
Una documentación mantenible:
está bien organizada
tiene secciones reutilizables
se puede actualizar sin rehacerla entera
separa lo estable de lo que cambia mucho
evita repeticiones innecesarias
Ejemplo
Si una versión del software cambia con frecuencia, conviene que la documentación tenga una sección concreta para versiones o requisitos, en lugar de repartir esa información por todo el documento.
Errores comunes al redactar documentación técnica
Ahora vamos a ver algunos de los errores más frecuentes. Esta parte suele ayudar mucho a los alumnos porque les permite reconocer fallos típicos que ellos mismos cometen al empezar.
Error 1. Dar cosas por supuestas
El autor sabe lo que ha hecho y cree que el lector también lo entenderá.
Ejemplo
Configuramos el servicio como siempre y continuamos con la instalación.
Problema: ¿Como siempre según quién? Eso solo lo entiende quien lo escribió.
Error 2. Escribir pasos incompletos
A veces se omiten pasos porque parecen obvios.
Ejemplo
Importa la base de datos y ejecuta la aplicación.
Pero quizá falta indicar:
qué archivo SQL usar
con qué usuario
sobre qué base de datos
en qué orden hacerlo
Error 3. No validar resultados
Muchos alumnos ponen comandos, pero no indican cómo comprobar que funcionó.
Ejemplo
Instala Apache.
Bien, pero falta decir:
cómo comprobar que está activo
qué comando usar
qué respuesta esperar
qué debería verse en navegador
Error 4. Mezclar demasiadas cosas en el mismo apartado
Por ejemplo, juntar en una misma sección:
teoría
comandos
explicación de errores
decisiones de diseño
conclusiones
Esto vuelve la documentación caótica.
Error 5. Usar frases ambiguas
Ejemplos típicos
“configura lo necesario”
“haz los cambios correspondientes”
“instala lo que falte”
“corrige los errores si aparecen”
Este tipo de redacción parece técnica, pero en realidad aporta muy poca información útil.
Error 6. No adaptar el nivel de detalle
A veces la documentación es tan breve que no sirve. Otras veces tiene tanto detalle irrelevante que entorpece la lectura.
Hay que encontrar el nivel adecuado según el público y el objetivo.
Error 7. No diferenciar entre borrador y documentación final
Una lista rápida de notas personales no es lo mismo que una guía lista para entregar o compartir.
Es importante enseñar al alumno que documentar también implica revisar, ordenar y pulir.
Cómo mejorar una mala documentación
Una buena forma de enseñar este módulo es mostrar que mejorar documentación no siempre significa reescribir todo desde cero.
Muchas veces basta con aplicar una revisión guiada.
Preguntas de revisión útiles
Antes de dar un documento por bueno, conviene revisar:
¿se entiende el objetivo?
¿queda claro para quién está escrito?
¿los pasos están ordenados?
¿faltan requisitos previos?
¿hay validación?
¿hay frases ambiguas?
¿se usan siempre los mismos términos?
¿se puede localizar rápido cada parte?
¿otra persona podría repetir el proceso?
Ejemplo práctico: de documentación deficiente a documentación útil
Versión deficiente
Instalamos el servidor, cambiamos unas cosas de configuración y luego metemos la base de datos. Después ya se puede probar el proyecto. Si da error habrá que revisar permisos o la conexión.
Versión mejorada
Instalación del entorno
Instala Apache con el comando:
sudo apt install apache2 -y
Instala MySQL Server:
sudo apt install mysql-server -y
Crea la base de datos proyecto_web:
CREATE DATABASE proyecto_web;
Importa el archivo proyecto_web.sql en esa base de datos.
Copia los archivos del proyecto a:
/var/www/html/proyecto_web
Comprueba en el navegador que la aplicación responde correctamente.
Validación
Verifica que Apache esté activo con:
systemctl status apache2
Comprueba que MySQL esté funcionando:
systemctl status mysql
Aquí ya vemos claridad, estructura, precisión y validación.
Qué debe aprender el alumno en este módulo
Al terminar esta unidad, el alumno debe ser capaz de:
identificar si una documentación es clara o confusa
detectar frases ambiguas o imprecisas
organizar mejor un documento técnico
aplicar criterios de consistencia y legibilidad
redactar pasos reproducibles
revisar una documentación para mejorarla antes de entregarla
Resultado práctico del módulo
El alumno analiza una documentación técnica sencilla, detecta sus fallos y la mejora aplicando principios de claridad, precisión, estructura, consistencia y legibilidad.
Actividad propuesta para el módulo
Actividad: detectar y corregir errores de documentación
Lee este fragmento de documentación:
Se instala el servidor web y luego se configura todo para que funcione con la aplicación. Después se mete la base de datos y se comprueba si va bien. Si falla, revisar lo necesario.
Tareas del alumno
Indica qué problemas tiene este texto.
Señala al menos 5 aspectos que deberían mejorarse.
Reescribe el fragmento para convertirlo en una documentación técnica más útil.
Solución orientativa
Problemas detectados
no indica qué servidor web se instala
no explica qué significa “configurar todo”
no especifica cómo se importa la base de datos
no incluye rutas ni comandos
no explica cómo comprobar que funciona
no concreta qué hacer si falla
Reescritura mejorada
Instalación y configuración básica
Instala Apache:
sudo apt install apache2 -y
Copia la aplicación a la carpeta:
/var/www/html/app_incidencias
Crea la base de datos app_incidencias en MySQL.
Importa el archivo app_incidencias.sql.
Edita el archivo de configuración de la aplicación para introducir:
nombre de la base de datos
usuario
contraseña
host
Abre el navegador y accede a la URL del proyecto para comprobar que carga correctamente.
Validación
comprueba el estado de Apache
verifica la conexión con MySQL
revisa permisos de archivos si la aplicación no carga
Caso de uso inventado para este módulo
Imagina que un alumno ha montado una pequeña aplicación de gestión de tareas en PHP y MySQL. Quiere entregar la práctica, pero su documentación consiste solo en:
una lista de comandos sueltos
una captura de la web funcionando
una frase que dice “la instalación es sencilla”
una mención rápida a la base de datos
Aunque la aplicación funcione, esa documentación no sería suficiente para:
repetir el despliegue
corregir errores
mantener el proyecto
evaluarlo correctamente
entregarlo de forma profesional
El problema no es solo el contenido técnico, sino cómo está explicado.
Ejemplo de índice para un documento bien estructurado
Índice de ejemplo
Introducción
Objetivo del documento
Requisitos previos
Instalación del entorno
Configuración de la base de datos
Despliegue de la aplicación
Validación del funcionamiento
Problemas frecuentes
Conclusión
Este índice ya muestra una secuencia lógica y fácil de seguir.
Ideas clave para recordar
Una buena documentación debe ser clara, precisa y útil.
Si un paso no se puede repetir, la documentación está incompleta.
Escribir mucho no garantiza documentar bien.
Una estructura ordenada facilita muchísimo el trabajo técnico.
La revisión final forma parte de la documentación.
🎧 Resumen en audio del tema Escucha este audio para repasar las ideas y los objetivos principales de este proyecto antes de continuar o al finalizar la lectura.
En muchas ocasiones, cuando trabajamos redes, sistemas, servidores, Raspberry Pi, sensores, monitorización o ciberseguridad, necesitamos montar pequeños laboratorios de prueba. A veces basta con una máquina virtual, otras veces usamos varias Raspberry, un switch, un router, discos duros, sensores, placas Arduino o algún equipo adicional.
El problema es que estos montajes suelen acabar ocupando demasiado espacio sobre la mesa: cables por todas partes, transformadores, regletas, adaptadores, tarjetas microSD, discos externos, pantallas, teclados, routers, switches y placas sueltas.
Por eso he decidido empezar un proyecto personal que iré documentando paso a paso: construir un laboratorio móvil dentro de una maleta, pensado para poder transportarlo, conectarlo rápidamente y usarlo como herramienta de trabajo en diferentes proyectos de ASIR, redes, sistemas y ciberseguridad.
No se trata de una práctica para que la realicen directamente los alumnos, al menos no en esta primera fase. La idea es construir una herramienta propia que después pueda utilizar en clase, en demostraciones, en laboratorios guiados y en proyectos más avanzados.
¿Qué quiero construir?
La idea inicial es montar una maleta rígida en cuyo interior irán fijados diferentes dispositivos de red y computación. Algunos de los elementos que estoy valorando incluir son:
un router o punto de acceso;
un switch de red;
una o varias Raspberry Pi;
una pantalla integrada;
discos SSD o discos duros externos;
alimentación centralizada;
ventilación;
conectores accesibles desde el exterior;
cableado interno ordenado;
posiblemente sensores, Arduino u otros módulos según evolucione el proyecto.
La intención es que todo quede montado de forma fija, ordenada y segura, evitando tener que sacar y conectar cada elemento cada vez que quiera usar el laboratorio.
La maleta funcionaría como una pequeña infraestructura portátil:
Maleta abierta │ ├── Router / punto de acceso ├── Switch ├── Raspberry Pi ├── Almacenamiento ├── Pantalla ├── Alimentación interna └── Conexiones de red y periféricos
¿Para qué puede servir este laboratorio móvil?
Este proyecto puede tener muchas aplicaciones dentro de la enseñanza de informática, especialmente en ciclos como ASIR y en módulos relacionados con redes, sistemas y ciberseguridad.
Algunas ideas de uso son:
montar una pequeña red aislada para pruebas;
crear un entorno de ciberseguridad controlado;
simular una red de empresa;
desplegar servicios en Raspberry Pi;
practicar escaneos de red con herramientas como Nmap;
montar laboratorios con IDS, SIEM o monitorización;
hacer pruebas con sensores y recogida de datos;
crear un pequeño servidor portátil;
trabajar con copias de seguridad y almacenamiento;
enseñar conceptos de segmentación, servicios, puertos y tráfico de red;
documentar instalaciones reales paso a paso.
No quiero que sea simplemente una “caja con aparatos”. La idea es que sea una plataforma didáctica reutilizable.
Objetivos del proyecto
El objetivo principal es construir un laboratorio portátil, funcional y documentado, que pueda utilizarse en diferentes contextos educativos y técnicos.
Objetivos técnicos
Diseñar una maleta con dispositivos montados de forma fija.
Centralizar la alimentación para evitar múltiples transformadores.
Mantener separada la parte de 230 V AC de la parte de baja tensión DC.
Usar fusibles y protecciones para cada línea de alimentación.
Integrar router, switch, Raspberry Pi y almacenamiento.
Preparar ventilación para evitar problemas de temperatura.
Ordenar el cableado interno de forma clara y mantenible.
Dejar el montaje preparado para futuras ampliaciones.
Objetivos didácticos
Mostrar a los alumnos cómo se planifica un proyecto técnico real.
Documentar decisiones, errores y mejoras.
Enseñar buenas prácticas de montaje, seguridad y organización.
Usar el laboratorio como base para prácticas de redes, sistemas y ciberseguridad.
Crear material reutilizable para futuras clases.
Mostrar que la informática no es solo software: también hay infraestructura, electricidad, hardware, montaje y mantenimiento.
Por qué hacerlo dentro de una maleta
Una maleta rígida permite crear un entorno compacto, transportable y relativamente protegido.
Las ventajas principales son:
Ventaja
Explicación
Portabilidad
Se puede llevar de un aula a otra o guardar fácilmente
Orden
Los dispositivos quedan fijados y cableados
Rapidez
Se abre, se conecta y se empieza a trabajar
Protección
Los equipos quedan más protegidos que si estuvieran sueltos
Reutilización
Sirve para muchos proyectos diferentes
Presentación
Visualmente es más atractivo para explicar conceptos
También tiene inconvenientes que hay que tener en cuenta:
Riesgo
Medida prevista
Calor interno
Añadir ventiladores y rejillas
Exceso de cableado
Usar distribución ordenada y etiquetas
Seguridad eléctrica
Separar 230 V y baja tensión
Mantenimiento
Montar los equipos de forma accesible
Ampliaciones futuras
Dejar espacio libre y conectores preparados
Primera fase: definir la arquitectura
Antes de cortar, atornillar o comprar componentes sin control, la primera fase será definir una arquitectura básica.
La idea inicial podría ser algo así:
Entrada 230 V AC │ ├── Enchufe interno para portátil o cargador auxiliar │ └── Fuente 230 V AC → 12 V DC │ ├── Router 12 V ├── Switch 12 V ├── Ventiladores 12 V └── Conversor 12 V → 5 V └── Raspberry Pi
La parte importante aquí es que no todos los dispositivos funcionan al mismo voltaje.
Por ejemplo:
el router puede necesitar 12 V;
el switch puede necesitar 5 V, 9 V o 12 V;
la Raspberry necesita 5 V;
los ventiladores pueden ir a 5 V o 12 V;
un portátil normalmente necesita su propio cargador a 230 V.
Por tanto, una de las primeras tareas será identificar el consumo real de cada equipo.
Alimentación: una de las partes más importantes
Uno de los puntos más delicados del proyecto es la alimentación eléctrica.
La solución más simple sería meter una regleta dentro de la maleta y conectar todos los transformadores originales, pero no es la opción más limpia ni la más eficiente en espacio.
La solución que estoy valorando es usar una fuente central de 12 V y, desde ahí, repartir la alimentación mediante una caja de fusibles y conversores DC-DC.
Un posible esquema sería:
Fuente 12 V │ ├── Fusible 2 A → Router ├── Fusible 2 A → Switch ├── Fusible 3 A → Conversor 12 V a 5 V → Raspberry ├── Fusible 1 A → Ventiladores └── Fusible 1 A → Pantalla o accesorios
Esto permite tener una instalación más ordenada, pero también obliga a hacerlo con cuidado.
No se trata solo de que “funcione”. Tiene que ser seguro, mantenible y comprensible.
Seguridad antes que estética
Aunque el objetivo es que la maleta quede bien presentada, la prioridad será siempre la seguridad.
Algunas normas que quiero seguir desde el principio:
no dejar conexiones de 230 V expuestas;
usar entrada de corriente con interruptor y fusible;
separar físicamente la zona de alta tensión y la zona de baja tensión;
proteger cada línea de 12 V con su fusible;
usar cable de sección adecuada;
evitar cables finos tipo Arduino para alimentar equipos;
comprobar polaridad y voltaje con multímetro antes de conectar nada;
añadir ventilación;
etiquetar cables y conexiones;
documentar cada cambio.
Esto también forma parte del aprendizaje. Muchas veces en clase enseñamos servicios, comandos, configuraciones y herramientas, pero no siempre se ve la parte física de montar una pequeña infraestructura de forma ordenada.
Posibles usos en ciberseguridad
Uno de los motivos principales para construir esta maleta es poder usarla como base para laboratorios de ciberseguridad.
Algunas posibilidades futuras:
1. Laboratorio de escaneo y reconocimiento
Usar la red interna de la maleta para practicar:
descubrimiento de hosts;
escaneo de puertos;
identificación de servicios;
pruebas con Nmap;
análisis de tráfico.
2. Mini SOC educativo
Integrar herramientas como:
Wazuh;
Suricata;
Grafana;
Prometheus;
logs centralizados;
alertas básicas.
3. Red aislada de pruebas
Crear un entorno donde se puedan levantar máquinas vulnerables o servicios de prueba sin afectar a la red real del aula.
4. Servidor portátil
Una Raspberry con almacenamiento podría actuar como:
servidor web;
servidor de ficheros;
servidor de logs;
panel de control;
repositorio local de documentación o scripts.
5. Simulación de red empresarial
Con router, switch y varios nodos se puede representar una pequeña red con:
clientes;
servidores;
segmentos;
servicios internos;
reglas de firewall;
monitorización.
Documentar el proceso: una parte esencial del proyecto
Este proyecto no solo consistirá en montar la maleta. También quiero documentar cada fase.
La documentación incluirá:
materiales utilizados;
decisiones de diseño;
esquemas de conexión;
pruebas realizadas;
problemas encontrados;
soluciones aplicadas;
fotografías del montaje;
configuraciones de red;
scripts utilizados;
posibles mejoras;
conclusiones de cada fase.
La idea es que cualquier persona que siga el proyecto pueda entender no solo el resultado final, sino también el razonamiento detrás de cada decisión.
Porque en proyectos reales rara vez todo sale perfecto a la primera. Hay que medir, probar, corregir, reorganizar y volver a probar.
Fases previstas del proyecto
Aunque el diseño todavía está abierto, una posible planificación inicial sería la siguiente:
Fase
Descripción
Fase 1
Definir objetivos y componentes iniciales
Fase 2
Elegir la maleta y diseñar la distribución interna
Fase 3
Planificar la alimentación eléctrica
Fase 4
Montar fuente, fusibles y distribución de 12 V
Fase 5
Integrar router, switch y Raspberry Pi
Fase 6
Añadir pantalla y almacenamiento
Fase 7
Configurar red interna y servicios básicos
Fase 8
Preparar primeros laboratorios de prueba
Fase 9
Documentar errores, mejoras y ampliaciones
Fase 10
Usar la maleta en proyectos reales de clase
Esta planificación podrá cambiar. De hecho, seguramente cambiará. Y eso también será parte del valor del proyecto.
Qué componentes estoy valorando
Por ahora, la lista de componentes posibles incluye:
Componente
Función
Maleta rígida
Estructura principal
Router
Crear o gestionar la red
Switch
Conectar varios equipos por cable
Raspberry Pi
Nodo principal de servicios
Pantalla
Visualización local
SSD/HDD
Almacenamiento
Fuente 12 V
Alimentación principal
Conversor 12 V a 5 V
Alimentar Raspberry
Caja de fusibles
Proteger líneas DC
Ventiladores
Refrigeración
Conectores de panel
Acceso externo ordenado
Cableado etiquetado
Mantenimiento
Interruptores
Control de encendido
Voltímetro/amperímetro
Supervisión de consumo
No todos tienen por qué estar desde el primer día. La idea es empezar con una base sencilla y hacerla crecer.
Qué quiero conseguir al final
Al terminar el proyecto me gustaría tener una herramienta que pueda abrir en clase y utilizar directamente.
Algo parecido a esto:
Abrir maleta │ ├── Conectar alimentación ├── Encender router/switch/Raspberry ├── Levantar servicios ├── Conectar portátil ├── Acceder al panel o terminal └── Empezar la práctica
Un laboratorio listo para trabajar.
No sustituirá a Proxmox, VirtualBox, Docker o las máquinas virtuales, pero sí puede complementarlas muy bien. Aporta algo físico, visible y tangible, que ayuda mucho cuando se explican redes, sistemas y seguridad.
Por qué merece la pena documentarlo
Este tipo de proyectos tienen un valor especial porque mezclan muchas áreas:
hardware;
redes;
sistemas;
electricidad básica;
Linux;
documentación;
seguridad;
automatización;
diseño;
resolución de problemas.
Es exactamente el tipo de proyecto que permite enseñar que la informática real no está formada por piezas aisladas. Todo se conecta con todo.
Un router no es solo un aparato con antenas. Una Raspberry no es solo una placa pequeña. Un switch no es solo una caja con puertos. Una fuente de alimentación no es un detalle secundario. Y una buena documentación no es un trámite: es lo que permite entender, mantener y mejorar el sistema.
Próximos pasos
En las siguientes entradas iré publicando el avance del proyecto.
Algunos de los próximos temas serán:
elección de la maleta;
diseño de la distribución interna;
elección de la fuente de alimentación;
montaje de la caja de fusibles;
conexión del router y el switch;
alimentación de la Raspberry;
integración de pantalla;
montaje del almacenamiento;
ventilación;
primeras pruebas de red;
primeras prácticas de ciberseguridad.
La idea es que este artículo sea el punto de partida de una serie. No quiero presentar solo el resultado final, sino todo el camino.
Conclusión
Este proyecto nace de una necesidad muy concreta: disponer de un laboratorio móvil, compacto y reutilizable para trabajar redes, sistemas y ciberseguridad de una forma más práctica y visual.
Todavía está en construcción. Algunas decisiones cambiarán, aparecerán problemas y seguramente habrá que rediseñar partes del montaje. Pero precisamente eso es lo interesante: convertir el proceso en aprendizaje.
A partir de aquí comienza la construcción del Laboratorio Móvil de Ciberseguridad.
Un proyecto para aprender, probar, equivocarse, mejorar y, sobre todo, llevar la práctica técnica un paso más allá.
Especificaciones para Montaje de Maleta-Laboratorio Electrónica
Elemento
Categoría
Voltaje Requerido
Amperaje/Potencia
Cantidad
Función
Fuente de alimentación AC/DC (Kingwen o similar)
Alimentación DC
Entrada: 230 V AC
12 V DC / 10 A – 20 A (120 W – 240 W)
1
Fuente principal para alimentar los dispositivos internos
Raspberry Pi 4/5
Cómputo
5 V DC
3 A – 5 A (15 W – 25 W)
Según diseño
Nodo de computación principal
Router
Red
12 V DC (típico)
1 A – 2 A
1
Gestión de red y conectividad
Switch Gigabit
Red
12 V DC (o 9 V / 5 V)
0.6 A – 1 A
1
Interconexión de los dispositivos de red
Conversor DC-DC Buck
Alimentación DC
Entrada: 12 V / Salida: 5 V
3 A – 5 A
1 por Raspberry
Reducir el voltaje de 12 V a 5 V para alimentar la Raspberry Pi
Caja de fusibles DC (Blade)
Seguridad
12 V DC
Soporte multi-vía
1
Protección individual de líneas (2 A para router, 3 A para RPi)
Entrada IEC C14 con interruptor y fusible
Alimentación AC
230 V AC
Protección por fusible
1
Punto de entrada único de corriente exterior para la maleta
Enchufe AC schuko / panel
Alimentación AC
230 V AC
Según cargador de portátil
1
Conexión interna para un ordenador portátil
Barra de distribución (Negativos)
Alimentación DC
12 V DC
Según carga total
1
Organización de los retornos de masa y negativos
Cable eléctrico flexible 1.5 mm2 – 2.5 mm2
Cableado
12 V DC
Línea principal
Varios metros
Cableado de alimentación desde la fuente a la distribución (evita caídas de tensión)
Cable eléctrico flexible 0.75 mm2
Cableado
12 V DC
Líneas de dispositivos
Varios metros
Conexión secundaria para router, switch y conversores
Cable 3 x 1.5 mm2 homologado
Cableado
230 V AC
Alta tensión
Varios metros
Conexión segura de entrada IEC y enchufe para portátil
Ventiladores 12 V
Climatización
12 V DC
2 W – 5 W
1 o 2
Extracción de calor y ventilación forzada para evitar sobrecalentamientos
Maleta rígida
Estructura
N/A
N/A
1
Carcasa y base del montaje del laboratorio
Placa interior de montaje
Estructura
N/A
N/A
1
Superficie para el anclaje y atornillado de todos los componentes