Buenas prácticas operativas de redes de computadoras para administradores de servidores

Objetivo operativo: redes predecibles y cambios seguros

En operación diaria, una red “buena” no es la más compleja, sino la que se puede entender, auditar y cambiar sin sorpresas. Este capítulo consolida prácticas aplicables para administradores de servidores: documentación mínima pero suficiente, control de cambios, respaldos de configuración y verificación posterior. Además, incluye listas de verificación para altas de servidores y patrones para evitar incidencias recurrentes.

Documentación técnica mínima (la que realmente se usa)

La documentación operativa debe ser breve, actualizable y fácil de consultar durante una incidencia. Evita documentos “perfectos” que nadie mantiene. Mantén un repositorio central (wiki interna o repositorio Git) con plantillas simples.

1) Topología (física y lógica)

Qué debe incluir:

• Diagrama de alto nivel: sedes, enlaces, firewalls, switches core/distribución, balanceadores, hipervisores.
• Diagrama lógico por zona: usuarios, servidores, DMZ, gestión, almacenamiento, backups.
• Puntos de falla y redundancia: enlaces, VRRP/HSRP, LACP, pares HA.

Guía práctica paso a paso:

• Empieza con un diagrama “L3”: subredes/zona y dispositivos que enrutan.
• Agrega “L2” solo donde importe: trunks, VLANs, enlaces agregados.
• Incluye un inventario mínimo por dispositivo: nombre, rol, ubicación, IP de gestión, método de acceso (SSH/console), responsable.
• Versiona el diagrama (fecha y autor del último cambio).

2) Rangos IP (plan de direccionamiento operativo)

Qué debe incluir:

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

• Tabla por subred: propósito, VLAN asociada, gateway, rango utilizable, reservas, DHCP (si aplica), rutas relevantes.
• Bloques reservados: infraestructura (switches, firewalls), servidores, VIPs/balanceo, iDRAC/iLO, almacenamiento.

3) VLANs (segmentación y propósito)

Qué debe incluir:

• ID de VLAN, nombre, propósito, subred asociada, dónde existe (switches/segmentos), puertos access típicos, trunks permitidos.
• Reglas de “no mezclar”: por ejemplo, gestión separada de producción.

Plantilla rápida:

VLAN: 110
Nombre: SRV-PROD
Subred: 10.20.10.0/24
Gateway: 10.20.10.1
Trunks permitidos: SW-CORE1<->SW-DIST*, FW-HA
Puertos access típicos: racks de servidores
Notas: sin acceso directo desde VLAN usuarios

4) DNS (zonas, convenciones y dependencias)

Qué debe incluir:

• Zonas internas y externas (si aplica), servidores autoritativos/recursivos, reenviadores, TTL estándar, política de registros (A/AAAA, PTR, CNAME).
• Convención de nombres: entorno, rol, ubicación (ej.: app01.prod.madrid.intra).
• Reglas para registros reversos (PTR) y quién los gestiona.

Práctica recomendada: documenta “fuente de verdad” (IPAM/CMDB o repositorio) para que IP ↔ nombre no se desalineen.

Control de cambios en configuración de red (cambios pequeños, seguros y trazables)

El objetivo del control de cambios no es burocracia: es reducir riesgo y acelerar recuperación. Un cambio de red debe ser reproducible, revisable y reversible.

Flujo operativo recomendado

1. Solicitud y alcance: qué se cambia, por qué, a quién afecta, ventana de mantenimiento.
2. Evaluación de impacto: dependencias (VLAN, rutas, ACL, NAT, balanceo, DNS), riesgo y plan de comunicación.
3. Plan de implementación: pasos exactos, comandos, orden, tiempos estimados.
4. Plan de rollback: cómo volver al estado anterior (comandos y validaciones).
5. Revisión por pares: otro admin valida el plan (especialmente ACL/firewall y routing).
6. Ejecución: registrar hora, operador, cambios realizados.
7. Verificación post-cambio: checklist de pruebas técnicas y de servicio.
8. Documentación: actualizar topología, rangos IP, VLANs, DNS, y adjuntar diffs.

Formato mínimo de “ticket de cambio”

ID: NET-CHG-2026-0017
Motivo: alta de nueva VLAN para cluster de BD
Alcance: SW-CORE1/2, FW-HA, IPAM, DNS
Ventana: 02:00-03:00
Riesgo: medio (impacto en routing/ACL)
Plan:
  1) Crear VLAN 210 en core
  2) Crear SVI/gateway 10.30.210.1/24
  3) Permitir VLAN 210 en trunks X/Y
  4) Crear reglas FW mínimas hacia servicios requeridos
Rollback:
  - Eliminar SVI, remover VLAN de trunks, revertir reglas FW
Verificación:
  - Ping gateway, DNS, NTP; pruebas de puerto a servicios
