Ejercicios de evaluación. Curso 2019 2020. Bloque III
- Ejercicios de evaluación y sus soluciones correspondientes al bloque III de prácticas: Enrutamiento IP, ARP, UDP y TCP
- Bloque-III-Practica.pdf
- Escenario para Netgui: escenario-test.zip
Descomprime el escenario disponible en el fichero escenario-test.zip y ábrelo con Netgui. Arranca todas las máquinas
- Obtén las tablas de enrutamiento de TODAS las máquinas que estén configuradas e indica el comando que hay que usar. Adjunta pantallazos de los resultados en el terminal en todas las máquinas
- Sol: Para ver las tablas de encaminamiento usamos el comando route
Ni ordenador pc1 ni el router r5 están configurados (no tienen IPs asignadas)
pc2:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
20.20.20.128 * 255.255.255.128 U 0 0 0 eth0
default 20.20.20.213 0.0.0.0 UG 0 0 0 eth0
pc2:~#
pc3:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
30.30.30.0 * 255.255.255.0 U 0 0 0 eth0
default 30.30.30.14 0.0.0.0 UG 0 0 0 eth0
pc3:~#
pc4:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
40.40.40.128 * 255.255.255.128 U 0 0 0 eth0
default 40.40.40.210 0.0.0.0 UG 0 0 0 eth0
pc4:~
r1:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
40.40.40.128 * 255.255.255.128 U 0 0 0 eth1
10.10.10.0 * 255.255.255.0 U 0 0 0 eth0
default 10.10.10.12 0.0.0.0 UG 0 0 0 eth0
r1:~#
r2:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
20.20.20.128 * 255.255.255.128 U 0 0 0 eth1
10.10.10.0 * 255.255.255.0 U 0 0 0 eth0
default 20.20.20.213 0.0.0.0 UG 0 0 0 eth1
r2:~#
r3:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
20.20.20.128 * 255.255.255.128 U 0 0 0 eth0
30.30.30.0 * 255.255.255.0 U 0 0 0 eth1
default 30.30.30.14 0.0.0.0 UG 0 0 0 eth1
r3:~#
r4:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
40.40.40.128 * 255.255.255.128 U 0 0 0 eth1
30.30.30.0 * 255.255.255.0 U 0 0 0 eth0
default 40.40.40.210 0.0.0.0 UG 0 0 0 eth1
r4:~#
- Comprueba si pc2 y pc4 pueden intercambiar datagramas. Indica el comando que has usado para ello, la salida que produce y porqué deduces que hay conectividad
- Sol: Sí hay conectividad entre pc2 y pc4. Lo comprobamos con el comando ping. Se puede probar de varias formas. Por ejemplo yendo a la terminal de pc2 y haciendo un ping a pc (cuya IP es 40.40.40.204):
pc2:~# ping 40.40.40.204
PING 40.40.40.204 (40.40.40.204) 56(84) bytes of data.
64 bytes from 40.40.40.204: icmp_seq=1 ttl=62 time=11.4 ms
64 bytes from 40.40.40.204: icmp_seq=2 ttl=62 time=0.660 ms
64 bytes from 40.40.40.204: icmp_seq=3 ttl=62 time=0.651 ms
64 bytes from 40.40.40.204: icmp_seq=4 ttl=62 time=0.772 ms
--- 40.40.40.204 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.651/3.374/11.413/4.641 ms
pc2:~#
Obtenemos respuesta de la máquina destino, por lo que hay conectividad
- Los paquetes enviados de pc2 a pc4, ¿Qué ruta siguen?. Justifícalo indicando los comandos que hay que ejecutar para saberlo, y las salidas que producen
- Sol: Para saber por qué rúters pasan los paquetes de pc2 con destino a pc4, nos situamos sobre el terminal de pc2 y usamos el comando traceroute
traceroute to 40.40.40.204 (40.40.40.204), 64 hops max, 40 byte packets
1 20.20.20.213 (20.20.20.213) 10 ms 0 ms 0 ms
2 40.40.40.214 (40.40.40.214) 35 ms 0 ms 0 ms
3 40.40.40.204 (40.40.40.204) 9 ms 0 ms 0 ms
pc2:~#
Observando las IPs de las máquinas intermedias, vemos que los paquetes van de pc2 a r3, de ahí a r4 y de r4 a pc4. Por tanto, la ruta es: pc2 => r3 => r4 => pc4
- Los paquetes enviados de pc4 a pc2, ¿Qué ruta siguen?. Justifícalo indicando los comandos que hay que ejecutar para saberlo, y las salidas que producen
- Sol: Lo hacemos igual que en apartado anterior. Ahora nos sale la ruta: pc4 => r1 => r2 => pc2
- Configura la IP de PC1 para que haya conectividad con PC2. Los paquetes de pc1 a pc2 deben seguir la ruta pc1=>r2=>PC2. Sin cambiar ninguna tabla de enrutamiento del resto de máquinas, ¿Qué ruta siguen los paquetes que van de PC2 a PC1?
- Sol: PC1 está en la misma subred que r1 y r2. Nos vamos a la terminal de cualquier de ellos (por ejemplo a r1) y ejecutamos el comando ifconfig para conocer la máscara de red:
r1:~# ifconfig
eth0 Link encap:Ethernet HWaddr 6e:01:79:84:7c:80
inet addr:10.10.10.11 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: fe80::6c01:79ff:fe84:7c80/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:440 (440.0 B) TX bytes:1828 (1.7 KiB)
Interrupt:5
Vemos que es 255.255.255.0. Con esta información y viendo las IPs de r1 y r2 samos que la IP de pc1 tiene que ser de la forma: 10.10.10.x, donde x puede ser cualquier números excepto 0, 11, 12 ó 255. Elejimos por ejemplo el 1 y configuramos su IP a 10.10.10.1
Configuramos también su tabla de enrutamiento para que los paquetes salgan por r2. El fichero /etc/network/interfaces de pc1 quedaría así:
pc1:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.10.10.1
netmask 255.255.255.0
gateway 10.10.10.12
pc1:~#
Ahora, si ejecutamos un ping a pc2, vemos que hay conectividad:
pc1:~# ping 20.20.20.202
PING 20.20.20.202 (20.20.20.202) 56(84) bytes of data.
64 bytes from 20.20.20.202: icmp_seq=1 ttl=61 time=10.5 ms
64 bytes from 20.20.20.202: icmp_seq=2 ttl=61 time=0.662 ms
64 bytes from 20.20.20.202: icmp_seq=3 ttl=61 time=0.392 ms
--- 20.20.20.202 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.392/3.863/10.535/4.719 ms
pc1:~
Y con traceroute verifcamos que efectivamente siguen el caminio pc1 => r2 => pc2
pc1:~# traceroute 20.20.20.202
traceroute to 20.20.20.202 (20.20.20.202), 64 hops max, 40 byte packets
1 10.10.10.12 (10.10.10.12) 0 ms 0 ms 0 ms
2 20.20.20.202 (20.20.20.202) 0 ms 0 ms 0 ms
pc1:~#
Si hacemos el traceroute desde pc2 a pc1, lo que obtenemos es:
pc2:~# traceroute 10.10.10.1
traceroute to 10.10.10.1 (10.10.10.1), 64 hops max, 40 byte packets
1 20.20.20.213 (20.20.20.213) 0 ms 0 ms 0 ms
2 40.40.40.214 (40.40.40.214) 8 ms 0 ms 0 ms
3 10.10.10.11 (10.10.10.11) 0 ms 0 ms 0 ms
4 10.10.10.1 (10.10.10.1) 0 ms 0 ms 0 ms
pc2:~#
Comprobamos que la ruta es diferente: pc2 => r3 => r4 => r1 => pc1
- Apaga r1, r2, r3 y r4. Configura las máquinas restantes para que haya conectividad entre todas ellas. Muestra la información del comando traceroute desde PC1 al resto de máquina, y justifica que tu configuración está funcionando. Guarda esta configuración de forma persistente
- Sol: Para que haya conectividad entre todos la única posibilidad es que sea a través de r5, por ello hay que configurar las 4 interfaces de r5 con direcciones IPs adecuadas, y luego hay que cambar las tablas de enrutamiento de pc1, pc2, pc3 y pc4 para que por defecto envíen los paquetes a través de r5
El primer paso es recopilar todas las máscaras de red de las cuatro subredes. Eso lo hacemos mirando la configuración de las IP de cada PC, con el comando ifconfig. En esta tabla se muestran los resultados.
| Máquina | IP | Máscara de red |
|---|---|---|
| PC1 | 10.10.10.1 | 255.255.255.0 |
| PC2 | 20.20.20.202 | 255.255.255.128 |
| PC3 | 30.30.30.3 | 255.255.255.0 |
| PC4 | 40.40.40.204 | 255.255.255.128 |
Ahora ya podemos seleccionar direcciones IP válidas para cada uno de los 4 interfaces de r5. Hay muchas posibilidades. En esta tabla se recoge una posible solución:
| Interfaz r5 | IP | Máscara |
|---|---|---|
| eth0 | 40.40.40.215 | 255.255.255.128 |
| eth1 | 10.10.10.215 | 255.255.255.0 |
| eth2 | 20.20.20.215 | 255.255.255.128 |
| eth3 | 30.30.30.215 | 255.255.255.0 |
Una vez configurado todo hacemos traceroute desde pc1 al resto de máquinas para confirmar que hay conexión con todas ellas
pc1:~# traceroute 20.20.20.202
traceroute to 20.20.20.202 (20.20.20.202), 64 hops max, 40 byte packets
1 10.10.10.215 (10.10.10.215) 0 ms 0 ms 0 ms
2 20.20.20.202 (20.20.20.202) 8 ms 0 ms 0 ms
pc1:~#
pc1:~# traceroute 30.30.30.3
traceroute to 30.30.30.3 (30.30.30.3), 64 hops max, 40 byte packets
1 10.10.10.215 (10.10.10.215) 0 ms 0 ms 0 ms
2 30.30.30.3 (30.30.30.3) 0 ms 0 ms 0 ms
pc1:~#
pc1:~# traceroute 40.40.40.204
traceroute to 40.40.40.204 (40.40.40.204), 64 hops max, 40 byte packets
1 10.10.10.215 (10.10.10.215) 0 ms 0 ms 0 ms
2 40.40.40.204 (40.40.40.204) 9 ms 0 ms 0 ms
pc1:~#
- Partimos del escenario que ya tenías configurado en el apartado 6. Asegúrate que hay conectividad entre PC2 y PC4 a través de r5. Cierra todas las máquinas y arranca sólo PC2, PC4 y r5. Completa la siguiente tabla:
| Máquina | Direccion Ethernet | Dirección IP |
|---|---|---|
| PC2 | ||
| PC4 | ||
| R5 |
- Sol: Nos situamos en cada una de las máquinas y usamos el comando ifconfig para obtener la información. NOTA: Las direcciones físicas (ethernet) en las máquinas virtuales se asignan aleatoriamente cada vez que arrancan las máquinas, por ello a cada uno os saldrán unas direcciones diferentes
| Máquina | Direccion Ethernet | Dirección IP |
|---|---|---|
| PC2 | d2:94:92:a9:76:4a | 20.20.20.202 |
| PC4 | 0e:52:61:de :85:bb | 40.40.40.204 |
| R5/eth0 | 6e:19:19:7e:31:29 | 40.40.40.215 |
| R5/eth1 | 52:1c:b9:32:6e:7e | 10.10.10.215 |
| R5/eth2 | 5a:61:50:05:7a:3a | 20.20.20.215 |
| R5/eth3 | ea:b4:47:97:ea:76 | 30.30.30.215 |
- Partiendo de estado inicial, antes de haber ejecutado ningún comando ping, comprueba el estado de las cachés de arp. Saca una captura de la terminal de cada máquina (pc2, pc4 y r5) con el comando que has usado y el resultado
- Sol: Para comprobar la caché usamos el comando arp. Nada más arrancar las máquinas, puesto que no ha habido ninguna comunicación entre las máquinas, todas las cachés arp estará vacías, y así al ejecutar el comando arp no obtendremos nada:
pc2:~# arp
pc2:~#
pc4:~# arp
pc4:~#
r5:~# arp
r5:~#
- Arranca tcpdump para capturar el tráfico en pc4 y en r5 (en su interfaz eth2). Realiza un único ping desde pc2 a pc4. Guarda las capturas en los ficheros cap-pc4-xxx.cap y cap-r5-xxx.cap donde xxx son tus iniciales (iguales que las que usaste en los ejercicios del bloque II). Toma una caputara de pantalla del terminal en pc4 y r5 donde se vea el comando tcpdump lanzado
- Sol: Realizamos la primera captura en pc4. Desde pc2 lanzamos un único ping (con el argumento -c 1) y finalizamos la captura en pc4:
pc4:~# tcpdump -i eth0 -s 0 -w /hosthome/cap-pc4-agm.cap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
4 packets captured
4 packets received by filter
0 packets dropped by kernel
pc4:~#
Repetimos con la segunda captura, pero ahora desde r5 (eth2):
r5:~# tcpdump -i eth2 -s 0 -w /hosthome/cap-r5-agm.cap
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
4 packets captured
4 packets received by filter
0 packets dropped by kernel
r5:~#
- Comprueba de nuevo el estado de las cachés de ARP y saca las capturas de la terminal de cada máquina (pc2, pc4 y r5). Compáralas con lo obtenido en 8 y explica qué ha ocurrido
- Sol: Ahora consultamos las cachés ARP ejecutando nuevamente el comando arp en cada máquina. Al haberse realizado una comunicación entre pc2 y pc4, pc4 tiene almacenada la dirección física para conectarse a r5. R5 también conoce las direcciones físicas de Pc4 y Pc2, y lo pc4 conoce la dirección física de conexión a r5. Por tanto, las cachés ARP ahora no están vacías, como al principio:
pc2:~# arp
Address HWtype HWaddress Flags Mask Iface
20.20.20.215 ether 5A:61:50:05:7A:3A C eth0
pc2:~#
PC2 tiene almacenada en su caché la dirección física de r5/eth2
pc4:~# arp
Address HWtype HWaddress Flags Mask Iface
40.40.40.215 ether 6E:19:19:7E:31:29 C eth0
pc4:~#
PC4 tiene almacenada en su caché la dirección física de r5/eth0
r5:~# arp
Address HWtype HWaddress Flags Mask Iface
20.20.20.202 ether D2:94:92:A9:76:4A C eth2
40.40.40.204 ether 0E:52:61:DE:85:BB C eth0
r5:~#
R5 tiene almacenada en su caché las direcciones físicas de PC2 y PC4
- Abre las dos capturas en wireshark, toma un pantallazo de cada una y adjúntalos como respuesta a este apartado
- Sol: Las capturas son las siguientes:
- Explica cada una de las tramas que aparecen en la captura tomada en r5, indicando el protocolo, quién la envía, quien la recibe y el propósito
- Sol: La primera trama se corresponde con el ping que envía pc2 a pc4. Protocolo ICMP. A continuación R5 necesita conocer la dirección física de PC2 para enviarle la trama, por ello envía un mensaje ARP a la red donde está PC2 preguntando por la dirección física correspondiente a la IP 20.20.20.202 (que es la de PC2). PC2 responde con un mensaje en el que le envía a R5 su dirección física. La última trama es la respuesta al ping original: que va desde PC4 a PC2
- Partimos del mismo escenario anterior, en el que hay conectividad entre PC2 y PC4 a través de r5. Arranca sólo PC2, PC4 y r5. Queremos enviar el mensaje "Hola, soy xxx", donde xxx son tus iniciales (iguales que en los ejercicios previos) desde PC2 a PC4, mediante el protocolo UDP. Para ello usaremos el comando nc. Como primer paso arranca el comando tcpdump en r5 para que se realice una captura del tráfico que pasa por su interfaz eth0. Guárdalo en el fichero udp-xxx.cap, donde xxx son tus iniciales. Lanza tcpump y toma una captura del terminal y adjúntala como respuesta a esta pregunta
r5:~# tcpdump -i eth0 -s 0 -w /hosthome/udp-agm.cap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
- Para recibir el mensaje en PC4 deberás lanzar nc en modo escucha desde un puerto que comience por el número 40 y termine con los dos primeros dígitos de tu DNI. Así, si tu dni es 32531021T, el puerto será 4032. Desde pc2 lanza el comando nc en modo cliente usando un puerto origen que comience por 20 y termine con los primeros dígitos de tu DNI. Como puerto destino usa el mismo que has empleado en el comando usado en pc4. Una vez lanzados ambos comandos, toma una captura de pantalla de los dos termines y adjúntalos como respuesta a esta pregunta. Todavía no hemos enviado el mensaje de texto
- Sol: Suponiendo que los dos primeros dígitos del DNI son 02, usaremos los puertos 4002 y 2002
En PC4 lanzamos nc en modo escucha, en el puerto 4002
pc4:~# nc -u -l -p 4002
Desde PC2 lanzamos nc en modo cliente, en el puerto 2002, con puerto destino 4002:
pc2:~# nc -u -p 2002 40.40.40.204 4002
- Desde pc2 escribe el mensaje "Hola, soy xxx", donde xxx son tus iniciales. Interrumpe el comando nc del ordenador pc2. Interrumpte la captura en r5, y adjunta pantallazos de los terminales de pc2 y pc4. ¿Se ha recibido en pc4 el mensaje enviado?
Esto es lo que ha ocurrido en pc2:
pc2:~# nc -u -p 2002 40.40.40.204 4002
Hola, soy agm
pc2:~#
Y esto es lo que aparece en pc4:
pc4:~# nc -u -l 4002
UDP listen needs -p arg
pc4:~# nc -u -l -p 4002
Hola, soy agm
Efectivamente, el mensaje enviado desde pc2 se ha recibido en pc4
- Abre la captura con Wireshark. Saca un pantallazo de todas las tramas recibidas y adjúntalo como respuesta a esta pregunta
- Sol: Este es el pantallazo. Se han resaltado algunas cosas para los siguientes apartados
- Indica de entre todas las tramas capturadas cuáles son de apertura de la conexión, y cuáles de cierre
- Sol: En esta captura aparecen 3 tramas. Dos son de ARP, y por tanto aparecerán o no dependiendo de cuándo se haga la captura. No son relevante. Eso nos deja una única trama UDP. Se trata de una trama exclusivamente de datos ya que en el protocolo UDP NO es orientado a conexión, y por tanto NO hay ni apertura ni cierres de conexiones
- Busca la trama que envía los datos. Toma una captura de wiresark en la que se puedan ver los datos enviados de PC2 a PC4
- Sol: La única trama UDP que hay es la de datos. Los datos enviados se muestran en el pantallazo anterior
- Repite el experimento, pero ahora el comando nc del terminal pc2 debe conectarse al puerto destino 8000. Comienza una captura nueva, en el fichero udp2-xxx.cap (donde xxx son tus inciiales), envía el mensaje "Probando" (desde pc2 a pc4) y cierra la captura. Abre el fichero con wiresark y envía un pantallazo con las tramas capturadas
- Sol: En PC4 seguimos teniendo el comando nc a la escucha:
pc4:~# nc -u -l 4002
UDP listen needs -p arg
pc4:~# nc -u -l -p 4002
Hola, soy agm
En r5 lanzamos la captura y en pc2 enviamos el nuevo mensaje:
pc2:~# nc -u -p 2002 40.40.40.204 8000
Probando
pc2:~#
Dejamos de capturar en r5
r5:~# tcpdump -i eth0 -s 0 -w /hosthome/udp2-agm.cap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
6 packets captured
6 packets received by filter
0 packets dropped by kernel
r5:~#
La nueva captura es la siguiente:
- Explica cada una de las tramas, y qué es lo que ha sucedido. ¿PC4 ha recibido el mensaje?
- Sol: Igual que antes, las tramas ARP las ignoramos (pueden aparecer o no, dependiendo de lo que hayamos hecho antes de tomar la captura). Nos aparece una trama UDP con los datos que van de PC2 a PC4 y una trama ICMP de PC2 a PC4 indicando que el destino NO es alcanzable. Por tanto, PC4 NO ha recibido el mensaje
El motivo por el que NO lo recibe es porque se envía a un puerto destino donde no hay ninguna aplicación escuchan (ya que nc está escuchando en el puerto 4002)
- Partimos del mismo escenario anterior. Queremos enviar el mismo mensaje desde pc2 a pc4: "Hola, soy xxx", donde xxx son tus iniciales. Pero ahora usaremos el protocolo TCP. Arranca el comando tcpdump en r5 para realizar una captura en su interfaz eth0. Guárdalo en elfichero tcp-xxx.cap, donde xxx son tus iniciales. Lanza tcpdump y toma una captura del terminal y adjúntala como resputa a esta pregunta
- Sol:
r5:~# tcpdump -i eth0 -s 0 -w /hosthome/tcp-agm.cap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
- Lanza nc en PC4 en modo escucha, desde un puerto que comience por el número 40 y termine con los dos primeros dígitos de tu DNI (igual que en el apartado de UDP). Desde pc2 lanza el comando nc en modo cliente un puerto origen que comience por 20 y termine con los primeros dígitos de tu DNI. Como puerto destino usa el mismo que has empleado en el comando usado en pc4. Una vez lanzamos ambos comandos, toma una captura de pantalla de los dos termines y adjúntalos como respuesta a esta pregunta. Todavía no hemos enviado el mensaje de texto
pc4:~# nc -l -p 4002
pc2:~# nc -p 2002 40.40.40.204 4002
- Desde pc2 escribe el mensaje "Hola, soy xxx", donde xxx son tus iniciales. Interrumpe el comando nc del ordenador pc2. Interrumpte la captura en r5, y adjunta pantallazos de los terminales de pc2 y pc4. ¿Se ha recibido en pc4 el mensaje enviado?
- Sol: Si. En pc4 se ha recibido el mensaje y el nc ha terminado
pc4:~# nc -l -p 4002
Hola, soy agm
pc4:~#
- Abre la captura con Wireshark. Saca un pantallazo de todas las tramas recibidas y adjúntalo como respuesta a esta pregunta
- Sol: En total se han capturado 14 tramas
- Indica de entre todas las tramas capturadas cuáles son de apertura de la conexión, y cuáles de cierre
- Sol: Descartando las tramas ARP, hay un total de 8 paquetes TCP. Como TCP es un protocolo orientado a la conexión, antes de empezar el intercambio de datos la conexión se debe abrir, y cerrarse al finalizar. Las tres tamas de apertaruda de conexión son la 1,2 y 3. Las tres para cerrar la transmisión son 12, 13 y 14
- Explica cada una de las tramas, y qué es lo que ha sucedido
- Sol: PC2 envía la trama 1 con destino PC4 para abrir la conexión. PC4 respondo con una trama de asentimiento ACK y PC2 responde nuevamente con un asentimiento de la recepción. La conexión está abierta. Ahora ya puede empezar el intercambio de datos. La trama 6 contiene el mensaje "Hola, Soy agm", que se envía de PC2 a PC4, y a continuación PC4 asiente los datos recibidos. Finalmente en la trama 12 PC2 envía un mensaje para cerrar la conexión. PC4 lo asiente y PC2 responde que lo ha recibido. La comunicación finaliza