Antecedentes
Pasó lo que tenía que pasar: el 21 de diciembre la PC que hace de server (ochentayseis) murió. De algún modo, de alguna forma, el disco rígido se apagó para no volver a prenderse.
No sería tan trágico si solamente mi (otro) blog hubiera desaparecido. El problema fue que la página de mi señora (
sop.no-ip.info) también desapareció.
Al menos estaba preparado y tenía backups de los foros y de las imágenes y artículos... en el mismo disco rígido que no funcionó más, así que aprendí que los backups no se hacen en el mismo rígido: se deben hacer en otro rígido, o en otra unidad distinta de la que están, y si tenes varias pc's en red, pues podes poner tus backups en otras unidades de red.
Más allá de las lecciones aprendidas, quedaba el tema de poner nuevamente el sitio de mi señora online. De pura casualidad, tenía por ahí, guardada en lo más hondo de mi /home una máquina virtual con un Slackware 12.1 que tenía una copia de sop.no-ip.info... puse a funcionar esa máquina mientras en un disco rígido nuevo instalaba un Slackware 14.1 y preparaba todo para que ochentayseis volviera a vivir.
El asunto, resumiendo, es que sop.no-ip.info quedo levantado y con tráfico, desde la máquina virtual primero, y desde el recién instalado Slackware 14.1 después. Mi propio blog no tenía backup, así que no se que va a pasar con él. Supongo que cuando tenga más tiempo lo voy a resucitar de alguna forma (y creo que es totalmente posible que lo haga, con ayuda de google).
Ya que estaba, quise aprovechar la instalación limpia de Slackware y migrar el site de mi señora, que está conformado por páginas estáticas, y montarlo sobre una plataforma Wordpress. Ya había comenzado a migrar algunas cosas, pero no con ímpetu... así que ya que estaba... puse manos a la obra y comencé a trabajar. Pueden darle una mirada a cómo va quedando:
sop.no-ip.info/blog, aunque aún es un trabajo que aún no está concluido.
De paso, ya que estaba, también quise optimizar un poco los contenidos de ambos sitios, es decir, de las páginas estáticas y del blog, y en parte logré esos objetivos: el servidor Apache tiene una performance aceptable para el trafico que genera (que es bastante poco, hay que aceptarlo), y las páginas del blog se adecuan al medio en que son servidas. Mmm, quedó difícil... traduzco: el blog se muestra --en tablets y pc's de escritorio--, en su tamaño normal, y en móviles muestra otro form factor que hace hincapié en la legibilidad de los contenidos. Es mejor mostrarlo en imágenes:
 |
| El blog visto en una pc de escritorio o tablet |
 |
