lunes, 9 de junio de 2014

Reviví tu Ideatab A2109A

Para las personas que, al igual que yo, compraron ya hace un tiempo un tablet Lenovo Ideatab A2109A, es medio decepcionante ver que en este momento, y luego de actualizar la mayoría de los paquetes, se pone furiosamente lenta.
Esto es debido a que la memoria interna comienza a quedar chica, y ya casi no entra un proceso sin lentificar a todos los demás.
El proceso de ejecución del launcher puede ser algo casi insoportable, y ni hablemos de lo que significa sacarla en sociedad para tomar notas con productos como es el Evernote, o leer mails en cantidad.
Cuando uno se pone a buscar en Cyanogenmod, no hay ROMs para esta máquina. Ahí es donde la desesperación aparece.
Pero bueno, el último fín de semana me propuse revivir mi máquina sea como sea, y hacerlo de manera tal de no sacrificar el hardware que tiene, ya sea por tener que abrirlo, o por dejar fuera de servicio elementos, tales como su interfaz HDMI.
Encontré retazos de información en muchos sitios, pero nada que pueda decir que constituye el 100% del procedimiento necesario para flashear esta máquina, que no solo es muy buena y rápida, sino que es estética y funcionalmente excelente.
Por ello, y pensando en quienes también poseen este hardware, decidí volver a mi blog para compartir lo que hice, y que permitió que todo funcione.
Las piezas de hardware que van a necesitar son las siguientes:


  • Tablet Ideatab A2109A
  • Cable USB incluído en la caja.
  • Cargador de bateria para evitar sustos.
  • Una PC, puede ser con GNU/Linux o Windows.


Ahora bien, el software es el siguiente:


  • LeTools: Se baja de acá: http://download.lenovo.com/slates/k1/letools/letools/LeTools_MultiLang_x86_x64_Full_setup_20320.exe para Windows. No encontré lo mismo para GNU/Linux, y el adb original del Android SDK puede no ser funcional en estos casos.
  • Imagen de ClockWork Mod Recovery, pero para la A2109, que se puede bajar de aca: http://d-h.st/KSH 
  • Imagen Slim Beanz 11, basada en la original de la A2109A, pero sin su "grasa". Se baja de acá: http://d-h.st/0EK 
  • Superuser, que se baja desde acá: http://www.androidfilehost.com/?fid=23050663588004341 


Respecto de tiempos, no creo que tarden más de una hora, aproximadamente, considerando unos minutos para tomar café.

IMPORTANTE: SIGUIENDO ESTE PROCEDIMIENTO VAMOS A PERDER TODOS LOS DATOS Y APLICACIONES INSTALADAS, si no se desea perder nada, lo mejor es mirar este artículo con cariño, y no hacer nada, o probar herramientas de backup, como en Nandroid Backup, por ejemplo.

El procedimiento es el siguiente. Recomiendo leerlo de punta a punta antes de ejecutarlo, sólo para entenderlo bien, y no caer en desesperación:


  • Copiar los dos archivos zip, uno con la imagen del Superuser y otro con la de Slim Beanz 11, a la raiz de "Almacenamiento Interno", con el tablet conectado a nuestra PC. 
  • Instalar LeTools con o sin el tablet conectado a la PC. Eso va a generar un directorio donde estarán ubicados a la vez dos subdirectorios, LeTools y LeDrivers. Tengamos en mente eso.
  • Si nuestra Ideatab está como la sacamos de su caja, y no hemos intentado romper nada, nuestro bootloader debe estar aún lockeado. Hay que deslockearlo, y para eso hay que seguir estos pasos, teniendo especial atención en los detalles atinentes al momento en el que cada cosa se debe hacer:

(llamemos a este procedimiento "A")

  • Apagar COMPLETAMENTE el tablet presionando unos segundos el botón de power, y esperando a que nos aparezca el mensaje de "Apagar".
  • Seleccionamos "Apagar", y lo confirmamos.
  • Con un dedo cerca del botón para bajar el volumen, pero no presionándolo, y con otro cerca del de power, presionamos el de power hasta que haga la primera vibración como queriendo encenderse. 
  • En ese momento, soltamos el de power, e inmediatamente presionamos el de volumen para abajo
  • A diferencia de cuando abrimos el boot loader, nos aparecerá un menú que nos pregunta si queremos continuar, rebootear, etc. En el medio de la pantalla nos va a aparecer un símbolo de conexion USB en color ocre. Es normal. 
  • Recién en ese momento conectamos la tablet a la PC.

(Fín del procedimento "A")

  • Con la tablet ya conectada a la PC por medio del cable USB, procederemos a instalar los drivers del Fastboot.
  • Ir al "Device Manager", donde en "Other Devices" encontraremos el "Fastboot". 
  • Hacer click derecho sobre "Fastboot", y seleccionar "Update Device Driver".
  • Seleccionar "Browse my computer for driver software".
  • Seleccionar "Let me pick from a list of device drivers on my computer".
  • Seleccionar "Show all devices", y presionar el botón "Next".
  • En la ventana "Select the device driver you want to install for this hardware" seleccionar "Have Disk".
  • Ir hasta DENTRO del directorio "LeDrivers", y presionar "Open".
  • Presionar "OK".
  • De la lista de drivers, seleccionar "Lenovo Fastboot Device".
  • Cuando aparezca un "Update Driver Warning", presionar "Yes".
  • Al finalizar, presionar el botón "Close". Ya está!
  • Ahora, procederemos a deslockear el bootloader.
  • Ingresaremos a una ventana de "cmd" como el usuario Administrador (click derecho sobre el ícono de cmd.exe, seleccionar "Ejecutar como Administrador").
  • Mediante el comlicadísimo comando "cd" llegaremos hasta donde están instaladas las "LeTools". En mi caso es "C:\Program Files(x86)\Lenovo\LeTools".
  • Ejecutemos el comando siguiente, que nos debe mostrar un número extraño junto con un dispositivo llamado "fastboot": fastboot devices
  • Si eso nos ha aparecido, y de seguro ocurrirá, ejecutemos el siguiente comando: fastboot oem unlock
  • En la pantallita de nuestro tablet aparecerá un pedido de confirmación, que sólo durará 10 segundos. Moverse entre las opciones con volumen hacia abajo, y confirmar que sí se quiere hacer el unlock con volumen hacia arriba. Esta modalidad sólo es necesaria en esta parte.
  • Cuando la máquina ya esté con el bootloader deslockeado, se puede rebootear. Para ello, ejecutar en la misma ventana: fastboot reboot 
  • No cerrar esta ventana, la usaremos de nuevo en breve.

