La capa 4 abre una conexión entre dos aplicaciones. Pero lo que un usuario hace con ellas dura más que una conexión y necesita más cosas: decir quién es, que el servidor se acuerde de él mientras trabaja, poder dejarlo a medias y volver, y que al acabar se libere lo que ocupaba. Eso es una sesión, y es de lo que trata la capa 5.
Aquí las averías son las del “conecto, pero…”. El ping llega, el puerto contesta, y aun así el escritorio remoto dice que no caben más usuarios, la consola del router se corta sola o un archivo está “en uso” por alguien que se fue a casa hace horas. La red y los servicios están bien: lo que falla es el estado de una sesión, en un extremo, en el otro o en medio.
Qué es una sesión (y dónde está en TCP/IP)
Una sesión es la conversación completa entre dos aplicaciones: desde “hola, soy yo” hasta “adiós”. Puede usar una conexión TCP o muchas, y a veces sobrevive a que una se corte.
En el modelo OSI es una capa aparte. En TCP/IP no existe: cada aplicación se encarga de sus sesiones a su manera. El escritorio remoto, las carpetas compartidas (SMB), SSH o una web con su inicio de sesión llevan cada uno su propia lógica para abrirlas, mantenerlas y cerrarlas. Por eso la capa 5 no es “un protocolo”: es un problema que todas las aplicaciones tienen que resolver. Y como lo resuelven parecido, fallan parecido.
Toda sesión pasa por lo mismo:
- Abrirse: demostrar quién eres y qué puedes hacer.
- Mantenerse: que los dos extremos sigan de acuerdo en que existe, aunque no pase nada.
- Retomarse, si se corta.
- Cerrarse, liberando lo que ocupaba.
Abrir una sesión: quién eres
Antes de nada, el servidor quiere saber dos cosas:
- Autenticación: quién eres. Una contraseña, una clave, una tarjeta.
- Autorización: qué puedes hacer, una vez que sabe quién eres. Que ventas2 exista no quiere decir que pueda entrar al escritorio remoto del servidor.
Dar la contraseña en cada paso sería pesado e inseguro. Lo normal es demostrarlo una vez y recibir a cambio una prueba de que ya lo hiciste, con caducidad: una cookie de sesión en una web, o un ticket en una red de Windows. Mientras la prueba valga, la sesión se reconoce sin volver a preguntar.
La hora, parte de la contraseña
En una empresa con Windows, los puestos no guardan cada uno sus usuarios: los valida un servidor,
el controlador de dominio. En la sala, el dominio se llama EMPRESA y su controlador es
SRV-SEDE. Al iniciar sesión, el puesto se presenta al servidor y recibe un ticket (el sistema
se llama Kerberos). Con ese ticket pide después otros, uno por servicio, y abre las carpetas
compartidas sin volver a dar la contraseña.
Cada petición lleva la hora del puesto. Si alguien la grabara y la repitiera más tarde, estaría caducada. Por eso el servidor rechaza los relojes que se desvían más de 5 minutos del suyo:
klist enseña los tickets de la sesión. Con el reloj bien, están ahí:
C:\Users\ventas2> klist Id. de inicio de sesión actual es 0:0x3e7a1 Vales almacenados en caché: (2) #0> Cliente: ventas2 @ EMPRESA.LAN Servidor: krbtgt/EMPRESA.LAN @ EMPRESA.LAN Hora de inicio: 25/9/2026 8:03:11 (local) Hora de finalización: 25/9/2026 18:03:11 (local) #1> Cliente: ventas2 @ EMPRESA.LAN Servidor: cifs/SRV-SEDE @ EMPRESA.LAN Hora de inicio: 25/9/2026 8:05:40 (local) Hora de finalización: 25/9/2026 18:03:11 (local)
Un puesto cuyo reloj se ha ido no tiene tickets, y al abrir una carpeta Windows le pide la
contraseña una y otra vez, o avisa de que hay una diferencia de hora o de fecha entre el cliente
y el servidor. En un dominio, cada puesto toma la hora del dominio (y el controlador, de
fuera). w32tm /query /source dice de dónde la saca:
C:\Users\conta1> w32tm /query /source Local CMOS Clock
Se le devuelve al dominio y se sincroniza:
C:\Users\conta1> w32tm /config /syncfromflags:domhier /update El comando se completó correctamente. C:\Users\conta1> w32tm /resync Enviando comando de resincronización al equipo local El comando se completó correctamente.
Mantenerla viva: inactividad y keepalives
Mientras nadie hace nada, por una sesión no pasa ningún paquete. ¿Sigue el otro ahí, o se apagó sin despedirse? Hay dos herramientas:
- Límite de inactividad (idle timeout): si pasa tanto tiempo sin actividad, la sesión se corta. Libera sitio y cierra puertas que alguien dejó abiertas. Pero si es demasiado corto, el usuario se queja de que “le echa cada dos por tres”.
- Keepalives: paquetes pequeños que dicen “sigo aquí”. Si no hay respuesta a varios seguidos, el otro extremo se da por perdido. Sirven para detectar sesiones medio abiertas (un extremo se fue sin cerrar) y para que nadie en medio las olvide.
Cada servicio tiene sus tiempos, y casi nunca coinciden:
| Dónde | Qué caduca | Por defecto |
|---|---|---|
| Escritorio remoto | sesión inactiva o desconectada | nunca |
| Consola de un router | exec-timeout |
10 minutos |
| PAT de un router Cisco | traducción TCP | 24 horas |
| Ticket del dominio | el ticket | 10 horas |
Desconectar no es cerrar
Una sesión de escritorio remoto se puede desconectar (cerrar la ventana, o que se corte la red) o cerrar (cerrar sesión). No es lo mismo:
- Desconectada: sigue viva en el servidor, con sus programas abiertos. Al volver a conectarse, el usuario la retoma tal y como la dejó.
- Cerrada: se acabó; lo que no estaba guardado se pierde.
Lo cómodo es desconectar, y por eso se acumulan sesiones desconectadas de hace días. Un servidor
Windows, sin licencias de Escritorio remoto, admite dos sesiones a la vez para administrarlo.
Si dos desconectadas ocupan las dos plazas, el siguiente se encuentra con esto: “El número de
conexiones a este equipo está limitado y todas las conexiones están en uso ahora mismo”. En el
servidor, query user enseña quién ocupa cada plaza y cuánto tiempo lleva sin hacer nada:
C:\Users\Administrador> query user NOMBRE DE USUARIO NOMBRE DE SESIÓN ID ESTADO TIEMPO IN. TIEMPO DE INICIO >administrador console 1 Activo . 25/9/2026 8:02 admin2 2 Desc 3+04:11 22/9/2026 9:15 admin3 3 Desc 2+18:40 23/9/2026 13:40
3+04:11 son tres días, cuatro horas y once minutos sin tocarla. Se cierran con logoff y su
número (logoff 2), sabiendo antes de quién son: lo que tuvieran abierto se pierde. Y para que no
vuelva a pasar, una directiva pone un límite a las sesiones desconectadas.
El estado en medio
Una sesión no solo la recuerdan los dos extremos. Todo lo que hay en medio con estado también:
- El PAT del router (capa 4) apunta cada conversación en su tabla, para saber de quién es cada respuesta.
- Los cortafuegos con estado recuerdan las conexiones abiertas desde dentro, para dejar pasar sus respuestas.
Y cada tabla borra lo que lleva un rato sin tráfico. Si olvida antes que los extremos, la sesión muere sin que ninguno de los dos la haya cerrado:
La tabla de traducciones lo dice, con verbose: cuándo se creó cada una, cuándo se usó por
última vez y cuánto le queda:
R-SEDE# show ip nat translations verbose Pro Inside global Inside local Outside local Outside global tcp 203.0.113.2:50231 10.20.1.10:50231 198.51.100.10:22 198.51.100.10:22 create 00:03:10, use 00:00:43, timeout:60000, left 00:00:17, flags: extended, use_count: 0
timeout:60000 son 60 segundos (se cuenta en milisegundos). Se cambia con ip nat translation tcp-timeout y los segundos, y no ip nat translation tcp-timeout lo devuelve al de fábrica
(24 horas). El remedio es que el que está en medio aguante más que los keepalives de los
extremos: con 24 horas (lo normal) o con una hora, la pregunta del servidor a
los dos minutos encuentra su camino. Si no se puede tocar lo de en medio, los keepalives del
cliente mantienen viva la entrada.
Cuando pasa, el cliente SSH de Windows lo cuenta así:
C:\Users\admin1> ssh [email protected] Welcome to Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-45-generic x86_64) empresa@web:~$ empresa@web:~$ ls client_loop: send disconnect: Connection reset C:\Users\admin1>
Las sesiones de un router: consola y SSH
A un router se entra de dos formas:
- Por la consola: el cable azul, en la mano. Una sola línea (
con 0), siempre disponible. - Por la red: con SSH (el puerto 22, cifrado), por las líneas VTY (virtual
terminal). Normalmente, cinco (
vty 0 4): cinco sesiones remotas a la vez como mucho.
Desde un puesto de Windows, SSH viene de serie. Informática entra con su clave (un par de claves guardado en su puesto y en el router), así que no pide contraseña:
C:\Users\admin1> ssh [email protected] R-SEDE>
Cada sesión remota ocupa una línea hasta que se cierra. Si alguien cierra la ventana sin exit, o
su portátil se queda sin batería, la línea sigue ocupada hasta que la sesión caduque: eso es el
exec-timeout. Si alguien lo puso a 0 0 (“nunca”, para que no le echara), las sesiones
colgadas no se van nunca, y cuando se juntan cinco, no entra nadie más. show users lo
enseña, con cuánto lleva cada línea sin hacer nada:
R-SEDE# show users Line User Host(s) Idle Location * 0 con 0 idle 00:00:00 2 vty 0 admin idle 06:12:33 10.20.1.10 3 vty 1 admin idle 05:47:02 10.20.1.10 4 vty 2 admin idle 04:30:15 10.20.1.11 5 vty 3 admin idle 03:05:40 10.20.1.10 6 vty 4 admin idle 01:22:09 10.20.1.12
Se liberan con clear line y el número de línea (el de la primera columna), y se pone un límite
razonable para que no vuelva a pasar:
R-SEDE# clear line 2 [confirm] [OK] R-SEDE# configure terminal R-SEDE(config)# line vty 0 4 R-SEDE(config-line)# exec-timeout 10 0 R-SEDE(config-line)# transport input ssh
(transport input ssh deja entrar solo por SSH: nada de Telnet, que va sin cifrar. Y al revés: con
transport input telnet o none, el router ya no atiende SSH, y ssh contesta Connection
refused, igual que con las líneas llenas. show running-config, bajo line vty 0 4, dice cuál
tiene.)
Sesiones de archivos y archivos bloqueados
Al abrir una carpeta compartida, el puesto abre una sesión SMB con el servidor, y dentro de ella, los archivos que va usando. Mientras un archivo está abierto para editarlo, el servidor lo bloquea: nadie más puede escribir en él a la vez. Tiene sentido: dos personas guardando encima la una de la otra acabarían perdiendo trabajo.
El problema llega cuando el que lo tenía abierto no lo cierra nunca: su puesto se apagó de golpe, o se colgó. Para el servidor, la sesión sigue ahí un buen rato, y el archivo, bloqueado:
En el servidor, net session enseña las sesiones (de quién, desde dónde, cuántos archivos tiene
abiertos y cuánto lleva sin hacer nada), y net file, los archivos abiertos:
C:\Users\Administrador> net session Equipo Nombre de usuario Tipo de cliente Abiertos Tiempo inactivo ------------------------------------------------------------------------------- \\10.20.1.70 ventas2 0 00:00:12 \\10.20.1.140 conta2 1 03:12:40 Se ha completado el comando correctamente.
C:\Users\Administrador> net file ID Ruta Nombre de usuario Bloqueos ------------------------------------------------------------------------------- 42 D:\Compartido\Contabilidad\cierre-2026.xlsx conta2 1 Se ha completado el comando correctamente. C:\Users\Administrador> net file 42 /close Se ha completado el comando correctamente.
Antes de cerrar un archivo ajeno, se mira de quién es: si conta2 estuviera trabajando de verdad en él, perdería lo que no hubiera guardado. Aquí su puesto lleva tres horas sin responder, y no hay nada que perder.
Cómo se diagnostica la capa 5
Con las capas de abajo descartadas (el ping llega, el puerto conecta), se pregunta por la sesión, y cada respuesta dice dónde mirar:
- ¿Te deja entrar? Si no: ¿no cabe nadie más (plazas o líneas llenas), o no te cree? Leer el mensaje entero: dice mucho.
- Si no te cree: ¿la hora? El reloj del puesto frente al del servidor,
klist(¿hay tickets?) yw32tm /query /source(¿de dónde saca la hora?). - Si no cabe: ¿quién ocupa el sitio, y desde cuándo? En el servidor,
query user; en un router,show usersdesde la consola. Las sesiones desconectadas o quietas desde hace horas son las sospechosas. - Si te echa: ¿cada cuánto, y con qué mensaje? Siempre al mismo tiempo de estar quieta: un
límite de inactividad (una directiva, un
exec-timeout). Con un “Connection reset” al volver: alguien en medio la olvidó (show ip nat translations verbose). - Si “está en uso”: ¿quién lo tiene abierto, y sigue ahí?
net sessionynet fileen el servidor. - Y al arreglarlo, el límite que evita que vuelva a pasar: ni “nunca” (se acumulan) ni un minuto (echa a la gente).