| El blog visto en un teléfono celular |
El problema
Todo esto que estoy contando no tiene mucho que ver con el título del post, pero puedo decir que fue la plataforma desde la cual despegó el tema que quiero tratar.
Continúo:
Mientras armaba el blog y le agregaba plugins y cambiaba los colores de fondo y configuraba wp-super-cache y etc etc, quería ir viendo cómo iba quedando el diseño y si el super-cache funcionaba (y sí, funciona). La máquina que hace de server (ochentayseis) "sirve" (evidentemente) a internet y a mi propia red local. Yo, desde mi PC (noventaynueve) voy a un navegador y pongo sop.no-ip.info/blog y listo, veo lo que estoy haciendo y cómo va quedando todo. Esto es así, es decir, puedo ver el blog, porque en un archivo local, en noventaynueve, llamado:
/etc/hosts
tengo las siguientes líneas:
#
# hosts This file describes a number of hostname-to-address
# mappings for the TCP/IP subsystem. It is mostly
# used at boot time, when no name servers are running.
# On small systems, this file can be used instead of a
# "named" name server. Just add the names, addresses
# and any aliases to this file...
#
# By the way, Arnt Gulbrandsen <agulbra@nvg.unit.no> says that 127.0.0.1
# should NEVER be named with the name of the machine. It causes problems
# for some (stupid) programs, irc and reputedly talk. :^)
#
# For loopbacking.
127.0.0.1 localhost
192.168.1.33 noventaynueve.control.org noventaynueve
192.168.1.36 sop.no-ip.info
192.168.1.36 ulijese.no-ip.org
# End of hosts.
Es decir, en noventaynueve, cuando yo pongo la dirección sop.no-ip.info, la petición no sale hacia el lado de internet, sino que se busca en mi propia red local, porque eso mismo es lo que /etc/hosts está diciendo: si en un navegador escribis tal dirección, y esta está referenciada en /etc/hosts, la petición se envia a la ip que le corresponde. En la transcripción del archivo que puse a modo de ejemplo se puede ver que ulijese.no-ip.org tiene la misma ip de host, pero como ese site falleció junto al disco rígido, cuando yo en un navegador ponga ulijese.no-ip.org voy a terminar viendo sop.no-ip.info porque ese es el site que se está sirviendo en la ip referida, en este caso 192.168.1.36.
Y entonces?
¿Y entonces maestro, cuál es el problema?
Bueno, decía que en la red local no tengo ningún drama; todas las pc's (incluso las que tienen windows) tienen un archivo hosts que referencia algunas ip's con algunos nombres de máquina o direcciones de red o direcciones de páginas web.
Peerooo...
Pero pasó que quería probar cómo se veía el blog en mi teléfono celular. En su momento tuve un maravilloso Nokia N9 que, adivinen, tenía editable el archivo /etc/hosts si me logueaba como root. Cero dramas por ese lado, pero fue amargo descubrir que los dispositivos android, a menos que esten rooteados, no te permiten editar /etc/hosts. Es una cosa indignante, pero es así. Una cosa tan insignificante y no te dejan... como si no pagaras un buen dinero por tu dispositivo, encima no te lo dejan tocar como vos querés...
¿Podría rootear los móviles y las tablets? Seguro que podría ¿Y con éxito? Bueno, eso ya es más difícil, pero sí, un 80% de éxito ¿Y sin perder tiempo en buscar información y los programas necesarios y etc. etc.? Definitivamente no, no tengo ganas.
Para rootear mis dispositivos tenía (tengo) puras desventajas. Algunas de ellas:
- Pierdo la garantía del equipo.
- Pierdo tiempo.
- Si algo malo ocurre, me echan de casa (piensen qué pasa si no funciona más la tablet de mi mujer, por ejemplo, o su teléfono)
Como soy un tipo muy despierto, estuve varios meses pensando en la solución. Divagaba, y entre esos divagues estaba el hacer que una de las máquinas de la red se convirtiera en servidor DNS, de forma tal que resolviera en la red local y las direcciones que no perteneciesen a esa red local se buscaran resolver fuera, en el DNS externo que te da el Internet provider. ¿Podría hacerse? ¿Cómo podría?
Cerca de la solución
Como estoy de vacaciones, estaba cierta madrugada luchando para ver el blog de mi señora en el celular y en la tablet, porque si querés hacerlo, podés hacerlo... ¿Cómo? De una forma que para mí es incómoda y no muy práctica: habilitas la zona activa del celular, que mediante wifi le da datos de la red móvil al resto de los dispositivos wifi que los admitan. Entonces desde el celular y desde la tablet podía ver cómo iba quedando el blog.
¿Por qué digo que es incómodo (cuando el resultado termina siendo el mismo)? por esto:
Habilitar zona activa --> deshabilitar red wifi local de la tablet --> habilitar red wifi con la zona activa --> navegar y comprobar cómo quedo todo --> rogar que anden los datos móviles (Movistar no siempre anda bien) --> deshabilitar wifi con zona activa --> habilitar wifi de red local en la tablet --> deshabilitar zona activa.
Muchos pasos para poder chequear un pequeño cambio en una página.
Ya cansado de hacer esto tres o cuatro veces la misma noche, decidí ponerme a investigar cómo llevar a cabo la operación habilitar un servidor DNS. Lo suponía complicado, así que lo primero que hice fue una búsqueda pequeña en google. Encontre a BIND y unos excelentes artículos de cómo configurarlo (eran exhaustivos). También era algo complejo, como pensaba, tal vez demasiado para lo que pretendía. Cuando me decidí a implementarlo (realmente estaba cansado de hacer ese truquito de la zona activa) encontré
este artículo, y me lo leí de cabo a rabo... y fue por eso que, justamente, descubrí lo que sería la solución.
DNSMASQ: La solución que estaba buscando
Al final del articulo mencionado anteriormente ponen lo siguiente:
Nota
Bind está pensado para ser un servidor DNS de grandes redes pero para pequeñas redes como la de un centro educativo es suficiente dnsmasq, mucho más sencillo de configurar
¡Lo que es totalmente cierto! El artículo que refiere cómo configurar dnsmasq
es este. Gracias a él dí con la solución. Si bien es cierto que si leen el link sabrán cómo se hace en su totalidad y harán de este artículo algo inútil, yo igual voy a referir los pasos que dí para que funcionara en mi red, que no fueron muchos.
Primero, les presento mi red:
Dónde:
- Zyxel p-600 es el modem ADSL y el servidor dhcp de toda la red, también pasarela predeterminada (gateway IP 192.168.1.1)
- SW1 es un switch de 8 bocas x 1GB/s cada una
- SW2 idem anterior
- ochentayseis es la máquina que hace de server (IP 192.168.1.36)
- noventaynueve es mi máquina (IP 192.168.1.33).
- trece es una máquina virtual que corro desde noventaynueve de vez en cuando.
- PC W7 es una pc con windows 7
- Creo que todo lo demás es auto-explicable (tablets, laptop, celulares, centro multimedia, tv, directv)
Dnsmasq no solo servirá como un servidor DNS, sino que también podría servir como un servidor DHCP. En el caso de mi red, esa función la cumple el modem ADSL, por lo tanto, no voy a utilizar esa característica de dnsmasq.
Primero debo habilitar el servicio dnsmasq. El tema es dónde voy a habilitarlo: lo haré en ochentayseis, que es la máquina que hace de server y que estará permanentemente encendida. Estará además encargada de funcionar como DNS de todas las demás máquinas de la red.
Hay que recordar que en Slackware el servicio de dnsmasq no viene habilitado por defecto, por lo que, si queremos que arranque cada vez que se inicia el sistema, deberemos darle primero permiso de ejecucioón al script:
/etc/rc.d/rc.dnsmasq
Luego de darle permiso de ejecución, lo ejecutamos;
root@ochentayseis:/etc/rc.d# ./rc.dnsmasq start
A partir de ese momento ya esta corriendo dnsmasq. Lo comprobamos:
root@ochentayseis:~# ps ax | grep dns
25339 ? S 0:04 /usr/sbin/dnsmasq
27881 pts/3 S+ 0:00 grep dns
Ahora comprobamos que exista el archivo:
/etc/resolv.conf
y que tenga configurados los servidores de nombres externos (en mi caso, los de google)
root@ochentayseis:~# cat /etc/resolv.conf
search control.org
nameserver 8.8.8.8
nameserver 8.8.4.4
De esta forma, ochentayseis se ha convertido (mediante dnsmasq) en un servidor DNS. Lo que resta es configurar los clientes, es decir, el resto de los elementos de la red.
Mi máquina, la noventaynueve, utiliza para configurar y conectar la red networkmanager, que es el programa que se encargará de escribir /etc/resolv.conf. Para cambiar los DNS, primero desconectamos la sesión actual, vamos a la configuración correspondiente a DNS, ponemos como primer DNS a la dirección de nuestro server con dnsmasq (en mi caso la dirección de ochentayseis, 192.168.1.36) y como DNS secundario el de google por si algo le pasa a ochentayseis, porque siempre hay que tener un plan antidesastres, ¿verdad?
 |
