Escenario 2.F: Configuración dun router virtualizado con Debian
O que imos facer neste escenario é virtualizar o servidor dserver2, que realiza as funcións de router. Isto vainos permitir aplicar nun caso práctico e entender mellor o funcionamento dos modos de conexión en VirtualBox, xa que este servidor fai unha función similar á que realiza o propio VirtualBox cando nunha máquina conectamos unha tarxeta de rede en modo NAT ou rede NAT.
Este escenario está extraído do seguinte esquema de rede, no que se virtualiza este mesmo servidor sobre Xen Server:
Renomear e agrupar as máquinas do escenario
Facendo uso da funcionalidade de VirtualBox de crear grupos de máquinas, imos agrupar todas as máquinas que van intervir neste escenario para facilitar o seu manexo.
Configurar as tarxetas de rede das máquinas
Como segundo paso, imos engadir nas máquinas os adaptadores necesarios e os modos de conexión de cada unha. Se revisamos o escenario, veremos que todos os adaptadores estarán en modo de rede interna excepto o adaptador 1 da máquina dserver2 que estará en modo ponte.
Agora ben, non todos os adaptadores estarán na mesma rede interna. Dado que queremos simular dúas LANs distintas (a que leva por nome LAN e a que leva de nome DMZ), imos definir dúas redes internas diferentes, ás que lle poremos ese nome. Desa forma, os adaptadores que están conectados a unha rede interna teñen conexión entre si, pero non terán conexión cos que están conectados a outra rede interna.
Instalación de webmin e shorewall en dserver2
Imos ver os pasos a seguir para configurar a máquina dserver2 para que realice as funcións que se reflicten no escenario. O obxectivo deste curso non é afondar na configuración de servizos de rede en Debian, así que intentaremos propoñer unha configuración o máis sinxela posible. Utilizaremos a ferramenta de administración de sistemas GNU/Linux webmin, que nos permitirá configurar o servizo de ruteo e devasa da máquina sen ter que manipular directamente os ficheiros de configuración.
Por iso imos instalar en primeiro lugar esta ferramenta na máquina dserver2, xunto co módulo shorewall que nos permitirá configurar as regras da devasa de forma máis accesible.
Co comando ifconfig podemos ver a dirección IP que a máquina tomou automaticamente por DHCP na interface que ten conectada en modo ponte. Se non houbese un servidor DHCP na rede, habería que configurar a dirección IP de forma manual. Nun apartado posterior no que se explica a configuración das interfaces de rede das distintas máquinas do escenario pódense ver os pasos da configuración das interfaces en dserver3 para ver como facelo.
Dado que a máquina dserver2 ten instalado o servidor ssh, agora que sabemos a súa dirección IP podemos conectarnos con un cliente ssh dende o host ou outro equipo da rede, xa que isto nos facilitará copiar e pegar os comandos que vaimos introducindo (se o host é un equipo Windows podemos utilizar o programa putty como cliente ssh).
Ollo que nas novas versións de ssh non deixa, por defecto, iniciar sesión co usuario root. Por tanto podemos iniciar sesión co usuario dadmin (abc123.) e unha vez no servidor pasarse a root con su -. Tamén se pode editar o ficheiro /etc/ssh/sshd-config tal como se indica en: https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root-login-via-ssh/Descargamos o paquete do webmin para debian, co comando wget http://prdownloads.sourceforge.net/webadmin/webmin_1.820_all.deb (Descargaremos e instalaremos a última versión, independentemente da versión que aparece na imaxe)
Xa podemos conectarnos ao webmin instalado en dserver2. Webmin é un servizo de administración remota que corre no porto 10000 e ao que pode accederse con un navegador usando unha conexión segura (https). Así que no host ou en calquera equipo da rede abrimos un navegador e introducimos como dirección https://IP_dserver2:10000. Aparecerá o aviso do navegador debido a que o certificado de seguridade non é fiable, cousa totalmente normal. Engadimos unha excepción...
Configuración das interfaces de rede
Neste apartado imos abordar a configuración IP de todas as máquinas virtuais que forman o escenario. Cada unha delas será diferente xa que contamos con unha máquina Windows 7 (wclient), unha máquina Ubuntu (uclient), unha máquina Windows 2012 Server (wserver3) e dúas máquinas debian pero unha delas configurarémola co webmin (dserver2) e a outra manipulando directamente os ficheiros de configuración (dserver3).
É moi importante prestar atención a que esta páxina se divide en dúas pestanas: Interfaces Activas Agora e Interfaces Activadas en Tempo de Arranque, e sempre teremos que facer os cambios nesta última (que é a que vemos por defecto), xa que senón os cambios non perdurarán cando se reinicie a máquina virtual. Veremos que só hai unha interfaz configurada, eth0, por DHCP. Picamos sobre ela para poñerlle a dirección que lle corresponde no escenario. Fixarse antes en que na columna de Activar ao inicio pon que non, parámetro que teremos que cambiar para que a interfaz se active de forma automática.
Poñemos como nome da interfaz eth1, marcamos que se active no inicio (Activate at boot->Si), e marcamos Static configuration en IPv4 address para introducir a dirección IP e máscara que se indican no escenario (fixarse que estamos usando unha dirección IP de clase B con máscara de clase C xa que estamos definindo subredes). Picamos en Crear e Aplicar.
Seleccionamos a interfaz eth0, que é o único cambio que aínda non está aplicado, e picamos no botón de Apply Selected Interfaces. Neste momento o webmin deixará de responder, xa que acabamos de cambiar a dirección IP da interfaz pola que nós nos estabamos conectado co navegador (era 10.0.0.11 e pasa a ser 10.1.69.1). Así que teremos que cambiar a dirección do navegador para poñer https://10.1.69.1:10000
Na imaxe vese o contido que imos deixar no ficheiro, engadindo a interfaz na liña auto... para que se active automticamente e establecendo unha configuración IP estática, cos datos de dirección e máscara indicados no escenario. A porta de enlace predeterminada (gateway) para este equipo será a dirección IP da interfaz eth2 de dserver2. É moi importante revisar ben a sintaxe de todo o que se introduciu no ficheiro para que a configuración se aplique correctamente.
A resposta é que non, porque aínda que todas as interfaces destas máquinas están en modo de rede interna, están conectadas a redes internas diferentes (a de esta máquina á rede lan e as das outras dúas á rede dmz), así que están conectados e switchs ficticios distintos e que non teñen conexión física entre si, como se refricte no escenario.
Activación servizo de ruteo
Utilizando o webmin, imos activar o servizo de enrutamento na máquina dserver2 para poder ter conexión entre as máquinas que están nas dúas redes (lan e dmz):
Pero... ¿podemos acceder a un equipo da rede real (o router de saída a Internet, por exemplo)?... Non... ¿Por que? Porque dserver2 non está facendo a función de NAT, e polo tanto un equipo como uclient que ten unha dirección IP privada non pode acceder a unha rede pública (aínda que a rede 10 sexa unha rede privada, neste caso para os equipos que están nas redes lan e dmz, é como se fose pública. Revisar a teoría sobre NAT). O mesmo pasará co resto das máquinas que están nas redes lan e dmz.
E aínda temos outro problema... Dende o equipo dserver3 podemos acceder ao equipo uclient ¿Debe ser así? Seguindo as regras da devasa, suponse que non se deberían permitir conexións que intenten entrar na rede interna, xa que é a rede que queremos protexer do exterior. A única rede accesible dende o exterior debería ser en todo caso a zona desmilitarizada ou dmz, que é na que se atopan equipos que prestan servizos accesibles dende Internet (chamados comunmente bastións). Imos agora a resolver todo isto...
Configuración da devasa e activación de NAT
Para resolver as dúas problemáticas que acabamos de detectar no apartado anterior, imos configurar a devasa no equipo dserver2 e activar a función de NAT. Utilizaremos para iso o módulo de shorewall de webmin, que nos facilitará a configuración de iptables, que é o módulo de Linux que xestiona as regras da devasa.
Atoparemos agora dentro da categoría de Rede o módulo de Cortafuegos Shoreline. Entramos nel. De momento o módulo está parado (fixarse en que temos o botón de Iniciar el Cortafuegos), pero se intentamos inicialo veremos que nos da un erro, debido a que é necesario establecer unha configuración básica para podelo facer.
Así teremos que definir as zonas wan (que representa a rede pública) e dmz (que representa a rede dmz do escenario). Tamén teremos que definir unha zona de tipo Firewall system, que representa ao propio equipo. Neste caso chamámoslle ds2. Recoméndase seguir estes nomes xa que teñen que ser nomes curtos e hai moitos caracteres inválidos.
O terceiro paso é definir a política por defecto da devasa; é dicir, como se vai comportar a nivel xeral. Aquí haberá que ter en conta dúas cuestións: primeiro que todo posible tráfico que poida manexar o equipo (da rede lan á rede wan, da rede wan á rede dmz, etc.) debe estar incluído nalgunha política, xa que se non a devasa non sabería que facer con el. E segundo que as políticas son as pautas básicas que rexen o comportamento da devasa, que logo afinaremos máis concretamente coas regras. As regras teñen prioridade sobre as políticas, así que a devasa mirará primeiro se ao paquete se lle pode aplicar unha regra, e se non é así, aplicaralle unha das políticas por defecto que teña definidas.
A configuración da devasa é unha decisión moi delicada e dependerá moito do nivel de seguridade e restricións que queiramos aplicar na nosa rede, pero unha opción para este caso podería ser deixar estas dúas políticas. Acéptase todo o que vaia á wan, e o resto rexéitase. Nótese que a orde na que se definen as políticas son moi importantes (por iso hai botóns para subilas e baixalas), xa que se aplican se arriba a abaixo. Por exemplo, se neste caso situásemos a segunda regra como primeira, executaríase sempre, xa que encaixa con calquera tráfico.
Como podemos ver, as regras ofrecen criterios moito máis específicos para poder indicar á devasa que tipo de tráfico se debe aceptar e cal non (protocolo, IP de orixe e destino, porto de orixe e destino, etc.). Con este regra indicámoslle que acepte o tráfico que vaia ao propio equipo con protocolo TCP ao porto 10000 (que é o porto no que corre o webmin).
Podemos deixar estas regras: Permitimos o acceso ao webmin, os pings dende a lan á dmz e acceder dende a lan ao porto 22 da máquina dserver3. En función dos servizos que quixésemos ter accesibles nos servizos da DMZ dende a lan ou dende Internet iríamos engadindo máis regras. A orde nas regras tamén é moi importante, aínda que neste caso non se solapan unhas coas outras.
- Pero.... ¿todo isto non se sae un chisco do obxecto do curso? Ademais de xogar de forma máis profunda cos modos das interfaces de rede en VirtulBox, o router que acabamos de simular é precisamente o que VirtualBox implementa cando configuramos unha interfaz de rede dunha máquina virtual por NAT ou rede NAT. Nese caso, é VirtualBox o que fai de router, con NAT, pero ademais tamén implementa o servidor DHCP e DNS (nós ímonos quedar aquí). Con isto preténdese así que quede máis claro todo este proceso, e entender a virtualización da rede que implementa VirtualBox.
Reenvío de portos
Para rematar, imos facer co noso router virtualizado a mesma función que VirtualBox permite coas tarxetas en modo NAT e rede NAT co reenvío de portos. Recórdese que isto permite acceder a un porto da máquina virtual mediante o reenvío dun porto da máquina host.
O equivalente neste caso sería redirixir un porto libre de dserver2 a un servizo por exemplo duha máquina da DMZ. Imos coller o servizo de ssh de dserver3:
Creamos unha regra de tipo DNAT (Destination NAT), que redirixe o tráfico que veña da zona wan e vaia á zona dmz, concretamente ao porto 22 do equipo 192.168.69.2, co protocolo TCP os paquetes que reciba para o porto 22222 (este será o porto de dserver2 que será redirixido ao servidor ssh de dserver3).