Adjuntos:
  - diff configuración, diagrama actualizado

Copias de seguridad de configuraciones (y cómo hacerlas útiles)

Un backup de configuración sirve si: (1) es frecuente, (2) está versionado, (3) se puede restaurar rápido, (4) está protegido.

Qué respaldar

• Switches, routers, firewalls, balanceadores, controladoras Wi-Fi (si aplica).
• Configuración de servicios de red críticos: DNS, DHCP, NTP, IPAM/CMDB (export), VPN.
• Plantillas y scripts de automatización (repositorio).

Guía práctica paso a paso (modelo agnóstico al fabricante)

1. Define frecuencia: diario para equipos críticos; semanal para periféricos; adicional “antes de cambios”.
2. Centraliza: servidor de backups con acceso restringido y auditoría.
3. Versiona: guarda cada configuración con marca de tiempo y conserva histórico (rotación).
4. Protege: cifrado en reposo, control de acceso, y copias fuera del sitio si aplica.
5. Prueba restauración: al menos mensual, en laboratorio o equipo de repuesto/virtual.

Convención de nombres sugerida:

/backups/network/{site}/{device}/{device}-running-{YYYYMMDDHHmm}.cfg
/backups/network/{site}/{device}/{device}-startup-{YYYYMMDDHHmm}.cfg

Consejo operativo: guarda también el “estado” asociado: versión de firmware/OS, módulos/licencias, y checksum del archivo.

Verificación posterior a cambios (no basta con “no se cayó”)

La verificación debe confirmar conectividad, resolución de nombres, sincronía horaria y exposición de puertos esperada. Haz pruebas desde al menos dos puntos: desde el propio servidor y desde un host en otra VLAN/zona.

Checklist post-cambio (red y servicio)

• Conectividad L3: reachability a gateway y a una IP remota de referencia.
• Rutas: la ruta esperada existe (sin asimetrías inesperadas).
• DNS: resolución directa e inversa coherente.
• NTP: sincronización correcta (evita fallos de TLS/Kerberos y logs inconsistentes).
• Puertos: solo los puertos necesarios están accesibles desde las redes permitidas.
• Observabilidad: métricas/logs sin errores nuevos (drops, flaps, CPU alta, errores de interfaz).

Comandos de verificación típicos (ejemplos)

# Conectividad y ruta (Linux)
ip route
ping -c 3 10.20.10.1
traceroute 10.20.99.10

# DNS
getent hosts app01.prod.intra
nslookup app01.prod.intra
nslookup 10.20.10.55

# NTP
timedatectl status
chronyc sources -v  # si usa chrony

# Puertos (cliente)
ss -lntup | head
nc -vz 10.20.10.55 22
nc -vz 10.20.10.55 443

Lista de verificación para alta de servidores (operación repetible)

Usa esta lista como “pre-flight” antes de poner un servidor en producción. Idealmente, conviértela en plantilla de ticket y automatízala parcialmente.

Checklist de red para alta

• IP: asignada (estática o reserva), sin conflicto, registrada en IPAM/CMDB.
• Máscara/prefijo: correcto para la subred.
• Gateway: correcto y alcanzable.
• VLAN/puerto: puerto switch en VLAN correcta (access) o trunk si aplica; descripción del puerto actualizada.
• DNS: servidores DNS correctos; registro A/AAAA creado; PTR creado; TTL acorde a política.
• NTP: servidores NTP definidos; sincronización verificada.
• Puertos/servicios: lista de puertos entrantes/salientes requeridos; reglas de firewall mínimas aplicadas.
• MTU: validada si hay redes especiales (almacenamiento/overlay).
• Seguridad: acceso de administración desde redes permitidas; sin exposición innecesaria.

Plantilla de “alta de servidor” (para pegar en un ticket)

Servidor: app01
Entorno: prod
Ubicación: DC1 / Rack R3
VLAN: 110 (SRV-PROD)
IP: 10.20.10.55/24
Gateway: 10.20.10.1
DNS: 10.20.99.53, 10.20.99.54
Nombre FQDN: app01.prod.intra
PTR: 55.10.20.10.in-addr.arpa
NTP: 10.20.99.123, 10.20.99.124
Puertos entrantes requeridos:
  - 22 desde 10.20.99.0/24 (gestión)
  - 443 desde 10.20.0.0/16 (apps internas)
Puertos salientes requeridos:
  - 53/udp,tcp hacia DNS
  - 123/udp hacia NTP
Validaciones:
  - ping gw OK
  - DNS directa/inversa OK
  - NTP sync OK
  - pruebas de puerto OK

Patrones para evitar incidencias comunes

1) Conflictos de IP

Síntomas típicos: desconexiones intermitentes, ARP flapping, sesiones que “saltan” entre equipos, logs con MAC cambiantes.