Ya tenemos el tablet con su bootloader deslockeado, ahora hay que instalar el ClockWork Module, y rootear el tablet.

  • Bootearemos normalmente el tablet, si nos pidiera los datos iniciales de configuración cargarlos (de todas formas los perderemos cuando flasheemos el tablet de nuevo).
  • Copiaremos el archivo "superuser" en el almacenamiento interno del tablet, en la raiz. También copiaremos el archivo con la nueva imagen, se podrá llamar algo así como "FlashesSlimzBeanz11.zip".
  • Luego copiaremos el archivo del CWM dentro de la carpeta LeTools, para evitar tener que setear paths, y demás complicaciones de Windows.
  • Una vez copiado, seguiremos el procedimiento "A" para llegar al fastboot.
  • En la ventana de cmd.exe que NO CERRAMOS antes, ejecutaremos: fastboot flash recovery A2109_CWMrecovery-6.0.2.8a.img 
  • Fijémonos en que haya terminado con un "OKAY".
  • Ahora tendremos que rebootear el tablet para entrar al ClockWork Module, por un lado, luego rootear la tablet, y luego instalar la nueva imagen.
  • Tengamos el dedo cerca del boton para subir el volumen. Ejecutaremos: fastboot reboot
  • Ni bien comienza el proceso de rebooteo, presionar el botón para subir el volumen. Eso nos llevará al ClockWork Module.
  • En este modo, los botones de volumen suben o bajan de opció, y el de power implica un "Enter".
  • Iremos hasta donde están las opciones para hacer un wipe tanto de data como de cache, y en cada caso seleccionarlas, y luego confirmarlas.
  • Cuando terminemos con ellas, vayamos a la sección avanzada, y seleccionemos hacer un wipe de Dalvik. Confirmemos, queremos hacer eso.
  • Luego, seleccionemos "Apply zip from card" o internal storage, o como se llame en la versión de CWM que tengamos.
  • Apliquemos el "superuser" (el archivo zipeado).
  • Una vez que hicimos esto, seleccionemos nuevamente aplicar un zip desde un espacio interno, como lo hicimos recién, pero ahora seleccionando el archivo "FlashesSlimzBeans11.zip", o como se llame la versión que bajamos.
  • Cuando terminamos con eso, seleccionar "reboot now".
  • Cuando se inicialice , puede que nos pida los datos de configuración inicial del tablet. Ingresarlos todos.
  • Ya con el tablet em funcionamiento, seleccionar el programa ROM Toolbox Lite.
  • Dentro del ROM Toolbox Lite, seleccionar el botón "ROM Management".
  • Seleccionar "Google Apps".
  • Seleccionar "Google Apps 4.1".
  • Seleccionar "Download".
  • Cuando termine de descargar, de seguro pedirá un reboot para instalarlas. El boot manager que tenemos es CWM, así que hay que seleccionar ese.
  • Luego de rebootear y aplicar las GAPPS, ya tendremos el tablet como nuevo, super rápido, y sólo con las aplicaciones que deseamos tener, y no todo el crapware que Lenovo instala por default.
Esto es todo, que disfruten su nuevo (viejo) tablet, ahora con anabólicos...

HeCSa.


sábado, 3 de mayo de 2014

Manjaro y PopCornTime

Esta entrada, dada su breve extensión, la puedo escribir desde mi celular, mientras tomo mi jugo de naranja, y disfruto de una película.
Porque es tan, pero tan sencillo instalar popcorntime en mi Manjaro con kernel 3.14.
Sólo se debe ejecutar, desde una terminal, "sudo yaourt -S popcorntime", luego decir no a cualquier pedido de edición de configuraciones, y sí a las instalaciones de todos los módulos que instala. Nada más.
Luego de unos quince minutos, dependiendo de la conexión a internet de que se disponga, queda instalado, y con un ícono listo para usarlo.
Que lo disfruten!

martes, 1 de abril de 2014

Manjaro, Apache 2.4.7 y PHP

Ocurrió en la comarca que luego de hacer una actualización completa de Manjaro Linux me encontré con que el nuevo Apache 2.4.7 no levantaba con el típico comando:

systemctl start httpd

Y que su salida de estado me mostraba lo siguiente:

[root@zentraedy-l ~]# systemctl status -l httpd.service
httpd.service - Apache Web Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
   Active: failed (Result: exit-code) since Tue 2014-04-01 01:12:34 ART; 5min ago
  Process: 2200 ExecStart=/usr/bin/apachectl start (code=exited, status=1/FAILURE)

Apr 01 01:12:34 zentraedy-l apachectl[2200]: httpd: Syntax error on line 59 of /etc/httpd/conf/httpd.conf: Cannot load modules/mod_authn_default.so into server: /etc/httpd/modules/mod_authn_default.so: cannot open shared object file: No such file or directory
Apr 01 01:12:34 zentraedy-l systemd[1]: httpd.service: control process exited, code=exited status=1
Apr 01 01:12:34 zentraedy-l systemd[1]: Failed to start Apache Web Server.
Apr 01 01:12:34 zentraedy-l systemd[1]: Unit httpd.service entered failed state.



Entonces, como buen tecnólogo, me puse a buscar dicho archivo, descubriendo que el mismo ya no estaba...

[root@zentraedy-l ~]# find / -name mod_authn* -print
/usr/lib/httpd/modules/mod_authn_core.so
/usr/lib/httpd/modules/mod_authn_anon.so
/usr/lib/httpd/modules/mod_authn_dbm.so
/usr/lib/httpd/modules/mod_authnz_ldap.so
/usr/lib/httpd/modules/mod_authn_file.so
/usr/lib/httpd/modules/mod_authn_socache.so
/usr/lib/httpd/modules/mod_authn_dbd.so


Muy para mi sorpresa, resulta que el proceso de actualización generó nuevos archivos httpd.conf y magic, llamados de la misma forma, pero con la extensión "pacnew".

La solución fue bien sencilla, sólo renombré los archivos httpd.conf a httpd.conf.original y magic a magic.original, para luego mover los archivos httpd.conf.pacnew a httpd.conf y magic.pacnew a magic.

Hasta acá, todo bien, cuando intenté levantar el web server lo hizo en forma satisfactoria.

Pero claro, nada puede ser tan sencillo, por lo que el módulo de PHP no parecía estar cargado...entonces debí volver a la carga y descubrí las bondades de ejecutarlo en modo standalone, ya que me liberé de tener que levantar todo el Apache para poder probar mis programas, en este caso para el puerto 8000:

php -S localhost:8000 -t /srv/http

Con eso, ya tuve mi PHP con los mismos módulos que alguna vez utilicé.

miércoles, 13 de noviembre de 2013

Actualización en Manjaro - se complicó!

Bueno, vengo usando en mi notebook Manjaro desde hace un buen tiempo, en especial desde que decidí sacar Fedora por la forma destructiva de sus actualizaciones.

