Red corporativa simulada en GNS3 que integra enrutamiento Cisco (router-on-a-stick, VLANs, NAT) con servicios de Windows Server 2016 — Active Directory (AD-DS), IIS, NPS/RADIUS y Remote Desktop Services — y autenticación de gestión centralizada AAA/RADIUS, validada desde un cliente Kali Linux. Despliegue automatizado con Python/Netmiko.
Autor: Edgardy Olivero · Plataforma de simulación: GNS3 · Servidor: Windows Server 2016 · Cliente de validación: Kali Linux
- Objetivo de la Red
- Topología y Direccionamiento
- Implementación de Servicios Core
- Automatización y Scripts
- Demostración de Funcionamiento
El proyecto simula la infraestructura de una sucursal corporativa en GNS3, integrando dispositivos Cisco (enrutamiento y segmentación L2/L3) con un servidor Windows Server 2016 que concentra los servicios de identidad, publicación web, autenticación centralizada y entrega de aplicaciones remotas. La validación de acceso y segmentación se realiza desde un cliente Kali Linux.
Los objetivos técnicos son:
- Segmentar el dominio de broadcast en dos VLANs:
VLAN 10 (Clientes)yVLAN 20 (Servidores), con enrutamiento inter-VLAN mediante router-on-a-stick y salida a Internet vía NAT overload. - Centralizar la autenticación de gestión (AAA) del router
R-Core: el login por Telnet/SSH se autentica y autoriza contra Windows NPS (RADIUS), con respaldo local para conservar el acceso al equipo si el servidor RADIUS no responde. - Concentrar los servicios core en el Windows Server 2016: Active Directory (AD-DS) para identidad, IIS como portal web interno, NPS/RADIUS como servidor AAA y RDS para la publicación de aplicaciones y escritorios remotos (RemoteAPP).
- Validar la segmentación, el enrutamiento y el flujo AAA desde un cliente Kali Linux ubicado en la VLAN de clientes.
El flujo AAA queda fijado en R-Core como:
aaa authentication login default group radius local # RADIUS primero; respaldo local
aaa authorization exec default group radius local # nivel de exec desde RADIUS; respaldo local
De este modo, si NPS no responde, las listas default caen en el usuario local admin y el acceso de gestión no se pierde.
La red se construye sobre un router Cisco IOS (R-Core) y un switch L2 Cisco IOS (SW1). R-Core implementa router-on-a-stick sobre el enlace troncal G0/1 ↔ SW1 G0/0, separando el tráfico de clientes y servidores en subinterfaces dot1q. La interfaz G0/0 actúa como uplink (cliente DHCP) con ip nat outside, mientras que las subinterfaces VLAN son ip nat inside y salen a Internet mediante NAT overload. El servidor DHCP se habilita en R-Core para la VLAN de clientes.
Tabla de VLANs y segmentación
| VLAN | Nombre | Red (CIDR) | Gateway — R-Core | Propósito | Puerto SW1 |
|---|---|---|---|---|---|
| 10 | CLIENTES | 10.0.10.0 /24 | 10.0.10.1 (G0/1.10) |
Clientes: Tiny Win10 y Kali Linux (DHCP) | G0/2 (access) |
| 20 | SERVIDORES | 10.0.20.0 /24 | 10.0.20.1 (G0/1.20) |
Windows Server 2016 (AD-DS, IIS, NPS, RDS) @ 10.0.20.5 | G0/1 (access) |
| troncal | — | — | — | Enlace L2 R-Core ↔ SW1 (dot1q, VLANs 10 y 20) |
G0/0 (trunk) |
| uplink | — | DHCP (cliente) | — | Salida a Internet (G0/0, ip nat outside) |
— |
Tabla de direccionamiento IP
| Dispositivo / Interfaz | Dirección IP | Máscara | VLAN | Función |
|---|---|---|---|---|
R-Core — Gi0/0 |
DHCP (cliente) | — | — | Uplink a Internet; ip nat outside |
R-Core — Gi0/1 |
(enlace L2 troncal) | — | 10,20 | Troncal hacia SW1 (router-on-a-stick) |
R-Core — Gi0/1.10 |
10.0.10.1 | /24 | 10 | Gateway VLAN Clientes; ip nat inside |
R-Core — Gi0/1.20 |
10.0.20.1 | /24 | 20 | Gateway VLAN Servidores; ip nat inside |
SW1 (switch L2) |
— | — | 10,20 | Troncal G0/0; acceso G0/1→VLAN20, G0/2→VLAN10 |
Windows Server 2016 (srv) |
10.0.20.5 | /24 | 20 | AD-DS · IIS · NPS/RADIUS · RDS |
| NPS / RADIUS | 10.0.20.5 (:1812 auth / :1813 acct) |
— | 20 | Servidor AAA al que delega R-Core |
| Clientes VLAN 10 | 10.0.10.10 – .254 | /24 | 10 | Asignados por DHCP (DNS 8.8.8.8 / 1.1.1.1) |
NAT/DHCP:
ip nat inside source list NAT_TRAFICO interface Gi0/0 overloadtraduce las VLANs 10 y 20 con la IP deG0/0; el poolVLAN10_CLIENTESentrega direcciones a los clientes (excluded-address 10.0.10.1 10.0.10.9).
Los cuatro servicios se despliegan sobre el Windows Server 2016 (srv.edgardy.olivero, 10.0.20.5, VLAN 20). Cada subsección documenta la configuración realizada y su propósito técnico, intercalando las evidencias gráficas.
Se promueve el servidor a Controlador de Dominio de un bosque nuevo, de modo que el servidor concentre la identidad (cuentas y grupos de Windows) sobre la que NPS/RADIUS resuelve la autenticación AAA.
Promoción del servidor a Controlador de Dominio de un bosque nuevo (edgardy.olivero); se define la contraseña de modo de restauración de servicios de directorio (DSRM).
Se confirman las opciones del controlador de dominio (DNS, catálogo global y roles) e integra el servicio DNS con Active Directory.
Se establece el nombre de dominio NetBIOS para compatibilidad con clientes heredados.
Las comprobaciones previas (esquema, bosque, replicación) se superan y se inicia la instalación del rol.
Se instala el rol Servidor Web (IIS) para publicar un portal/intranet interna que los clientes de la VLAN 10 consumen a través del router-on-a-stick.
Marca del rol Servidor Web (IIS) en el Asistente para agregar roles.
Se seleccionan los servicios de rol (documento predeterminado, contenido estático, registro, seguridad y gestión) según las necesidades del portal interno.
El Network Policy Server (NPS) actúa como servidor RADIUS: R-Core delega en él la autenticación y autorización de sus logins de gestión. Se registra el router como cliente RADIUS y se construyen la Connection Request Policy y la Network Policy que gobiernan el acceso, ajustando los métodos de autenticación y los atributos específicos de Cisco.
Selección del rol Network Policy and Access Services (NPS).
Registro del router R-Core (10.0.20.1) como cliente RADIUS, con la clave compartida que debe coincidir con radius server NPS del router.
Creación de la Network Policy (y su Connection Request Policy) que rige el acceso AAA.
La política aplica únicamente a un grupo de Windows y al cliente IPv4 R-Core (10.0.20.1), acotando quién y desde qué equipo se autentica.
Se habilitan métodos Unencrypted PAP/SPAP, exigido porque Cisco IOS envía PAP en el aaa authentication login sobre Telnet; sin este ajuste la autenticación RADIUS falla.
Se inyecta el atributo Vendor-Specific Cisco-AV-Pair shell:priv-lvl=15, de modo que el login AAA entrega al operador el nivel de ejecución privilegiado (15) sin enable adicional.
RDS publica aplicaciones y escritorios basados en sesión, de manera que los clientes de la VLAN 10 consumen el software corporativo de forma centralizada desde el servidor.
Inicio del asistente de Remote Desktop Services.
Opción Quick Start para un despliegue rápido en un único servidor.
Se elige el despliegue basado en sesión (session-based), apto para publicar escritorios y RemoteAPP.
Se selecciona srv.edgardy.olivero como RD Session Host para el rol.
El repositorio entrega la configuración de los dispositivos Cisco en formato plano (.ios) y un script Python que la aplica automáticamente a los nodos de GNS3. El servidor NPS/RADIUS se despliega por GUI del Windows Server 2016 (ver 3.3).
RDP-RemoteAPP-RADIUS-AAA/
├── Capturas/ # 17 evidencias gráficas de la implementación
├── Configuraciones/ # Configuración Cisco IOS — R-Core.ios, SW1.ios
├── configurar_redes.py # Aplica los .ios a los nodos de GNS3 (Netmiko vía Telnet)
├── requirements.txt # Dependencias Python (netmiko==4.7.0)
├── .gitignore # Excluye .venv/, __pycache__/ y Grabacion/ (video vía YouTube)
└── README.md # Este documento
R-Core.iosySW1.ios: configuración plana en formato Cisco IOS que documenta el estado final de cada equipo (VLANs, router-on-a-stick, NAT/DHCP y AAA/RADIUS en el router). Son la fuente de verdad del despliegue de red:configurar_redes.pylas lee y las aplica a los nodos.
Script Python que lee los archivos .ios de Configuraciones/ y los aplica directamente a los nodos de GNS3 mediante Netmiko sobre Telnet local (consolas). Permite elegir el dispositivo objetivo con --dispositivo.
# 1) Entorno (una sola vez)
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
# 2) Aplicar la configuración a los dispositivos de GNS3
.venv/bin/python configurar_redes.py # ambos
.venv/bin/python configurar_redes.py --dispositivo sw1 # solo SW1
.venv/bin/python configurar_redes.py --dispositivo rcore # solo R-CoreEl inventario de consolas GNS3 se mantiene en el diccionario DEVICES del propio script: sw1 → 127.0.0.1:5006 / SW1.ios y rcore → 127.0.0.1:5009 / R-Core.ios (con enable para acceder al modo exec del router).
Los valores que enlazan ambos extremos del flujo AAA deben coincidir en el router (radius server NPS) y en el cliente RADIUS configurado en el NPS:
| Parámetro | Valor de referencia | Router (R-Core.ios) |
NPS (GUI) |
|---|---|---|---|
| IP del servidor NPS | 10.0.20.5 (auth 1812 / acct 1813) |
radius server NPS → address ipv4 |
(IP del propio servidor) |
| IP del cliente RADIUS | 10.0.20.1 (R-Core) |
(IP de su interfaz G0/1.20) |
Cliente RADIUS "R-Core" |
| Clave compartida | la misma en ambos extremos | key 0 … |
Secreto del cliente "R-Core" |
Advertencia de credenciales: el repositorio se entrega con valores de marcador (p. ej.
Admin123,AdminRcore123!,EnableRcore123!). En un despliegue real deben rotarse y reconciliarse entre el router y el NPS.
La entrega incluye un video que valida el despliegue completo (el archivo de grabación se mantiene fuera del repositorio y se entrega como enlace no listado en YouTube).
▶ Ver video de demostración en YouTube
Durante la demostración se valida:
- AAA centralizado: la autenticación de gestión de
R-Corese delega en NPS (verificable contest aaa group radius RADIUS_NPS <usuario> <clave> legacy); el login Telnet/SSH entrega privileged exec (nivel 15) por el atributo Cisco-AV-Pairshell:priv-lvl=15configurado en la política RADIUS. - Respaldo local: al caer NPS,
R-Coreconserva acceso vía el usuario localadmin(respaldolocalengroup radius local). - Conectividad: los clientes de la VLAN 10 alcanzan el servidor (
10.0.20.5) y el sitio IIS a través del router-on-a-stick, y salen a Internet por NAT overload. - RDS/RemoteAPP: una estación Tiny Win10 consume aplicaciones publicadas desde
srv.edgardy.olivero. - Validación de seguridad: desde Kali Linux (VLAN 10) se verifica la segmentación L3 y que el acceso de gestión al router sólo se concede tras la autenticación RADIUS.