Supuesto de Entorno de Trabajo en SXE. Preparación de escenarios

Introducción

Plantearemos la instalación de un ERP, concretamente Odoo, en el entorno de una empresa

(PYME) en dos supuestos escenarios: ERP instalado en un Windows Server 2012 con equipos

clientes Ubuntu y Windows que a su vez se conectan a Internet a través del Servidor y la misma

situación pero un escenario donde el Servidor es Debian. En ambos a su vez instalaremos un AD

(Directorio Activo para gestión de usuarios de la empresa)

Plantemiento de los escenarios

1. El servidor es un equipo bajo Debian

Escenario 1

2. El servidor es un Windows 2012 Server

Escenario 2

1

A. Comenzamos configurando un Servidor Debian en una MV

En lo sucesivo DebServer, al cual añadiremos dos tarjetas, una en modo NAT y DHCP, y otra en

modo Red Interna.

Datos:

nombre: debserver

usuario: admindebian

pass: abc123.

En el fichero /etc/network/interfaces añadiremos las siguientes líneas para configurar la tarjeta en

Red Interna eth1. La tarjeta en modo NAT eth0 no hay que tocarla.

A continuación reiniciamos el servicio con:

#service networking restart

B. Configuramos un servidor DHCP cuya función será facilitar la configuración de red de los

equipos clientes sirviéndoles un rango de IP’s

#apt-get install isc-dhcp-server

Editamos el fichero /etc/dhcp/dhcpd.conf1 y lo modificamos según la imagen siguiente:

#nano /etc/dhcp/dhcpd.conf

1Algunos gráficos están tomados de Curso sobre Instalaciones Desatendidas del profesor Daniel Medina.

2

Reiniciamos el servidor DHCP:

#service isc-dhcp-server restart

Explicación. Este servidor servirá IP’s a los clientes desde el 10.0.0.50 hasta 10.0.0.100, para unos

50 clientes. Si en nuestro empresa hubiese más necesidad, pues nada, se aumentaría el rango. El

valor 10.0.0.1 es la IP de la tarjeta eth1 que permitirá la salida a Internet a los equipos clientes.

Para finalizar necesitamos enrutar la salida de eth1 a eth0 de Debserver para dar salida a Internet.

Para ello modificamos el fichero /etc/rc.local añadiento las siguientes líneas.

echo 1 > /proc/sys/net/ipv4/ip_forward

otra línea

/sbin/iptables – P FORWARD ACCEPT

/sbin/iptables –table nat -A POSTROUTING -o eth0 -j MASQUERADE

Solo nos que reiniciar Debserver o bien ejecutar el fichero con el comando:

#sh /etc/rc.local

Solo nos queda probar que todo funciona y para ello vamos a montar dos MV una con Windows

7/10 y otra con Ubuntu en modo Red Interna. Las podemos llamar Win1 y Ubu1. Una vez iniciadas

debemos comprobar dos cosas:

1. Que toman una IP del servidor DHCP (ipconfig o ifconfig)

2. Que tienen salida a Internet

C. Datos de las máquinas cliente:

Ubuntu:

nombre: ubucliente

usuario: adminubu

pass: abc123.

Red. RED INTERNA

3

Windows:

nombre: wincliente

usuario: adminwin

pass: abc123.

Red. RED INTERNA

En la siguiente imagen vemos la configuración de Red de Ubuntu donde se observan los datos que

le proporciona el servidor DHCP y la conexión a Internet del enrutamiento. Se conecta a Internet y

toma una IP del servidor DHCP:

Comprobamos que tiene acceso a la red externa.

D. Instalamos el servidor Windows 2012 Server

En lo sucesivo WinServer. Dos tarjetas una en modo NAT y otra en modo Red Interna.

4

Datos:

nombre: winservser

usuario: administrador

pass: abc123.

Red. RED INTERNA

Los datos de la tarjeta de Red Interna:

IP: 10.0.0.10

Netmask: 255.0.0.0

DNS: 8.8.8.8

Para identificar “quien es quien” en las dos tarjetas de Red, la NAT aparecere como RED, le

cambiamos el nombre y le ponemos INTERNET. La tarjeta de Red Interna aparece como RED NO

IDENTIFICADA, le cambiaremos el nombre a RED INTERNA.

