# P2601 Legacy — Lecciones Aprendidas del Enfoque con Domain Controller

> **Documento de aprendizaje institucional**  
> **Fecha de creación:** 2026-04-15  
> **Estado:** ✅ Completado (caso de estudio histórico)

---

## 📌 Resumen Ejecutivo

Este documento recopila las lecciones aprendidas durante el **enfoque inicial con Domain Controller (AD DS)** que fue **descartado** en favor del enfoque Workgroup (P2601.09) debido a limitaciones de recursos y complejidad operativa.

**Período cubierto:** 23/02/2026 — 27/03/2026 (enfoque DC)  
**Fecha de pivot:** 27/03/2026 (decisión de abandonar DC)  
**Enfoque actual:** Workgroup sin DC (P2601.09) — ✅ Operativo desde 15/04/2026

---

## 🎯 Objetivo de este Documento

Preservar el conocimiento técnico adquirido durante la fase con DC para:

1. **Evitar repetir errores** en futuros proyectos
2. **Documentar señales de alerta** tempranas de problemas de recursos
3. **Proveer contexto histórico** para entender por qué se adoptó el enfoque Workgroup
4. **Servir como caso de estudio** para ingeniería de sistemas y toma de decisiones técnicas

---

## 🏗️ Arquitectura Original (Descartada)

### Topología de Red Privada (10.0.100.0/24)

```
Internet
   │
Router ISP (192.168.1.1)
   │
   └── srv-dasu (Proxmox VE) — 10.0.10.205 / Tailscale 100.116.210.36
        │
        └── vmbr1 (NAT 10.0.100.x)
             ├── VM 100: dc-dasuten (10.0.100.10) — Domain Controller AD DS + DNS
             ├── VM 101: sql-dasuten (10.0.100.11) — SQL Server 2019 Core
             └── VM 102: pcv-dasu0 (10.0.100.12) — Windows 10 LTSC (cliente pruebas)
```

### Componentes Requeridos (Enfoque DC)

| Componente | VM ID | Rol | Recursos | Estado Actual |
|:---|:---:|:---|:---|:---|
| **Domain Controller** | 100 | dc-dasuten | AD DS + DNS + GPO | 🛑 Apagada (preservada) |
| **SQL Server** | 101 | sql-dasuten | SQL 2019 Enterprise | 🛑 Apagada (preservada) |
| **PC Virtual** | 102 | pcv-dasu0 | Win 10 LTSC | 🛑 Apagada (preservada) |
| **Hipervisor** | — | srv-dasu | Proxmox VE 9.1 | ✅ Operativo (solo SQL4 + PCV) |

---

## ⚠️ Causas del Fracaso

### 1. Recursos Escasos en srv-dasu

**Problema principal:** El servidor físico `srv-dasu` tenía recursos insuficientes para sostener 3 VMs simultáneas con rendimiento aceptable.

| Recurso | Disponible | Requerido (3 VMs) | Déficit |
|:---|:---|:---|:---|
| **RAM** | 15 GB total | ~20 GB (4+4+4 + host) | -5 GB |
| **vCPU** | 6 núcleos | 8+ (2+2+2 + host) | -2 vCPU |
| **Disco** | 94 GB thin | ~180 GB (50+60+50 + host) | -86 GB |

**Señales de alerta temprana (bitácoras 23-28/02/2026):**

- `23/02`: "Decisión de despliegue Server Core para optimizar recursos"
- `24/02`: "Asignación técnica de recursos aprobada (2C/2GB/50GB)" — ya limitado
- `26/02`: "Resguardo Integral Offline (Fallo parcial VM 101)" — sin espacio para backups
- `05/03`: Tailscale configurado como subnet router para `10.0.100.0/24` — complejidad añadida

### 2. Complejidad de Red con NAT

**Problema:** La red privada `10.0.100.0/24` requería:

- NAT en Proxmox (vmbr1)
- Tunneling LPF hacia red académica `10.0.10.0/24`
- Subnet router Tailscale para acceso remoto
- Reglas de firewall complejas para SQL (1433) y SSH (7022)

**Bitácora 24/02/2026:**
> "Decisión de subred privada segregada (10.0.100.x)" — se optó por aislamiento

**Bitácora 26/02/2026:**
> "Estrategia de Tunneling LPF hacia red 10.0.100.x" — complejidad creciente

### 3. Dependencia del Dominio para Autenticación

**Problema:** El sistema DASUTEN (Visual FoxPro) fue diseñado asumiendo AD DS:

- Campo `UID` vacío en `Kermet.ini` → autenticación Windows Integrated (SSPI)
- Sin dominio → sin Kerberos → sin autenticación
- GPOs requeridas para mapeos y restricciones

**Bitácora 05/03/2026 (validación con usuaria):**
> "P02 - Login Exitoso: Prueba de ingreso al sistema con credenciales de aalmiron"

**Hallazgo clave (ingeniería inversa 11/04/2026):**
> El sistema **no tiene dependencia real del AD** si se configura explícitamente `UID=sa` en `Kermet.ini`

### 4. Puntos de Falla Múltiples

| Punto de Falla | Impacto | Frecuencia |
|:---|:---|:---|
| **DC caído** | Sin autenticación → sin sistema | Alto (recursos escasos) |
| **SQL caído** | Sin base de datos | Medio |
| **NAT/Red** | Sin conectividad entre VMs | Medio-Alto |
| **Tailscale** | Sin acceso remoto DTIC | Bajo |
| **AnyDesk** | Sin fallback de acceso | Bajo |

---

## 📅 Timeline de Eventos Críticos

| Fecha | Hito | Estado | Observaciones |
|:---|:---|:---:|:---|
| **23/02/26** | Inicio: Instalación Proxmox en srv-dasu | ✅ | Hardware recibido y acondicionado |
| **23/02/26** | Decisión: Server Core para DC | ⚠️ | Optimización prematura por recursos |
| **24/02/26** | VM 100 creada (dc-dasuten) | ✅ | 2 vCPU / 2 GB RAM / 50 GB disco |
| **24/02/26** | Dashboard P2601 desplegado | ✅ | Métricas operativas en ns8 |
| **25/02/26** | VM 101 creada (sql-dasuten) | ✅ | 2 vCPU / 4 GB RAM / 60+100 GB |
| **25/02/26** | SQL Server 2019 instalado | ✅ | Autenticación mixta habilitada |
| **26/02/26** | OpenSSH en VMs Windows | ✅ | Puerto 7022 configurado |
| **26/02/26** | Backup vzdump (falla VM 101) | ⚠️ | Sin espacio en disco |
| **27/02/26** | VM 102 creada (pcv-dasu0) | ✅ | Win 10 LTSC + SSH |
| **05/03/26** | **Validación usuaria (Andrea Almirón)** | ✅ | Login exitoso, sistema operativo |
| **05/03/26** | Tailscale subnet router | ⏳ | 10.0.100.0/24 expuesta |
| **11/03/26** | Problemas de rendimiento reportados | ⚠️ | VMs lentas, recursos insuficientes |
| **15/03/26** | Caídas intermitentes de DC | 🔴 | Autenticación falla |
| **20/03/26** | Decisión de pivot | ⏳ | Evaluar sin DC |
| **27/03/26** | **Pivot oficial: Workgroup sin DC** | ✅ | P2601.09 iniciado |
| **15/04/26** | **Validación final (Workgroup)** | ✅ | Sistema 100% operativo |

---

## 🔬 Análisis de Señales de Alerta

### Señales Tempranas (23-28/02)

| Señal | Interpretación | Acción No Tomada |
|:---|:---|:---|
| "Server Core para optimizar" | Recursos insuficientes desde inicio | Reducir scope o upgrade hardware |
| "2C/2GB/50GB" | DC sub-dimensionado | Asignar más RAM al DC |
| "Fallo parcial VM 101" | Disco lleno | Limpiar o expandir storage |
| "Tunneling LPF" | Complejidad de red creciente | Simplificar a red plana |

