Módulo 5: Máquinas remotas, redes y scripting

2. Cómo se hablan las máquinas: IP, puertos y DNS

Siguiente →

Descripción

Al terminar esta lección vas a poder diferenciar una IP pública de una privada, explicar qué distingue realmente a localhost, 127.0.0.1 y 0.0.0.0 —y por qué confundirlos rompe despliegues reales, no solo exámenes teóricos—, diagnosticar de memoria por qué un puerto "ya está en uso", y explicar paso a paso qué pasa entre que escribes un dominio y tu máquina obtiene una dirección IP, incluyendo por qué un cambio de DNS "todavía no se ve" aunque ya lo hayas hecho.

Esto no es trivia de certificación. El día que despliegues una API dentro de un contenedor y funcione perfecto por dentro pero nadie pueda conectarse desde afuera, la causa casi siempre es una de las dos primeras direcciones de esta lección mal elegida. El día que muevas tu dominio a un nuevo proveedor y un compañero jure que "el sitio sigue caído" mientras a ti te funciona perfecto, la causa es TTL, no un servidor roto. Sin este modelo, cada uno de esos momentos se siente como magia negra impredecible; con él, se convierte en una pregunta con respuesta.

Conexión con el módulo: la lección anterior mapeó el módulo y prometió que ibas a diagnosticar una conexión por capas —¿resuelve el nombre?, ¿hay alcance?, ¿el puerto responde?— antes de tocar SSH. Esta lección es exactamente el vocabulario de esas capas: direcciones, puertos y DNS. Todavía no vas a usar ping, dig ni curl -v para diagnosticar nada —eso es el método completo de la siguiente lección—. Hoy el objetivo es entender qué es cada pieza, para que mañana sepas qué comando apunta a cuál.

El modelo cliente-servidor: quién pregunta y quién contesta

Imagina que pides comida a domicilio. Tú marcas un número (inicias el contacto), alguien del restaurante que está esperando la llamada contesta, y esa persona responde a tu pedido específico. El restaurante no te llama a ti primero — se queda ahí, con el teléfono listo, esperando a que alguien marque. Si nadie contesta, tu pedido nunca llega, sin importar cuántas veces marques.

Así es prácticamente cualquier comunicación en internet. Una máquina asume el rol de cliente: inicia la conexión, hace una petición concreta y espera una respuesta. La otra asume el rol de servidor: se queda corriendo un proceso que "escucha" pacientemente, listo para aceptar conexiones entrantes y responder a cada una. Tu navegador es cliente cuando visitas una página; el proceso que corre en el servidor de esa página es, justamente, el servidor. Y el mismo modelo aplica en tu propia laptop cuando corres una API local y la consultas con otra terminal: dos procesos, dos roles, uno esperando y otro preguntando.

Ejemplo trabajado

Vas a montar los dos lados de esta conversación en tu propia máquina, sin instalar nada nuevo — Python trae un servidor HTTP mínimo listo para usar.

Terminal 1 — el servidor, esperando conexiones:

python3 -m http.server 8000

Qué esperar:

$ python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

El proceso queda corriendo en primer plano — no te devuelve el prompt. Está en el estado que llamamos "escuchando": abierto, atento, sin hacer nada hasta que alguien se conecte.

Terminal 2 — el cliente, preguntando:

curl http://localhost:8000/

Qué esperar: un bloque de HTML con el listado de archivos de la carpeta desde la que lanzaste el servidor, y en la Terminal 1 una línea nueva de log confirmando que atendió tu petición:

127.0.0.1 - - [21/Jul/2026 09:20:11] "GET / HTTP/1.1" 200 -

Fíjate en ese 127.0.0.1 del log: es la dirección desde la que llegó la conexión — en este caso, tu propia máquina. Esa dirección es exactamente el tema de la siguiente sección.

Direcciones IP: la dirección postal de la máquina

Antes de que una carta llegue a tu casa, el sistema postal necesita una dirección única: calle, número, ciudad. Sin ella, no hay forma de enrutar nada. Una dirección IP cumple el mismo papel para una máquina en una red: un identificador numérico que dice, sin ambigüedad, a qué dispositivo va dirigido cada paquete de datos. La versión más común todavía hoy, IPv4, se ve así: cuatro números de 0 a 255 separados por puntos — 192.168.1.23, 8.8.8.8.