Siempre pude actualizar en forma automática todo, sin temor a perder nada. Y así fue, pero hoy la cosa se complicó, y quiero compartir mi experiencia con los que me leen para que no tengan que deambular por mil páginas tratando de sacar adelante la actualización.

El tema es que cuando ejecutaba el comando de actualización, no aparecía nada. Eso es bastante extraño, considerando que ya hacía más de un mes que no actualizaba mi máquina, y que no me aparecía ningún mensaje llevándome a hacerlo.

Los comandos y salidas fueron estos:

sudo pacman -Syu
...
Nothing to do.

Entonces, me encontré con que existe la posibilidad de tener los repositorios desactualizados, por lo que ejecuté el siguiente comando, y noté con grata alegría que tenía muchísimos paquetes pendientes de ser actualizados, específicamente unos 800 MB:

sudo pacman-mirrors -g

Luego sincronicé la base de paquetes:

sudo pacman -Syy 

Y finalmente procedí a ejecutar el tan querido comando de actualización:

sudo pacman -Syu

Ahora sí descargó paquetes! Pero no todo es tan fácil. Cuando estaba realizando el chequeo de conflictos, encontré que algunos archivos no permitían la actualización, como ser el libdbudmenu-glib, y sus dos dependencias,

error: failed to commit transaction (conflicting files)
libdbusmenu-glib: /usr/include/libdbusmenu-glib-0.4/libdbusmenu-glib/client.h exists in filesystem
libdbusmenu-glib: /usr/include/libdbusmenu-glib-0.4/libdbusmenu-glib/dbusmenu-glib.h exists in filesystem
libdbusmenu-glib: /usr/include/libdbusmenu-glib-0.4/libdbusmenu-glib/enum-types.h exists in filesystem
libdbusmenu-glib: /usr/include/libdbusmenu-glib-0.4/libdbusmenu-glib/menuitem-proxy.h exists in filesystem

Ergo, tuve que proceder primero a desinstalar dichos tres paquetes, y luego seguir con la actualización, que ahora sí puedo decir, funcionó de mil maravillas:

[root@zentraedy-l ~]# pacman -R libdbusmenu-gtk3 libdbusmenu plank
checking dependencies...

Packages (3): libdbusmenu-12.10.2-1  libdbusmenu-gtk3-12.10.2-1  plank-811-1

Total Removed Size:   2.24 MiB