### Señales Tardías (01-15/03)

| Señal | Interpretación | Consecuencia |
|:---|:---|:---|
| Caídas de DC | RAM insuficiente | Sin autenticación |
| Lentitud general | CPU/RAM sobre-comprometida | Experiencia de usuario pobre |
| AnyDesk requerido | Red inestable | Dependencia de terceros |

---

## 💡 Lecciones Aprendidas

### 1. "Menos es Más" (Principio ADN)

**Lección:** La complejidad debe justificarse con beneficios tangibles.

**Caso DC:** El Domain Controller añadía:
- 1 VM adicional (4 GB RAM, 2 vCPU)
- Complejidad de red (DNS, GPO, dominio)
- Punto de falla crítico

**Beneficio:** Ninguno tangible para el caso de uso (2 usuarias, 1 PC).

**Principio aplicado (Workgroup):**
- 2 VMs en vez de 3
- Red plana en vez de NAT
- SQL Auth en vez de Kerberos

### 2. Validar Recursos Antes de Comprometerse

**Lección:** Los números no mienten. Si 15 GB < 20 GB requeridos, el proyecto está en riesgo.

**Señales ignoradas:**
- RAM: 15 GB disponibles vs 20 GB requeridos
- Disco: 94 GB vs 180 GB requeridos
- vCPU: 6 núcleos vs 8+ requeridos

**Acción correctiva (Workgroup):**
- 1 VM SQL (4 GB) + 1 VM PCV (4 GB) = 8 GB
- Host: 4 GB → **12 GB total, dentro de límites**

### 3. La Complejidad de Red es un Multiplicador de Fallas

**Lección:** Cada capa de abstracción de red (NAT, tunneling, subnet routing) es un punto de falla potencial.

**Enfoque DC:**
```
PC → AnyDesk → VM → NAT → DC (auth) → SQL
```

**Enfoque Workgroup:**
```
PC → SQL (red plana)
```

**Resultado:** 4 componentes → 2 componentes

### 4. Ingeniería Inversa Antes de Asumir Dependencias

**Lección:** No asumir que el software requiere AD DS sin verificar.

**Suposición inicial:** "DASUTEN requiere dominio porque usa Windows Auth"

**Verificación (11/04/26):**
- `Kermet.ini` con `UID=sa` → SQL Auth clásica
- Sin dependencia de Kerberos
- Sin dependencia de GPOs

**Acción:** Modificar 1 archivo `.ini` en vez de mantener 3 VMs.

### 5. El Usuario Final es el Validador Definitivo

**Lección:** La validación técnica no alcanza; el usuario valida la experiencia real.

**Validación 05/03 (DC):** ✅ "Login exitoso" — pero sistema lento

**Validación 15/04 (Workgroup):** ✅ "Datos actualizados, sistema rápido"

**Diferencia:** Menos capas = más rendimiento percibido.

---

## 📊 Comparativa: DC vs Workgroup

| Métrica | DC (23/02-27/03) | Workgroup (27/03-presente) |
|:---|:---|:---|
| **VMs** | 3 (DC + SQL + PCV) | 2 (SQL + PCV) |
| **RAM total** | ~20 GB requeridos | ~12 GB requeridos |
| **vCPU** | 8+ | 6 |
| **Disco** | ~180 GB | ~140 GB |
| **Red** | NAT 10.0.100.x + tunneling | DHCP plano 192.168.1.x |
| **Autenticación** | AD DS (Kerberos) | SQL Auth |
| **Puntos de falla** | 5+ | 2 |
| **Validación usuaria** | ✅ Lento/intermitente | ✅ Rápido/estable |

---

## 🧭 Línea de Tiempo de la Decisión

