Práctica 3#

Equipo ARFA-FGFG-RCJE-ROFM#

  1. Arganis Ramírez Francisco - 108003620
  2. Ramón Cisneros Jorge - 308283961
  3. Flores García Fernando - 314107035
  4. Romo Olea Fhernanda - 314284286

Topología de RED empleada#

El diagrama siguiente corresponde a la topología que se emplea para que una máquina virtual con Debian, la cual provee los servicios de red NAT, DHCP y fordwarder DNS permita que otras máquinas virtuales, una CentOS-8 y otra Alpine tengan servicio de conexión a internet a través de ella dentro de un entorno de máquinas virtuales usando VirtualBox.

topología

Recuperado del sitio de redes: https://redes-ciencias-unam.gitlab.io/laboratorio/practica-3/img/diagrama_red.png

La máquina Debian se encuentra conectada por medio de su interfaz eth1 a un Router NAT, el cual le provee de servicio a internet, las otras máquinas no cuentan con una red NAT (en verde) que les permita esta conexión, por lo que la máquina de Debian figura también como "pasarela" (gateway) de conexión entre estas máquinas y los servicios de internet.

Para que las otras máquinas entablen conexión con la máquina de Debian se genera una red host-only (red de color azul), que puede ser vista como un switch virtual y permite las interconexiones entre los equipos. Este switch virtual es conectado a la interfaz eth0 de la máquina Debian con la dirección 192.168.56.254, y a esta misma interfaz pero de las máquinas CentOS con la dirección 192.168.56.100 y Alpine con la 192.168.56.200 la cual conforma una de las IP reservadas en DHCP.

Finalmente, el DHCP por defecto, es decir el de VirtualBox es deshabilitado para que las direcciones IP sean asignadas a las máquinas CentOS y Alpine a través del servicio que la máquina de Debian provee.

Nota: algunas diferencias en nuestra red con la red del diagrama son
- Las interfaces de red de la máquina Debian son enp0s3 para la red NAT y enp0s8 para la red host-only,
- La interfaz de red de la máquina CentOS es enp0s8 para la red host-only,
- La interfaz de red de la máquina Alpine es eth0 para la red host-only.
- La dirección IP de la interfaz para la máquina CentOS es asignada de forma dinámica por el DHCP y no necesariamente es 192.168.56.100.

Procedimiento de configuración de NAT#

  1. Se deshabilita el DHCP de la red host-only de VirtualBox NAT apagada
  2. Se configura la dirección IP estática en la interfaz host-only en este caso enp0s8 Se adjunta archivo: /etc/network/interfaces
  3. Se configura el sysctl, la configuración es realizada en el archivo /etc/sysctl.conf. La salida del comando:

/sbin/sysctl -p

net.ipv4.ip_forward = 1
  1. Tras la configuración de IPTABLES la salida del comando save es:

/sbin/iptables-save

# Generated by IPtables-save v1.8.7 on Fri May  6 12:27:32 2022
*filter
:INPUT ACCEPT [42327:84240204]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [32616:1468474]
-A FORWARD -i enp0s8 -o enp0s3 -j ACCEPT
-A FORWARD -i enp0s3 -o enp0s8 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Fri May  6 12:27:32 2022
# Generated by IPtables-save v1.8.7 on Fri May  6 12:27:32 2022
*nat
:PREROUTING ACCEPT [2:1152]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [456:32715]
:POSTROUTING ACCEPT [15:1117]
-A POSTROUTING -o enp0s3 -j MASQUERADE
COMMIT
# Completed on Fri May  6 12:27:32 2022

El archivo con la configuración persistente se puede encontrar en: /etc/iptables/rules.v4

Procedimiento de la configuración del forwarder DNS#

  1. Modificamos el archivo /etc/dnsmasq.conf agreando las líneas
resolv-file=/etc/resolv-upstream.conf
address=/gateway.local/192.168.56.254
address=/dns.local/192.168.56.254
interface=enp0s8
bind-interfaces
  1. Se generó el archivo /etc/resolv-upstream.conf con las direcciones IP de servidores DNS públicos.
  2. Finalmente se configura la resolución local del DNS modificando el archivo /etc/resolv.conf con
nameserver 127.0.0.1
  1. Se anexan pruebas de la verificación de las resoluciones DNS:

dig google.com @127.0.0.1

