El mismo flujo puede tener varias verdades observables
Cuando una aplicación informa «no puedo conectar», la frase todavía no identifica un fallo. Puede no existir una ruta, el host puede haber enviado una solicitud que ningún vecino aceptó, un servicio puede haberla rechazado, un intermediario puede haber terminado una conexión y creado otra, o la respuesta puede haberse perdido después de que el servidor decidiera aceptarla. Cada explicación pertenece a una relación distinta entre capas y sólo algunas pueden distinguirse desde el punto donde estamos mirando.
Las redes se vuelven analizables cuando dejamos de tratarlas como una tubería opaca. Una comunicación es una composición de servicios: una aplicación entrega datos a un transporte; el transporte los asocia con una conversación; la capa de red selecciona una representación para atravesar dominios; el enlace los lleva hasta un vecino; y el receptor deshace esas transformaciones. El modelo no predice por sí solo qué equipo existe ni qué producto implementa cada función. Sí permite formular preguntas precisas sobre responsabilidad, unidad de datos, alcance y evidencia.
Este capítulo construye ese modelo. El objetivo no es recitar una lista de capas, sino poder reconstruir qué ocurrió entre dos observaciones y declarar lo que sigue sin observarse. «Encapsulación» nombra una transformación de representación; «punto de observación» nombra el lugar y la interfaz que limitan una inferencia. Ambos conceptos serán necesarios para leer Ethernet, IP, TCP, HTTP y TLS sin atribuir a un protocolo propiedades que pertenecen a otro.
Una capa es un contrato, no una planta del edificio
Una capa organiza una responsabilidad y ofrece un servicio a la capa que la utiliza. La interfaz define qué información se entrega, qué resultado se espera y qué errores pueden aparecer. El componente concreto puede estar en una biblioteca, en el kernel, en un controlador, en una tarjeta de red o en un dispositivo intermedio. Por eso un dibujo de capas no debe interpretarse como un mapa físico.
La arquitectura de Internet documentada en RFC 1122 distingue, entre otras, capa de enlace, capa IP y capa de transporte, y relaciona cada una con una interfaz. La separación es útil porque cada mecanismo tiene un dominio de validez: el enlace sabe cómo entregar una unidad a un vecino dentro de su tecnología; IP representa un datagrama y lo encamina por una interred; TCP ofrece a la aplicación un transporte orientado a conexión con reglas propias. Ninguna de esas frases dice que un único proceso implemente exactamente una capa. RFC 1122, §§1–4
Una pila es la composición efectiva que encontramos en un sistema. Puede incluir una biblioteca HTTP, TLS, un socket del kernel, TCP, IPv6, una interfaz Wi-Fi y un punto de acceso. También puede incluir una VPN, un túnel, una traducción de direcciones o un proxy. Una capa conceptual puede aparecer dos veces —por ejemplo, una conexión TLS delante de otra— o quedar oculta dentro de un túnel. La pregunta profesional es qué contrato se conserva en cada transición, no qué etiqueta se puede colocar sobre cada caja.
El error frecuente consiste en usar «capa» como sinónimo de «nivel de seguridad». Una capa superior no es automáticamente más confiable, y una capa inferior no es automáticamente más peligrosa. La seguridad depende de la propiedad, el adversario, los extremos y la evidencia. Un enlace autenticado entre vecinos no autentica por sí mismo la identidad de una aplicación remota; una aplicación que valida una identidad no convierte cada salto intermedio en confiable.
De datos de aplicación a unidades de protocolo
Alcance: ejemplo TCP sobre IPv6 y Ethernet; el punto de captura condiciona la vista.
Una aplicación produce una secuencia con significado propio: una petición, una consulta o un registro. La capa siguiente no necesita comprender ese significado completo; necesita recibir una unidad que pueda transportar según su contrato. Cada protocolo define una unidad de datos de protocolo —protocol data unit, PDU— aunque la terminología cotidiana varíe entre mensaje, segmento, datagrama o trama.
La encapsulación coloca una unidad dentro del campo de datos de otra. En una ruta típica, el transporte añade una cabecera a los datos de aplicación y forma un segmento TCP. IP añade su cabecera y forma un paquete o datagrama IP. El enlace agrega la información que necesita su dominio y forma una trama. No es correcto decir que «TCP añade una trama» o que «la dirección IP identifica el proceso»: cada campo tiene un propietario semántico y un receptor que debe interpretarlo.
La representación puede describirse así, sin pretender que todas las tecnologías usen exactamente esos nombres:
datos de aplicación
[cabecera de transporte | datos de aplicación] segmento
[cabecera IP | segmento] datagrama
[cabecera de enlace | datagrama | trailer] trama
El interés de la figura textual está en el orden de interpretación. El transmisor construye desde arriba hacia abajo. El receptor procesa desde abajo hacia arriba, comprobando lo que su protocolo puede comprobar y entregando el resto a la capa siguiente. Si una trama no es aceptable para el enlace, el contenido IP no llega a existir como entrada válida para la capa IP de ese receptor. Si IP acepta el datagrama pero no puede entregarlo al transporte indicado, la aplicación tampoco recibe una petición, aunque el emisor haya producido bytes correctos.
La encapsulación no significa que el contenido sea siempre opaco. Un dispositivo puede leer una cabecera IP, alterar un campo, descartar la unidad o crear una nueva. Un proxy HTTP puede leer un mensaje de aplicación y enviar otro por una conexión distinta. Un túnel puede encapsular una unidad entera dentro de otra capa de transporte y ocultar la estructura interna al observador externo. El verbo adecuado depende de qué componente interpreta y qué componente sólo reenvía.
Multiplexar es compartir sin confundir conversaciones
Una misma máquina puede ejecutar muchos procesos y mantener múltiples flujos simultáneos. El transporte necesita un criterio para entregar una unidad a la conversación correcta. En TCP, la combinación de direcciones y puertos, junto con el estado de la conexión, participa en esa demultiplexación. Un puerto es un identificador dentro de ese contrato; no es una prueba de que un programa concreto sea legítimo, ni de que la petición haya alcanzado la lógica de negocio. RFC 9293, §§2–3
La capa IP también multiplexa protocolos de capa superior mediante un campo que indica qué interpretación corresponde al siguiente paso. La capa de enlace, a su vez, identifica el tipo de carga que contiene la trama. Estos identificadores son útiles para enrutar el procesamiento, pero no aportan automáticamente autenticación, autorización o integridad end-to-end. Un número correcto puede aparecer en una unidad fabricada, retransmitida o transformada por un intermediario.
El mecanismo explica un diagnóstico habitual. Si una captura muestra un SYN dirigido a un puerto, podemos inferir que una unidad TCP fue observada con esos campos en ese punto. No podemos inferir todavía que el proceso esperado estaba escuchando, que la política permitió la conexión o que el servicio entendió la petición. Para avanzar hacen falta observaciones del socket, del estado TCP, de la respuesta y, si corresponde, del log del servicio. Cada nueva observación reduce hipótesis, pero no cambia el alcance de las anteriores.
Qué se conserva y qué se transforma en cada salto
Un campo de una cabecera puede tener alcance local, de extremo lógico o de una conexión específica. Un router suele interpretar la cabecera IP para tomar una decisión de reenvío y luego construir una representación apropiada para el siguiente enlace. El encabezado de la trama original no viaja necesariamente más allá del primer dominio. El datagrama IP puede continuar con cambios permitidos por su protocolo, mientras el segmento TCP sigue siendo una unidad para los extremos TCP aunque atraviese varios routers.
Esta distinción permite hablar de hop-by-hop y end-to-end sin convertirlos en etiquetas absolutas. Hop-by-hop significa que la propiedad o el control se aplica entre vecinos o dentro de un tramo definido. End-to-end significa que el argumento se extiende entre extremos concretos y que los intermediarios no rompen sus supuestos. La ruta puede contener más de un tipo de relación a la vez: un enlace puede proteger un salto; TCP puede ordenar y retransmitir entre extremos; la aplicación puede autenticar una identidad mediante una capa superior.
El tamaño también puede forzar transformaciones. Cada enlace tiene una unidad máxima de transmisión (MTU) para su carga; IP y las capas superiores deben respetar o gestionar ese límite. IPv6 reserva la fragmentación para el origen y el destino mediante reglas de su especificación, mientras un router intermedio no debe tratarla como una operación transparente equivalente a reensamblar la aplicación. Una observación de un fragmento no basta para concluir que la aplicación recibió el mensaje completo. Hay que localizar quién reensambla, qué espera y qué errores quedan registrados. RFC 8200, §§3–5 y 8.3
El mismo cuidado se aplica a los checksums y a la fiabilidad. Un control de integridad de una capa detecta ciertas alteraciones según su alcance y algoritmo; no prueba que el dato tenga el significado correcto para la aplicación. TCP puede entregar un flujo ordenado, pero no decide si una transacción es autorizada ni si el servidor escribió un estado correcto. Confundir garantía de transporte con corrección semántica es una forma especialmente costosa de diagnóstico incompleto.
Caso conductor: una petición y cuatro vistas
Supongamos una aplicación cliente que envía una petición sintética a api.ejemplo.test. La aplicación pasa bytes a una biblioteca de transporte seguro, que usa un socket TCP sobre IPv6 y una interfaz de red. En el camino existe un gateway HTTP que termina la conexión del cliente y abre otra hacia el servicio de origen. El caso no describe una red real; sólo hace visibles las fronteras.
En el cliente, el proceso puede observar que la biblioteca devolvió un error de conexión o de validación. Esa observación habla del contrato de la biblioteca y de su estado local. El socket puede mostrar que la conexión TCP se estableció o que expiró sin respuesta. Es una observación más cercana al transporte, pero aún no prueba que el servidor de aplicación procesara la petición. Cuando intervienen proxy, gateway o túnel, HTTP puede atravesar conexiones distintas entre tramos. RFC 9110, §3.7
Una captura en la interfaz del cliente puede mostrar paquetes IPv6 y segmentos TCP. En ese punto vemos lo que la interfaz entregó al capturador y lo que el tipo de enlace permite decodificar. Podemos comparar direcciones, puertos, flags, tamaños, tiempos y secuencia relativa. No vemos automáticamente el contenido de una capa cifrada ni el estado del gateway. Si no aparece un paquete, quedan abiertas hipótesis sobre el filtro, la interfaz, el momento de captura, el camino y la pérdida de evidencia. libpcap, pcap(3PCAP)
El gateway recibe una conexión del cliente y puede decidir rechazarla, responder localmente o construir una segunda conexión. Para el primer tramo, es un extremo de la conexión HTTP; para el segundo, actúa como cliente o intermediario. El servicio de origen no debería tratar el socket del gateway como si fuera necesariamente el socket original del usuario. La identidad, el contexto y las cabeceras que el gateway transmite requieren un contrato explícito. Un log del origen prueba que el origen recibió una solicitud según su parser y su reloj, no que haya visto todos los bytes o la misma conexión que vio el cliente.
Este caso explica por qué una línea temporal es mejor que una frase como «la red bloqueó la petición». Una línea útil separa: creación de la unidad en el proceso, entrega al socket, emisión por la interfaz, observación del primer salto, llegada al gateway, creación de la conexión posterior, recepción en el origen, decisión de aplicación y respuesta en sentido inverso. Para cada evento se anota fuente, reloj, dirección, identificador y grado de confianza. Las brechas no se rellenan con narración.
Puntos de observación: la ubicación es parte de la evidencia
Alcance: un tramo observado no sostiene automáticamente un claim end-to-end.
El punto de observación no es sólo una coordenada. Incluye interfaz, filtro, instante, dirección, formato, parser y autoridad sobre el dato. Comparar dos puntos exige comprobar si ambos observan la misma unidad o unidades diferentes. Una captura de enlace, un contador de socket y un log de aplicación pueden hablar de la misma comunicación, pero no tienen el mismo alcance ni el mismo reloj.
Proceso y socket
El proceso conoce lo que su biblioteca le entrega: éxito, error, respuesta o timeout. El socket y el kernel pueden aportar estado de conexión, colas y errores asíncronos. Estas señales son útiles para separar «la aplicación no llamó» de «la aplicación llamó y el transporte no estableció». No demuestran por sí solas que una unidad cruzara la interfaz física ni que el receptor la aceptara.
Captura en el host
Una captura en una interfaz de host puede revelar cabeceras visibles, tamaños, orden relativo y retransmisiones. El modo de captura, el filtro, la descarga de checksum, la virtualización y la ubicación respecto de una VPN pueden cambiar la representación observada. La captura es evidencia del punto de captura. «No hay paquetes» debe formularse como «no se observaron paquetes que cumplieran este filtro en esta interfaz durante esta ventana», salvo evidencia adicional.
Enlace, router e intermediario
En un enlace se ven unidades pertenecientes a ese dominio. Un router puede registrar una entrada, una decisión de reenvío o un contador, pero no necesariamente el contenido de una capa superior. Un firewall puede descartar, modificar o generar una respuesta. Un proxy de aplicación puede terminar una conexión y comenzar otra. La visibilidad no aumenta linealmente al acercarse al centro de la red: a menudo cambia el objeto observado.
Aplicación y telemetría
El log de aplicación puede registrar una petición parseada, una decisión de autorización o un resultado. Es la mejor evidencia para preguntas semánticas, pero no necesariamente para reconstruir el camino de red. Los campos normalizados pueden omitir bytes, cabeceras o errores previos. La correlación necesita identificadores y relojes compatibles; una marca temporal parecida no prueba causalidad.
Diagnosticar por hipótesis, no por etiqueta de capa
Alcance: la rama depende de interfaz, filtro, reloj y punto de observación.
Un diagnóstico por capas no consiste en comenzar por la capa «más baja» y subir de forma ritual. Consiste en elegir una observación que discrimine explicaciones. Si el proceso nunca abrió un socket, capturar en Ethernet no explica la ausencia de una llamada. Si el socket reporta conexión establecida y el origen no registra ninguna solicitud, hay que comparar la ruta, el terminador, el filtro y la conexión que realmente maneja la aplicación. Si el origen registra la solicitud y el cliente no recibe respuesta, la búsqueda se desplaza al retorno, al intermediario y al estado del cliente.
La secuencia profesional puede ser breve:
- Fijar extremos, dirección y operación: qué aplicación, qué socket, qué servicio y qué respuesta se esperaba.
- Identificar la unidad relevante: mensaje de aplicación, segmento, datagrama o trama.
- Elegir el punto de observación más cercano a la hipótesis, sin presuponer que es suficiente.
- Registrar observación literal, tiempo, filtro, fuente y versión del decodificador.
- Formular al menos una explicación alternativa y buscar una evidencia que la separe.
- Declarar qué capa o intermediario tiene la decisión final y qué queda fuera de alcance.
Un ejemplo: «el puerto está abierto, por tanto el servicio funciona» confunde una señal de transporte con la función de aplicación. Un mejor claim sería: «en el host cliente, durante la ventana indicada, se observó un establecimiento TCP hacia la dirección y puerto especificados; esta evidencia no determina si el gateway autenticó la identidad, si el origen procesó la petición ni si la respuesta fue semánticamente correcta». La formulación es menos concluyente y mucho más reutilizable.
Implicaciones para seguridad
Las capas ayudan a localizar controles y a detectar saltos de confianza, pero no reemplazan el threat modeling. Un filtro que usa una dirección como identidad puede aceptar una entrada cuyo origen lógico fue transformado por un proxy. Un control aplicado al enlace puede desaparecer al cruzar el router. Un contenido cifrado hasta un terminador deja el tramo posterior bajo otra política. La pregunta no es si existe «seguridad en la capa», sino qué propiedad se preserva, entre qué extremos y con qué intermediarios.
También importa la interpretación de errores. Un adversario de red puede provocar pérdida, reordenamiento, duplicación o cambios según el protocolo y el punto que controle; una red defectuosa puede producir señales parecidas. Un mensaje observado en una captura demuestra presencia en esa ubicación, no intención ni autoría. La decisión de atribución necesita más procedencia y contexto que una dirección o un puerto.
El modelo de capas tampoco autoriza a ignorar operaciones transversales. Relojes, identificadores, logging, configuración de interfaces, resolución de nombres y gestión de claves cruzan varias fronteras. Si un diagnóstico omite la versión del parser, el modo de captura o la terminación de TLS, puede producir una narrativa coherente pero falsa. La seguridad profesional requiere conservar el alcance de cada evidencia, igual que en un análisis de sistema local.
Límites y errores frecuentes
«Hay siete capas y siempre son siete saltos». Falso por categoría: una taxonomía conceptual y una ruta física responden preguntas diferentes. Declare qué modelo usa y qué implementación observa.
«El paquete llegó, luego la aplicación lo recibió». Sólo es válido si el punto de captura, el parser, la dirección y la cadena de entrega se han demostrado. La unidad puede haber sido descartada, dirigida a otro socket o terminada en un intermediario.
«El puerto identifica al servidor». El puerto participa en demultiplexación local. No prueba identidad, autorización, proceso esperado ni estado de negocio.
«La ausencia en una captura prueba que no se envió». La conclusión depende de interfaz, filtro, modo, ventana, pérdida y sincronización. Una prueba negativa necesita demostrar que el punto podía observar la señal.
«Un túnel hace visible la ruta interna». El encapsulamiento puede ocultar la estructura interior al observador externo. Hay que identificar el extremo que termina el túnel y obtener evidencia allí si la pregunta es interna.
«La capa inferior arregla la aplicación». Reensamblar una unidad o entregar un flujo no comprueba invariantes de negocio. La aplicación sigue siendo responsable de su semántica.
Uso profesional: construir un claim de flujo
Un informe técnico debería poder responder: «Para la comunicación entre el proceso P y el servicio S, versión V, en el entorno E, durante la ventana T, el punto O observó la unidad U con los campos F. Esa evidencia permite inferir I sobre la capa L, bajo las condiciones C; no demuestra N porque el intermediario M y el tramo R quedan fuera». Esta plantilla fuerza a separar observación, inferencia e impacto posible.
El artefacto profesional no es una captura aislada. Es un mapa de flujo con dirección, fronteras, transformaciones y owner de cada decisión, acompañado por una matriz que enumere puntos de observación, visibilidad, filtros, reloj, evidencia positiva y resultado negativo. Un diagrama sin direcciones o sin distinción entre conexión y mensaje decora el informe, pero no permite adjudicar un fallo.
Antes de cerrar el análisis, intente romper su propia explicación. Cambie el punto de captura, compare una conexión directa con una que pase por el intermediario, busque una respuesta generada localmente y compruebe si el parser que interpreta los bytes es el mismo que supuso. Si las observaciones no cambian cuando deberían, la hipótesis gana apoyo; si cambian, el claim debe reducirse. La calidad está en la discriminación y en los límites, no en acumular nombres de capas.
Síntesis
Las capas separan responsabilidades mediante interfaces; la pila concreta puede fusionarlas, repetirlas, tunelizarlas o repartirlas entre procesos y dispositivos. La encapsulación transporta una unidad dentro de otra y la desencapsulación invierte ese recorrido, pero cada cabecera tiene un dominio y un intérprete. Multiplexar permite compartir un transporte sin convertir puertos, direcciones o tipos en identidades.
Una propiedad hop-by-hop no se vuelve end-to-end por aparecer en varios saltos. Un proxy puede transformar una comunicación en varias conexiones. Un punto de observación muestra una señal situada, no la totalidad del flujo. Por ello, un diagnóstico debe fijar la unidad, el punto, la dirección, el reloj, la fuente y la decisión que se intenta explicar; después debe buscar evidencia que distinga hipótesis.
El modelo queda completo cuando puede contestar dos preguntas a la vez: «¿qué mecanismo produjo esta representación?» y «¿qué conclusión permite este lugar de observación?». La primera evita atribuir a TCP, IP o Ethernet una semántica que pertenece a otra capa. La segunda evita convertir una captura, un log o un timeout en una afirmación absoluta sobre el sistema. Con ese lenguaje, los capítulos siguientes pueden estudiar cada protocolo sin perder de vista sus fronteras.
Problema de transferencia
Un equipo afirma: «La API estuvo disponible porque vimos tráfico en la interfaz y el puerto remoto respondió». Reformula la afirmación como dos claims acotados: uno sobre observación de transporte y otro sobre función de aplicación. Especifica qué punto, dirección, ventana, unidad, intermediarios y evidencia adicional necesitarías para afirmar que el servicio recibió, autorizó y procesó una petición. Incluye una explicación alternativa compatible con la misma captura y señala qué dato la discriminaría.