Patrones preventivos:

• Fuente de verdad: toda IP estática debe registrarse antes de usarse (IPAM/CMDB).
• Reservas por bloques: separa rangos (infra/servidores/VIPs) para reducir colisiones.
• Política DHCP: si hay DHCP en la subred, evita usar IPs dentro del pool para estáticos.
• Verificación antes de asignar: prueba de reachability/ARP desde un host de administración.

Mini-procedimiento:

1. Consulta IPAM: confirmar que la IP está libre.
2. Desde una máquina en la misma VLAN, intenta ping a la IP (si responde, investiga).
3. Revisa tabla ARP del gateway/switch para ver MAC asociada (si tienes acceso).
4. Solo entonces asigna la IP y registra el cambio.

2) DNS incoherente (directa e inversa no alineadas)

Síntomas típicos: fallos de autenticación, certificados/TLS con nombre incorrecto, herramientas que dependen de PTR, confusión en logs.

Patrones preventivos:

• Alta DNS como parte del alta de IP: no como tarea “después”.
• Regla A/AAAA ↔ PTR: si existe A/AAAA, debe existir PTR correspondiente (salvo excepciones documentadas).
• Convención de nombres: evita nombres ambiguos; incluye entorno/rol.
• TTL razonable: TTL muy alto dificulta cambios; TTL muy bajo aumenta carga. Define estándar por tipo de registro.

3) Reglas de firewall demasiado amplias

Síntomas típicos: superficie de ataque innecesaria, movimiento lateral, auditorías fallidas, exposición accidental.

Patrones preventivos:

• Principio de mínimo privilegio: permitir solo origen/destino/puerto necesarios.
• Reglas por servicio: agrupa por aplicación/flujo, no por “any-any”.
• Objetos y etiquetas: usa grupos (por ejemplo, “APP-PROD-SERVERS”) para evitar reglas repetidas y errores.
• Caducidad: reglas temporales deben tener fecha de expiración y responsable.
• Revisión periódica: elimina reglas huérfanas; valida hits/contadores.

Ejemplo de anti-patrón y corrección (conceptual):

# Anti-patrón
permit any -> app01 tcp/443

# Mejor
permit 10.20.0.0/16 -> app01 tcp/443
permit 10.20.99.0/24 -> app01 tcp/22
deny   any -> app01 any (implícito o explícito según política)

Escenarios integradores (validación práctica de competencias)

Escenario 1: Alta completa de un servidor web interno

• Contexto: se despliega web02 en VLAN de servidores. Debe ser accesible por HTTPS desde redes internas y administrable por SSH solo desde la red de gestión.
• Entregables: registro en IPAM/CMDB, registros DNS (A y PTR), ticket de cambio, reglas de firewall mínimas, evidencia de verificación (comandos/salidas).
• Validaciones: conectividad, DNS directa/inversa, NTP sincronizado, puerto 443 accesible desde red permitida y 22 solo desde gestión.

Escenario 2: Cambio controlado: creación de una nueva VLAN para un clúster

• Contexto: se requiere una VLAN nueva para un clúster de base de datos con acceso limitado desde una capa de aplicación.
• Entregables: actualización de documentación (VLAN, subred, topología), plan de implementación y rollback, backup pre-cambio de equipos afectados, checklist post-cambio.
• Validaciones: trunking permitido solo donde corresponde, gateway operativo, reglas de firewall específicas por puertos, pruebas de conectividad entre capas.

Escenario 3: Incidencia por conflicto de IP en producción

• Contexto: un servicio presenta cortes intermitentes; se sospecha conflicto de IP.
• Entregables: hipótesis, pasos de diagnóstico, identificación del segundo host, corrección (reasignación/aislamiento), actualización de IPAM y documentación del incidente.
• Validaciones: estabilidad tras el cambio, ausencia de ARP flapping, verificación de servicio.

Escenario 4: DNS incoherente tras migración

• Contexto: se migró un servidor a otra IP; el nombre resuelve, pero algunos sistemas fallan por PTR antiguo.
• Entregables: corrección de registros A/AAAA y PTR, ajuste de TTL si aplica, evidencia de propagación/validación, actualización de la plantilla de cambio para incluir verificación inversa.
• Validaciones: resolución directa e inversa consistente desde al menos dos redes.

Escenario 5: Auditoría interna detecta reglas de firewall amplias

• Contexto: existen reglas “any-any” históricas para una aplicación crítica.
• Entregables: plan de reducción de permisos por etapas, propuesta de reglas mínimas, ventana de cambio, rollback, pruebas de regresión de aplicación.
• Validaciones: aplicación funcional con reglas acotadas, contadores/hits revisados, documentación actualizada y reglas temporales con caducidad.