Saltar al contenido
Roadmap

$ ssh lab-01-tcp-pcap-state·M01 · L3/L4

Anatomía del Paquete y la Pila de Transporte

10.0.1.0/24ipv4 · tcp · udp · icmp

Objetivo: capturar el handshake y diferenciar DROP de puerto cerrado.

Runtime: Linux, iproute2, tcpdump, nc; root

Lee el mecanismo; después interroga la evidencia.

La teoría define qué debe ocurrir. Las figuras y tablas reducen el mecanismo a señales observables; la topología y el inspector de paquete permiten comprobarlo después. Cada lección termina con «Lo entiendo»: márcala cuando puedas explicarla, no cuando la hayas leído.

Conceptos disponibles22

Antes de mirar una cabecera: ¿qué incidente estás intentando explicar?

Una aplicación intenta abrir api:8080 y expira. Ese síntoma no dice todavía si el servidor cayó, si el puerto está cerrado, si una no existe, si un firewall descartó el tráfico o si la respuesta se perdió al volver. Este módulo te enseña a separar esas hipótesis con evidencia, no a memorizar números de protocolo. [1]

Al terminar deberías poder defender una frase precisa como: “el cliente emitió SYN; el router lo reenvió; el servidor respondió RST” o “el SYN no llegó al servidor”. Es una conclusión mucho más útil que “la red está fallando”.

¿La entiendes?

Márcala sólo si puedes explicarla con tus palabras y decir por qué importa en producción.

El mapa mínimo: una petición es varias decisiones encadenadas

Flujo del mecanismo5 etapas

Una petición recorre varias decisiones

La misma solicitud cambia de contexto en cada etapa.

intención

proceso. La aplicación pide abrir un socket hacia un host y puerto.

Ver la figura original
proceso cliente
      │ abre socket TCP hacia api:8080
      ▼
TCP ── ¿hubo SYN, SYN-ACK, ACK o RST?
      │ encapsula datos
      ▼
IPv4 ── ¿qué destino, protocolo, TTL y tamaño lleva?
      │ consulta ruta
      ▼
router/firewall ── ¿por dónde sale y se permite?
      │
      ▼
servidor ── ¿hay listener y qué respuesta regresa?

No necesitas estudiar todos los campos ahora. Empieza por cuatro preguntas: qué host/puerto se intentó alcanzar, si TCP abrió sesión, por qué ruta viajó y en qué punto se capturó la evidencia. , fragmentación, offsets y checksum aparecen después porque explican por qué una captura o una ruta pueden engañarte. [2]

¿La entiendes?

Márcala sólo si puedes explicarla con tus palabras y decir por qué importa en producción.

Ruta de estudio de este módulo

  1. Primero reconoce las firmas TCP de un timeout, un puerto cerrado y una sesión sana.
  2. Después usa y para entender a dónde debía ir el paquete.
  3. Luego observa cómo TTL, y fragmentación alteran el tránsito.
  4. Por último relaciona el PCAP con firewall , y el punto de captura.

El módulo siguiente responderá una nueva pregunta: cuando ya sabes qué pasó con el paquete, ¿qué objetos del kernel Linux —, , , ruta y — hicieron que ocurriera?

Lectura de bytes: de hexadecimal a decisión de red

Un analista no empieza por Wireshark: empieza por invariantes. En una cabecera cuyo inicio es 45 00 00 3c, el byte 45 se separa como 0100|0101: versión 4 e IHL=5, por tanto L4 comienza en el byte 20. 00 3c es 60 bytes de datagrama total. Si Flags+Offset es 40 00, DF está activo y offset=0: un router con MTU menor no debe fragmentar; devuelve Fragmentation Needed. En una ruta de contenedores, esa señal puede desaparecer por filtrado y convertirse en un fallo que sólo aparece con respuestas grandes. [3]

Flujo del mecanismo3 etapas

Los primeros cuatro bytes orientan la lectura

Selecciona un campo para conectar los bits con la decisión posterior.

versión + IHL

45. 0100 indica IPv4; 0101 significa IHL=5, por lo que L4 empieza en el byte 20.

Ver la figura original
Byte:        0          1          2          3
Hex:        45         00         00         3c
Bits:     0100|0101       DSCP       Total Length = 60
          IPv4 | IHL=5                 └─ 20 B IP + 20 B TCP + 20 B data/options
Observación en PCAPInferencia correctaSiguiente comprobación
TTL pasa 64 → 63cruzó al menos un router L3capture ambos lados del router
DF=1 y payload grande fallaposible black-hole de PMTUDICMP type 3/code 4 y MTU de overlay
mismo ID con offsets 0 y 185fragmentación del datagramareensamblado de endpoint y sensor
checksum malo sólo en hostposible TX checksum offloadcapture en peer

Pulsa una fila para fijarla.

¿La entiendes?

Márcala sólo si puedes explicarla con tus palabras y decir por qué importa en producción.

TCP no es una secuencia de tres paquetes

El handshake fija dos espacios de secuencia independientes. Si cliente emite SYN con SEQ=1000 y servidor SYN-ACK con SEQ=7000, el ACK final vale 7001; cuando cliente envía 120 bytes con SEQ=1001, ACK acumulativo esperado es 1121. Una ventana cero no es caída de red sino back-pressure del receptor. Window Scale y MSS se negocian en SYN; comparar sólo Window sin escala da un diagnóstico equivocado. [4]

