Fundamentos de redes de computadoras para administración de servidores

Qué es una red de computadoras (visión operativa para administrar servidores)

Desde la perspectiva operativa, una red de computadoras es el conjunto de componentes que permite que sistemas (servidores, PCs, móviles, dispositivos virtuales) intercambien datos para entregar servicios. Para un administrador de servidores, lo importante no es solo “que haya conexión”, sino entender qué piezas intervienen, qué objetivo se está cumpliendo y dónde puede fallar.

Componentes operativos

• Nodos: equipos que envían/reciben datos. Ejemplos: servidor web, cliente (navegador), firewall, switch, router, VM, contenedor con IP.
• Enlaces: medios y caminos por los que viajan los datos. Ejemplos: cable Ethernet, Wi‑Fi, enlace de fibra, túnel VPN, enlace virtual (vSwitch).
• Servicios: funciones expuestas por los nodos. Ejemplos: HTTP/HTTPS, SMB/NFS, DNS, LDAP/Kerberos, SSH, RDP.
• Objetivos: criterios que guían decisiones y diagnósticos:
  • Conectividad: que exista ruta y resolución de nombres para llegar al servicio.
  • Rendimiento: que el servicio responda rápido y con buen caudal (sin congestión ni cuellos de botella).
  • Disponibilidad: que el servicio esté accesible de forma continua (redundancia, tolerancia a fallos, monitoreo).

Cómo se traduce esto en tareas reales

• Conectividad: verificar IP/prefijo, gateway, DNS, rutas, reglas de firewall, estado de interfaz.
• Rendimiento: medir latencia, pérdida, saturación de enlace, límites de CPU/IO, colas en el switch, MTU.
• Disponibilidad: revisar redundancia (NIC bonding, rutas alternativas), salud de servicios, failover, alertas.

Entorno cliente-servidor: roles típicos que administras

En un modelo cliente-servidor, el cliente inicia solicitudes y el servidor responde. En la práctica, un “servidor” suele cumplir uno o varios roles, y cada rol tiene dependencias de red específicas.

Servidor de aplicaciones

• Qué hace: ejecuta lógica de negocio y expone APIs o sitios web.
• Tráfico típico: clientes → (80/443) → aplicación; aplicación → base de datos (puertos específicos); aplicación → servicios internos (colas, cachés).
• Qué debes vigilar: puertos abiertos, balanceadores, certificados (si aplica), latencia hacia dependencias internas, reglas de seguridad.

Servidor de archivos

• Qué hace: comparte almacenamiento en red.
• Tráfico típico: SMB/CIFS (Windows), NFS (Linux/Unix).
• Qué debes vigilar: rendimiento (ancho de banda y latencia), permisos/autenticación, resolución DNS, MTU si hay enlaces especiales, disponibilidad del almacenamiento.

Servidor de autenticación / directorio

• Qué hace: centraliza identidades, políticas y acceso (por ejemplo, LDAP/Kerberos/AD).
• Tráfico típico: clientes/servidores consultan al directorio para iniciar sesión o validar permisos.
• Qué debes vigilar: sincronización de hora (crítica para Kerberos), DNS correcto, conectividad entre subredes, puertos permitidos, alta disponibilidad.

Información mínima que un administrador debe identificar en cualquier host

Cuando te enfrentas a un incidente (“no hay acceso”, “va lento”, “solo falla desde cierta red”), hay un conjunto de datos que debes poder obtener rápido en el servidor y, si es posible, también en el cliente.

Checklist rápido (qué anotar antes de “tocar” nada)

• IP actual y si es estática o por DHCP.
• Prefijo/máscara y subred esperada.
• Gateway configurado y si responde.
• DNS configurado y si resuelve nombres internos.
• Interfaz correcta (por ejemplo, eth0 vs eth1) y su estado.

Guía práctica paso a paso: identificar y validar conectividad básica

Este procedimiento te ayuda a aislar si el problema es de interfaz, direccionamiento, ruta o DNS. Úsalo tanto en servidores físicos como en VMs.

Paso 1: verificar estado de interfaz y dirección IP

Objetivo: confirmar que la interfaz correcta está activa y tiene IP/prefijo esperados.

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

# Linux (comandos típicos) ip -br addr ip link show # Windows (PowerShell) ipconfig /all Get-NetIPConfiguration