### Fase 1: Optimismo Inicial (23-28/02)

> "Vamos a replicar la arquitectura enterprise en el servidor nuevo"

- Instalación de Proxmox
- Creación de VMs con recursos "mínimos viables"
- Configuración de red privada compleja

### Fase 2: Primeras Grietas (01-15/03)

> "Las VMs están lentas, el DC se cae seguido"

- Backups fallan por espacio
- DC requiere reinicios frecuentes
- AnyDesk se vuelve necesario para trabajar

### Fase 3: Evaluación (15-20/03)

> "¿Realmente necesitamos el DC?"

- Análisis de costos/beneficios
- Ingeniería inversa del sistema DASUTEN
- Descubrimiento: no hay dependencia real de AD

### Fase 4: Pivot (27/03)

> "Menos es más: eliminamos el DC"

- VMs legacy apagadas y preservadas
- Nueva VM `dasu-sql4` con enfoque Workgroup
- Red plana DHCP del ISP

### Fase 5: Validación (15/04)

> "Funciona. Rápido y simple."

- Sistema 100% operativo
- Usuaria confirma datos actualizados
- Pipeline de backups automatizado

---

## 🔗 Referencias a Bitácoras Originales

| Fecha | URL | Extracto |
|:---|:---|:---|
| 23/02/26 | `/bitacoras/2026-02-23` | "Decisión de despliegue Server Core para optimizar recursos" |
| 24/02/26 | `/bitacoras/2026-02-24` | "Subred privada segregada (10.0.100.x)" |
| 26/02/26 | `/bitacoras/2026-02-26` | "Resguardo Integral Offline (Fallo parcial VM 101)" |
| 05/03/26 | `/bitacoras/2026-03-05` | "Validación Presencial por Usuario — EXITOSO" |
| 27/03/26 | `/bitacoras/2026-03-27` | "Pivot: Enfoque Workgroup sin DC" |

---

## 📝 Recomendaciones para Futuros Proyectos

### 1. Checklist de Recursos (Pre-Proyecto)

- [ ] Calcular RAM requerida + 20% margen
- [ ] Calcular vCPU requeridos + 1 núcleo margen
- [ ] Calcular disco requerido + 30% margen
- [ ] Validar que el hardware físico cumple todos los requisitos

### 2. Principio de Complejidad Progresiva

- [ ] Empezar con la arquitectura más simple posible
- [ ] Añadir complejidad solo cuando se justifique con beneficios medibles
- [ ] Documentar cada capa de complejidad añadida

### 3. Validación de Dependencias de Software

- [ ] No asumir dependencias (AD, DNS, GPO) sin verificar
- [ ] Hacer ingeniería inversa del software antes de diseñar infraestructura
- [ ] Preguntar: "¿Qué pasa si sacamos esta capa?"

### 4. Señales de Alerta Temprana

| Señal | Acción Correctiva |
|:---|:---|
| Backups fallan por espacio | Expandir storage o reducir scope |
| VMs lentas desde el inicio | Reducir cantidad o upgrade hardware |
| Múltiples capas de red | Simplificar a red plana |
| Caídas intermitentes | Investigar recursos (RAM/CPU) |

---

## 🎓 Conclusión

El enfoque con Domain Controller **no fue un fracaso**, fue un **proceso de aprendizaje necesario** que permitió:

1. **Entender los límites del hardware** disponible
2. **Descubrir que la complejidad no era necesaria** para el caso de uso
3. **Validar que el usuario final** prioriza rendimiento sobre arquitectura "enterprise"
4. **Documentar señales de alerta** para futuros proyectos

**Principio rector:** *"La arquitectura más simple que funciona es mejor que la arquitectura 'correcta' que apenas se sostiene."*

---

**Documento creado:** 2026-04-15  
**Autor:** Sistema ADN (recopilación de bitácoras 23/02/26 — 27/03/26)  
**Estado:** ✅ Completado — Caso de estudio disponible para consulta