; <<>> DiG 9.16.22-Debian <<>> google.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10167
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.   IN A

;; ANSWER SECTION:
google.com.  124 IN A 142.250.113.100
google.com.  124 IN A 142.250.113.139
google.com.  124 IN A 142.250.113.102
google.com.  124 IN A 142.250.113.113
google.com.  124 IN A 142.250.113.138
google.com.  124 IN A 142.250.113.101

;; Query time: 36 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri May 06 12:30:11 CDT 2022
;; MSG SIZE  rcvd: 135

dig google.com @127.0.0.1 dig 1

dig gateway.local @127.0.0.1

; <<>> DiG 9.16.22-Debian <<>> gateway.local @127.0.0.1
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31104
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gateway.local.   IN A

;; ANSWER SECTION:
gateway.local.  0 IN A 192.168.56.254

;; Query time: 0 msec

dig gateway.local @127.0.0.1 dig 2

dig google.com @1.1.1.1

; <<>> DiG 9.16.22-Debian <<>> google.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54583
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.   IN A

;; ANSWER SECTION:
google.com.  293 IN A 142.250.138.101
google.com.  293 IN A 142.250.138.100
google.com.  293 IN A 142.250.138.139
google.com.  293 IN A 142.250.138.113
google.com.  293 IN A 142.250.138.102
google.com.  293 IN A 142.250.138.138

;; Query time: 36 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri May 06 12:37:38 CDT 2022
;; MSG SIZE  rcvd: 135

dig google.com @1.1.1.1 dig 3

dig gateway.local @1.1.1.1

; <<>> DiG 9.16.22-Debian <<>> gateway.local @1.1.1.1
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gateway.local.   IN A

;; AUTHORITY SECTION:
.   86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022050601 1800 900 604800 86400

;; Query time: 36 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri May 06 12:38:46 CDT 2022
;; MSG SIZE  rcvd: 117

dig gateway.local @1.1.1.1 dig 4

Procedimiento del servidor DHCP#

  1. Se modifica la configuración del archivo /etc/dhcp/dhcpd.conf
  2. Especificamos la interfaz de red donde se brindará el servicio de DHCP en el archivo /etc/default/isc-dhcp-server

Procedimiento para reservar una dirección IP en el servidor DHCP#

El procedimiento se realiza en el archivo de configuración /etc/dhcp/dhcpd.conf, las sección a añadir para tener esta funcionalidad es:

subnet 192.168.56.0 netmask 255.255.255.0 {

    range 192.168.56.100  192.168.56.200;
    option routers 192.168.56.254;

    host alpine {
        hardware ethernet 08:00:27:56:34:68;
        fixed-address     192.168.56.200;
    }
}

Donde lo que se indica con estas instrucciones es que en la subred host-only el servidor DHCP va a otorgar direcciones IP del rango 192.168.56.100 a la 192.168.56.200, y que especíificamente la IP 192.168.56.200 se encuentra reservada para la direción MAC 08:00:27:56:34:68, que corresponde a la máquina Alpine.

Las líneas que especifican que se va a reservar la dirección son las dos que se encuentran dentro de la sección llamada host alpine{}. Se debe ingresar la dirección MAC de forma manual de aquel equipo que se desee tenga una IP reservada.

Explicar el contenido del archivo leases del servidor y cliente DHCP#

Un ejemplo del contenido de este archivo es:

# The format of this file is documented in the dhcp.leases(5) manual page.
# This lease file was written by isc-dhcp-4.4.1

# authoring-byte-order entry is generated, DO NOT DELETE
authoring-byte-order little-endian;

server-duid "\000\001\000\0018=\035\231\010\000'\3026\347";

lease 192.168.56.103 {
    starts 4 2022/05/05 14:34:37;
    ends 4 2022/05/05 14:44:37;
    cltt 4 2022/05/05 14:34:37;
    binding state active;
    next binding state free;
    rewind binding state free;
    hardware ethernet 08:00:27:14:d6:33;
    client-hostname "centos-8";
}

Almacena el registro de las direcciones que han sido solicitadas por los equipos de la red al servidor DHCP. Seguido de la palabra lease aparece la IP que el servidor DHCP otorga a determinado equipo, las primeras dos líneas tras esta declaración indican a qué hora se le otorgó esta IP y a qué hora expira. También se indica a qué hora debe volver a solicitarse.

