TFC: add testing methodology
Signed-off-by: Nicolás Ortega Froysa <nicolas@ortegas.org>
This commit is contained in:
parent
136e9fa4d6
commit
8c95a52b71
Binary file not shown.
@ -4,6 +4,7 @@
|
||||
\usepackage{hyperref}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{subcaption}
|
||||
\usepackage{minted}
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage[
|
||||
backend=biber,
|
||||
@ -375,6 +376,72 @@ página está bloqueada y el administrador ha sido avisado.
|
||||
|
||||
\section{Pruebas y Despliegue}
|
||||
\subsection{Plan de Pruebas}
|
||||
|
||||
Una vez montada la solución, hemos de probar que funciona correctamente. Sería
|
||||
también conveniente hacerlo sin necesidad de visitar ninguna página {\it web}
|
||||
prohibida.
|
||||
|
||||
Lo primero sería verificar que se ha configurado correctamente nuestro servidor
|
||||
DHCP (normalmente en el propio {\it router}) para asignar nuestra solución como
|
||||
servidor DNS de la red. Para verificar esto nos conectamos a la red por medio de
|
||||
un ordenador ajeno y vemos cuál es el servidor DNS que nos ha dado.
|
||||
|
||||
Si nuestra máquina de pruebas es también un sistema de Debian GNU/Linux,
|
||||
entonces podemos asegurarnos de que hemos pedido información del servidor DHCP
|
||||
utilizando el comando siguiente:
|
||||
|
||||
\begin{minted}{console}
|
||||
# dhclient -v
|
||||
Internet Systems Consortium DHCP Client 4.4.1
|
||||
Copyright 2004-2018 Internet Systems Consortium.
|
||||
All rights reserved.
|
||||
For info, please visit https://www.isc.org/software/dhcp/
|
||||
|
||||
Listening on LPF/enp0s8/08:00:27:5f:48:3a
|
||||
Sending on LPF/enp0s8/08:00:27:5f:48:3a
|
||||
Listening on LPF/enp0s3/08:00:27:16:c6:22
|
||||
Sending on LPF/enp0s3/08:00:27:16:c6:22
|
||||
Sending on Socket/fallback
|
||||
DHCPREQUEST for 192.168.0.104 on enp0s8 to 255.255.255.255 port
|
||||
67 (xid=0x4dcd9939)
|
||||
DHCPREQUEST for 192.168.0.108 on enp0s3 to 255.255.255.255 port
|
||||
67 (xid=0x606bc4b3)
|
||||
DHCPACK of 192.168.0.104 from 192.168.0.1 (xid=0x3999cd4d)
|
||||
\end{minted}
|
||||
|
||||
Luego podemos verificar cuál es la dirección IP del servidor DNS configurado
|
||||
mirando el archivo {\tt /etc/resolv.conf}:
|
||||
|
||||
\begin{minted}{console}
|
||||
# cat /etc/resolv.conf
|
||||
nameserver 192.168.1.135
|
||||
\end{minted}
|
||||
|
||||
Si la dirección IP que muestra coincide con aquella que corresponde a nuestro
|
||||
servidor entonces sabemos que el servicio de DHCP se ha montado correctamente.
|
||||
|
||||
Ahora, para asegurarnos de que se ha configurado correctamente nuestro servidor
|
||||
también como filtro de DNS, tan sólo hace falta correr el comando {\tt
|
||||
nslookup}, que se puede encontrar en el paquete de Debian denominado {\tt
|
||||
bind9-dnsutils}. Con esto verificamos cuál sería la respuesta si alguien de la
|
||||
red quisiera acceder a una de las páginas prohibidas en nuestra red. Debería de
|
||||
devolver una respuesta de la forma siguiente, asumiendo que la dirección IP de
|
||||
nuestro servidor es {\tt 192.168.1.135}:
|
||||
|
||||
\begin{minted}{console}
|
||||
# nslookup porn.com
|
||||
Server: 192.168.1.135
|
||||
Address: 192.168.1.135#53
|
||||
|
||||
Non-authoritative answer:
|
||||
Name: porn.com
|
||||
Address: 192.168.1.135
|
||||
\end{minted}
|
||||
|
||||
Si la salida sale así, hemos podido verificar el funcionamiento correcto de
|
||||
nuestra solución, y sin conectarnos siquiera a un servidor que provee el
|
||||
contenido bloqueado.
|
||||
|
||||
\subsection{Manuales Técnicos y de Usuario}
|
||||
\subsection{Plan de Despliegue}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user