E. Configuración del servidor de enrutamiento y del servidor DHCP en Windows Server

Datos:

a. Instalación basada en características o roles

b. Nombre del Servidor DHCP: winserver

c. Intervalo a distrubuir: 10.0.0.50 – 10.0.0.100 Intervalo a excluir: Ninguno

d. IP enrutador: 10.0.0.10 (configuramos el enrutador también en Windows Server)

Probamos si funciona con los equipos ubucliente y wincliente

5

Seguimos con el enrutador en Windows Server.

6

Finalmente comprobamos que hay salida a Internet desde los equipos clientes.

F. Configuración de Windows Server como controlador de dominio AD (Escenario 2)

Un Directorio Activo podemos decir de forma sencilla que es un “un servicio establecido en uno o

varios servidores en donde se crean objetos tales como usuarios, equipos o grupos, con el

objetivo de administrar los inicios de sesión en los equipos conectados a la red, así como también

la administración de políticas en toda la red ”

Empecemos configurando el AD en Server 2012. Solo indicaremos las imágenes más importantes.

7

Y reiniciamos y lanzamos el elemento de administración del Directorio Activo que nos permite dar

altas, bajas o modificaciones de los diferentes objetos a administrar. Desde la opción herramientas

en la parte superior derecha de Windows Server podemos acceder a los diferentes elementos o

útiles de administración de los servidores de la familia Microsfot.

8

Nota.- En propiedades del ámbito DHCP del Server, hay que asignar algunos valores para que éstos se transmitan a

los clientes:

3. Puerta de Enlace: La IP del router 10.0.0.10

6. DNS servers: 10.0.0.10

15. Domain name: MIDOMINIO.LOCAL

Vamos a crear nuestro primer clon enlazado para añadir un equipo al dominio de Windows Server.

Arrancamos el nuevo clon y pasamos a agregarlo al domino. Para ello en el equipo cliente:

Equipo → (botón derecho) Propiedades → Cambiar configuración

9

Si falla ver configuración de DNS en tarjeta de red del cliente y añadir como DNS el Server 2012.

Para añadir un equipo Ubuntu a un AD bajo Windows Server creamos un clon enlazado de la

plantilla de Ubuntu.

Como en nuestro en el caso que nuestro dominio tiene el sufijo .local, se debe cambiar, el orden

de resolución de nombres en el archivo /etc/nsswitch.conf de manera que después de files, se

utilice el servicio dns.

El siguiente paso, será bajar la versión Open del PBIS (antiguo likewise) en el siguiente enlace2

PBIS es un programa que permite a una máquina UNIX/Linux unirse a un dominio Microsfot y

autenticarnos en esa máquina con nuestras credenciales de AD (Active Directory).

Tras descargar la versión para 64 bits le damos permiso de ejecución al script y lo ejecutamos:

$sudo chmod +x pbis-open-8.2.2.2993.linux.x86.deb.sh

$sudo ./pbis-open-8.2.2.2993.linux.x86.deb.sh

Si falla la instalación probamos previamente a desinstalar el servico avahi

$sudo apt-get remove avahi-daemon

2Imágenes tomadas de la web waytoit.wordpress.com

10

Contestamos afirmativamente a las dos preguntas que nos hace durante el proceso de instalación

y ya estaremos listos para agregar nuestro cliente al dominio y hace falta poner el nombre de

usuario con el que queremos agregar el dominio.

$sudo domainjoin-cli join –disable ssh MIEMPRESA.LOCAL administrador

Una vez entrada la password si todo ha ido bien, nos indica con un mensaje que se ha agregado

con éxito al dominio:

Podemos comprobar en el DC que efectivamente, se ha agregado la máquina con éxito:

El siguiente paso es configurar el cliente Ubuntu para que funcione correctamente el inicio de

sesión de los usuarios del dominio. En primer lugar ejecutaremos como root (o mediante sudo)

las siguientes configuraciones

Especialmente importante el detalle de añadir el símbolo ^ en lugar del espacio al definir el grupo

de usuarios que podrá iniciar sesión. Es conveniente utilizar “Usuarios^del^dominio” en vez del

término en inglés.

11

A continuación, editaremos el archivo /etc/pam.d/common-session y modificaremos la línea

correspondiente a session pam_lsass.so

Llegados a este punto, previo al último paso, realizaremos unas modificaciones que no se reflejan

