rmonla/dtic-DIIAA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
81c28a388e818814046ec11d0ba07fb124dd8a94
dtic-DIIAA/docs/ambito/dtic-DASUTEN/A04.P005_DASUTEN-sin-DC.md
T

19 KiB
Raw Blame History

Plan: DASUTEN sin Domain Controller (Modo Workgroup)

Ámbito: A04 — dtic-DASUTEN

Código: A04.P005
Fecha: 27 de marzo de 2026
Autor: Sistema ADN
Versión: 4.0
Estado: 🚧 EN EJECUCIÓN (F5 completada — BD restaurada, pendiente validación con PC cliente)
Dependencia: A04.P001 (Red srv-dasu)

📊 Progreso General

  • Fase 1: Preparación [██████████] 100% (6/6) ✅
  • Fase 2: VM SQL Server [██████████] 100% (9/9) ✅
  • Fase 3: VM PC Cliente [██████████] 100% (9/9) ✅
  • Fase 4: Nueva VM dasu-sql4 [██████████] 100% (12/12) ✅
  • Fase 5: Migración BD [██████████] 100% (5/5) ✅
  • Fase 5b: Hardening [██████████] 100% (4/4) ✅
  • Fase 6: Validación [█░░░░░░░░░] 9% (1/10) 🚧

📋 Resumen Ejecutivo

Evaluar si el sistema DASUTEN puede operar sin la dependencia de un Domain Controller (AD DS), utilizando únicamente un SQL Server y una PC cliente en modo Workgroup. Esto simplifica significativamente la infraestructura y elimina los problemas de red asociados al dominio.

Motivación

Los intentos previos (P2601.06 a P2601.08) demostraron que la topología con DC introduce complejidad de red que entra en conflicto con el router del ISP de la oficina DASUTEN. Al eliminar la dependencia del DC, se reducen los puntos de falla y se simplifica la conectividad.

Decisiones clave

  • VMs existentes preservadas: dasu-srvv-dc (VM 100), dasu-srvv-sql (VM 101) y dasu-pcv (VM 102) fueron apagadas y deshabilitadas del autostart. Pueden reactivarse si se decide retornar al enfoque con DC.
  • Enfoque nuevo: VMs limpias en modo Workgroup, sin Active Directory.
  • Red provista por ISP: Tanto srv-dasu como las VMs (dasu-sql2, dasu-pcv2) y la PC física (dasu-pc) obtienen IP directa del router del ISP. No se usa red privada 10.0.100.x.

🌐 Topología de Red

Internet
   │
Router ISP (192.168.1.1 — gateway confirmado)
   │
   ├── srv-dasu     → DHCP del ISP: 192.168.1.13 (vmbr0 bridge sobre enp33s0)
   │    ├── dasu-sql2  (VM 103) → ⚠️ Descartada (sin conectividad IP)
   │    ├── dasu-pcv2  (VM 104) → ⚠️ Descartada (sin conectividad IP)
   │    └── dasu-sql4  (VM 106) → DHCP del ISP: 192.168.1.11 ✅ ACTIVA (SQL+BD restaurada)
   │
   └── dasu-pc      → DHCP del ISP (PC física cliente)

Nota: Todas las máquinas están en la misma red plana del ISP. No hay subnetting privado ni gateway interno. Esto elimina los problemas de routing que existían con el enfoque anterior.

🎯 Objetivo

Crear dos VMs nuevas (SQL Server + PC cliente) en srv-dasu, instalar el sistema DASUTEN sobre SQL Server, y verificar que la PC cliente puede operar el sistema sin estar unida a un dominio, usando la red del ISP.

📅 Fases de Implementación

✅ FASE 1: Preparación del Entorno en srv-dasu (completada 2026-03-27)

  • 1.1: Verificar estado de srv-dasu: conectividad Tailscale ✅ (100.112.46.104, activo), RAM 15 GB total / 10 GB libres / 12 GB disponibles, disco 94 GB / 30 GB disponibles (68%).
  • 1.2: Confirmar que las VMs originales (100, 101, 102) están apagadas ✅ (todas stopped).
  • 1.3: Definir IDs y configuración de las nuevas VMs:
    • VM 103: SQL Server (Windows Server 2022 Core) → DHCP del ISP
    • VM 104: PC cliente (Windows 10 LTSC) → DHCP del ISP
  • 1.4: Verificar ISOs disponibles ✅: Windows_Server_2022_Core_Eval_x64.iso, Windows_10_enterprise_ltsc_2021_x64_dvd_es-es_*.iso, SW_DVD9_SQL_Svr_Enterprise_Edtn_2019*.ISO, virtio-win.iso.
  • 1.5: Verificar configuración bridge vmbr0 ✅ → HALLAZGO CRÍTICO: vmbr0 configurado como estático 10.0.100.1/24 (red privada anterior). Requiere reconfiguración a DHCP del ISP antes de crear las VMs.
  • 1.6: (agregado) Reconfigurar vmbr0: bridge sobre enp33s0 con DHCP del ISP ✅. IP asignada: 192.168.1.13/24, gateway 192.168.1.1. Backup en /etc/network/interfaces.bak.20260327-182319. Aplicado con ifreload -a — Tailscale se reconectó automáticamente.