Flujo del mecanismo4 etapas

TCP confirma bytes, no paquetes

Las banderas y los números de secuencia distinguen apertura, datos y cierre.

apertura

SYN. El cliente propone su espacio de secuencia y opciones TCP.

Ver la figura original
cliente                                      servidor
SYN SEQ=1000, MSS=1460, WS=7  ───────────►  LISTEN → SYN-RECEIVED
◄─────────── SYN,ACK SEQ=7000 ACK=1001      reserva estado
ACK SEQ=1001 ACK=7001         ───────────►  ESTABLISHED
PSH,ACK SEQ=1001 LEN=120      ───────────►
◄─────────── ACK=1121                      confirma bytes, no paquetes
FirmaHipótesisEvidencia que la refuta
SYN repetido, sin respuestaruta/firewall/host caídoSYN-ACK visto en otra interfaz
SYN seguido de RSThost alcanzable, puerto cerradoRST inyectado por middlebox
ACK duplicados y retransmisiónpérdida tras handshakeACK llegó al punto de captura
ventana ceroreceptor o aplicación saturadosnueva Window Update posterior

Pulsa una fila para fijarla.

¿La entiendes?

Márcala sólo si puedes explicarla con tus palabras y decir por qué importa en producción.

Caso de producción: IP no equivale a identidad

Un pod de pagos que permite 10.44.0.0/24 puede aceptar otra carga tras reprogramación. La tupla L3/L4 depura flujo, no afirma quién es el workload. La defensa combina ruta, política stateful, identidad y telemetría. [5]

CapaPreguntaEvidencia
ruta¿por dónde debía ir?prefijo ganador/gateway
TCP¿hubo sesión y quién cerró?SEQ/ACK, flags, retransmisión
firewall¿qué decisión se tomó?regla y conntrack
identidad¿qué servicio era?/ y log

Pulsa una fila para fijarla.

¿La entiendes?

Márcala sólo si puedes explicarla con tus palabras y decir por qué importa en producción.

Referencia técnica: campos y estados que sostienen el diagnóstico

IPv4 mínimo tiene 20 bytes: Version=4, IHL en palabras de 32 bits para localizar L4, Total Length, Identification, flags DF/MF, Fragment Offset, TTL, Protocol y checksum de cabecera. TTL cero causa ICMP Time Exceeded; Protocol es TCP=6, =17, ICMP=1. El checksum se recalcula cuando NAT o router modifica cabecera. [3]

Una ruta se elige por longest-prefix match; /p contiene 2^(32-p) direcciones. CIDR expresa alcance, no autorización. Campos origen/destino pueden ser falsificados dentro de una red permisiva; fragmentos pueden evadir controles que no reensamblen igual; ACL TCP deja UDP/ICMP sin política. [3]

TCP usa 4-tupla, SEQ y ACK. ACK es siguiente byte esperado; SYN y FIN consumen secuencia. Apertura: SYN(x), SYN-ACK(y,x+1), ACK(y+1); cliente CLOSED→SYN-SENT→ESTABLISHED, servidor LISTEN→SYN-RECEIVED→ESTABLISHED. FIN cierra una dirección; RST aborta estado. [4]

Una política stateful autoriza SYN esperado y retorno ESTABLISHED,RELATED. Timeout sin SYN-ACK es compatible con ; RST demuestra stack alcanzable sin listener. Capture sobre veth/NIC, no sólo any: offload/NAT alteran evidencia. [5]

Referencia: no cuenta para tu progreso. Vuelve aquí cuando necesites un campo o un estado concreto.

Checkpoint 01 · predice antes de revelar

Un SYN que no vuelve no identifica por sí solo al culpable

Capturas en el namespace del cliente tres SYN hacia TCP/8080. No observas ningún paquete de retorno durante el intervalo de captura.

10.44.0.2.40000 > 10.45.0.2.8080: Flags [S], seq 1000
10.44.0.2.40000 > 10.45.0.2.8080: Flags [S], seq 1000 (retransmisión)
10.44.0.2.40000 > 10.45.0.2.8080: Flags [S], seq 1000 (retransmisión)
¿Cuál es la conclusión técnicamente defendible con esta evidencia?

Inspector de paquete

client → PREROUTING → route → FORWARD → POSTROUTING → server

10.44.0.2:40000 → 10.45.0.2:8080

IPv4TCP

IPv4 · bits 64–71 · 8 bits

TTL

64

Saltos restantes. Cada router lo decrementa; en 0 descarta y emite ICMP Time Exceeded.

Cambia en cada salto: por eso el checksum IP se recalcula en cada router.

40 bytes · hex

Supuestos de la síntesis
  • TTL inicial 64 (valor por defecto de Linux); Identification 0x1c46 ilustrativo.
  • SYN sin opciones TCP para que la cabecera quepa en 20 bytes; un SYN real de Linux añade MSS, SACK, timestamps y window scale. ISN ilustrativo.
Notas del autor · calidad del contenido1 aviso

Estas observaciones revisan la consistencia de los materiales y scripts de verificación; no son pasos del laboratorio ni indican un error de tu entorno.

  • DoD línea 5: Bajo `set -e`, un comando negado con `!` nunca aborta el script: en la versión original este check no puede fallar. La versión instrumentada sí lo evalúa.