en how-tos sobre el tema pero que nos evitan el que pueda producirse un error que consiste en

que el usuario no pueda acceder al dominio dando un mensaje de contraseña inválida y se deben a

un error de configuración del servicio lwsmd. Para ello debemos seguir los siguientes pasos:

$sudo nano /lib/systemd/system/lwsmd.service

A continuación añadimos la línea marcada en negrita:

[Unit]Description=BeyondTrust PBIS Service Manager

After=network.target

[Service]

Type=forking

EnvironmentFile=/opt/pbis/libexec/init-base.sh

ExecStart=/opt/pbis/sbin/lwsmd –start-as-daemon

ExecReload=/opt/pbis/bin/lwsm refresh

ExecStop=/opt/pbis/bin/lwsm shutdown

# We want systemd to give lwsmd some time to finish gracefully, but still want

# it to kill lwsmd after TimeoutStopSec if something went wrong during the

# graceful stop. Normally, Systemd sends SIGTERM signal right after the

# ExecStop, which would kill lwsmd. We are sending useless SIGCONT here to give

# lwsmd time to finish.

KillSignal=SIGCONT

PrivateTmp=true

[Install]

WantedBy=multi-user.target nss-lookup.target

12

Creamos los enlaces al servicio y lo lanzamos:

$cd /etc/systemd/system

$sudo ln -s /lib/systemd/system/lwsmd.service

$sudo systemctl enable lwsmd.service

$sudo service lwsmd start

El último paso, es permitir que en la pantalla de inicio se permita iniciar sesión a cualquier usuario.

Para ello debemos editar la configuración de lightdm, que en esta versión ya no se encuentra

en /etc/ sino en:

/usr/share/lightdm/lightdm.conf.d/50-unity-greeter.conf

Añadiremos la siguiente línea:

greeter-show-manual-login=true

Ahora simplemente reiniciamos Ubuntu. Si nos apareciese un error en el arranque, deberemos

entrar en mode recovery y comprobar las dos últimas configuraciones explicadas. Si todo está

correcto, nos aparecerá la pantalla de inicio y podremos iniciar con un usuario del dominio:

Solo nos quedan algunos ajustes finales.

Si entramos en nuestro Ubuntu recién agregado al dominio con la cuenta del administrador del

dominio (administrator) y probamos de realizar una tarea con permisos elevados (sudo),

recibiremos el mensaje que el usuario no pertenece al grupo de sudoers.

Para conseguir este propósito, podemos hacer dos acciones diferentes:

• agregar un usuario directamente al grupo de sudo o

• crear un grupo de administradores de equipos linux y darle a este grupo capacidad de

ejecutar con privilegios elevados.

13

Si elegimos la primera opción, simplemente, deberemos validarnos en la máquina Linux con el

usuario local, en nuestro caso ubuadmin, (que sí pertenece al grupo sudo) y editar el archivo

/etc/group, añadiendo un usuario que pertenezca al dominio al grupo sudo. No hace falta indicar

que dicho usuario es del dominio, porque cuando configuramos el sistema en la primera parte ya

indicamos que asume el prefijo del dominio por defecto (AssumeDefaultDomain true).

Obviamente, podríamos haber añadido cualquier otro usuario del dominio como el administrator.

Si ahora ejecutamos el comando id veremos como este usuario, en este caso user1, además de ser

miembro del grupo Domain Users, es miembro del grupo sudo. Además podemos comprobar que

puede ejecutar comandos elevados.

La segunda opción, que es la que viene comentada en la guía de PowerBroker (pbis), consiste en

crear un grupo de administradores Linux en el Active Directory. Agregaremos a los

administradores del dominio a este grupo.

A continuación, en el cliente y con una cuenta que tenga derechos administrativos, ejecutamos

visudo y añadimos este grupo al final del archivo (documentamos la línea como buena práctica).

14

Comprobamos ahora entrando como administrator que se ha actualizado correctamente la

configuración.

La cuestión es la siguiente: “¿interesa que los usuarios del dominio que utilicen Ubuntu tengas

derechos administrativos sobre el equipo cliente?” Eso es algo que debería determinar el

administrador del sistema informático de la empresa según la lógica negocio de la empresa.

ACTIVIDAD. Instalación de Odoo en el servidor Windows y comprobación de acceso desde los