Entre otras líneas que indican que el servicio se encuentra activo y también nos indica la dirección MAC asociada al equipo que tiene la IP que engloba esta sección, así como su nombre de cliente con el que se le conoce a este equipo.

Por ejemplo, en el archivo anterior se otorgó la IP 192.168.56.103 al equipo CentOS con dirección MAC 08:00:27:14:d6:33 a las 2:34 y el lease expira en 10 minutos, a las 2:44.

La línea authoring-byte-order little-endian indica el formato de extremidad con el que se debe leer el orden de los bytes en el archivo de leases. Si no está presente esta línea, por defecto, los bytes se toman en el mismo formato de extremidad en que está configurado el servidor que lee el archivo.

La línea server-duid "\000\001\000\0018=\035\231\010\000'\3026\347"; indica el DUID del servidor. En la especificación del protocolo DHCP para IPv6, RFC3315, se establece que el DUID es un identificador único para cada participante DHCP. Todos los clientes y servidores tienen uno asignado. Los servidores usan el DUID para identificar clientes para la selección de parámetros de configuración y en la asociación de identidad con los clientes. Los clientes usan el DUID para identificar un servidor en los mensajes. Esto solo aplica para DHCPv6 y se puede omitir si el servidor solo otorga direcciones IPv4.

Explicar detalladamente cómo es que el cliente obtiene una dirección IP del servidor DHCP#

El servidor DHCP nos ayuda a no tener que configurar de manera manual cada una de las IP de los equipos presentes en nuestra red, ésto lo hace otorgándole direcciones IP de un pool a aquellos equipos que por medio del protocolo DHCP soliciten una IP.

  1. El cliente manda un mensaje llamado Discovey el cual se envía por broadcast ya que no conocemos el destino en un inicio, ya que podemos tener varios servidores DHCP. Espera la respuesta del servidor a través del puerto 67.
  2. El servidor responde al cliente directamente una vez que recibe el primer mensaje por medio de una respuesta que lleva el nombre de Offer, lo que hace el servidor es buscar en su pool de direcciones alguna dirección que pueda asignarle al cliente y se la manda junto con los parámetros del leases (tiempo que te prestan la IP).
  3. El cliente tras recibir la o las IPs que se le pueden asignar, el cliente se decide por una y le manda por broadcast a toda la red aquella IP por la que se ha decidido. A este mensaje se le llama Request.
  4. Cuando el servidor recibe aquel mensaje de Request entonces verifica si no le ha dado la IP a otro equipo en lo que el cliente le respondía, en caso de no ser así, el servidor le notifica al cliente que a partir de ese momento le va a conocer por esa IP en la red enviándole un mensaje llamado Acknowledge. En caso que el cliente haya rechazado la IP, el servidor sabe que la IP sigue disponible en el pool. O bien, si la IP ya la tomó otro cliente, el servidor le notifica al cliente original que la IP ya no está disponible, por lo que éste último debe comenzar una nueva petición.

Wireshark-DHCP

Qué ventajas y desventajas existen al tener un forwarder DNS en la red local#

Entre las principales ventajas es que las consultas son mucho más rápidas, y que podemos almacenar dentro del caché aquellas peticiones anteriormente resueltas para que las páginas solicitadas abran mucho más rápido. Entre las desventajas se incluye que se requiere realizar la configuración adicional de forma manual del servicio dnsmasq (en nuestro caso en la máquina Debian) y que el caché del DNS forwarder es suceptible a un ataque de DNS spoofing, lo cual puede comprometer la seguridad de todos los equipos de la red local.

Explicar detalladamente cómo es que una petición se envía desde el cliente hasta su destino fuera de la red host-only#

Para esta explicación nos apoyamos en el diagrama:

topología

Cuando alguna de las máquinas CentOS o Alpine desean realizar una petición fuera de la red host-only (azul) utilizan el gateway que tenemos configurado para estas máquinas.

Este gateway en el diagrama, corresponde a la IP 192.168.56.254, al recibir el equipo Debian la petición, si éste ve que la petición no va dirigida hacia él, simplemente permite el tránsito del paquete a la red NAT 10.0.2.0. Esto debido a la configuración dentro del archivo /etc/sysctl.conf, ya que activamos la opción:

net.ipv4.ip_forward = 1