Igual que una dirección postal, hay dos alcances distintos:

  • IP pública: única en todo internet, como un código postal reconocido globalmente. Es la dirección con la que tu router de casa —o el servidor de una empresa— se presenta ante el resto del mundo.
  • IP privada: válida solo dentro de una red local, como el número de departamento que solo tiene sentido una vez que ya llegaste al edificio correcto. El RFC 1918 reserva tres bloques enteros para este uso, que nunca se asignan como direcciones públicas: 10.0.0.0 a 10.255.255.255, 172.16.0.0 a 172.31.255.255, y 192.168.0.0 a 192.168.255.255. Por eso miles de redes distintas —tu casa, tu oficina, la de tu vecino— pueden reutilizar exactamente 192.168.1.1 sin ningún conflicto: esa dirección nunca sale de su propia red.

Puedes ver la IP privada que tu propia máquina tiene asignada ahora mismo:

# macOS (adapta en0 si tu interfaz de red tiene otro nombre)
ipconfig getifaddr en0

# Linux
hostname -I

Qué esperar: una sola línea con un número del rango privado, por ejemplo 192.168.1.23. Un router hace la traducción entre esa IP privada y la IP pública que el resto de internet ve — ese mecanismo se llama NAT (Network Address Translation) y es exactamente por qué puedes tener diez dispositivos en tu casa compartiendo una sola IP pública sin que se pisen entre ellos.

localhost, 127.0.0.1 y 0.0.0.0: tres direcciones que no son intercambiables

Las tres aparecen constantemente en configuraciones de desarrollo, y las tres se parecen lo suficiente como para que confundirlas se sienta inofensivo — hasta que rompe un despliegue completo.

Piensa en un edificio con un sistema de intercomunicador interno. 127.0.0.1 es como hablarte a ti mismo por ese intercomunicador sin que la señal salga jamás del propio departamento: es la dirección de loopback, un truco de red que hace que el paquete nunca abandone tu propia máquina. localhost es simplemente el nombre legible que casi siempre apunta a esa misma dirección — un alias, no una dirección distinta. 0.0.0.0, en cambio, no es un destino al que puedas hablarle: es una instrucción para quien está escuchando, algo así como decirle al portero del intercomunicador "acepta llamadas desde cualquier departamento del edificio, no solo el tuyo". Cuando un servidor se enlaza (bind) a 0.0.0.0, está diciendo "acepta conexiones que lleguen por cualquier interfaz de red de esta máquina" — no solo la interna.

La diferencia deja de ser teórica en el momento exacto en que metes tu aplicación en un contenedor o en una máquina virtual. Si tu servidor se enlaza a 127.0.0.1, solo acepta conexiones que se originen dentro de ese mismo contenedor — ni siquiera la máquina anfitriona que lo contiene puede hablarle por más que el puerto esté mapeado hacia afuera, porque la conexión entrante llega por una interfaz distinta a la de loopback. Si se enlaza a 0.0.0.0, acepta conexiones por cualquier interfaz, incluida la que conecta con el mundo exterior del contenedor. Este es, con diferencia, el motivo número uno por el que "funciona en mi contenedor pero nadie más puede conectarse".

Puedes comprobar el comportamiento restringido tú mismo. Detén el servidor de la Terminal 1 con Ctrl+C y vuelve a levantarlo, esta vez forzando el enlace a loopback:

python3 -m http.server 8000 --bind 127.0.0.1

Qué esperar:

$ python3 -m http.server 8000 --bind 127.0.0.1
Serving HTTP on 127.0.0.1 port 8000 (http://127.0.0.1:8000/) ...

Fíjate en la diferencia con el primer arranque: ahí decía 0.0.0.0, ahora dice 127.0.0.1. Desde tu propia terminal, curl http://localhost:8000/ sigue funcionando exactamente igual —porque tú también estás en la propia máquina—, pero cualquier otro dispositivo de tu red local que intentara alcanzar esa misma IP y puerto se quedaría sin respuesta. Es la misma diferencia, en miniatura, que rompe un contenedor mal configurado.

Puertos: la puerta específica dentro de la máquina, y por qué "ya está en uso"

Una IP te lleva al edificio correcto, pero un edificio tiene muchas puertas. Un puerto es un número de 0 a 65535 que identifica, dentro de una misma máquina, a cuál de los procesos que están escuchando va dirigida cada conexión. Sin puerto, una IP solo te dice "a esta máquina" — con puerto, te dice "a esta máquina, a este servicio específico". Por convención, HTTP escucha en el puerto 80, HTTPS en el 443, SSH en el 22 (lo vas a ver de cerca en la lección 4 de este módulo).

El espacio de puertos se divide en tres franjas, definidas por IANA:

  • 0 a 1023, puertos "bien conocidos", reservados para servicios estándar. En sistemas Unix, enlazar un proceso a uno de estos puertos exige privilegios de administrador — la misma lógica de menor privilegio que viste en la lección anterior del módulo 4 aplica aquí: nadie quiere que cualquier usuario común pueda suplantar el servicio de DNS del sistema con solo levantar su propio proceso.
  • 1024 a 49151, puertos registrados para aplicaciones específicas — aquí caen convenciones informales como el 3000 o el 8000 que usas al desarrollar localmente.
  • 49152 a 65535, puertos dinámicos o efímeros, que el sistema operativo asigna automáticamente a conexiones de salida temporales.

"Escuchando" significa que un proceso reservó ese número de puerto para sí mismo y quedó a la espera de conexiones. Un puerto solo puede tener un proceso escuchando en él a la vez, por eso el mensaje "el puerto ya está en uso" no es un capricho del sistema: es la misma protección de identidad y propiedad que ya viste con archivos, aplicada aquí a un recurso de red.

Compruébalo intentando levantar un segundo servidor en el mismo puerto que el primero, sin haber cerrado el original:

python3 -m http.server 8000

Qué esperar, si la Terminal 1 sigue corriendo su propio servidor en el puerto 8000:

$ python3 -m http.server 8000
Traceback (most recent call last):
  ...
OSError: [Errno 48] Address already in use

(En Linux vas a ver Errno 98 en vez de Errno 48 — el número cambia según el sistema operativo, el mensaje Address already in use es el mismo). El sistema operativo no está bloqueando el puerto arbitrariamente: literalmente ya hay otro proceso —el de tu Terminal 1— enlazado a él, y solo uno puede estarlo a la vez. En la siguiente lección vas a aprender a preguntarle al sistema exactamente qué proceso tiene tomado un puerto, con ss y lsof; por ahora, la solución práctica es cerrar el proceso anterior con Ctrl+C o elegir un puerto distinto.

DNS: el directorio que traduce nombres en direcciones

Nadie memoriza el número de teléfono de sus contactos — tocas un nombre en tu agenda y el teléfono hace la traducción por ti. El DNS (Domain Name System) cumple ese papel para internet: traduce nombres legibles como example.com en la dirección IP numérica que la red realmente necesita para enrutar el tráfico. Sin DNS, tendrías que memorizar IPs para visitar cualquier sitio.

La traducción sigue, en su forma simplificada, esta secuencia:

  1. Tu máquina revisa primero si ya tiene esa respuesta guardada de una consulta reciente (caché local).
  2. Si no la tiene, le pregunta a un resolutor recursivo —normalmente el de tu proveedor de internet o uno público como 8.8.8.8— que hace el trabajo pesado en tu nombre.
  3. Ese resolutor, si tampoco tiene la respuesta en caché, recorre una jerarquía: pregunta a un servidor raíz qué servidor sabe de .com, luego le pregunta a ese servidor de .com quién es el servidor autoritativo de example.com, y finalmente le pregunta a ese servidor autoritativo por el registro exacto.
  4. El servidor autoritativo responde con el dato real, el resolutor lo guarda en caché por un tiempo determinado, y te lo devuelve a ti.

El "dato real" que se devuelve suele ser uno de dos tipos de registro:

  • Registro A: mapea un nombre directamente a una dirección IPv4. Es la traducción más simple — "este nombre es esta IP", punto.
  • Registro CNAME (canonical name): mapea un nombre a otro nombre, no a una IP. Es un alias — si blog.example.com tiene un CNAME hacia example.com, resolver el primero implica resolver también el segundo, un paso más en la cadena.

Cada registro trae asociado un TTL (time to live), un número en segundos que le dice a cada resolutor cuánto tiempo puede confiar en esa respuesta antes de volver a preguntar. Aquí está el detalle que sorprende a casi todo el mundo la primera vez: el reloj del TTL no arranca cuando tú cambias el registro — arranca en el momento en que cada resolutor distinto guardó su propia copia en caché. Imagina que tu equipo actualiza el registro A de app.empresa.com para que apunte a un servidor nuevo, y ese registro tenía un TTL de 3600 segundos (una hora). Un resolutor que guardó la IP vieja hace 5 minutos va a seguir devolviendo la IP vieja durante 55 minutos más. Otro resolutor, en otra ciudad, que la guardó hace 58 minutos, va a actualizarse en 2 minutos. Nadie mintió, nadie rompió nada — cada copia en caché, en cada punto del mundo, simplemente vence en un momento distinto. Es exactamente por qué, la próxima vez que muevas un dominio de proveedor, conviene bajar el TTL a un valor pequeño (por ejemplo 300 segundos) uno o dos días antes del cambio: para que, cuando llegue el momento real, ninguna caché tenga que esperar una hora entera para enterarse.

/etc/hosts: tu propio mini-DNS local, sin pedirle permiso a nadie

Antes de que tu máquina le pregunte a cualquier resolutor externo, revisa un archivo de texto plano que vive en tu propio disco: /etc/hosts. Es, literalmente, una nota adhesiva pegada arriba de la agenda completa — si tu nota ya tiene la respuesta, el sistema ni se molesta en consultar la agenda real. Cada línea del archivo asocia una dirección IP con uno o más nombres, exactamente con el mismo formato con el que ya viste resolver un nombre en el ejemplo del servidor.

cat /etc/hosts

Qué esperar como mínimo (el contenido exacto varía por sistema):

127.0.0.1       localhost
::1             localhost

Esa primera línea es, de hecho, la razón por la que localhost siempre resuelve a 127.0.0.1 sin necesidad de ningún DNS real: ya está escrito ahí, localmente, desde que instalaste el sistema operativo.

Puedes agregar tus propias entradas para darle un nombre memorable a un servicio que corres localmente, sin tocar ningún DNS real ni depender de internet. Con permisos de administrador —vas a necesitar sudo porque este archivo pertenece a root, tal como viste en la lección anterior del módulo 4—, agrega una línea al final:

127.0.0.1       myapp.local

Con el servidor de la Terminal 1 corriendo de nuevo en el puerto 8000 (recuerda relanzarlo sin --bind 127.0.0.1 si quieres que acepte la conexión), prueba:

curl http://myapp.local:8000/

Qué esperar: exactamente la misma respuesta que obtuviste antes con localhost — porque, para tu sistema, myapp.local ahora significa 127.0.0.1, sin que ningún servidor DNS real haya intervenido en absoluto. Es un atajo genuinamente útil cuando desarrollas contra varios servicios locales a la vez y quieres nombrarlos en vez de recordar números de puerto sueltos.

Por qué esta capa sigue siendo tuya, aunque una plataforma "lo resuelva todo"

Es tentador pensar que, si despliegas en una plataforma moderna que promete gestionar DNS, certificados y balanceo de forma automática, este modelo dejó de importarte. No es así. La plataforma automatiza el papeleo, no elimina la física de la red: cuando conectas un dominio propio, sigues esperando la propagación de un TTL. Cuando tu contenedor no responde desde afuera, la causa sigue siendo un enlace a 127.0.0.1 en vez de 0.0.0.0. Cuando dos servicios de tu proyecto compiten por el mismo puerto en tu máquina de desarrollo, el mensaje sigue siendo Address already in use. La plataforma abstrae el cómo configurarlo, pero el qué está pasando cuando algo falla sigue siendo exactamente este modelo — y es la única forma de diagnosticar un problema que la interfaz bonita de la plataforma no te explica.

Errores comunes

Creer que un cambio de DNS se ve al instante en todo el mundo (conceptual). Qué pasa: el estudiante actualiza un registro A o CNAME, lo revisa desde su propia máquina cinco minutos después, ve el resultado nuevo, y concluye que "ya está propagado para todos". Después recibe un reporte de un compañero o un cliente que sigue viendo la versión vieja, y asume que algo se rompió. Por qué ocurre: confunde su propia caché local —que puede haber vencido o nunca haber guardado el valor viejo— con el estado de todas las cachés del mundo, cada una con su propio reloj de TTL corriendo desde un momento distinto. Cómo detectarlo: si tu respuesta ante un reporte de "todavía veo la versión vieja" es "no puede ser, a mí ya me funciona", esa es la señal. Cómo corregirlo: recuerda que el TTL cuenta desde que cada resolutor guardó su copia, no desde que tú cambiaste el registro — un cambio no está completamente propagado hasta que pasa, como mínimo, el TTL original completo desde el momento del cambio, y baja el TTL con anticipación antes de cualquier migración planeada.

Pensar que 0.0.0.0 es una dirección a la que puedes conectarte (conceptual). Qué pasa: el estudiante ve 0.0.0.0 en la salida de un servidor y después intenta usar esa misma cadena como destino —por ejemplo, escribiéndola en el navegador o pasándosela a curl— esperando llegar al servicio. Por qué ocurre: 0.0.0.0 aparece en el mismo lugar visual donde antes vio 127.0.0.1, y ambas se parecen a "una IP más", así que el estudiante las trata como intercambiables. Cómo detectarlo: si alguna vez copiaste literalmente 0.0.0.0 de la salida de un servidor para pegarla como URL de destino, ese es el síntoma. Cómo corregirlo: recuerda que 0.0.0.0 es una instrucción de "acepta por cualquier interfaz", dirigida al proceso que escucha — nunca un destino válido al que conectarte desde el lado del cliente. Para conectarte, usa localhost, 127.0.0.1, o la IP real de la máquina.

Interpretar "Address already in use" como que el puerto está roto o bloqueado permanentemente. Qué pasa: el estudiante ve el error, prueba el mismo puerto varias veces más, sigue fallando, y concluye que ese número de puerto específico "no funciona" en su máquina, cambiando de puerto sin entender la causa real. Por qué ocurre: el mensaje no dice explícitamente "hay OTRO proceso tuyo corriendo ahora mismo" — solo dice que la dirección ya está en uso, y sin ese contexto suena a una falla permanente del propio número. Cómo detectarlo: si reiniciaste tu máquina completa solo para "liberar" un puerto en vez de buscar qué proceso lo tenía tomado, esa es la señal de que no identificaste la causa real. Cómo corregirlo: el error significa, casi siempre, que un proceso previo —tuyo, de una terminal anterior que olvidaste cerrar— sigue escuchando en ese puerto. Ciérralo con Ctrl+C en la terminal donde corre, o espera a la siguiente lección para aprender a identificar exactamente qué proceso lo ocupa sin tener que adivinar.

Ejercicios

1. Clasifica cada una de estas direcciones como IP pública o IP privada, y justifica cada una con el rango correspondiente: 10.0.0.5, 8.8.8.8, 192.168.1.1, 172.20.4.4, 203.0.113.10.

Ver solución
  • 10.0.0.5 — privada (dentro de 10.0.0.0/8).
  • 8.8.8.8 — pública (fuera de los tres rangos reservados por RFC 1918).
  • 192.168.1.1 — privada (dentro de 192.168.0.0/16, el rango típico de routers domésticos).
  • 172.20.4.4 — privada (dentro de 172.16.0.0/12, que cubre de 172.16.x.x a 172.31.x.x).
  • 203.0.113.10 — pública (fuera de los tres rangos privados; de hecho, este bloque específico está reservado por convención solo para documentación y ejemplos, exactamente el uso que le acabas de dar).

Esto funciona porque los tres rangos privados son exactamente los que RFC 1918 reservó y ningún router de internet enruta — cualquier dirección fuera de esos tres bloques es, por definición, potencialmente enrutable en la red pública.

2. Intentas levantar tu API en el puerto 5000 y ves este error:

OSError: [Errno 48] Address already in use

¿Qué está pasando exactamente, y qué dos soluciones inmediatas tienes sin necesidad todavía de identificar qué proceso específico ocupa el puerto?

Ver solución

El sistema operativo te dice que ya hay otro proceso —casi seguro tuyo, de un intento anterior que no cerraste— enlazado (bind) a ese mismo puerto en esa misma máquina, y un puerto solo admite un proceso escuchando a la vez. Sin identificar todavía cuál proceso es, tienes dos salidas inmediatas: revisar tus terminales abiertas y cerrar con Ctrl+C cualquier servidor anterior que hayas dejado corriendo, o simplemente levantar tu API en un puerto distinto (por ejemplo 5001) mientras resuelves cuál proceso tiene tomado el 5000. Esto funciona porque el error no describe un puerto dañado —los puertos no se dañan—, describe un recurso momentáneamente ocupado por otro proceso vivo.

3. Tu equipo actualiza el registro A de app.empresa.com para apuntar a un servidor nuevo. El registro tenía un TTL de 3600 segundos. Cuarenta minutos después del cambio, un compañero en otra ciudad reporta que todavía ve el sitio viejo. ¿Está roto el cambio? ¿Cuándo, como máximo, debería verlo actualizado?

Ver solución

No, el cambio no está roto. El resolutor DNS que usa tu compañero probablemente guardó en caché el registro viejo poco antes de que ustedes hicieran el cambio, y ese TTL de 3600 segundos (una hora) todavía no venció desde el punto de vista de esa caché específica — el reloj cuenta desde que esa caché guardó el valor, no desde que tu equipo lo cambió. En el peor de los casos, tu compañero va a ver el valor actualizado a más tardar 3600 segundos (una hora completa) después del momento del cambio, si su resolutor cacheó el valor viejo justo un instante antes de la actualización. Esto funciona porque cada resolutor en el mundo mantiene su propia copia independiente con su propio vencimiento — no existe un mecanismo que empuje el cambio a todas las cachés de inmediato.

4. Agregas 127.0.0.1 api.local a tu /etc/hosts y levantas un servidor con python3 -m http.server 4000 --bind 127.0.0.1. ¿Funcionará curl http://api.local:4000/ desde tu propia máquina? ¿Funcionaría desde otra computadora de tu misma red local? Explica ambas respuestas.

Ver solución

Desde tu propia máquina, sí va a funcionar: /etc/hosts traduce api.local a 127.0.0.1 antes de que se consulte ningún DNS real, y el servidor —aunque enlazado estrictamente a 127.0.0.1— sí acepta conexiones que se originan en la propia máquina, porque eso es exactamente lo que la dirección de loopback permite. Desde otra computadora de la red, no va a funcionar por dos razones independientes que se refuerzan: primero, esa otra máquina no tiene la entrada api.local en su propio /etc/hosts, así que ni siquiera sabría a qué IP apuntar; y segundo, aunque se conectara directamente a la IP real de tu máquina en la red, el servidor enlazado a 127.0.0.1 rechazaría esa conexión porque no llega por la interfaz de loopback. Esto funciona porque /etc/hosts es local a cada máquina —no se comparte automáticamente— y el enlace a 127.0.0.1 es una restricción del propio proceso servidor, independiente de cómo resolviste el nombre.

Resumen y siguiente paso

Hoy viste el vocabulario completo que necesitas antes de diagnosticar nada: el modelo cliente-servidor como la conversación básica entre dos procesos, las IP públicas y privadas como direcciones de distinto alcance, la diferencia real entre localhost, 127.0.0.1 (un destino válido, restringido a la propia máquina) y 0.0.0.0 (una instrucción de enlace, nunca un destino), los puertos como la puerta específica dentro de una máquina y por qué solo un proceso puede tenerla tomada a la vez, y el DNS como el directorio jerárquico que traduce nombres en direcciones, con TTL determinando cuánto tarda cada caché individual en enterarse de un cambio. También viste /etc/hosts como tu propio atajo local, anterior a cualquier consulta DNS real.

Antes de avanzar deberías poder: clasificar cualquier IP como pública o privada de memoria; explicar sin dudar por qué un servidor enlazado a 127.0.0.1 dentro de un contenedor es invisible desde afuera aunque el puerto esté mapeado; explicar qué significa "Address already in use" sin pensar que el puerto está roto; y explicar, con tus propias palabras, por qué un cambio de DNS puede tardar hasta el TTL completo en verse en todas partes.

Lo que aprendiste hoy es el mapa; la siguiente lección es la brújula. Con el vocabulario de IP, puertos y DNS ya en tu cabeza, en la próxima lección vas a aprender el método para descartar por capas —¿resuelve el nombre?, ¿hay alcance?, ¿el puerto responde?, ¿la respuesta es correcta?— con herramientas concretas: ping, dig, curl -v y ss. Cada una de esas herramientas va a apuntar exactamente a uno de los conceptos que viste hoy.

Recursos

← Anterior1. Introducción: salir de tu máquina y automatizar el trabajoSiguiente →3. Diagnosticar la red desde la terminal: ping, dig, curl y ss