✅ Resuelto: vmbr0 reconfigurado exitosamente. Las VMs conectadas a vmbr0 ahora obtienen DHCP directo del ISP.

✅ FASE 2: Creación de VM SQL Server (sin dominio) (completada 2026-03-28)

  • 2.1: Crear VM 103 en Proxmox ✅ (4 GB RAM, 2 vCPU, 60 GB disco SATA, vmbr0, SeaBIOS, i440fx). MAC: BC:24:11:8D:EC:46.
  • 2.2: Instalar Windows Server 2022 Core ✅. Instalado vía consola noVNC. Drivers VirtIO instalados vía pnputil /add-driver D:\*.inf /subdirs /install. Red operativa (DHCP ISP). Credencial Admin guardada en candados (dasu-sql2:Administrator). Backup vzdump realizado (modo stop, zstd, 3.28 GB).
  • 2.3: Configurar red: DHCP del ISP ✅. IP actual asignada: 192.168.1.14/24, gateway 192.168.1.1.
  • 2.4: Configurar hostname (dasu-sql2) ✅ y modo Workgroup (WORKGROUP).
  • 2.5: Instalar y habilitar OpenSSH Server (puerto 7022) ✅. Shell por defecto: PowerShell.
  • 2.6: Instalar Tailscale VPN ✅. Cuenta pcdasu0@frlr.utn.edu.ar. IP Tailscale: (Pendiente login). ⚠️ Server Core interfiere con el popup GUI en la instalación normal, requiere comando CLI manual para URL interactiva.
  • 2.7: Instalar SQL Server 2019 ✅. Instalado vía bypass del relay w-zombi (limitación por encoding base64 de W-ZOMBI y escapes booleanos de PowerShell estricto en Server Core). Locale cambiado a es-ES.
  • 2.8: Configurar autenticación mixta SQL ✅. LoginMode=2 (registro), SA habilitado con password, firewall TCP 1433 abierto. Login SA verificado con sqlcmd.
  • 2.9: Verificar conectividad SQL ✅. TCP 1433 accesible desde srv-dasu (192.168.1.13) a dasu-sql2 (192.168.1.19). Login SA verificado localmente.

⏳ FASE 3: Creación de VM PC Cliente (sin dominio)

  • 3.1: Crear VM 104 en Proxmox (4 GB RAM, 2 vCPU, 50 GB disco SATA, vmbr0, SeaBIOS, i440fx) ✅. Instalador de Win 10 LTS montado en IDE2, VirtIO en IDE0. Red: e1000.
  • 3.2: Instalar Windows 10 LTSC ✅.
  • 3.3: Configurar red: DHCP del ISP (gateway del ISP). Anotar IP asignada. ✅ IP: 192.168.1.15.
  • 3.4: Configurar hostname (dasu-pcv2) y modo Workgroup ✅.
  • 3.5: Instalar OpenSSH Server (puerto 7022) ✅ Instalado silente vía QEMU Guest Agent.
  • 3.6: Instalar Tailscale VPN (cuenta pcdasu0@frlr.utn.edu.ar). Anotar IP Tailscale asignada. ✅ IP: 100.98.225.100
  • 3.7: Instalar herramientas cliente SQL (SSMS o sqlcmd) si es necesario.
  • 3.8: Verificar conectividad hacia dasu-sql2 (ping + test TCP 1433).
  • 3.9: ⚠️ PROBLEMA: VMs sin conectividad de red IP. Estado: 192.168.1.x NO responde a ping desde srv-dasu. Investiguando causa (posible conflicto de bridge/red).
  • 3.9: Instalar qemu-guest-agent en VM dasu-pcv2 para backups desatendidos (ACPI shutdown) ✅.