clientes.

G. Configuración de Debian-Server como controlador de dominio AD (Escenario 1)

En ambos casos el dominio será local con el nombre misapellidos.local. Siempre que sea posible

“desconectaremos” la tarjeta en NAT, especialmente cuando configuremos el servidor dns.

Instalamos el servicio ntp

# apt-get install ntp

15

A continuación procederemos a instalar Samba4. Aunque se puede descargar como paquete ya

construido mediante apt-get, la página de Samba recomienda bajar las fuentes y compilarlas.

En primer lugar, nos bajamos los archivos necesarios o prerequisitos:

# apt-get install build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls28-dev

libreadline-dev python-dev python-dnspython gdb pkg-config libpopt-dev libldap2-

dev dnsutils libbsd-dev attr krb5-user docbook-xsl libcups2-dev acl git bind9

El protocolo Kerberos nos pedirá tres datos que son:

Reino Kerberos: misapellidos.local

Servidor: debserverprofe (o nombre del servidor)

Servidor administrativo: debserverprofe (o nombre del servidor)

Una vez finalizada la instalación, bajaremos la versión más reciente del repositorio GIT:

# git clone git://git.samba.org/samba.git /usr/src/samba4/

Una vez finalizada la descarga procederemos a compilar:

# ./configure --enable-debug

# make

# make install

y añadiremos el path de las carpeta bin y sbin de samba:

# export PATH=”/usr/local/samba/sbin:/usr/local/samba/bin:$PATH”

Cuando reiniciemos el servidor o la sesión debemos ejecutar este comando para añadir al path.

Procedemos a la construcción del dominio utilizando el comando samba-tool domain provision y

procederemos a rellenar los datos de nuestro dominio, tal como muestra la imagen siguiente

16

En DNS forwarder, pondremos la dirección IP del DNS que queremos que resuelva las peticiones

externas (reenviador).

En cuanto la password que nos solicita, deberá tener complejidad, caso contrario nos pedirá una

nueva contraseña y hasta que no sea lo suficientemente compleja no dejará de solicitarla.

Si todo va bien, procedemos a desconectar la tarjeta NAT del servidor y comenzamos la

configuración.

Primero echamos un vistazo al fichero smb.conf donde completamos las líneas dns forwader y

allow dns updates

A continuación configuramos los ficheros relacionados con la tarjeta de red. A saber son tres:

• /etc/resolv.conf

17

• /etc/hosts

• /etc/network/interfaces

Reinciamos el servicio de Red.

#service networking restart

A continuación reiniciamos la máquina y cuando iniciamos sesión debemos iniciar siempre el

servicio de samba. Esto sera hara también siempre tras cada inicio de sesión.

# /usr/local/samba/sbin/samba start

Pasamos a configurar el servidor DNS.

18

Por defecto, Samba crea las siguientes dos zonas durante la implementación del nuevo dominio: -

Una zona para nuestro dominio, en nuestro caso misapellidos.local y la zona

_msdcs.debserverprofe.misapellidos.local que contiene los registros SRV para diversos servicios.

Samba no crea la zona de búsqueda inversa, de modo que la creamos de formal manual:

Solo nos falta incluir en /etc/bind/named.conf

Empezamos las comprobaciones:

19

Importante.- En Debian cada vez que activamos la NAT el fichero /etc/resolv.conf se modifica a su

estado original por ello es necesario tener la NAT solo activa cuando sea necesario. Podemos

hacerla estática, puedes verlo aquí o se podría resolver usando modo Bridge pero por

requerimientos de nuestra red del centro no es posible. Así que durante las prácticas nunca nos

olvidemos de repasarla cada vez que activemos la NAT.

Llegados a este punto, empezamos las pruebas de integración agregando los equipos al dominio. A

partir de aquí utilizaremos clones enlazados. Primero con Windows y posteriormente con Linux

(solo si tenemos tiempo). Añadiremos a Windows el servidor dns configurado en Linux.

20

Aunque Samba 4 dispone de herramientas gráficas web como SWAT, utilizaremos para administrar

el dominio unconjunto de herramientas gratuitas que ofrece Microsoft conocido como RSAT

(Remote Server Administration Tool). Dichas herramientas, disponibles tanto para Windows 7

