El mapa mínimo de una red e Internet
Mara escribe fotos.example en una aplicación. Un instante después aparece una imagen del servicio. Entre ambos hechos hay varias preguntas que una sola palabra —«Internet»— no responde: ¿qué dispositivo ejecutó la aplicación?, ¿cómo obtuvo un dato de dirección a partir del nombre?, ¿qué punto lógico de la aplicación intentó alcanzar?, ¿qué enlaces y routers participaron?, ¿qué extremo respondió y qué permite afirmar esa respuesta?
Este capítulo construye un mapa mínimo para seguir una interacción sin confundir nombre, dirección, identidad, puerto o permiso. No calcularemos subredes, no estudiaremos protocolos de routing ni configuraremos DNS o Transport Layer Security (TLS). Esos mecanismos vendrán después. Aquí aprenderemos qué pregunta responde cada elemento y qué conclusión queda fuera de su alcance.
El mapa parte de dos dispositivos y crece sólo cuando hace falta: un enlace dentro de una red local, un router que conecta con otras redes, un camino posible hacia un servicio, un nombre que se resuelve a datos de dirección y un puerto que sitúa la entrega lógica. Al final añadiremos TLS como límite conceptual de un canal protegido, sin reducirlo a «el candado del navegador».
Vista adaptada. Toca el diagrama para ampliarlo.
Un recorrido antes que una nube
En muchos diagramas, Internet aparece como una nube. La nube es útil para ocultar detalles que no importan, pero no debe ocultar las entidades necesarias para razonar. En nuestro recorrido hay un teléfono C, un punto de acceso A, un router R y un servicio S. C y A comparten un enlace local; R conecta ese alcance con otros; S se encuentra tras un camino que puede incluir más dispositivos y enlaces.
El dibujo no afirma que ésa sea la topología física completa. Es un modelo con una frontera. Podemos observar que C se comunica localmente con A, que R es el siguiente sistema configurado para ciertos destinos y que una respuesta atribuible a S regresa. Los tramos intermedios pueden permanecer agrupados mientras no sostengamos afirmaciones específicas sobre ellos.
Esta forma de dibujar evita dos errores. El primero es tratar Internet como un único dispositivo que recibe y devuelve mensajes. El segundo es inventar cada salto para llenar el espacio. Un buen mapa muestra las entidades conocidas, las dependencias necesarias y las zonas no observadas.
Dispositivo, host y persona
Un dispositivo es una entidad física o virtual capaz de participar en una interacción: teléfono, portátil, router, servidor o máquina virtual. Un host es un sistema final que ejecuta aplicaciones y participa en protocolos de comunicación. Ninguno de esos términos equivale a persona. Mara puede usar un teléfono; varias personas pueden compartirlo; un programa puede actuar sin que alguien mire la pantalla.
RFC 1122 describe la arquitectura de Internet en términos de hosts conectados a redes y de gateways que interconectan redes (RFC 1122, §1.1.3). El vocabulario es arquitectónico. No atribuye identidad humana ni permiso. Si un registro muestra actividad desde un host, demuestra actividad asociada con ese sistema o dirección dentro de cierto contexto, no quién sostuvo físicamente el dispositivo.
Esta distinción conecta con el capítulo 0.6. Persona, principal, cuenta y sesión pertenecen a un modelo de identidad y autoridad. Dispositivo y host pertenecen al mapa de comunicación. Pueden relacionarse, pero una dirección de host no sustituye una identidad autenticada.
Enlace y vecindad
Un enlace conecta participantes vecinos dentro de cierto alcance. Puede ser inalámbrico, cableado o virtual; aquí no estudiaremos su tecnología. Lo importante es que describe una relación local, no el camino completo hacia cualquier destino. El teléfono puede alcanzar el punto de acceso por un enlace y depender después de otros enlaces que no observa directamente.
Decir «está conectado al Wi‑Fi» informa una relación local. No demuestra que exista un camino funcional hasta el servicio, que DNS responda, que el puerto de aplicación esté disponible ni que Mara tenga autorización. También puede haber un enlace activo sin una configuración útil para continuar el recorrido.
La observación inversa exige el mismo cuidado. Si la aplicación no obtiene respuesta, no podemos culpar al enlace local sólo porque es visible. El fallo podría estar antes de emitir, en la resolución de nombre, en otro tramo, en el extremo o en la aplicación. Un diagnóstico empieza marcando fronteras, no eligiendo la causa más cercana.
Red local como alcance
Llamaremos red local al alcance en el que ciertos dispositivos y enlaces participan bajo reglas comunes de conectividad. «Local» depende de la arquitectura; no significa automáticamente seguro, privado, pequeño ni controlado por una sola persona. Tampoco es una frontera universal: un mismo dispositivo puede participar en más de una relación de red.
En el mapa, C, A y la interfaz local de R forman el alcance que necesitamos representar. S está fuera. Esa separación permite preguntar qué sistema reenvía hacia otros destinos sin afirmar todavía cómo calcula rutas o traduce direcciones. El capítulo posterior de redes desarrollará esas decisiones.
La red local tampoco concede confianza. Alcanzar otro dispositivo en el mismo alcance no prueba identidad ni permiso. Las políticas de aplicación y los mecanismos de autenticación siguen siendo necesarios. La topología puede explicar posibilidad de comunicación; no adjudica autoridad.
Capas como responsabilidades
Una aplicación no necesita implementar cada detalle del enlace o del reenvío para enviar una petición. Usa servicios de capas inferiores. RFC 1122 organiza requisitos por capas y explica que cada una ofrece funciones a la superior (RFC 1122, §2.1). Aquí usaremos la idea como separación de responsabilidades, no como una pila que explique todo por sí sola.
La aplicación conoce un nombre o destino lógico y produce mensajes con una semántica. Otras capas se ocupan de transportar datos hacia una dirección y un punto de entrega. El enlace resuelve la vecindad inmediata. Un router participa en el reenvío entre redes. Cada nivel puede aportar observaciones diferentes.
La separación no implica independencia total. Un cambio de dirección puede afectar a la aplicación; un fallo local puede impedir cualquier petición; una política puede bloquear un puerto. La ventaja del mapa por responsabilidades es diagnóstica: obliga a formular en qué frontera apareció la evidencia y evita convertir «red» en explicación universal.
Nombre, dirección e identidad
Un nombre es una etiqueta dentro de un espacio de nombres. Una dirección es un dato usado por un protocolo para localizar un destino o interfaz. Una identidad es la entidad reconocida bajo un contexto de confianza. Las tres pueden estar relacionadas, pero responden preguntas diferentes.
fotos.example es un nombre. Una consulta de resolución puede devolver datos de dirección. El cliente usa esos datos para intentar una interacción. Nada en esa secuencia demuestra por sí solo quién controla el servicio. El nombre podría resolverse correctamente y el extremo no estar autenticado; una dirección podría cambiar sin que cambie la identidad prevista; varias identidades podrían compartir infraestructura.
RFC 1034 describe un espacio de nombres jerárquico y el proceso general de consultas y respuestas (RFC 1034, §§3.1 y 4.3.1). Ese mecanismo relaciona nombres con datos publicados. No convierte una respuesta DNS en prueba universal de identidad, autorización o integridad del contenido.
Vista adaptada. Toca el diagrama para ampliarlo.
Qué hace una dirección
Una dirección permite a los protocolos situar origen o destino dentro de un alcance. No es el dispositivo completo, el proceso, la persona ni el recurso. Puede identificar una interfaz o punto de conectividad según el protocolo y contexto. El mismo dispositivo puede usar varias direcciones; una dirección puede dejar de estar asociada con él; una infraestructura puede presentar una dirección para varios servicios.
RFC 1122 sitúa Internet Protocol (IP) como capa que transporta datagramas entre hosts a través de redes interconectadas (RFC 1122, §3.2). En este capítulo no estudiamos la estructura de una dirección IP ni calculamos prefijos. Conservamos sólo su función en el recorrido: aporta información para intentar entregar datos hacia un destino de red.
Por eso «la dirección respondió» es un atajo. Lo observado puede ser una respuesta procedente de un extremo alcanzado mediante esa dirección. Para atribuir un servicio, una organización o una persona hacen falta otras relaciones. La dirección ayuda a encontrar; no autentica por naturaleza.
Puerto como punto lógico
Un mismo host puede ofrecer o consumir varias funciones de aplicación. Un puerto permite señalar un punto lógico de entrega dentro del contexto del transporte. En una referencia URI, el componente port aparece dentro de la autoridad y puede indicar el puerto al que se dirige la interacción (RFC 3986, §§3.2 y 3.2.3).
El puerto no es una puerta física ni una identidad. Observar una respuesta en cierto puerto permite afirmar que algún componente respondió en ese contexto. No demuestra que sea la aplicación esperada, que el canal esté protegido, que el principal tenga permiso ni que una operación de negocio haya tenido éxito.
Tampoco debemos convertir números conocidos en garantías. Una convención puede asociar un puerto con un protocolo esperado, pero la observación real depende del extremo y la interacción. Del mismo modo, un puerto que no responde puede estar filtrado, cerrado, inaccesible por el camino o simplemente no producir respuesta bajo esa prueba. El resultado debe describirse sin adivinar la causa.
Vista adaptada. Toca el diagrama para ampliarlo.
Router: conectar y reenviar
Un router conecta redes y participa en el reenvío de datagramas. RFC 1812 lo describe como un sistema que interconecta redes y toma decisiones para reenviar tráfico (RFC 1812, §§1.1 y 2.1). En nuestro mapa, R recibe datos desde el alcance local y decide hacia qué siguiente relación enviarlos.
El router no interpreta necesariamente el significado de la operación de fotografía. Su participación en el camino no demuestra que S aceptará la petición ni que Mara esté autorizada. Puede aplicar políticas o descartar tráfico, pero esos mecanismos quedan fuera de esta introducción.
Decir «pasó por el router» también necesita evidencia. El mapa puede mostrar que R es una dependencia configurada, no que observamos físicamente cada mensaje. Para sostener tránsito real harían falta registros o mediciones autorizadas. El dibujo diferencia camino esperado y camino observado.
Camino como modelo y observación
El camino es la secuencia de enlaces y sistemas intermedios que una comunicación puede atravesar. Puede cambiar entre interacciones, diferir en cada dirección o incluir componentes ocultos por nuestra frontera. Este capítulo no enseña cómo se elige ni qué algoritmos lo calculan.
Podemos representar C → A → R → Internet no observada → S. La parte central es una dependencia resumida. No afirmamos cuántos routers existen ni que el regreso use exactamente los mismos. Si una respuesta llega, sabemos que existió alguna cadena funcional para esa interacción; no reconstruimos automáticamente todos sus saltos.
Esta modestia es útil en seguridad. Una línea en un diagrama de arquitectura suele expresar una relación prevista, no evidencia de cada tránsito. Un análisis competente marca si una conexión es diseño, configuración, observación o inferencia. Mezclarlas produce mapas convincentes pero falsos.
Vista adaptada. Toca el diagrama para ampliarlo.
DNS: resolver un nombre
Domain Name System (DNS) permite consultar información asociada con nombres. Para nuestro mapa, el cliente pregunta por fotos.example y obtiene datos que puede usar para intentar llegar a un destino. RFC 1034 separa el espacio de nombres, los resolvers y los servidores de nombres; una consulta produce una respuesta según los datos disponibles (RFC 1034, §§3.1 y 4.3.1).
La respuesta DNS no es el servicio de fotografías. Tampoco prueba que la dirección responda, que el camino funcione, que el extremo controle legítimamente el nombre ni que Mara tenga permiso. Es una pieza del recorrido. Puede existir una respuesta correcta y fallar el paso siguiente; también puede existir conectividad hacia una dirección aunque el nombre no se resuelva en ese momento.
No estudiaremos tipos de registro, caché, recursión, delegación o seguridad de DNS. La pregunta mínima es: ¿qué nombre se consultó, qué dato devolvió la respuesta, quién produjo esa observación y qué relación falta por demostrar?
Vista adaptada. Toca el diagrama para ampliarlo.
Alcanzar no es autenticar
Supongamos que C consigue una respuesta desde la dirección obtenida y el puerto previsto. Esto demuestra una forma de alcance observada: hubo una interacción capaz de producir respuesta. No demuestra todavía que el extremo sea S en el sentido de identidad que Mara esperaba.
Autenticación relaciona evidencia con una identidad o principal. Conectividad relaciona puntos capaces de intercambiar datos. Autorización decide si una acción sobre un recurso está permitida. Son tres preguntas separadas. Un servicio auténtico puede denegar una acción; un extremo no autenticado puede responder; un puerto accesible puede no hablar el protocolo esperado.
Esta separación evita frases como «si abre el puerto, es seguro» o «si resuelve el dominio, es legítimo». La evidencia debe corresponder a la propiedad. El mapa de red explica por dónde y hacia qué punto se intentó comunicar; los controles de identidad y aplicación sostienen otras conclusiones.
TLS como canal delimitado
Transport Layer Security (TLS) 1.3 está diseñado para impedir escucha, alteración y falsificación de mensajes bajo sus supuestos, y permite autenticación del servidor y, opcionalmente, del cliente (RFC 8446, §1). Esa frase no significa que «TLS vuelve seguro al sistema». El resultado depende del protocolo, la configuración, la validación y la identidad que se pretende autenticar.
En el mapa mínimo, TLS protege un canal entre extremos del protocolo. La validación del certificado enlaza una identidad esperada con material presentado durante el establecimiento del canal; RFC 8446 especifica el mensaje de certificado y su papel en autenticación (RFC 8446, §4.4.2). No desarrollaremos la cadena de certificados ni el handshake.
El canal no protege automáticamente lo que ocurre antes o después de sus extremos. No corrige una autorización equivocada, no garantiza almacenamiento, no hace confiable todo el dispositivo y no revela cada router del camino. Su figura debe mostrar con precisión dónde empieza y termina la propiedad.
Vista adaptada. Toca el diagrama para ampliarlo.
Reconstruir la apertura del servicio
Volvamos al recorrido. Mara introduce fotos.example. La aplicación produce una referencia con nombre y puerto previsto. Un resolver devuelve datos de dirección. El dispositivo intenta enviar hacia esa dirección; la red local entrega al siguiente punto; uno o más routers participan en el camino; el extremo acepta o no la interacción del puerto; TLS puede autenticar y proteger el canal; finalmente la aplicación envía una petición con su propia semántica.
Cada transición tiene evidencia y fallos posibles. Ver el nombre no prueba la resolución. Obtener una dirección no prueba alcance. Alcanzar un puerto no prueba identidad. Validar TLS no prueba autorización. Recibir una respuesta de aplicación no prueba que toda operación futura tendrá éxito. La cadena es fuerte cuando cada claim se limita a su mecanismo.
Un diagnóstico inicial puede registrar:
- dispositivo y aplicación que originan la interacción;
- nombre consultado y datos de dirección observados;
- red local y router configurado como dependencia;
- dirección y puerto intentados;
- evidencia de canal autenticado o su ausencia;
- petición y respuesta de aplicación;
- tramos conocidos, inferidos y desconocidos.
La lista no sustituye herramientas ni procedimientos. Organiza preguntas para que una observación de una capa no se use como respuesta de otra.
Una matriz de evidencia mínima
El mapa puede resumirse como una matriz de afirmaciones y evidencias. «El nombre se resolvió» necesita la consulta, su respuesta y el nombre preguntado. «Existe un camino funcional» necesita una interacción que atravesó algún camino, pero no identifica automáticamente todos sus saltos. «El puerto respondió» necesita una respuesta correlacionada con el intento hacia esa dirección y puerto. «El canal autenticó al servidor esperado» necesita una validación TLS ligada al nombre o identidad prevista. «La operación fue autorizada» necesita una decisión de aplicación, no sólo conectividad.
La matriz también registra lo que una prueba negativa no distingue. Ausencia de respuesta DNS puede proceder de resolución no disponible o de una condición local; no informa directamente del puerto. Ausencia de respuesta del puerto no decide si el nombre era incorrecto, si el camino falló, si una política descartó el tráfico o si el extremo eligió callar. Un error de aplicación puede ocurrir después de que nombre, dirección, camino, puerto y TLS funcionaron.
Esta separación permite formular controles positivos y negativos sin adelantar herramientas. Si una respuesta de aplicación demuestra que el camino completo funcionó para una interacción, una segunda observación puede aislar el nombre o el canal. Si sólo tenemos una etiqueta de interfaz, el claim se queda en la interfaz. La fuerza no proviene de acumular palabras técnicas, sino de relacionar cada propiedad con el productor capaz de demostrarla.
Ante una explicación, el lector puede preguntar: ¿qué entidad produjo esta evidencia?, ¿qué frontera cubre?, ¿qué condición temporal tenía?, ¿qué hipótesis rivales predicen el mismo resultado? Si la respuesta usa «Internet», «DNS» o «TLS» como causa única sin precisar el mecanismo observado, el mapa todavía está incompleto.
Transferencia: servicio dentro de una organización
Una aplicación interna usa inventario.intra para consultar existencias. El nombre puede resolverse a una dirección dentro de la red local. El servicio escucha en un puerto concreto y responde. Aunque el tráfico no salga a Internet pública, el mismo mapa funciona: dispositivo, enlace, alcance local, nombre, dirección, puerto y aplicación.
Lo que cambia es la topología y el contrato, no las distinciones. «Interno» no prueba confianza; la dirección no prueba identidad; la respuesta del puerto no prueba permiso. Si existe TLS, su identidad esperada y validación deben corresponder al servicio interno. Si no existe, no podemos atribuir confidencialidad al simple hecho de estar en una red local.
Transferir el modelo consiste en volver a justificar cada relación. No copiar la conclusión del caso público. La obra profesional exige poder señalar dónde termina el mapa y qué capítulo posterior hace falta para sostener una propiedad más fuerte.
Límites
No calculamos máscaras ni prefijos, no explicamos tablas de routing, NAT, firewalls, registros DNS, validación de certificados o detalles de TLS. Tampoco enseñamos escaneo ni pruebas sobre sistemas ajenos. El mapa es conceptual y defensivo: organiza observaciones autorizadas y documentación.
El resultado esperado es poder leer un diagrama sencillo sin llamar identidad a una dirección, permiso a un puerto abierto o seguridad a una línea cifrada. En el capítulo siguiente seguiremos una página web completa y reutilizaremos estas distinciones.
Fuentes principales
- RFC 1122, §§1.1.3, 2.1 y 3.2 — hosts, redes, gateways y capas.
- RFC 1812, §§1.1 y 2.1 — función general de routers.
- RFC 1034, §§3.1 y 4.3.1 — espacio de nombres y consultas DNS.
- RFC 3986, §§3 y 3.2.3 — host y puerto en referencias URI.
- RFC 8446, §§1 y 4.4.2 — objetivos y autenticación en TLS 1.3.
Comprobación
Una aplicación muestra «no se puede conectar» después de resolver inventario.intra a una dirección. Construye tres hipótesis que pertenezcan a fronteras distintas sin confundirlas: camino, puerto y aplicación. Explica qué demuestra la resolución y qué no. Después formula el claim más fuerte que podrías sostener si el puerto responde pero no existe evidencia de TLS ni de autenticación de aplicación.