✅ FASE 4: Nueva VM dasu-sql4 (VM 106) (2026-04-09 — 2026-04-10)

  • 4.N1: Crear VM 106 (dasu-sql4) ✅. Eliminar VMs anteriores problemáticas, crear VM limpia.
  • 4.N2: ISO Windows Server 2022 Español ✅. Usar Windows_Server_2022_Spanish_Evaluation.iso.
  • 4.N3: Discos SATA ✅. 60GB (sata0) para SO + 120GB (sata1) para datos SQL.
  • 4.N4: Finalizar instalación Windows ✅.
  • 4.N5: Instalar VirtIO drivers ✅.
  • 4.N6: Configurar hostname dasu-sql4 y Workgroup ✅.
  • 4.N7: Configurar red DHCP ✅. IP: 192.168.1.26.
  • 4.N8: Instalar W-Zombi Relay en srv-dasu y agente PS1 en dasu-sql4 ✅.
  • 4.N9: Instalar Tailscale ✅. IP: 100.107.15.82 (Autenticado remotamente vía Zombi). ⚠️ Inestable, usar relay.
  • 4.N10: Instalar QEMU Guest Agent ✅. (Instalado desatendido desde la unidad VirtIO).
  • 4.N11: Instalar SQL Server 2019 Enterprise ✅. Instalado desatendido vía W-Zombi (comandos individuales). Disco F: 120GB (GPT/NTFS "SQLData") con carpetas DATA/LOG/BACKUP/TEMPDB. Auth mixta, SA habilitado, TCP 1433 abierto. Verificado con sqlcmd @@VERSION.
  • 4.N12: Backup comprimido generado en origen ✅. BACKUP DATABASE ... WITH COMPRESSION ejecutado en srvv-fenix vía tiny_tds. Archivo: E:\BK_SQL\sysdasuten_compressed_ADN.bak.

✅ FASE 5: Migración de Base de Datos a dasu-sql4 (completada 2026-04-11)

  • 5.1: Obtener backup comprimido de DASUTEN ✅. Generado con BACKUP DATABASE ... WITH COMPRESSION en srvv-fenix vía tiny_tds (script dasuten_backup_origen.rb). Archivo: sysdasuten_compressed_ADN.bak en E:\BK_SQL (~1.33 GB).
  • 5.2a: Descargar .bak desde srvv-fenix → srv-ns8 (SMB) ✅. 1333 MB descargados a /var/tmp/ en ~17 seg (76 MB/s).
  • 5.2b: Transferir .bak desde srv-ns8 → srv-dasu (SCP vía Tailscale) ✅. Re-transferido el 2026-04-11 (se perdió del /tmp tmpfs tras reboot por corte de luz).
  • 5.2c: Transferir .bak desde srv-dasu → dasu-sql4 ✅. OpenSSH Server instalado vía W-Zombi (puerto 7022). SCP exitoso usando credencial dasu-sql3:Administrador de bóveda. Archivo en F:\BACKUP\sysdasuten_compressed_ADN.bak (1.397 GB).
  • 5.3: Restaurar base de datos con RESTORE DATABASE en dasu-sql4 ✅. RESTORE con MOVE a F:\DATA y F:\LOG. Procesó 1.186.793 páginas en 26 segundos (354 MB/s).
  • 5.4: Verificar integridad de la base restaurada ✅. DBCC CHECKDB sin errores. BD ONLINE, recovery FULL, compatibilidad nivel 100.
  • 5.5: Registrar credenciales dasu-sql4:Administrador y dasu-sql4:sa en bóveda candados ✅.

✅ FASE 5b: Hardening y Persistencia de Servicios (completada 2026-04-11)

Tests de persistencia (sobreviven reboot)

  • 5b.1: OpenSSH Server (sshd) → StartType: Automatic, Status: Running ✅
  • 5b.2: QEMU Guest Agent → ⚠️ Incompatible/no instala en WS2022 con VirtIO 0.1.285. No bloqueante — gestión remota asegurada vía SSH :7022.
  • 5b.3: SQL Server (MSSQLSERVER) → StartType: Automatic, Status: Running ✅
  • 5b.4: Test de reinicio completo ✅. Restart-Computer ejecutado, sshd y SQL levantaron solos. IP mantuvo 192.168.1.11.

Nota: W-Zombi fue un andamiaje temporal usado para instalar software cuando no había SSH. Ahora que OpenSSH está operativo en :7022, W-Zombi ya no es necesario en esta VM.

🚧 FASE 6: Validación con PC cliente (restore de VM 102) (en curso 2026-04-11)