| Propiedades dns de Networkmanager |
Una vez que terminemos, damos ok y volvemos a levantar la red. De esta forma networkmanager reescribirá el archivo /etc/resolv.conf con los nuevos valores, y la máquina recién configurada buscará como servidor DNS a la que tiene corriendo dnsmasq. Lo mismo tuvo que hacerse con la máquina con windows 7 y con la laptop que tiene windows vista: el servidor DNS primario quedó con la direccion 192.168.1.36, y el secundario con la dirección de google 8.8.8.8.
De esta forma ya está configurado el DNS (externo) para toda la red. Las máquinas buscan resolver yendo a ochentayseis, y ochentayseis busca los servidores de google. Ahora bien, ¿cómo hará dnsmasq para resolver la red interna? Utilizando el archivo /etc/hosts. En el caso de ochentayseis, tengo:
root@ochentayseis:~# cat /etc/hosts
#
# hosts This file describes a number of hostname-to-address
# mappings for the TCP/IP subsystem. It is mostly
# used at boot time, when no name servers are running.
# On small systems, this file can be used instead of a
# "named" name server. Just add the names, addresses
# and any aliases to this file...
#
# By the way, Arnt Gulbrandsen <agulbra@nvg.unit.no> says that 127.0.0.1
# should NEVER be named with the name of the machine. It causes problems
# for some (stupid) programs, irc and reputedly talk. :^)
#
# For loopbacking.
127.0.0.1 localhost sop.no-ip.info
192.168.1.36 sop.no-ip.info ochentayseis.control.org ochentayseis
# End of hosts.
Cada vez que se agregue un elemento de red a /etc/hosts debe reiniciarse dnsmasq. Se hace de la siguiente forma:
root@ochentayseis:/etc/rc.d# ./rc.dnsmasq restart
Solo faltaba una configuración más para que los móviles funcionaran: entrar a la configuración del modem Zyxel y cambiar en él los DNS. ¿Por qué? Pues porque los dispositivos android (no se si todos, pero por lo menos los que yo tengo) no permiten ningún tipo de configuración, simplemente "descubren" la red wifi y la utilizan. Si la red wifi sigue resolviendo por los DNS predeterminados del modem ADSL, todo lo hecho no valdría para nada... así que entonces entramos a la configuración del modem y...
 |
| Configuración DNS en setup del modem ADSL Zyxel P600 |
En Primary DNS server ponemos la dirección de la máquina con dnsmasq, y como Secondary DNS server la direccion 8.8.8.8 de google (en mi caso) o la del internet provider que ustedes tengan.
De esta forma conseguí entrar desde los celulares y las tablets mediante la red wifi a los sites que tengo en mi server dentro de mi lan.
=) Saludos.