Que permite el flujo de tráfico si la petición no le corresponde.

Cuando los paquetes con dirección IP de origen 192.168.56.X provenientes de la red host-only llegan al equipo Debian y están dirigidos al un destino externo, el servicio NAT los reenvía como nuevos paquetes con dirección de origen 10.0.2.15. Estos paquetes que salen por la red NAT ocultan la información de la red host-only a los host externos, que solo ven la dirección IP pública. Si hay una respuesta externa, se debe dirigir a la dirección 10.0.2.15 para que, cuando alcance al equipo Debian, el servicio NAT construya nuevos paquetes con las direcciones IP originales y los mande por la red host-only al equipo correspondiente, ya sea la máquina CentOS o Alpine. El servicio NAT puede distinguir a qué destino en la red host-only enviar los paquetes entrantes dirigidos a 10.0.2.15, por ejemplo, al mantener un mapa de pares de dirección IP y número de puerto de los paquetes redirigidos.

Conclusiones sobre las capturas de tráfico de red#

  • ¿Hay alguna diferencia en el tráfico de las capturas de red?

El contenido de las capturas en la interfaz host-only es idéntico, tanto para la máquina de Debian como para la máquina CentOS. Con ambos equipos se capturaron exactamente los mismos 51 paquetes, siendo la única diferencia los tiempos. Esto tiene sentido pues ambas capturas fueron realizadas en una interfaz conectada a la misma red, por lo que se puede ver el tráfico en esa red.

En estas capturas se pueden apreciar los mensajes de ARP para determinar las direcciones físicas de los equipos conectados en la red host-only después de que se limpiaran las tablas ARP de las máquinas Debian, CentOS y Alpine. También, se observan los paquetes de DHCP para asignar las direcciones IP 192.168.56.106 a la máquina CentOS y la dirección IP reservada 192.168.56.200 a la máquina ALpine. Los paquetes número 20 a 23 de la captura son la consulta DNS para example.com de la máquina CentOS y la respuesta del DNS forwarder en 192.168.56.254 (la máquina Debian). Los paquetes número 38 a 41 de la misma captura son la misma consulta y respuesta pero para la máquina Alpine. El resto de los paquetes, del protocolo ICMP, son el resultado del ping hecho en las máquinas CentOS y Alpine a example.com.

Por otro lado, con un total de 18 paquetes, la captura en la interfaz NAT en la máquina Debian es muy diferente. Hay dos paquetes del protocolo ARP para resolver la dirección de la interfaz en la red NAT y los otros paquetes son únicamente la salida de los ping a internet, pues están dirigidos a example.com en la dirección IP 93.184.216.34, y las respuestas a esos ping. Nótese que en la captura en la red NAT no hay paquetes del protocolo DNS. Esto es porque las consultas DNS no salen a internet, sino que se resuleven directamente en la red host-only ya que el DNS forwarder ya tenía en caché la dirección de example.com al momento de capturar el tráfico.

  • ¿Qué parte de tráfico de DHCP es broadcast y unicast?

Como se observa en los cuatro paquetes, número 13 a 16 en la captura centos-hostonly.pcap, que corresponden a ciclo completo del protocolo DHCP, los mensajes del cliente de Discover y Request son broadcast ya que tienen destino IP 255.255.255.255 y MAC ff:ff:ff:ff:ff:ff y deben poder alcanzar a todos los servidores DHCP en la red. Por otro lado, los mensajes del servidor de Offer y Acknowledge son unicast dirigidos a la dirección IP propuesta y la dirección MAC del cliente.

  • ¿Cómo es que funciona ARP?

Para que alguna de las máquinas pueda entablar comunicación con otra, deben hacer uso de la red host-only, si la red acaba de iniciarse (o si se limpió la tabla ARP), los dispositivos no tienen información sobre cuál es la dirección física de destino que, por ejemplo la máquina de CentOS debe seguir para poder contactar a la máquina Alpine.

La máquina CentOS envía un paquete por broadcast que indica que desea comunicarse con la máquina que tenga determina IP, en este caso 192.168.56.200 (máquina con Alpine). Dentro del paquete incluye también su IP (192.168.56.100).