Estrategia: Restaurar el backup vzdump de la VM 102 (pcv-dasu0, 13.47 GB del 2026-03-16) como VM 107. Esta VM ya tiene el launcher DASUTEN configurado y funcionando con el antiguo SQL en dominio. Se desvinculará del dominio, se renombrará y se apuntará al nuevo SQL Server en modo Workgroup.

Nota: Los discos originales de VM 102 fueron eliminados durante la limpieza de espacio. El backup images:backup/vzdump-qemu-102-2026_03_16-00_40_03.vma.zst se encontró en el storage images de Proxmox.

Preparación de la VM

  • 6.1: Restaurar backup → VM 107 en Proxmox 🚧: 
    qmrestore images:backup/vzdump-qemu-102-2026_03_16-00_40_03.vma.zst 107 --storage local-lvm
  • 6.2: Renombrar VM a dasu-pcv, ajustar config (RAM 4GB, red vmbr0, quitar ISOs).
  • 6.3: Iniciar VM 107 y acceder vía consola noVNC.

Desvinculación del dominio

  • 6.4: Quitar del dominio → unir a WORKGROUP: 
    # Sin DC accesible, forzar salida del dominio:
Remove-Computer -WorkgroupName "WORKGROUP" -Force -Restart
  • 6.5: Renombrar hostname a dasu-pcv: 
    Rename-Computer -NewName "dasu-pcv" -Restart
  • 6.6: Verificar red DHCP del ISP y anotar IP asignada.

Acceso y gestión

Nota: dasu-pcv es una PC cliente con GUI. Se gestiona directamente desde la consola noVNC de Proxmox. No requiere SSH ni W-Zombi.

Reconfiguración DASUTEN

  • 6.7: Reconfigurar connection string del launcher DASUTEN:
    • Servidor: 192.168.1.11 (dasu-sql4)
    • Puerto: 1433
    • Base: sysdasuten
    • Auth: SQL (sa / password en bóveda)
  • 6.8: Ejecutar pruebas funcionales: login al sistema, consultas, altas, reportes.
  • 6.9: Documentar qué funcionalidades dependen del DC (si alguna) y cuáles operan sin él.

Decisión final

  • 6.10: Decisión: ¿Se puede prescindir del DC para esta implementación?
    • ✅ SÍ → Adoptar enfoque definitivo, apagar VMs legacy (100, 101), limpiar VM 105.
    • ❌ NO → Reactivar VMs originales y retomar enfoque con DC.

🔄 Diferencias clave vs enfoque anterior

Aspecto Con DC (P2601.06-08) Sin DC (P2601.09)
Red Privada 10.0.100.x (gw interno) DHCP del ISP (gw del ISP)
Autenticación SQL Windows Integrated (Kerberos) SQL Auth (mixta)
Usuarios Active Directory Usuarios locales Windows
DNS AD DNS (10.0.100.10) DNS del ISP (automático)
Complejidad de red Alta (DC + DNS + dominio + routing) Mínima (red plana ISP)
Puntos de falla DC, SQL, red dominio, routing Solo SQL
VMs necesarias 3 (DC + SQL + PC) 2 (SQL + PC)

⚠️ Consideraciones de red ISP

  • Las IPs asignadas por DHCP del ISP pueden cambiar. Se recomienda reservar IPs en el router del ISP o documentar las IPs asignadas para referencia rápida.
  • Todas las máquinas se ven entre sí directamente (misma LAN del ISP), lo cual simplifica la comunicación pero requiere que el firewall de Windows permita el tráfico SQL (puerto 1433).
  • El acceso remoto a srv-dasu sigue siendo por Tailscale (independiente de la red local ISP).

📊 Recursos

Recurso Valor real
RAM total srv-dasu 15 GB
RAM disponible 12 GB (10 GB libres + 3 GB cache) — VM 103 aún no consume (recién creada)
RAM para nuevas VMs 8 GB (SQL 4GB + PC 4GB) → queda ~4 GB para host
Disco total 94 GB (30 GB disponibles, 68% uso) — thin provisioned
ISOs Win Server 2022 Core, Win 10 LTSC, SQL 2019, virtio-win
Bridge vmbr0 ✅ DHCP ISP sobre enp33s0 — IP: 192.168.1.13/24
Gateway 192.168.1.1 (router ISP confirmado)