como Windows 8, no permitirán gestionar nuestro controlador de dominio, de forma idéntica a si

estuviéramos delante de un Windows Server.

El primer paso será descargarnos de la página de Microsoft la versión RSAT adecuada a nuestro

equipo cliente. En nuestro caso, un Windows 7 Enterprise de 64 bits.

Una vez instalado el paquete de herramientas, procederemos a habilitar aquellas que necesitemos,

para ello deberemos ir a Panel de Control, Programas y características, Activar características de

Windows:

Aquí activaremos las herramientas de administración que sean necesarias, en nuestro caso

tendremos suficiente con la administración básica del AD y la administración de políticas de

grupo. Si posteriormente se necesitan herramientas adicionales, siempre se pueden activar.

Una vez hemos activado las diferentes herramientas, vamos a comenzar a administrar nuestro

dominio. En primer lugar, abrimos Usuarios y Equipos de Active Directory. En esta consola

podemos crear OU, grupos, usuarios y gestionar máquinas del dominio. Aquí a modo de ejemplo,

creamos dos usuarios que llamaremos ana y pepe.

21

Vamos a crear ahora la carpeta en el servidor donde ubicaremos las carpetas personales de los

usuarios del dominio y a continuación editaremos el archivo smb.conf (recordar que lo tenemos en

/usr/local/samba/etc para compartir dicho recurso. En el ejemplo vamos a llamar a dicha carpeta

Usuarios:

# mkdir /Usuarios

Una vez realizada esta acción, reiniciamos el servidor y volvemos a iniciar el servicio de samba

para que los cambios tengan efecto.

#/usr/local/samba/sbin/samba restart

ACTIVIDAD. Instalación de Odoo en el servidor Debian y comprobación de acceso desde los

clientes.

H. Ampliación I. Mejoras adicionales.

El siguiente paso es configurar los permisos de este nuevo recurso. Esto lo haremos desde el

cliente. Es muy importante recordar que debemos evitar que un usuario tenga acceso a la carpeta

personal de otro, para ello, es necesario bloquear las herencias de los permisos de la carpeta

Usuarios a las carpetas hijas creadas en su interior. Para acceder desde el cliente a la carpeta

compartida utilizaremos el explorador de archivos.

22

Botón derecho sobre la carpeta, seleccionamos Seguridad y elegimos Opciones Avanzadas.

Eliminamos todos los permisos que aparecen y procedemos ahora a crear los que necesitamos:

• Administrator (administrador del dominio) tiene control total para esa carpeta,

subcarpetas y archivos.

• Repetimos los mismos permisos para el grupo Domain Admins.

• Elegimos idéntica configuración para SYSTEM.

• A CREATOR OWNER (el usuario que crea un recurso) le damos control total pero solo de

subcarpetas y archivos.

• Al grupo Domain Users les daremos permiso de Atravesar carpeta/Ejecutar archivo,

mostrar carpeta/leer datos, Crear archivos/escribir datos y Cambiar permisos, pero

solamente en esta carpeta.

En las siguientes imágenes podemos observar algunas de las configuraciones que podemos

plantear en nuestro servidor.

23

Toca ahora configurar el perfil de los usuarios definidos anteriormente para que crear su carpeta

personal. Para ello, desde la consola de Usuarios y Equipos seleccionamos el usuario y en

Propiedades -> Perfil escribimos la ruta de su carpeta personal, utilizamos la variable de entorno

%username% que nos permitirá que usuarios nuevos creados a partir de copiar uno de los

anteriores, utilicen su nombre de usuario para crear la carpeta.

Si ahora iniciamos sesión en el cliente con uno de los usuarios, por ejemplo ana o pepe

comprobamos como nos aparece su carpeta personal.

24

A modo de ejemplo vamos a ver como mapear directamente a las carpetas personales en red de

los usuarios que se han creado en el servidor, la carpeta de Documentos que aparece en el perfil

de cada usuario. De esta manera, cuando un usuario guarde el archivo en Documentos, realmente

lo está guardando en red (informes, documentos, listados, etc) y por tanto, verá ese documento

independientemente del equipo desde el cual inicie sesión lo que implica dos beneficios, la

seguridad de no guardar en local y la comodidad de disponer en esos documentos desde cualquier

equipo cliente.

Para aplicar las GPO en nuestro caso, desde el equipo cliente y validados como administrador del

dominio, abrimos la herramienta Administración de directivas de grupo del conjunto

25

Creamos una nueva GPO y la vinculamos al dominio le ponemos un nombre, por ejemplo

mapear, una vez creada clicamos con el botón derecho y procedemos a editar

Desplegamos el árbol de directivas hasta la opción deseada, Configuración de usuario ->

Configuración de Windows -> Redirección de carpetas -> Documentos y con el botón derecho

seleccionamos Propiedades.

En Destino, marcamos la opción básica, la opción de crear una carpeta para cada usuario en la

ruta raíz y como ruta raíz, elegimos la ruta donde tenemos las carpetas en red de los usuarios.

26

En Configuración marcamos la opción de Mover el contenido de Documentos a la nueva ubicación.

Finalmente sobre la máquina cliente forzamos la actualización de las directivas y cerramos sesión.

C:\>gpupdate /force

Iniciamos sesión con un usuario del dominio y comprobamos como si vamos a la ruta de red,

aparece la carpeta Documentos creada en su carpeta personal. A veces es necesario, reiniciar la

sesión de usuario la primera vez para que los cambios tengan efecto.

27

Comprobamos creando un archivo en la carpeta Documentos de Bibliotecas, cómo este archivo

realmente se crea en la carpeta en red y por tanto estará disponible desde cualquier cliente del

dominio.

A partir de aquí se puede aplicar cualquier tipo de directiva, tanto de equipo como de usuario a los

miembros del dominio.

Para que los clientes Ubuntu se mapeen en las carpetas de Windows Server lo haremos de forma

gráfica.

28

En primer lugar vamos a Lugares -> Red

A partir de aquí debería solicitarnos usuario y contraseña tal como se muestra en las imágenes.

Este apartado lo ampliaremos en la prácticas de Gestión de Usuarios

I. Ampliación II. Mejoras adicionales.

Vamos a configurar el reenvio de puertos con NAT en VirtualBox. Si tenemos la red de nuestra

máquina virtual configurada en NAT y queremos acceder desde el exterior a dicha máquina,

deberemos de crear una regla sencilla en VirtualBox. Ya que si miramos la configuración IP de la

máquina virtual veremos que tiene una IP de la red 10, no accesible desde la máquina host.

Para ello primero hacemos clic botón derecho de nuestra máquina virtual y pulsamos en

settings...

En la ventana que nos abre vamos al apartado de red y pulsamos en Port forwarding

29

Vamos a habilitar el puerto 22 en la máquina virtual y el puerto de host de escucha sea el 2222.

Aquí señalar que es mejor utilizar como IP dela maquina real 127.0.0.1

Aquí hago la prueba con mi máquina. Como vemos, hago un ssh al puerto 2222 de mi máquina y

VirtualBox se encarga de redireccionarme la conexión al puerto 22 de la máquina virtual.

30

Estos redireccionamientos son útiles cuando creamos una máquina virtual en VirtualBox, por

defecto se le asigna una red de tipo NAT. La dirección IP de esta máquina será privada y asignada

por el propio VirtualBox que actúa como servidor DHCP.

El problema viene cuando tenemos que acceder a determinados servicios internos de esa máquina

desde nuestro ordenador (host real). Puede ser el caso por ejemplo de un servidor SSH, servidor

web Apache, Nginx, un Jboss, etc…

Muchas veces lo que se hace es simplemente cambiar el tipo de red de la máquina a Adaptador

Puente (Bridged Adapted) para que la máquina adquina coja una IP de nuestra red y acceder sin

problemas.

Sin embargo, también podemos dejar la red en tipo NAT y realizar una redirección de puertos tal

como mostramos anteriormente

Podríamos crear las reglas que consideráramos necesarias. Por ejemplo para Apache.

31

Corolario

Damos por finalizado con la configuración, más o menos estándar, de posibles escenarios que

contemplan varias posibles situaciones: servidores Linux o Windows junto con además clientes

Linux o Windows. Podríamos ampliar algunas características y configuraciones adicionales pero se

escapa del objetivo el módulo profesional en cuestión. La configuración de los escenarios

mediante la utilización de Servidores en NAT podría haberse realizado de forma similar con la

utilidad NAT Network pero en mi opinión perderíamos en cierta medida la perspectiva de un

escenario real.

32