Tarea 3#

Integrantes:

  • Aleman Galicia Diego Leonardo
  • Carlos Cabrera Ramirez
  • Paredes Sanchez Jacqueline
  • Saavedra Escalona Braulio Ruben

Solicitud de nueva direccion IP.#

Primero veremos cual es el nombre de la interfaz que estaremos usando, asi como la direccion IP que tenemos actualmente asignada:

$ ip a  // Nos muestra los detalles de nuestras interfaces de red.
...
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d8:12:65:5e:2f:9f brd ff:ff:ff:ff:ff:ff
    inet 192.168.15.18/24 brd 192.168.15.255 scope global dynamic noprefixroute wlan0
       valid_lft 85183sec preferred_lft 85183sec
    inet6 fe80::c687:7add:33ee:fdff/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Usando el comando dhclient -r wlan0 para luego volver a usar ip a

2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d8:12:65:5e:2f:9f brd ff:ff:ff:ff:ff:ff
    inet 192.168.15.18/24 brd 192.168.15.255 scope global dynamic noprefixroute wlan0
       valid_lft 84770sec preferred_lft 84770sec
    inet6 fe80::c687:7add:33ee:fdff/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Como nota, en la distro donde hago esto, el servicio que se encarga de pedir al servidor DHCP una direccion IP siempre intentara obtener de nuevo la direccion que ya se estaba usando, por ende el obtener una nueva direccion consiste en borrar el lease, y apagar y prender el proceso.

Ahora obtenemos la direccion IPv4 e IPv6 del ruteador:

$ ip route show
default via 192.168.15.1 dev wlan0 proto dhcp metric 600 
192.168.15.0/24 dev wlan0 proto kernel scope link src 192.168.15.18 metric 600 
$ ip -6 rout show
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 1024 pref medium

Captura de trafico#

Tenemos identificada que la interfaz wlan0 es desde nos conectamos a internet en esta maquina fisica.

Pruebas de conectividad.#

Capa 2 - Enlace#

En nuestra captura de trafico podemos ver como nuestro equipo envia a BROADCAST paquetes ARP, donde "pregunta" a otros equipos quien tiene alguna direccion IP (Who has 192.168.15.X?) y pide que se le comunique a la direccion IP de nuestro equipo. Si existe algun equipo con esa direccion IP asignada este le manda un paquete ARP "diciendo" a cual Direccion MAC esta asignada la direccion IP pedida. Podemos ver los equipos que respondieron con el comando arp -an:

$ arp -an
? (192.168.15.17) at ce:ca:1c:e1:95:1b [ether] on wlan0
? (192.168.15.7) at 30:ff:f6:85:24:fa [ether] on wlan0
? (192.168.15.4) at 30:ff:f6:82:47:d2 [ether] on wlan0
? (192.168.15.10) at 22:a2:c7:40:bb:20 [ether] on wlan0
? (192.168.15.12) at 44:07:0b:af:b4:ba [ether] on wlan0
? (192.168.15.1) at 2a:02:71:87:54:72 [ether] on wlan0
? (192.168.15.9) at 36:96:61:74:69:8f [ether] on wlan0
? (192.168.15.14) at 10:e9:53:b4:09:3d [ether] on wlan0
? (192.168.15.3) at 64:52:99:d5:1a:5e [ether] on wlan0
? (192.168.15.2) at 94:b9:7e:04:91:f5 [ether] on wlan0

Capa 3 - Red#

En nuestra captura de trafico podemos ver como nuestro equipo manda paquetes ICMP request, las cuales al alcanzar el servidor seran regresados como paquetes ICMP reply, los cuales le daran certeza a nuestro equipo de que existe una conexion entre el y el servidor. De igual manera podemos observar que se dan 10 de cada uno (10 de request, 10 reply).

Tambien es posible observar como al hacer pings a servicios externos a nuestra red local primero se hara un DNS request para que nuestro router tenga certeza a cual direccion IP es a la que le mandara el paquete ICMP.

Tambien podemos observar que al hacer traceroute nuestro equipo de igual manera mandara paquetes ICMP, los cuales tendran un TTL (time-to-live) fijo (y creciente por cada nuevo ICMP) los cuales haran posible el calculo de la ruta entre los routers que toman nuestros paquetes para llegar al host requerido.

(En mi equipo o red no ha sido posible hacer pings o traceroutes con IPv6)

Capa 4 - Transporte#

Primero vemos que en nuestra captura de datos no exitosa como nos intentamos conectar usando netcat a algun puerto de alguna maquina (en particular yo intente conectarme a esos puertos en mi router sabiendo que no me lo iba a permitir), nuestra maquina envia un paquete TCP con la bandera de SYN para empezar un three-way handshake con la maquina receptora, la cual al no permitir conexiones al puerto en cuestion (o tener cerrado el puerto) nos envia de igual manera un paquete TCP, solo que con las banderas de RST, ACK, dandonos a entender que la conexion fue recibida, pero por alguna razon no proseguira, esto indicado por la bandera RST, que basicamente reinicia la conexion y termina el handshake

De igual manera en nuestra captura de datos exitosa podemos observar que se mandan paquetes TCP, dentro de los cuales podemos observar que se completa una three-way handshake con la serie de paquetes SYN; SIN,ACK; ACK, los cuales nos indican que la conexion fue exitosa y pudimos conectarnos al puerto buscado.

(Nota, en algunos casos hay paquetes DNS, eso solo fue mi conexion de internet tanto con Spotify o con los repositios de mi distro checando si existen actualizaciones, una disculpa de antemano)

Capa 7 - Aplicacion#

En nuestra captura de trafico podemos ver como nuestro equipo hace resoluciones de DNS tipo A y AAAA a los servidores de www.example.com a traves de 1.1.1.1 las cuales esta misma direccion las responde. Luego haremos peticiones HTTP, cuyas peticiones estaran dadas en TCP. De igual manera con HTTPS, las cuales seran dadas con TCP ademas tendran un saludo TLS que anadira una capa de seguridad a los datos enviados y recibidos.

Ademas usamos el filtro 'host (www.example.com or 1.1.1.1 or 2606:4700:4700::1111)' el cual solo permite capturar trafico que proviene de esos hosts.