8. Lecciones Aprendidas y Troubleshooting

  • New-NetFirewallRule -Enabled en entornos PS puros: Al inyectar comandos de PowerShell a Server Core de forma automatizada (WS2022), debe pasarse el string 'True' y no la variable booleana $True, ya que la Cmdletization falla la conversión estricta al vuelo.
  • Escape JSON en W-ZOMBI de PowerShell: Grandes scripts en línea que se parsean a través de cmd.json destrozan la interpretación si hay fallas en la conexión. Para Server Core sin GUI, fue más seguro bypassear W-ZOMBI subiendo el PowerShell directo sobre un HTTP en Python temporal (/tmp/s.ps1).
  • QEMU-GA y Nombres de Unidad Aleatorios: En entornos con múltiples CDs montados (OS + Drivers VirtIO + CD Extra), Windows Server asigna letras impredecibles (no siempre D:). El path del Agent MSI debe resolverse programáticamente usando Get-WmiObject Win32_CDROMDrive.
  • Usuario Administrador localizado: Al instalar Server Core desde la ISO es-es, el administrador por defecto se renombra literalmente a Administrador en español. Esto es crítico porque intentos de conexión desatendida vía SSH con sshpass o secuencias usando Administrator devolverán "Permission denied", ocultando que el servidor SSH en realidad sí estaba escuchando en el puerto.
  • Compresión Nativa de BACKUP SQL vs RAR: Actualmente el sistema de origen encapsula los .bak dentro de un .rar gigante (ej. bksysdasuten.rar). SQL Server no sabe leer .rar ni ZIP nativamente para operaciones RESTORE DATABASE. Solución definitiva implementada: generar el .bak con WITH COMPRESSION directamente desde SQL Server origen vía tiny_tds. Resultado: ~80% más pequeño, sin pasos intermedios de extracción.
  • W-Zombi y comillas en argumentos PowerShell: Al enviar comandos con comillas dobles a través de W-Zombi (cmd.json), las comillas se escapan incorrectamente (\" en lugar de ""). Solución: enviar comandos individuales sin comillas en los filtros (ej. Get-Disk 1 en vez de Where-Object PartitionStyle -eq "RAW").
  • Instalación SQL Server desatendida vía W-Zombi: Enviar el comando Start-Process D:\setup.exe -ArgumentList "..." -Wait funciona correctamente. La instalación Enterprise tarda ~8 minutos. Las comillas dobles internas se escapan con "" (doble-doble) dentro del argumento.
  • Servir archivos a VMs sin Tailscale directo: Cuando Tailscale cae en la VM, se puede servir archivos desde srv-dasu con python3 -m http.server 8080 en /tmp, y la VM los descarga vía iwr http://192.168.1.13:8080/archivo por la LAN del ISP.
  • Python http.server NO soporta descargas grandes (~1GB+): Invoke-WebRequest y Net.WebClient.DownloadFile() en PowerShell fallan con "conexión terminada inesperadamente" al descargar archivos de ~1.3GB desde python3 -m http.server. El módulo es single-threaded y no maneja correctamente respuestas chunked/grandes. Solución: instalar OpenSSH Server en la VM destino Windows y transferir vía SCP por la LAN (gigabit), que es nativo y confiable para archivos grandes.
  • W-Zombi se bloquea en comandos largos: Cuando el agente PS1 ejecuta un comando que tarda minutos (ej. Add-WindowsCapability), deja de pollear el relay. No se pierde — al terminar, reanuda automáticamente y recoge el siguiente comando en cola. No reiniciar el agente prematuramente.
  • Scripts wrapper evitan problemas de escape con candados: Para comandos con comillas complejas (ej. smbclient -U "user%$PASS"), crear un script .sh local con File.write, asignar chmod 0755, y pasarlo como argumento a candados run. Esto evita el doble/triple escape de comillas.

🔗 Referencias

📝 Lecciones Aprendidas (2026-04-11)

  • /tmp es tmpfs en srv-dasu: Archivos en /tmp se pierden al reiniciar (montado en RAM). Para transferencias intermedias críticas usar /var/tmp o directorio persistente.
  • DHCP del ISP cambia IPs tras reboot: dasu-sql4 obtuvo .11 en vez de .26 tras el corte de luz. Verificar siempre la IP actual usando ARP + MAC antes de asumir que la IP anterior sigue vigente.
  • W-Zombi no sobrevive reboots del agente: El script PS1 debe re-lanzarse manualmente desde la consola Proxmox/noVNC tras un reinicio inesperado de la VM. Considerar crear una Scheduled Task.
  • QEMU Guest Agent no inicia automáticamente: Tras corte de luz, el servicio QEMU-GA quedó caído. Verificar que el servicio esté en Automatic startup.
Reference in New Issue View Git Blame Copy Permalink