La capa 3 lleva cada paquete hasta el equipo correcto. Pero en un equipo hay muchas aplicaciones a la vez: el servidor de la empresa sirve la intranet, las carpetas compartidas, la hora y el escritorio remoto, todo con la misma IP. La capa 4 lleva cada paquete hasta la aplicación correcta, con un número más: el puerto. Y decide cómo viajan los datos: con una conexión que confirma cada trozo (TCP) o sin ella, deprisa y sin garantías (UDP).
Aquí las averías son las del “la red va, pero no me funciona”. El ping llega, la IP es la buena, y aun así la intranet rechaza la conexión o las carpetas se quedan pensando. Casi siempre es un servicio que no escucha, o un cortafuegos que no deja pasar. Para distinguirlos hay que leer cómo falla la conexión.
Puertos: de un equipo a una aplicación
Un puerto es un número de 0 a 65535. El servidor escucha en el puerto de cada servicio (la web, en el 80; las carpetas, en el 445), y el cliente sale desde un puerto cualquiera que elige él, un puerto efímero. Las dos direcciones, los dos puertos y el protocolo identifican una conversación: es lo que se llama un socket en cada extremo.
Los puertos se reparten en tres tramos:
- Bien conocidos (0–1023): los de los servicios de siempre.
- Registrados (1024–49151): los de aplicaciones concretas (el escritorio remoto, 3389).
- Efímeros (49152–65535 en Windows): los que se inventa el cliente para cada conexión y suelta al acabar.
Los que vas a ver:
| Puerto | Protocolo | Para qué |
|---|---|---|
| 22 | TCP | consola remota (SSH) |
| 53 | UDP | nombres (DNS) |
| 67 y 68 | UDP | DHCP (servidor y cliente) |
| 80 | TCP | web (HTTP) |
| 123 | UDP | la hora (NTP) |
| 443 | TCP | web cifrada (HTTPS) |
| 445 | TCP | carpetas compartidas (SMB) |
| 3389 | TCP | escritorio remoto (RDP) |
UDP: mandar y olvidarse
UDP pone delante de los datos una cabecera de solo 8 bytes: puerto de origen, puerto de destino, longitud y una suma de comprobación. Y ya. No abre conexión, no confirma nada, no reordena, no reenvía lo que se pierde. Si un datagrama no llega, UDP ni se entera.
Parece poco, y justo por eso se usa: para preguntas cortas en las que esperar no compensa (DNS, DHCP, la hora) y para lo que va en directo (la voz, el vídeo), donde un trozo que llega tarde ya no sirve. Lo que UDP no hace, si hace falta, lo hace la aplicación: el cliente de la hora, si no le contestan, vuelve a preguntar.
TCP: una conexión de verdad
TCP hace justo lo contrario: garantiza que todo llega, entero y en orden. Para eso, antes de mandar nada, abre una conexión en tres pasos (el three-way handshake), numera cada byte y espera confirmaciones.
- Números de secuencia y de confirmación: cada lado numera los bytes que manda. El otro contesta con un ACK que dice “tengo todo hasta aquí, mándame el siguiente”. (Wireshark los enseña relativos, empezando en 0, para que se lean mejor.)
- Retransmisión: si la confirmación no llega a tiempo, se vuelve a mandar. El usuario solo nota que va lento.
- La ventana (control de flujo): cuántos bytes puede mandar uno sin esperar confirmación, para no ahogar al que recibe. Y el control de congestión: si se pierden paquetes, TCP entiende que la red va cargada y frena.
- El cierre: cada lado cierra su mitad con FIN y el otro lo confirma. Un RST es otra cosa: un corte en seco. Es lo que contesta un equipo cuando le llega un SYN a un puerto en el que nadie escucha.
La web, las carpetas compartidas y el escritorio remoto van por TCP: ahí perder un byte rompería el archivo.
Los estados de una conexión y netstat
Cada conexión TCP pasa por varios estados. Los que más se ven:
- LISTENING: un servicio esperando conexiones en su puerto.
- SYN_SENT: el cliente mandó el SYN y sigue esperando respuesta. Si se queda ahí, algo está tirando sus paquetes.
- ESTABLISHED: conexión abierta, datos yendo y viniendo.
- TIME_WAIT: recién cerrada; se guarda un rato por si llega algún paquete rezagado.
netstat -an los enseña todos. En un puesto:
C:\Users\ventas2> netstat -an Conexiones activas Proto Dirección local Dirección remota Estado TCP 10.20.1.70:49702 10.20.1.200:445 ESTABLISHED TCP 10.20.1.70:49711 10.20.1.200:80 SYN_SENT UDP 0.0.0.0:123 *:*
En el servidor, lo interesante es qué escucha y dónde. Con -o sale además el proceso (PID)
de cada una:
C:\Users\Administrador> netstat -ano Conexiones activas Proto Dirección local Dirección remota Estado PID TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 1136 TCP 127.0.0.1:80 0.0.0.0:0 LISTENING 2210 UDP 0.0.0.0:123 *:* 1452
Fíjate en la web. 0.0.0.0 quiere decir “en todas mis direcciones”: se le puede llamar desde
cualquier sitio. 127.0.0.1 es el propio equipo: esa web solo contesta al servidor mismo.
Desde él, abrirla funciona; desde cualquier puesto, conexión rechazada. Es un error típico después
de instalar o actualizar un servicio.
Rechazada o sin respuesta
Cuando una conexión TCP falla, cómo falla dice dónde mirar:
- Rechazada al instante: el paquete llegó al servidor, y el servidor dice que ahí no hay nadie. El servicio está parado o escucha en otro sitio. El problema está en el servidor.
- Tiempo agotado: el SYN salió, se reintentó, y no volvió nada. Algo lo tiró por el camino sin avisar: un cortafuegos, el del servidor o el de la red. Windows tarda unos 20 segundos en rendirse; esa espera ya es una pista.
En Windows, la prueba de un puerto se hace con PowerShell. Desde el símbolo del sistema, se
escribe powershell para entrar (y exit para volver):
PS C:\Users\ventas2> Test-NetConnection 10.20.1.200 -Port 445 ComputerName : 10.20.1.200 RemoteAddress : 10.20.1.200 RemotePort : 445 InterfaceAlias : Ethernet SourceAddress : 10.20.1.70 TcpTestSucceeded : True
Cuando falla, además del aviso, hace un ping, que dice si al menos la capa 3 está bien:
PS C:\Users\ventas2> Test-NetConnection 10.20.1.200 -Port 80 ADVERTENCIA: TCP connect to (10.20.1.200 : 80) failed ComputerName : 10.20.1.200 RemoteAddress : 10.20.1.200 RemotePort : 80 InterfaceAlias : Ethernet SourceAddress : 10.20.1.70 PingSucceeded : True PingReplyDetails (RTT) : 1 ms TcpTestSucceeded : False
La salida es la misma para “rechazada” que para “tiempo agotado”. Lo que las distingue es cuánto
tarda (al instante o unos 20 segundos), netstat mientras espera (SYN_SENT) y, sobre todo,
capturar: un RST que vuelve, o un SYN que se repite sin respuesta.
C:\Users\ventas2> w32tm /stripchart /computer:10.20.1.200 /samples:1 /dataonly Seguimiento de 10.20.1.200 [10.20.1.200:123]. Recopilando 1 muestras. La hora actual es 25/09/2026 10:14:03. 10:14:03, error: 0x80072746
Cortafuegos: el del equipo y el de la red
Un cortafuegos decide qué tráfico pasa y cuál no. Los hay en dos sitios:
- En el propio equipo. El Firewall de Windows bloquea por defecto todo lo que entra sin
que nadie lo haya pedido, salvo lo que permitan sus reglas de entrada (una por servicio: “la
intranet, TCP 80, permitido”). Las respuestas a lo que el propio equipo pidió sí entran: el
cortafuegos recuerda las conexiones que se abrieron desde dentro (es con estado). Instalar un
servicio y olvidarse de su regla es un clásico: el servicio escucha,
netstatlo enseña, y desde fuera, tiempo agotado. - En la red: los routers filtran con listas de acceso (ACL), y los cortafuegos de red dedicados, con reglas parecidas. Protegen a muchos equipos a la vez y hacen cumplir las políticas de la empresa: quién puede llegar a qué.
Si el SYN llega al cable del servidor y no hay respuesta, el filtro está en el servidor. Si ni siquiera llega, está antes, en la red. Capturar en el sitio justo lo decide.
Las ACL extendidas del router
Una ACL extendida de Cisco es una lista de líneas permit (dejar pasar) o deny (tirar),
cada una con el protocolo, el origen, el destino y, si es TCP o UDP, el puerto:
R-SEDE(config)# access-list 110 permit tcp 10.20.1.0 0.0.0.63 host 10.20.1.200 eq 3389
Las redes no se escriben con máscara sino con máscara comodín (wildcard): la máscara al revés, unos donde da igual y ceros donde tiene que coincidir. Se calcula restando cada octeto de 255:
- /26 (255.255.255.192): 255 − 192 = 63, comodín 0.0.0.63.
- /24 (255.255.255.0): 0.0.0.255.
host 10.20.1.200es un solo equipo (comodín 0.0.0.0), yany, cualquiera.
Cómo la lee el router es lo que más importa:
- El orden importa. El router mira las líneas de arriba abajo y aplica la primera que
coincide; las de debajo ni se miran. Un
permit ip any anypuesto antes de undenyhace que esedenyno sirva para nada. - El deny implícito. Al final de toda ACL hay un
deny ip any anyque no se ve: lo que no coincide con ninguna línea, se tira. Por eso una ACL que solo quiere prohibir algo acaba con unpermitgeneral. - Se aplica a una interfaz, en un sentido:
in(lo que entra por ella) uout(lo que sale). Para proteger la VLAN del servidor, en su subinterfaz, hacia fuera:
R-SEDE(config)# interface GigabitEthernet0/0.99 R-SEDE(config-subif)# ip access-group 110 out
Y la herramienta de diagnóstico: show access-lists, que enseña cuántas veces ha coincidido
cada línea. Un contador que sube dice qué línea está decidiendo; uno que se queda en cero, que
esa línea nunca llega a mirarse (o que no coincide con lo que crees).
R-SEDE# show access-lists Extended IP access list 110 10 permit tcp 10.20.1.0 0.0.0.63 host 10.20.1.200 eq 3389 (12 matches) 20 deny tcp any host 10.20.1.200 eq 3389 (4 matches) 30 permit ip any any (1583 matches)
Esos números (10, 20, 30) sirven para cambiar una ACL que ya existe sin escribirla entera
otra vez. Con ip access-list extended 110 se entra en ella; no y el número borran esa línea, y
una línea escrita sin número va al final:
R-SEDE(config)# ip access-list extended 110 R-SEDE(config-ext-nacl)# no 10 R-SEDE(config-ext-nacl)# permit ip any any R-SEDE(config-ext-nacl)# end
Y una línea escrita con un número delante entra justo en ese sitio: dentro de la ACL 110,
15 deny tcp any host 10.20.1.200 eq 3389 queda entre la 10 y la 20. Así se pone en su lugar una
línea que se borró por error, sin tocar las demás.
(Un router Cisco puede avisar de lo que tira con un ICMP de “prohibido administrativamente”, pero
muchas redes lo desactivan con no ip unreachables para no dar pistas. En la sala, R-SEDE no
avisa: lo que tira una ACL es silencio.)
NAT y PAT: muchos equipos, una IP
Las direcciones de dentro de la empresa son privadas (10.x.x.x): en internet no existen, y el
proveedor tira lo que le llega con un origen así. Para salir, el router de la empresa cambia la
dirección privada de origen por su IP pública: eso es NAT. Y como hay una sola IP pública
para cien equipos, lo que distingue cada conversación a la vuelta es el puerto. Es PAT (en
Cisco, NAT con overload), y es lo que hace casi cualquier router de oficina o de casa.
En IOS se le dice qué interfaces dan a la red de dentro y cuál a la de fuera, qué direcciones se traducen (con una ACL) y a qué IP:
R-SEDE(config)# access-list 1 permit 10.20.1.0 0.0.0.255 R-SEDE(config)# access-list 1 permit 10.20.2.0 0.0.0.255 R-SEDE(config)# interface GigabitEthernet0/0.20 R-SEDE(config-subif)# ip nat inside R-SEDE(config-subif)# interface GigabitEthernet0/2 R-SEDE(config-if)# ip nat outside R-SEDE(config-if)# exit R-SEDE(config)# ip nat inside source list 1 interface GigabitEthernet0/2 overload
(ip nat inside va en cada interfaz de dentro: las subinterfaces de la sede y el enlace hacia
la sucursal.) La tabla de traducciones enseña quién está saliendo ahora mismo:
R-SEDE# show ip nat translations Pro Inside global Inside local Outside local Outside global tcp 203.0.113.2:50123 10.20.1.70:50123 198.51.100.10:443 198.51.100.10:443 tcp 203.0.113.2:1024 10.20.2.51:50123 198.51.100.10:443 198.51.100.10:443
Inside local es el equipo tal y como se ve dentro; inside global, como lo ve internet. Si una red no está en la ACL del NAT, sus paquetes salen con el origen privado, el proveedor los tira, y esa red se queda sin internet mientras todo lo de dentro funciona. En la tabla, ni rastro de ella.
Cómo se diagnostica la capa 4
Con la capa 3 descartada, se sube de abajo arriba, y cada respuesta dice dónde mirar:
- ¿Llega el ping? (
ping, o el propioTest-NetConnection). Si no, el problema es de la capa 3 o de más abajo. - ¿Conecta al puerto?
Test-NetConnectioncon-Port. Si conecta, la capa 4 está bien. - Si no, ¿rechaza o no contesta? Al instante, o tras unos 20 segundos;
netstat -anen el puesto (SYN_SENT); el capturador (RST, o SYN que se repiten). - Rechazada → al servidor: ¿el servicio está en marcha?
netstat -ano: ¿escucha, en qué puerto, en0.0.0.0o solo en127.0.0.1? - Sin respuesta → ¿desde todas partes o solo desde algunas? Captura en el cable del
servidor: si el SYN llega, es su cortafuegos; si no llega, es la red:
show access-listsy sus contadores. - Sin internet desde una red concreta →
show ip nat translationsy la ACL del NAT. - Y lo que funciona y no debería: comprobar también lo que la política prohíbe.