Diseño de una infraestructura empresarial con VLSM y servicios de red
1. Introducción
Audio presentación
El Centro de Investigación Avanzada de Hawkins es una organización ficticia inspirada en la serie Stranger Things. Tras varios incidentes en sus instalaciones, la dirección ha decidido sustituir su red improvisada por una infraestructura profesional, segmentada, documentada y preparada para crecer.
El centro está formado por tres ubicaciones:
Sede Central de Hawkins: oficinas, laboratorios, seguridad, servidores y zona de visitantes.
Estación de Campo Starcourt: pequeño centro remoto de observación y comunicaciones.
Búnker NINA: instalación aislada en la que se realizan pruebas especialmente sensibles.
Vuestro equipo ha sido contratado como consultora de sistemas y redes. Tendréis que analizar las necesidades de la organización, diseñar el direccionamiento mediante VLSM, construir una maqueta funcional y desplegar varios servicios de red.
No se valorará únicamente que los equipos puedan comunicarse. La empresa exige una solución lógica, segura, ampliable, comprobada y correctamente documentada.
2. Modalidad de trabajo
Trabajo individual o en parejas, según indique el profesor.
Herramienta principal recomendada: Cisco Packet Tracer.
Red IPv4 asignada a todo el proyecto: 172.20.0.0/16.
Todos los cálculos de subnetting deberán realizarse manualmente y explicarse además de mostrar las tablas completas.
En Packet Tracer no es necesario colocar físicamente todos los dispositivos indicados. Se representará cada red con un número reducido de equipos, pero el direccionamiento deberá admitir la cantidad real solicitada.
No es necesario realizar la configuración en los routers y switch, aunque si debe estar bien explicado en la documentación.
3. Objetivos de aprendizaje
Al terminar el proyecto, el alumnado deberá ser capaz de:
Analizar las necesidades de una infraestructura con varias sedes.
Crear subredes de distinto tamaño mediante VLSM.
Calcular direcciones de red, broadcast, rangos utilizables y máscaras.
Organizar departamentos mediante redes o VLAN independientes.
Configurar direccionamiento estático y dinámico.
Permitir la comunicación entre redes mediante routing.
Aplicar reglas básicas de segmentación y control de acceso.
Verificar el funcionamiento mediante pruebas reproducibles.
Elaborar documentación técnica en Markdown.
4. Historia del proyecto
La infraestructura antigua utilizaba una única red para empleados, cámaras, servidores y visitantes. Esto ha provocado direcciones duplicadas, dificultad para localizar averías y acceso de usuarios no autorizados a recursos internos.
La nueva red recibirá el nombre HAWKNET. Cada departamento deberá disponer de su propia subred. Las tres sedes estarán conectadas mediante enlaces WAN y compartirán determinados servicios alojados en la sede central.
La dirección establece cuatro prioridades:
separar el tráfico de los departamentos;
garantizar que los nombres internos se resuelvan mediante DNS;
proporcionar configuración automática a los puestos de usuario;
proteger los laboratorios y la red de gestión frente a visitantes y dispositivos IoT.
5. Topología general requerida
La maqueta deberá contener, como mínimo:
un router o dispositivo de capa 3 en cada sede;
switches suficientes para representar la segmentación solicitada;
un switch principal en la sede central;
enlaces troncales cuando se utilicen VLAN;
un enlace entre la sede central y Starcourt;
un enlace entre la sede central y el búnker NINA;
servidores centralizados en Hawkins;
al menos un equipo cliente representativo en cada subred;
una nube o router ISP que represente Internet;
puntos de acceso inalámbricos para empleados y visitantes.
El diseño exacto queda a criterio del equipo, pero todas las decisiones deberán justificarse.
6. Necesidades de direccionamiento
Se utilizará la red 172.20.0.0/16. A partir de ella debéis crear todas las subredes necesarias mediante VLSM.
Las cantidades representan la capacidad que debe soportar cada red, no el número de dispositivos que hay que insertar en Packet Tracer.
6.1. Sede Central de Hawkins
Red o departamento
Dispositivos actuales
Crecimiento mínimo previsto
Sensores, puertas y dispositivos IoT
850
20 %
Wi-Fi de visitantes
420
20 %
Personal administrativo
190
20 %
Laboratorio de Energía
110
20 %
Videovigilancia y seguridad física
75
20 %
Investigadores
60
20 %
Centro de Operaciones
42
20 %
Servidores internos
26
20 %
Telefonía IP
24
20 %
Administración de red
12
20 %
6.2. Estación de Campo Starcourt
Red o departamento
Dispositivos actuales
Crecimiento mínimo previsto
Personal de operaciones
48
20 %
Sensores y cámaras
30
20 %
Invitados
18
20 %
Administración de red
6
20 %
6.3. Búnker NINA
Red o departamento
Dispositivos actuales
Crecimiento mínimo previsto
Laboratorio restringido
28
20 %
Seguridad
14
20 %
Servidores locales
6
20 %
Administración de red
5
20 %
6.4. Enlaces entre routers
Debéis reservar una subred independiente para cada uno de estos enlaces:
Hawkins ↔ Starcourt.
Hawkins ↔ NINA.
Hawkins ↔ ISP.
Cada enlace solo necesita las direcciones imprescindibles para sus dos extremos. Deberéis decidir si usar /30 o /31 y comprobar si la opción elegida es compatible con el simulador y los dispositivos utilizados.
7. Normas para realizar el VLSM
Calculad la capacidad necesaria sumando el crecimiento del 20 % y redondeando siempre hacia arriba.
Recordad incluir las direcciones que vayan a consumir puertas de enlace, servidores u otros dispositivos de infraestructura.
Ordenad las redes desde la que necesita más direcciones hasta la que necesita menos.
Asignad a cada red el bloque más pequeño que cubra su necesidad.
No pueden existir subredes solapadas.
No debe desperdiciarse un bloque excesivamente grande sin una justificación técnica.
La primera dirección utilizable de cada LAN se asignará, salvo justificación, a su puerta de enlace.
Los servidores, routers, switches gestionables e impresoras usarán direcciones estáticas.
Los clientes de usuario recibirán su configuración mediante DHCP.
Para cada subred debéis mostrar el razonamiento utilizado. No será suficiente entregar una tabla generada automáticamente.
8. Tabla obligatoria de direccionamiento
La documentación incluirá una tabla como la siguiente, completada para todas las redes:
Sede
Red/VLAN
Necesidad con crecimiento
Prefijo
Máscara decimal
Dirección de red
Primer host
Último host
Broadcast
Gateway
Hawkins
IoT
También se añadirá una segunda tabla para los dispositivos configurados:
Dispositivo
Interfaz
Dirección IP
Máscara/prefijo
Gateway
DNS
Asignación
SRV-DNS-01
Fa0
Estática
9. VLAN y segmentación
En la sede central cada departamento deberá estar separado mediante una VLAN o interfaz física diferente. Si se utilizan VLAN, debéis:
asignar un identificador y un nombre descriptivo a cada VLAN;
configurar los puertos de acceso;
utilizar una VLAN de gestión distinta de la VLAN nativa;
documentar qué puertos pertenecen a cada VLAN.
Los identificadores de VLAN son libres, pero deben seguir un criterio coherente. Por ejemplo, se pueden agrupar por sede o por tipo de servicio.
10. Routing entre sedes
Todos los routers deberán conocer las redes remotas. El equipo elegirá una de estas opciones:
El fallo de una ruta no podrá ocultarse añadiendo rutas innecesarias o utilizando una única red sin segmentación.
11. Servicios obligatorios
La red de servidores y las redes de administración no utilizarán DHCP para sus dispositivos principales.
11.2. DNS
El dominio interno será:
hawkins.lab
El DNS deberá contener, al menos, estos registros:
11.3. Servidor web e intranet
El servidor web mostrará una página sencilla con:
nombre y logotipo ficticio de la organización;
estado de las tres sedes;
mensaje de bienvenida;
nombre de los integrantes del equipo;
fecha de la última comprobación.
La web pública de pruebas podrá ser accesible desde todas las redes. La intranet solo deberá ser accesible desde redes internas autorizadas.
12. Requisitos básicos de seguridad
La segmentación debe traducirse en reglas de acceso. Se configurarán ACL u otro mecanismo equivalente para cumplir, como mínimo, estas políticas:
La red de visitantes solo puede acceder al DNS necesario, al portal web y a Internet.
Los visitantes no pueden iniciar conexiones hacia las redes internas.
La red IoT no puede acceder a Administración de red ni a los equipos de investigadores.
Solo Administración de red puede gestionar routers y switches mediante SSH.
Telnet deberá permanecer deshabilitado.
El laboratorio NINA no será accesible desde redes de invitados.
Seguridad podrá consultar las cámaras y sensores de las tres sedes.
Los servidores DNS, DHCP y correo deberán ser accesibles únicamente desde las redes que necesiten cada servicio.
Las reglas se colocarán lo más cerca posible del origen o destino y se documentará el motivo de cada una.
13. Acceso a Internet y NAT
La sede central se conectará a un router ISP. Debéis configurar:
una ruta por defecto hacia el ISP;
NAT/PAT para que las redes privadas autorizadas puedan salir a Internet;
un servidor externo de prueba, por ejemplo www.vecna-news.net, situado en una red que no pertenezca a 172.20.0.0/16;
bloqueo de salida para las redes que, según vuestra política, no deban acceder a Internet.
No es necesario publicar servidores internos mediante NAT estático, aunque puede realizarse como ampliación.
14. Nombres y configuración de dispositivos
Los nombres deberán permitir identificar su ubicación y función. Ejemplos:
Identificad las sedes, departamentos, servidores y enlaces.
Dibujad un primer esquema lógico.
Decidid qué servicios serán centrales y cuáles serán locales.
Anotad las restricciones de seguridad.
Fase 2. Cálculo VLSM
Calculad el número de hosts con crecimiento.
Ordenad las redes de mayor a menor.
Determinad el prefijo mínimo de cada una.
Asignad los bloques dentro de 172.20.0.0/16.
Calculad red, primer host, último host y broadcast.
Comprobad que no existen solapamientos.
Reservad espacio para futuras ampliaciones.
Fase 3. Construcción de la topología
Colocad routers, switches, servidores y clientes.
Cablead correctamente los dispositivos.
Asignad nombres a todos los equipos.
Cread VLAN y configurad puertos.
Configurad puertas de enlace.
Fase 4. Direccionamiento y routing
Configurad interfaces y subinterfaces.
Asignad direcciones estáticas a infraestructura.
Configurad rutas estáticas u OSPF.
Fase 5. Pruebas y documentación
Ejecutad el plan de pruebas.
Corregid los fallos encontrados.
Capturad evidencias relevantes.
Completad el README.md.
Revisad que otra persona pueda comprender y reproducir el proyecto.
No se considerará demostrada una política si únicamente se prueba el caso permitido. Cuando corresponda, deberán probarse tanto el acceso correcto como su bloqueo.
17. Entregables
La entrega contendrá una carpeta comprimida con esta estructura orientativa:
El archivo principal se llamará exactamente README.md y utilizará Markdown. Más adelante, cuando se haya trabajado Git, el mismo proyecto deberá poder incorporarse a un repositorio sin reorganizar toda la documentación.
18. Contenido obligatorio del README.md
Portada: título, integrantes, curso y fecha.
Resumen ejecutivo del proyecto.
Descripción de las tres sedes.
Requisitos detectados.
Diagrama lógico de red.
Explicación paso a paso del cálculo VLSM.
Tabla completa de direccionamiento.
Tabla de VLAN.
Inventario y función de los dispositivos.
Explicación del routing seleccionado.
Reglas de seguridad y ACL aplicadas.
Configuración de NAT/PAT.
Plan de pruebas y resultados.
Problemas encontrados y soluciones.
Conclusiones y posibles mejoras.
Fuentes consultadas.
Las capturas deben estar recortadas, ser legibles y llevar un pequeño texto explicativo. No se admitirán decenas de capturas sin contexto ni configuraciones pegadas sin explicación.
19. Condiciones de aceptación
El proyecto se considerará funcional cuando:
todas las subredes estén calculadas correctamente;
no haya direcciones duplicadas ni bloques solapados;
la comunicación entre sedes funcione;
los nombres internos se resuelvan mediante DNS;
los servicios obligatorios sean accesibles desde las redes autorizadas;
los accesos prohibidos sean realmente bloqueados;
el acceso exterior utilice NAT/PAT;
las pruebas estén documentadas;
el archivo de Packet Tracer se abra sin errores;
el README permita entender el trabajo sin una explicación oral adicional.
Un proyecto en el que “todo puede comunicarse con todo” no cumplirá los requisitos de segmentación y seguridad.
Las ampliaciones solo puntuarán si la parte obligatoria funciona y están correctamente explicadas.
20. Penalizaciones importantes
Subredes solapadas o uso incorrecto de red/broadcast.
Archivo .pkt que no abre o que no coincide con la documentación.
Capturas de pantalla ajenas o configuraciones copiadas que el equipo no pueda explicar.
Uso de una sola red para evitar el trabajo de VLSM.
21. Defensa del proyecto
El profesor podrá seleccionar al azar cualquier dispositivo o prueba. El equipo tendrá que:
Todos los integrantes deben conocer el proyecto completo. La división de tareas no exime de comprender el trabajo de la otra persona.
23. Pregunta final de reflexión
Incluid al final del README una respuesta razonada a estas cuestiones:
¿Qué ventajas ofrece VLSM frente a utilizar la misma máscara en todas las redes?
¿Qué ocurriría si empleados, servidores, cámaras y visitantes compartieran la misma red?
¿Qué servicio causaría un impacto mayor si dejara de funcionar: DHCP, DNS o routing? Justificad la respuesta según vuestra infraestructura.
¿Qué parte del diseño cambiaríais si la empresa duplicara su tamaño?
Misión
La red de Hawkins no debe limitarse a “tener pings”. Debe ser una infraestructura organizada, útil y defendible. Vuestro objetivo es demostrar que podéis convertir las necesidades de una organización en un diseño IP correcto, desplegar los servicios básicos y verificar que cada usuario accede únicamente a los recursos que necesita.