• Si la interfaz está DOWN, revisa configuración, cable/vSwitch, o políticas de energía.
• Si la IP no corresponde a la subred esperada, revisa DHCP, configuración estática o la interfaz equivocada.

Paso 2: validar conectividad local (misma subred)

Objetivo: comprobar que el host puede comunicarse con vecinos y con el switch/segmento.

# Probar con un host de la misma subred ping 192.168.10.20 # Ver tabla ARP (vecinos) ip neigh

• Si no hay respuesta y la IP es correcta, sospecha VLAN incorrecta, filtrado local o problema físico/virtual de enlace.

Paso 3: validar puerta de enlace y salida a otras redes

Objetivo: confirmar que existe ruta por defecto y que el gateway responde.

# Ver rutas ip route # Probar gateway ping 192.168.10.1

• Si el gateway no responde, el problema suele ser de segmentación (VLAN), gateway equivocado o reglas de seguridad.
• Si el gateway responde pero no hay salida, revisa rutas, NAT (si aplica) o firewall perimetral.

Paso 4: separar “problema de DNS” de “problema de red”

Objetivo: comprobar si el fallo es resolución de nombres.

# Probar por IP (si conoces la IP del servicio) curl -I http://203.0.113.10 # Probar resolución DNS (Linux) resolvectl status nslookup ejemplo.interno # Windows nslookup ejemplo.interno

• Si por IP funciona pero por nombre no, el problema es DNS (servidor DNS, zona, registro, búsqueda/sufijos).
• Si ni por IP funciona, vuelve a rutas/firewall/servicio.

Paso 5: validar que el servicio está escuchando en el puerto esperado

Objetivo: distinguir entre “no llego al host” y “llego pero el servicio no responde”.

# Linux ss -lntp # Windows (PowerShell) netstat -ano | findstr LISTENING

• Si el puerto no está en escucha, revisa el servicio (systemd, IIS, etc.) y su configuración.
• Si está en escucha pero desde fuera no conecta, revisa firewall local/perimetral y ACLs.

Mapa conceptual: flujo básico de comunicación cliente → servidor

El siguiente mapa conceptual resume el recorrido típico de una solicitud y los puntos donde un administrador suele diagnosticar.

[Cliente]   | 1) Necesita el nombre del servicio (ej: app.interno)   v[DNS] --(respuesta: IP del servidor)--> [Cliente]   | 2) Decide si el destino es local o remoto (según IP/prefijo)   |    - Si es remoto: usa gateway por defecto   v[Gateway/Router] --(encamina por la red)--> [Red intermedia: switches/routers/firewalls]   | 3) Llega al servidor (IP destino)   v[Servidor]   | 4) La pila de red entrega al puerto del servicio (ej: TCP 443)   v[Servicio/Aplicación]   | 5) Respuesta vuelve por el camino (rutas/estado de sesión)   v[Cliente]

Puntos de control típicos (para ubicar fallos)

• DNS: ¿resuelve al IP correcto?
• Dirección/prefijo: ¿el cliente sabe si debe usar gateway?
• Rutas: ¿existe ruta de ida y de vuelta?
• Firewall/ACL: ¿se permite el puerto/protocolo?
• Servicio: ¿está escuchando y responde?
• Rendimiento: ¿hay latencia/pérdida/saturación?

Glosario mínimo para administración de servidores

• Paquete: unidad de datos a nivel IP que viaja entre direcciones IP origen/destino. Es la “carga” que enrutan los routers.
• Trama: unidad de datos a nivel de enlace (por ejemplo Ethernet) que viaja dentro de una red local; incluye direcciones MAC y encapsula al paquete IP.
• Puerto: identificador lógico (TCP/UDP) que permite que múltiples servicios convivan en una misma IP. Ejemplos: 22 (SSH), 53 (DNS), 80/443 (HTTP/HTTPS).
• Sesión: intercambio mantenido entre extremos (por ejemplo, una conexión TCP) con estado asociado; ayuda a que la comunicación sea ordenada y confiable.
• Latencia: tiempo que tarda un dato en ir de un punto a otro (a menudo medido como RTT). Afecta la “sensación” de rapidez incluso si hay buen ancho de banda.
• Ancho de banda: capacidad de transmisión de un enlace (por ejemplo 100 Mbps, 1 Gbps). No es lo mismo que velocidad percibida si hay latencia, pérdida o congestión.