Una vez que la trama alcanza al equipo Alpine, al éste reconocer su IP, le responde por unicast al equipo CentOS que él es el equipo que tiene la IP que se encuentra solicitando y le envía junto con este mensaje su dirección física también. Las direcciones IP y MAC se guardan en una entrada la tabla ARP de manera que para nuevos mensajes destinados a la máquina Alpine ya se sepa a dónde enviarlos.

  • ¿Cómo es que llega una petición y respuesta de PING desde la máquina CentOS hasta un servidor en Internet?

Se considera el ejemplo del ping a example.com que se puede ver en los paquetes ICMP en las capturas. Primero, la máquina CentOS manda un paquete con origen IP 192.168.56.106 y destino IP 93.184.216.34. Este paquete va dirigida a su gateway, que en este caso es la dirección MAC de la interfaz host-only de la máquina Debian. Cuando llega, el servicio NAT en la máquina Debian verifica que el paquete no está dirigido a ella, registra la dirección IP de origen y el identificador 0003 del protocolo ICMP y construye un nuevo paquete, pero esta vez con origen IP 10.0.2.15 y destino IP 93.184.216.34. La máquina Debian ahora manda este nuevo paquete a través de su interfaz NAT para que llegue a example.com. Cuando la respuesta, con origen IP 93.184.216.34 y destino IP 10.0.2.15, es recibida en la máquina Debian, nuevamente verifica que no va destina a ella, pues el destino es la IP pública 10.0.2.15. Revisa que el paquete del protcolo ICMP con identificador 0003 y entonces sabe que debe reenviarlo a la dirección interna 192.168.56.106. Finalmente construye un nuevo paquete con origen IP 93.184.216.34 y destino IP 192.168.56.106 y lo envía por su interfaz de la red host-only hacia la máquina CentOS.

Se puede notar en la captura de la red NAT, que las respuestas del ping a example.com van todas dirigidas a la dirección pública 10.0.2.15, pero la mitad son para la máquina CentOS y la otra mitad son para la máquina Alpine. Sin embargo, como se ve en la captura de la red host-only, los paquetes ICMP provenientes de la máquina CentOS tiene identificador 0003 y los provenientes de la máquina Alpine tienen identificador 0713. Esto permite que el servicio NAT pueda distinguir a qué equipos de la red host-only van dirigidos. Si no fuesen paquetes del protocolo ICMP, se podría usar la combinación de la dirección IP y el número de puerto para hacer esta distinción.

Descripción de los archivos incluidos#

Configuración y pruebas de conectividad en Debian#

Archivo Descripción
debian-arp-rutas.txt Tablas ARP y de rutas
salida-comandos-debian.txt Comandos de configuración y pruebas de conectividad
interfaces Archivo /etc/network/interfaces
sysctl.conf Archivo /etc/sysctl.conf
rules.v4 Archivo /etc/iptables/rules.v4
dhcpd.conf Archivo /etc/dhcp/dhcpd.conf
isc-dhcp-server Archivo /etc/default/isc-dhcp-server
dhcpd.leases Archivo /var/lib/dhcp/dhcpd.leases
dnsmasq.conf Archivo /etc/dnsmasq.conf
resolv-upstream.conf Archivo /etc/resolv-upstream.conf
resolv.conf Archivo /etc/resolv.conf

Configuración y pruebas de conectividad en CentOS#

Archivo Descripción
centos-arp-rutas.txt Tablas ARP y de rutas
salida-comandos-centos.txt Comandos de configuración y pruebas de conectividad
resolv.conf Archivo /etc/resolv.conf
internal-16ceb844-b7f2-4b0f-b842-0ed76de92447-enp0s8.lease Archivo /var/lib/NetworkManager/internal-16ceb844-b7f2-4b0f-b842-0ed76de92447-enp0s8.lease

Configuración y pruebas de conectividad en Alpine#

Archivo Descripción
alpine-arp-rutas.txt Tablas ARP y de rutas
salida-comandos-alpine.txt Comandos de configuración y pruebas de conectividad

Capturas de tráfico#

Archivo Descripción
debian-hostonly.pcap Captura de ARP, DHCP, DNS e ICMP para la interfaz host-only de Debian
debian-nat.pcap Captura de ARP, DHCP, DNS e ICMP para la interfaz NAT de Debian
centos-hostonly.pcap Captura de ARP, DHCP, DNS e ICMP para la interfaz host-only de CentOS

Configuración de VirtualBox#

Archivo Descripción
vboxmanage.txt Comandos de VBoxManage