:: Do you want to remove these packages? [Y/n] y
(1/3) removing plank                               [######################] 100%
(2/3) removing libdbusmenu-gtk3                    [######################] 100%
(3/3) removing libdbusmenu                         [######################] 100%

[root@zentraedy-l ~]# pacman -Syu
:: Synchronizing package databases...
 core is up to date
...

El resto es sólo historia. Ya tengo mi Manjaro fuerte y vital como siempre.
¡Nos vemos!

lunes, 11 de noviembre de 2013

Redes - Quinta Parte

Quinto artículo sobre redes de datos, publicado en la revista Tuxinfo #60.



Redes para las masas – Parte V



Ya contamos con los conocimientos teóricos para comprender el funcionamiento de las redes de datos que encontremos delante nuestro. En las entregas anteriores pudimos interiorizarnos en cuestiones de base, fundamentales y no siempre conocidas por los administradores de sistemas que configuran entre otras cosas las redes que usamos para hacer funcionar nuestras aplicaciones.

En esta entrega pondremos las manos en la grasa, y configuraremos los elementos necesarios para probar nuestros conocimientos. A no asustarnos, comienza aquí una nueva etapa, excitante y movida, que si seguimos al pie de la letra nos aportará fuertes conceptos, ahora tanto teóricos como prácticos. Y como debe ser, no perderemos oportunidad para abordar nuevos conocimientos ahora ya más avanzados. Súbanse al tren, no paramos.

Preparando la escena

Las prácticas que veremos estarán basadas en determinados parámetros de nuestra red. Sabemos que, como pasa con las familias, no hay dos redes iguales. Pero tomaremos como punto de partida algunos parámetros que podrán ajustarse a cada caso, según corresponda. Los parámetros iniciales serán los siguientes:

  • Conexión a Internet: Consideramos tener una conexión a Internet medianamente decente, nada ambiciosa, pero sí que esté funcionando. La usaremos para bajar imágenes de sistemas operativos, si aún no los tenemos. En mi caso, me conecto a Internet a través de un pequeño router WiFi conectado a un cablemódem configurado con la dirección IP interna 10.100.100.1/24. Eso quiere decir que siempre que configure un router predeterminado y esté utilizando una conexión que carezca de la configuración “NAT” (paciencia, ya revisaremos este concepto) lo haré con esa dirección. Este punto se podrá ajustar a los parámetros de la red que tengamos. Si no tuviéramos un router, y sí una conexión directa a Internet, podremos ver los parámetros de ruteo ejecutando el comando “netstat -nr” desde una terminal GNU/Linux, y revisando la columna “Gateway” en la línea que tenga el valor “UG” en la columna “Flags”. Para las prácticas iniciales, utilizaremos facilidades que nos provee el mismo virtualizador, y que no desemerecen ninguno de los puntos que estudiaremos. Todo lo contrario, cuanto más complicado, mejor. Más adelante, jugaremos con estos parámetros.

  • Direcciones IP disponibles: Si contamos en nuestra red con un servidor DHCP (más adelante veremos qué es eso) utilizaremos las direcciones IP que él nos entregue. En mi caso tengo uno que entrega direcciones IP desde la 10.100.100.100 a la 10.100.100.150, siempre con máscara 24. Si no usamos esa tecnología, no hay problema, veremos opciones para estos casos. E inclusive, para nuestra práctica jugaremos con el servidor DHCP que tiene el software hipervisor.

  • Espacio en disco: Si bien no es concluyente, ya que no lo utilizaremos en forma completa, el contar con unos 30~60 GB de espacio en disco será conveniente para la generación de las máquinas virtuales que utilizaremos en nuestras prácticas. Para la totalidad de este artículo, 30 GB son más que suficientes, y hasta me animaría a decir que demasiado.

  • Memoria RAM: Convendrá tener por lo menos 1,5 GB de memoria RAM disponible. Si tenemos muchas aplicaciones abiertas mientras ejecutamos las prácticas, tendremos que cerrar algunas hasta que podamos contar con máquinas virtuales funcionales. No es tan terrible, en mi caso estoy ejecutando todo en una pequeña notebook.

  • Sistema operativo: Cualquier sistema operativo que nos permita la ejecución de un programa de virtualización como lo es VirtualBox nos servirá. Eso incluye GNU/Linux en casi todos sus sabores, OpenIndiana, *BSD, y “los que ya no son primeros en ventas”, también.

  • Software de virtualización: Como software de virtualización utilizaremos VirtualBox. Dependiendo de la versión de GNU/Linux de que dispongamos podremos utilizar el set de comandos “apt-get”, “yum”, “pacman”, o bajarlo desde el sitio http://www.virtualbox.org para nuestro sistema operativo y arquitectura de procesador. Recordemos también bajar la “VM VirtualBox Extension Pack” para usar funciones avanzadas de este software.


El motivo por el cual estamos bajando dos versiones diferentes de GNU/Linux es el poder experimentar por una lado con una basada en “.deb”, como lo es Debian, Ubuntu, Linux Mint, etc., y por el otro con una basada en “.rpm”, como lo son Red Hat, CentOS, Scientific Linux, Fedora, etc.

No dejaré de lado la configuración de otras distribuciones, como lo son las *BSD, como lo son FreeBSD, NetBSD o PC-BSD; y las basadas en IllumOS, como lo son OpenIndiana, por ejemplo. Ellas quedarán, por no ser las más populares (no saben lo que se pierden) para el final de esta sección.

Debian Virtual

Lo primero que haremos es implementar una máquina virtual basada en Debian GNU/Linux 7, y para ello haremos uso de la primer imagen que hemos bajado. Para realizar esta instalación, abriremos el programa VirtualBox y en la ventana principal seleccionaremos el botón superior “New” o “Nueva”.

En la primer ventana, donde se nos pide “Name and Operating System”, colocaremos, como nombre (“Name”), “firewall1”, como tipo de sistema operativo (“Type”), “Linux”, y como versión (“Version”), “Debian”.

En la siguiente pantalla, donde se define el tamaño de la memoria, asignaremos no más de 512 MB. En la siguiente, donde se debe configurar el disco virtual a generar, seleccionaremos “Crear un disco virtual ahora” (“Create a virtual hard drive now”), y presionaremos el botón “Crear” (“Create”). Debemos seleccionar el tipo de archivo a utilizar para el disco virtual, que en nuestro caso será “VDI”.

El almacenamiento de este disco será “Dinámicamente alojado” (“Dynamically allocated”), y su tamaño será no menor a los 15 GB. Con eso prácticamente quedará creado el entorno que necesitamos para hacer nuestra práctica. Sólo nos queda cambiar algo de la configuración.

Para ello, presionaremos el botón derecho sobre el nombre de la máquina virtual, y en el menú que se desplegará seleccionamos “Configuración” (“Settings”). El primer cambio que introduciremos será dejar el tipo de red como “NAT” (veremos en breve qué es eso). Luego, seleccionaremos en el menú de la sección izquierda de la pantalla la parte de “Almacenamiento” (“Storage”), y en el disco óptico simulado, seleccionaremos la imagen que bajamos, “debian-7.0.0-i386-netinst.iso”, o la que hayamos bajado.

Ahora, con los cambios introducidos, podremos presionar el botón “OK”. La máquina virtual quedará configurada como lo vemos en la figura, y estaremos listos para encenderla presionando el botón “Iniciar” (“Start”).



Como el orden de inicio lo determina, comenzaremos a ver el booteo desde el CD-ROM, que en nuestro caso, es la imagen del CD de sistema operativo Debian 7.

En la primer pantalla, seleccionaremos como idioma de instalación “English”. En “Select your location”, elegiremos “other”, luego “South America”, luego “Argentina”.

En “Select your locales”, elegiremos “United States”. En “Configure the Keyboard”, a menos que tengamos un teclado algo distinto, “Latin American” será adecuado. Así llegaremos a la sección “Configure the network”.

Como hostname escribiremos “firewall”. Domain name lo dejaremos en blanco. Colocaremos la clave de root dos veces. Crearemos un nuevo usuario colocando su nombre, username, e ingresando la contraseña dos veces.

En la sección de particionamiento de discos seleccionaremos la opción “Manual”, luego elegiremos el disco virtual que hemos configurado antes, y como “Partitioning scheme”, para simplificar este paso, elegiremos “All files in one partition (recommended for new users”. Seleccionaremos “Finish partitioning and write changes to disk”, y lo confirmaremos.

Luego de unos segundos se nos solicitará que configuremos el gestor de paquetes (“Package Manager”), para lo cual, en mi caso selecciono “Argentina”, y luego “ftp.ccc.uba.ar”, pero que podrá ser cualquier otro valor según la zona donde estén viviendo.

Si no uso un proxy para salir a internet, dejaré este campo en blanco. Selecciono “No” a participar del concurso de popularidad de paquetes (“popularity contest”). En la sección “Software selection” sólo dejo seleccionado “SSH Server” y “Standard System Utilities”.

En la sección de instalación de GRUB, digo “Yes” a instalarlo en el MBR (“Master Boot Record”). Cuando termine la instalación podré ingresar a mi nuevo sistema operativo, ya que me encontraré ante una ventana típica de login en modo caracter.



NAT King Cole y el enmascarado misterioso

Bueno, venimos hablando de NAT hace un par de párrafos, llegó el momento de definir qué es eso.



NAT es una sigla que significa “Network Address Translation”, o “Traducción de Direcciones de Red”. Éste es un sistema de cambio de direcciones IP utilizado para interconectar dos o más redes que tienen rangos de direcciones incompatibles. Imaginemos una empresa donde haya un telefonista que dedica sus días a recibir llamadas desde dentro de esa entidad, escuchar a alguien decir “comuníqueme con el teléfono xxx”. Esa persona lo que hará será utilizar alguna de sus líneas disponibles, y comunicará al empleado INTERNO, a través de un número de teléfono que es público, a otro número de teléfono que también es público. Si del otro lado de la comunicación tuviéramos también un conmutador telefónico, estaríamos entrando a esa red de teléfonos a través de un número público, y luego nuestra llamada sería enrutada hacia el número interno que corresponda.



Entonces, las redes de datos tendrán la forma de hacer algo similar. Como ya sabemos, las direcciones IP rápidamente se están agotando, y si tuviérmos que colocar una dirección IP pública (es decir, alguna que pueda ser directamente contactada en Internet) a cada dispositivo que en este momento utilizamos, estaríamos en serios problemas. En una empresa de cinco mil empleados, utilizaríamos esa cantidad de direcciones IP públicas. Por lo tanto, el proceso de NAT, en este caso, permitirá tener un ruteador en el borde de la red (esto es, el punto donde se interconecta la red privada y la pública, internet), que haría una traducción de las direcciones internas para que todas contacten sus destinos a través de una única, o únicas direcciones IP públicas.

Supongamos que tenemos una red que internamente tiene el rango de direcciones IP 10.100.100.0/24 (sí, máscara 255.255.255.0), es decir, que soporta unos doscientos cincuenta y tres direcciones internas. En lugar de contratar con nuestro proveedor ese número de direcciones IP públicas, contratamos una sola, supongamos la 200.12.13.14, y colocamos en el punto de interconexión el ya tan famoso ruteador.

Cada vez que algún usuario interno quiera contactar un sitio de internet, podrá hacerlo, y ese sitio leerá que la dirección que lo contactó fue la 200.12.13.14, no la dirección interna. Y cuando ese servidor envíe información de vuelta hacia la red que lo contactó, esa información le llegará al puesto de trabajo interno que originalmente la solicitó.

La primer pregunta que nos haríamos es “¿cómo sabe el servidor a qué dirección interna enviar la información, si todos los pedidos salieron por la misma dirección IP pública, que es la 200.12.13.14?”. El servidor enviará un paquete de red de respuesta, que de seguro tendrá “algo” para saber que debe llegar a ese puesto de trabajo. Caso contrario, sería muy cómico que yo pida una página de internet, y que el resultado le llegue a cualquier persona, sea mi jefe, o mi empleado.

¿Qué es ese “algo”? Es un mecanismo. Por un lado, TCP/IP en tiempo real edita las cabeceras de los paquetes de red, y agrega información destinada a esta traducción. Si la conexión fuera del tipo “uno a uno” (“one to one”), estaríamos ante lo que se denomina “basic NAT”. Pero cuando tenemos una red entera escondida detrás de una única dirección IP pública, aparte de llamarlo “uno a muchos” (“one to many”) lo que se hace es armar en el ruteador una tabla de puertos de salida para que, cuando el servidor contactado devuelve su respuesta, se verifique por qué puerto está llegando, y entonces dicha respuesta sea enviada al sistema que la solicitó. Sencillo, ¿no? A veces, este tipo de NAT es llamado NAPT, por la sigla de “Network Address and Port Translation”, ya que se están traduciendo tanto las direcciones IP como los puertos.

Ahora bien, supongamos que en nuestra red interna tengo un servidor web en una máquina que tiene la dirección IP 10.100.100.10, luego un servidor FTP en otra máquina que tiene la dirección IP 10.100.100.20, y un servidor SSH en una tercera máquina, con la dirección IP 10.100.100.30. ¿Cómo puedo hacer para que desde afuera de mi red un cliente externo pueda, por un lado, ver páginas alojadas en mi sitio interno, por el otro transferir archivos utilizando el protocolo FTP, y por el otro conectarse con un servidor mediante SSH?

Para eso tenemos una de las variantes del NAT, llamado DNAT por su significado, “Destination Network Address Translation”, o “Traducción de direcciones de red de destino”. Esto también se encontrará en el ruteador que está conectado a la dirección IP pública, y tendrá una tabla con reglas de este estilo: “si el paquete de red tiene como destino el puerto 80, debe ir al servidor web, que está en la dirección IP 10.100.100.10; si el destino es el puerto 21 para comenzar una transferencia FTP, se debe redirigir a la dirección 10.100.100.20; finalmente, si el destino es el puerto 22, se redirigirá a la dirección IP interna 10.100.100.30”.

De esta forma, tendremos inclusive la oportunidad de tener en nuestra red interna más de un servidor web. Supongamos que el sistema que muestra fotos está en la dirección IP 10.100.100.50; luego el que muestra la interfaz gráfica de un webmail está en la dirección IP 10.100.100.60; y finalmente el portal web está en la dirección 10.100.100.70. Podré definir, en el ruteador, que todo lo que ingrese por el puerto 8080 sea redirigido al puerto 80 del primer servidor, luego lo que ingrese con un destino de puerto 8090 sea redirigido al puerto 80 del seguundo servidor, y lo que ingrese con puerto 8100 como destino sea redirigido al tercer servidor. Sencillo, pero se complica un poco, ¿no? No tanto, sería peor si el DNAT no existiera. DNAT en algunos casos es denominado también “port forwarding”, dado que se toma un puerto determinado, y se reenvía a otro puerto, de otra dirección IP.

Si en cambio, necesito que una serie de direcciones internas de una red sean “NATeadas” para cambiar su dirección IP por la pública, estaré ejecutando “SNAT”, o “Source Network Address Translation”, que es similar al caso que vimos al principio.

Ahora bien, ya sabiendo todo esto, ¿qué es “IP Masquerade”, o “Enmascaramiento de IP”? Es casi lo mismo que NAT, tal como lo vimos en un primer momento, pero que puede funcionar inclusive con interfaces de red que no tengan una dirección IP estática asignada. Eso quiere decir que funciona inclusive con las conexiones de internet que tenemos en nuestra casa, así sea un cablemodem, una conexión ADSL, por módem 3G, etc.

Ah, ¿no saben qué es una dirección IP estática, y una dinámica? No hay problema, ya vamos, ya vamos.

Dinámicas y estáticas

Habrán notado que en la instalación de nuestra máquina virtual como único parámetro de red hemos configurado su hostname. No le hemos agregado, aún, ninguna dirección IP, máscara de subred, ruteador predeterminado, ni nada que se le parezca. ¿Qué valores obtendrá cuando este sistema virtualizado inicie su procesamiento?

Ejecutemos un “ifconfig eth0” y veamos su salida:

root@firewall:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 08:00:27:31:01:50
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe31:150/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:125 errors:0 dropped:0 overruns:0 frame:0
TX packets:123 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:15005 (14.6 KiB) TX bytes:12720 (12.4 KiB)

Esto quiere decir que nuestra máquina virtual obtuvo de “algún lado” la dirección IP 10.0.2.15. Esa dirección es claramente interna, ya que al menos en mi caso no se corresponde con ninguna de las redes que tengo disponible, y no la hemos configurado nosotros, entonces ¿quién la configuró? Sencillamente la configuró nuestro hipervisor, VirtualBox, a través de un servidor de direcciones dinámicas que posee embebido.

Ahora bien, como teníamos configurada nuestra tarjeta de red con el protocolo NAT, de seguro vamos a poder llegar a cualquier dirección IP pública a través de ésta, privada, y haremos la prueba con la 8.8.8.8, perteneciente a Google:

root@firewall:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=63 time=43.9 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=63 time=42.2 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=63 time=51.2 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 42.260/45.805/51.240/3.902 ms

Qué bueno, tenemos salida a internet, y no hemos sacrificado ninguna dirección IP pública más. Ésta es una muestra de cómo NAT puede ayudarnos a solucionar parte de la problemática de consumo de direcciones IP públicas.

Pero volviendo al tema de este apartado, decimos que VirtualBox nos ha entregado una dirección IP “dinámica”, dado que la misma cambiará cada vez que la máquina virtual se encienda. Si fuera estática, la misma se mantendría constante y estaría asignada en forma manual a nuestra máquina.

Pero ¿es el único parámetro que nuestro servidor de direcciones IP entregó? Claro que no.

Ejecutemos este comando para entender cuál es el juego de servidores DNS que hemos recibido:

root@firewall:~# more /etc/resolv.conf
domain fibertel.com.ar
search fibertel.com.ar
nameserver 200.42.4.207
nameserver 200.49.130.44

Estas direcciones IP son las correspondientes a los servidores que transformarán nombres del tipo “DNS”, como lo es http://www.google.com a direcciones IP, ya que en Internet, si bien uno escribe en su navegador esa dirección, denominada URL (por “Uniform Resource Locator”, o “Localizador de recursos uniforme”), cuando se accede a un sitio web, se accede a una dirección IP provista por esos servidores de DNS, o “Domain Name Service”, “Servicios de nombres de dominios”.

Por lo tanto, un servidor de direcciones dinámicas podrá entregarnos una serie de parámetros para que nuestra máquina posea una dirección IP, parámetros de servidores de nombres, ruteador predeterminado, y un sinfín de otros. El protocolo que permite este tipo de configuración dinámica se denomina “DHCP”, o “Dynamic Host Configuration Protocol”, “Protoclo de configuración de hosts dinámico”.

¿Pero qué pasaría si necesitara que sí o sí un sistema cuente con una dirección IP que no cambie cada vez que se reinicie? En ese caso lo que debiera hacer es configurar una dirección IP estática para esta máquina, y por ende también configurar otros parámetros, como ser sus servidores DNS, y su ruteador predeterminado, por lo menos, para permitir que nuestra máquina virtual tenga conexión con el mundo exterior.

Esto también se puede hacer utilizando el protocolo DHCP, ya que podría, como se hace en muchos casos, fijar del lado del servidor DHCP una determinada dirección IP a una dirección MAC, y aprovechar todos los demás servicios que este protocolo supone.

Una de las primeras conclusiones ya está saliendo a la luz, y es que claramente DHCP trabaja en un nivel, en la capa OSI, más abajo que “IP”, ya que cuando una máquina envía paquetes para buscar un servidor DHCP, lógicamente aún no posee esa dirección IP, y espera que el servidor se la entregue.

Profundamente dinámico

En esta sección veremos el protocolo DHCP en profundidad, para comprender bien cómo es que funciona, ya que el que asigne direcciones IP bajo pedido puede ser algo confuso de comprender.



Cuando un cliente configurado con DHCP se conecta a una red, envía paquetes de broadcast (para todos lados, para ser simplista) pidiendo por un servidor DHCP. El DHCP server, que tiene bajo su gestión un conjunto de direcciones IP (“IP address pool”), casi como si fuera un almacén, y esas direcciones se trataran de su stock, asigna a esa computadora una dirección, enrutador predeterminado, servidores DNS, servidor de zona horaria predeterminado, tiempo de alquiler (“lease time”, o el tiempo que dichos parámetros serán válidos en el cliente antes que el mismo deba enviar un nuevo pedido a la red, y renovar o conservar dichos valores) y otros tantos parámetros posibles. Cuando el cliente DHCP se desconecta de la red, por ejemplo al apagar la máquina, la dirección IP es devuelta al servidor DHCP para que luego pueda ser utilizada por otro cliente que así lo necesite.

DHCP utiliza dos puertos para su funcionamiento, que son lógicamente UDP (¿podrían ser de otro tipo, considerando que aún no hay direcciones IP en el cliente?), y que se corresponden con los puertos 67 y 68. DHCP, entonces, hace uso de cuatro fases para poder entregar las direcciones a sus clientes, a saber:

  • DHCP discovery: El cliente envía mensajes en la subred física de forma tal de descubrir un servidor DHCP que pueda atenderlo. Si la subred estuviera separada de la que posee el servidor DHCP, se podría jugar con los ruteadores para que reenvíen los pedidos de los clientes, y les lleguen. Y claro está, si el cliente antes estuvo configurado con DHCP, puede solicitar un DHCP server que le entregue la misma dirección IP.
  • DHCP offer: Cuando el servidor DHCP recibe un pedido de un cliente, reserva una dirección IP de su pool, y le extiende un “contrato de alquiler” de ese tipo de direcciones, o un “lease offer”. Esto no es más que un mensaje que contiene la MAC address del cliente, la dirección IP que se ofrece, su máscara de red, etc.
  • DHCP request: Como respuesta a la oferta de alquiler enviada por el servidor DHCP, el cliente envía un pedido de parámetros DHCP para recibir formalmente esos parámetros ofrecidos, y definir que la dirección IP en cuestión ya será asignada a esa máquina, quitándose del pool del servidor.
  • DHCP aknowledgement: En esta fase final, el servidor DHCP le envía un paquete al cliente con el tiempo de alquiler, y otros tantos parámetros de red.

Dependiendo de la implementación que se efectúe, un servidor DHCP puede tener tres posibles métodos de asignación de direcciones IP, a saber:

  • Alojamiento dinámico (“dynamic allocation”): Las direcciones IP disponibles se encuentran en un conjunto previamente configurado por el administrador del servidor DHCP. Las mismas son entregadas a los clientes que así las soliciten, y cuando el tiempo de alquiler termina, el servidor las reclama, y las vuelve a colocar en el conjunto o pool para ser entregadas a otro cliente. El esquema típico de los ISP (“Internet Service Providers”) es éste, ya que necesitan poder entregar direcciones IP a más clientes que direcciones IP tengan asignadas en sus rangos.
  • Alojamiento automático (“automatic allocation”): El servidor DHCP entrega direcciones IP en forma dinámica, pero guarda una tabla de correspondencias MAC – IP, de forma tal de entregar, de ser posible, la misma IP a la misma MAC, si estuviera aún disponible. Los ISP más serios tienen este esquema, y generalmente también los servidores DHCP de las empresas, también serias.
  • Alojamiento estático (“static allocation”): Las direcciones IP están fijadas y asignadas a las MAC de cada equipo. Es útil para cambiar direcciones IP de clientes sin que éstos siqquiera tengan que tocar un parámetro, o para asegurar que no habrán en nuestra red máquinas que no hayan sido expresamente declaradas.

Archívese

Vimos que los puestos de trabajo cliente podrán tener dos tipos de configuraciones de direcciones IP, estática o dinámica.

Ha llegado el momento de ver cuáles son los parámetros que se deben tocar en los diferentes puestos de trabajo *NIX para responder a una u otra configuración.

Estos parámetros se configuran, dependiendo del sabor de GNU/Linux, en diferentes archivos. Para el caso de Debian y sus derivados (Ubuntu, Mint, etc.), se debe configurar el archivo “/etc/network/interfaces”, colocando, por ejemplo, las siguientes entradas si quisiéramos que reciba direcciones IP dinámicas en una tarjeta de red “eth0”:

root@firewall:~# more /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

Nótese que en este archivo se ha resaltado la entrada que indica que la interfaz de red eth0 utilizará “DHCP” para funcionar. Cuando el sistema operativo esté arrancando, y configure esta tarjeta de red, sabrá que debe salir a buscar un servidor DHCP para recibir sus parámetros de red.

Si quisiéramos asignarle, por ejemplo, la dirección IP 10.0.2.25/24, conservando su routeador predeterminado (10.0.2.2), tendríamos que modificar este archivo para que tenga las siguientes entradas:

root@firewall:~# more /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 10.0.2.25
netmask 255.255.255.0
gateway 10.0.2.2

Nótese la palabra “static”, resaltada en la sección que configura la tarjeta eth0, así como también la dirección IP asignada, su máscara de subred, y el ruteador predeterminado.

Si tuviéramos un programa como el “resolvconf” instalado en nuestro sistema, podríamos también agregar un par de entradas correspondientes a los DNS servers a utilizar, del estilo:

dns-nameservers 200.42.4.207, 200.49.130.44

Claro está, esto se agrega en la sección de la tarjeta eth0...eso quiere decir entonces que ¿se podrían tener parámetros de DNS diferentes para tarjetas diferentes?

Ahora bien, ¿qué pasa cuando lo que tenemos que implementar es esto mismo, pero en un sistema que posee Fedora GNU/Linux, o sus derivados (Red Hat, CentOS, etc.)? En este caso el archivo a modificar no será uno solo, ya que existirá uno por cada tarjeta de red a configurar, y estará ligado en forma biunívoca a esa interfaz, sea la misma tanto física como virtual; única como conjunto de otras interfaces:

Por ejemplo, si se quiere configurar la tarjeta de red eth0, nos encontraremos con el archivo /etc/sysconfig/network-scripts/ifcfg-eth0, que para el caso dinámico tendrá un contenido como el siguiente:

[root@server1 ~]# more /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
ONBOOT="yes"
HWADDR=52:54:00:37:4B:A5
TYPE=Ethernet
BOOTPROTO=dhcp

Nuevamente, nótese la palabra “dhcp”, resaltada.

Y para el caso estático, tendrá un contenido como el siguiente, considerando que la dirección IP que deseo es la 10.0.2.35/24, con el mismo ruteador predeterminado:

[root@server1 ~]# more /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
ONBOOT="yes"
HWADDR=52:54:00:37:4B:A5
TYPE=Ethernet
BOOTPROTO=static
IPADDR=10.0.2.35
PREFIX=24
GATEWAY=10.0.2.2
DEFROUTE=yes

Virtualmente, jugando un poco

Ahora bien, supongamos que decidimos verificar cuál es la dirección de la que salen paquetes de red correspondientes a un ping efectuado desde nuestra máquina virtual, basada en una dirección IP entregada por un DHCP server, y que tiene configurado un NAT. Para ello, utilizaremos, desde nuestra máquina física (no la virtual) el comando “tcpdump”. Supongamos que estamos conectados a internet a través de la interfaz de red “eth0”.

Entonces ejecutaremos el comando “tcpdump -i eth0”, en nuestra máquina física, y mientras tanto, “ping 8.8.8.8” en nuestra máquina virtual. La salida del comando en cuestión será la siguiente (algo recortado, ya que los mensajes son larguísimos):

[root@zentraedy-l ~]# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:48:07.407951 IP 10.100.100.105.59955 > scl03s06-in-f22.1e100.net.https: Flags [FP.], seq

(...)

00:48:27.238728 IP 10.100.100.105 > google-public-dns-a.google.com: ICMP echo request, id 2555, seq 6, length 64

(...)

00:48:35.309868 IP google-public-dns-a.google.com > 10.100.100.105: ICMP echo reply, id 2555, seq 14, length 64
^C
73 packets captured
73 packets received by filter
0 packets dropped by kernel
[root@zentraedy-l ~]#

Esto quiere decir que, para el sistema que contacte, la dirección que lo estará contactando será la 10.100.100.105, que en mi caso es la dirección IP que tengo asignada en la interfaz física de mi máquina, valga la redundancia, física, y diferente de la 10.0.2.15, configurada en mi máquina virtual.

Hemos tenido, entonces, la oportunidad de verificar cómo funciona NAT en carne propia, y hasta hemos contactado máquinas en Internet desde una máquina virtual cuya interfaz de red eth0 ha recibido una dirección IP gracias a un servidor DHCP.

Ahora, subiremos la apuesta, generando una máquina virtual que se conecte a internet a través de esta máquina con la que hemos practicado hasta ahora. Bajemos nuestra máquina virtual, para poder modificar un poco su configuración. Ejecutemos con mucho cuidado el comando “poweroff”.

Primero, seleccionemos la configuración de nuestra máquina virtual, específicamente la sección de “Red” (“Network”), y seleccionaremos la solapa que se refiere al segundo adaptador (“Adapter 2”). En ella clickearemos el cuado que habilita dicha tarjeta de red. En la sección “Adjunta a” (“Attached to”) seleccionaremos “Internal Network”, y como nombre de red pondremos “interna1”, por ejemplo. Luego de esto, presionaremos “OK” para aceptar todos los cambios.

¿Qué hemos hecho? Hemos agregado una tarjeta de red a nuestra máquina virtual, y la hemos apuntado a una red interna que hemos generado, llamada “interna1”, a la cual luego conectaremos otra máquina virtual.

Ahora, crearemos otra máquina virtual, pero basada en RPM, es decir, una VM CentOS, para la cual utilizaremos la imagen CentOS-6.0-i386-bin-DVD.iso.

Seguiremos los mismos pasos que antes seguimos, pero como nombre de máquina seleccionaremos “centos1”, luego como tipo seleccionaremos “Linux” y como versión “Red Hat”. También asignaremos 512 MB de memoria RAM, y crearemos un nuevo disco del tipo de archivo “VDI”, dinámicamente alojado, de 15 GB de tamaño total.

Seleccionaremos como lo hemos hecho antes la opción “Configuración” con el botón derecho del mouse sobre la máquina virtual, asignando al CD la imagen CentOS-6.0-i386-bin-DVD.iso, y a la red la configuración “Internal Network”, y como nombre de la red interna “interna1”, la misma que agregamos a la segunda tarjeta de red de nuestra máquina virtual Debian.

Seleccionaremos “OK” para confirmar los cambios, e iniciaremos la instalación de la máquina virtual. Seleccionaremos, luego del booteo, “Install or upgrade an existing system”, saltarmos la comprobación del disco de instalación (“Disk Found” -> “Skip”), con lo que el instalador gráfico dará inicio. Seleccionaremos las siguientes opciones, a saber:

  • En la primera pantalla, sólo seleccionaremos “Next”.
  • Como idioma de la instalación, seleccionaremos “English”, y presionaremos el botón “Next”.
  • Como teclado seleccionaremos “Latin American”, y presionaremos “Next”.
  • Como tipo de almacenamiento, seleccionaremos “Basic Storage Device”, y presionaremos “Next”.
  • Si apareciera un error de inicialización de disco, presionar el botón “Re-initialize all”, siempre verificando antes que se haga referencia al “VBOX DISK”.
  • Como hostname coloquémosle “centos1”, y presionemos el botón “Configure Network”.
  • En la ventana de “Network Connections” seleccionemos la solapa “Wired”, y dentro de ella la interfaz “System eth0”.
  • Presionemos el botón “Edit”.
  • En la nueva ventana, “Editing system eth0”, seleccionemos el checkbox “Connect automatically”.
  • Seleccionemos la solapa “IPv4 Settings”.
  • En la lista que aparece en “Method” cambiemos de “Automatic (DHCP)” a “Manual”.
  • En la sección de “Addresses” presionemos el botón “Add”.
  • Configuremos la nueva dirección con “10.200.200.2” como “Address”, “255.255.255.0” como “Netmask”, y “10.200.200.1” como “Gateway”.
  • En la sección de DNS Servers coloquemos “10.200.200.1”, y presionemos el botón “Apply”.
  • En la ventana de “Network Connections” presionemos el botón “Close”.
  • Presionemos el botón “Next”.
  • Configurar la zona horaria según el lugar donde estemos. En mi caso, es “America/Argentina/Buenos_Aires”, y presiono el botón “Next”.
  • Configuremos la clave de root dos veces, y presionemos “Next”.
  • En la sección de particionamiento, seleccionemos “Use all space”, y seleccionemos “Next”.
  • Aceptemos el particionamiento propuesto por el instalador presionando “Next”.
  • Si se nos pregunta por la opción de formatear, presionar el botón “Format”.
  • Confirmar con “Write changes to disk”.
  • Dejar la opción “Install boot loader on /dev/sda”, y presionar “Next”.
  • En la selección de software, seleccionemos “Minimal”, y presionemos “Next”.
  • Cuando termine la instalación, presionar el botón “Reboot”.
  • Al final esta instalación, relativamente chica, tendremos un sistema CentOS 6 implementado, con el cual jugaremos para ver cómo se comporta detrás de una máquina Debian, y conectándose a internet a través de ella.

Cuando la máquina virtual reinicie, levantemos también firewall1, para ver qué ocurre al intentar ejecutar un ping como antes lo hicimos. ¿Sorpresa? Los paquetes de red de la máquina centos1 no salen a la red. ¿Motivo? Sencillo, su ruteador predeterminado, 10.200.200.1, no existe aún. Esa será la dirección IP que configuraremos en la segunda tarjeta de red que hemos definido para la máquina firewall1.



Para eso, ingresaremos a la máquina virtual “firewall1”, que tiene hostname “firewall”, y configuraremos su segunda tarjeta de red. Primero veremos cuáles son ahora sus tarjetas de red disponibles:

root@firewall:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 08:00:27:31:01:50
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe31:150/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:75 errors:0 dropped:0 overruns:0 frame:0
TX packets:68 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9344 (9.1 KiB) TX bytes:8579 (8.3 KiB)

eth1 Link encap:Ethernet HWaddr 08:00:27:20:21:ba
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Editemos el archivo /etc/network/interfaces, para que quede parecido a lo siguiente (nótense los agregados de las líneas que comienzan con “auto”):

root@firewall:~# vi /etc/network/interfaces

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

auto eth1
allow-hotplug eth1
iface eth1 inet static
address 10.200.200.1
netmask 255.255.255.0

Ahora relancemos los servicios de red en el sistema Debian, y veamos lo que ocurre al verificar nuevamente las direcciones IP existentes en él:

root@firewall:~# service networking restart
[....] Running /etc/init.d/networking restart is deprecated because it may not r[warnble some interfaces ... (warning).
[....] Reconfiguring network interfaces...Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/08:00:27:31:01:50
Sending on LPF/eth0/08:00:27:31:01:50
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from 10.0.2.2
DHCPACK from 10.0.2.2
RTNETLINK answers: File exists
bound to 10.0.2.15 -- renewal in 38093 seconds.
ifup: interface eth1 already configured
done.

En este último comando tenemos varios elementos interesantes. Veamos algunos de los marcados en negrita. DHCPDISCOVER, DHCPREQUEST, DHCPOFFER, y DHCPACK nos deben sonar bastante conocidos, para lo que estuvimos viendo en apartados anteriores, ¿verdad?

Por otro lado, vemos un mensaje que anuncia una renovación de dirección en una cantidad de tiempo determinado. Claro, ¿verdad?

Verificaremos con ifconfig nuevamente:

root@firewall:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 08:00:27:31:01:50
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe31:150/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1052 errors:0 dropped:0 overruns:0 frame:0
TX packets:690 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:89314 (87.2 KiB) TX bytes:83407 (81.4 KiB)

eth1 Link encap:Ethernet HWaddr 08:00:27:20:21:ba
inet addr:10.200.200.1 Bcast:10.200.200.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe20:21ba/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:2340 (2.2 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Ahora, intentaremos llegar desde “firewall” hasta “centos”, con el siguiente comando:

root@firewall:~# ping 10.200.200.2
PING 10.200.200.2 (10.200.200.2) 56(84) bytes of data.
64 bytes from 10.200.200.2: icmp_req=1 ttl=64 time=33.1 ms
^C
--- 10.200.200.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.162/33.162/33.162/0.000 ms

Efectivamente, ya la máquina “centos” forma parte de nuestra red, y podemos alcanzarla. Ese será el puntapié para las prácticas que haremos en próximos artículos. A no borrar las máquinas virtuales.

Conclusión

En este artículo hemos aprendido algo sobre NAT, DNAT, SNAT, IP Masquerade, DHCP, configuración de direcciones estáticas y dinámicas, y armamos una red interna que utilizaremos para las prácticas que vendrán. En el artículo próximo jugaremos con protocolos como DHCP, DNS, comprenderemos qué es y armaremos nuestro firewall, permitiremos y denegaremos puertos, colocaremos servidores internos y los accederemos (o no), traeremos vía TCP/IP a Snowden, seremos testigos de su casamiento en Venezuela con la hermosa espía rusa que se lo propuso, y mucho más.

¡Hasta la próxima!