Archive for the ‘Computación’ category

Android como plataforma de desarrollo

25 abril, 2019

Hola a todos,

Trayéndoles las siguientes notas del curso de Android, ahora vamos a conocer a Android como plataforma de desarrollo. Conoceremos las herramientas con las que podemos producir aplicaciones Android, cómo se administra la ejecución de las aplicaciones, cómo y qué se debe tomar en cuenta al desarrollar una aplicación.

Aquí las notas: http://www.nachintoch.mx/teaching/mobile_dev/android-framework.pdf

Anuncios

Debian: cómo enlazar interfaces de red con NAT y usar una PC como “adaptador” WiFi de otro dispositivo sin capacidad inalámbrica

1 agosto, 2017

Hola a todos!

Encaminándonos hacia la configuración de un equipo con Debian como router inalámbrico; vamos a aprender a usar NAT para enlazar interfaces de red. Esto es muy útil cuando por alguna razón no podemos establecer un puente de red por alguna razón.

Vamos a aprovechar el ejemplo para establecer un puente de red entre una interfa inalámbrica y otra cableada; lo que nos puede permitir usar una laptop (por ejemplo) como “adaptador” WiFi de una máquina de escritorio.

Sin más, comencemos.


Vamos a valernos de la configuración de DNS y DHCP que hemos trabajado en semanas anteriores. Si no cuentas con un servidor DNS y/o DHCP en el equipo que quieres usar como “adaptador inalámbrico”, puedes consultar los post de semanas anteriores que he escrito al respecto:

Vamos a usar estos servidores para montar una subred tras la interfaz eth0 (en el tutorial, si prefieres usar una tarjeta de red distinta a la que el sistema identifique como eth0; puedes, hacerlo, solo sustituye eth0 por la tarjeta que deseas usar).

Los siguientes pasos asumen que hay un servidor DNS y un servidor DHCP ejecutándose en el equipo local (a usar como “adaptador inalámbrico”) y que tiene dirección IP 10.5.5.1 (si has configurado tu servidor DNS y/o DHCP en uno o varios equipos con direcciones IP distintas; sólo ten encuenta que la dirección IP que uses en la configuración que sigue sea la que tenga asignada la interfaz que va a compartir internet).


Bien. Lo primero que debemos hacer es habilitar el reenvío de paquetes en el kernel. Para ello, editamos el archivo /proc/sys/net/ipv4/ip_foward

1

Debemos asegurarnos que aparezca un “1” en la última línea del archivo. Si “1” es el único contenido en el archivo, con eso basta.

Ahora, vamos a dar de alta la configuración que enmascara el tráfico de red al ser retransmitido de una interfaz a la otra. En consola, usamos el siguiente comando:

# iptables -t nat -A POSTROUTING -s 10.5.5.0/24 -j MASQUERADE

¡Y listo! Estas configuraciones deberían ser suficientes para servir a otros equipos que se conecten directa o indirectamente (a través de un switch opor ejemplo 😉 ) a nuestro equipo. Este tipo de puentes de red no sólo son útiles entre una interfaz wlan0 y otra eht0 para comparitr wifi a través de ethernet; podemos establecer varios puentes de redes de esta forma.

Si queremos revertir estas configuraciones, basta con deshabilitar la retransmisión de paquetes y editar de nuevo el archivo /proc/sys/net/ipv4/ip_foward de forma que ahora el único contenido (o la última línea) sea “0” (cero en lugar de uno).


La próxima semana, aprenderemos a establecer uno quizá más interesante: usar un equipo con Debian como punto de acceso inalámbrico; aka, “compartir wifi”.

Hasta entonces, que el límite sea la imaginación.

Debian y DNS: cómo montar un DNS local

18 julio, 2017

Hola a todos!

Continuando con nuestra serie de publicaciones para el administrador Jr de redes, hoy vamos a empezar a aplicar lo que hemos aprendido sobre DHCP y DNS para configurar una PC con debian como router. Este administrará una subred de forma automática (DHCP) y resolverá nombres de dominio (DNS); tanto nombres de equipos dentro de la subred como equipos externos en Internet.

Para que la subred opere de  forma “autónoma”, es necesario configurar un DHCP, pero para usar un DHCP, necesitamos también un DNS. Si nuestra subred tendrá salida a Internet o no nos interesa definir dominios locales; podemos simplemente usar los DNS de Google 8.8.8.8 y 8.8.4.4

Sino, empecemos a configurar nuestro propio servidor DNS.


Empecemos por descargar elservidor DNS bind9. Con permisos de súper usuario, ejecutamos:

# apt-get install bind9 dnsutils

Ahora, vamos a configurarlo. Empecemos por editar el archivo /etc/bind/named.conf.options

options { 
        directory "/var/cache/bind"; 
 
        forwarders { 
                // Google DNS 
                8.8.8.8; 
                8.8.4.4; 
                // DNS Local 
                192.168.1.1; 
        }; 
 
        dnssec-validation auto; 
 
        listen-on port 53 { 127.0.0.1; 192.168.1.111; }; 
        allow-query { 127.0.0.1; 192.168.1.0/24; }; 
        allow-recursion { 127.0.0.1; 192.168.1.0/24; ::1; }; 
        allow-transfer { none; }; 
 
        auth-nxdomain no;
};

La dirección 192.168.1.111 y las subredes 192.168.1.0, las pongo en el ejemplo tal y cómo me han funcionado en mi configuración. Verifica cuál es la IP que tenga asignada tu equipo y reeplaza 192.168.1.111 por la que tenga y el segmento de red (puedes inferirlo por el tercer número en tu IP) por 192.168.1.0 (es común que algunos routers usen 192.168.0.0).


Ahora; si usamos Network Manager (lo más probable si usas un entorno gráfico), es necesario impedir que actualice automáticamente la configuración de DNS o los cambios que hagamos a continuación NO surtirán efecto. Para esto, editamos el archivo /etc/NetworkManager/NetworkManager.conf Ubicamos la sección [main] y agregamos lo siguiente:

[main]
.
.
.
dns=none
.
.
.

Bien, lo siguiente es asegurarnos que en el archivo /etc/nsswitch.conf aparezca una línea con lo siguiente:

hosts:    files dns

Puede haber más configuraciones entre files y dns o después de dns; pero al menos deben aparecer estas dos en la línea hosts. Si no existen, las escribimos.


Ahora, editamos el archivo /etc/bind/named.conf.local para agregar una zona local:

zone "nachintoch.local" {
    type master;
    file "/etc/bind/db.nachintoch.local";
};

Estamos declarando una zona llamada nachintoch.lan; pero puede tener cualquier otro nombre. Sin embargo, la delcaración de los nombres de dominio locales no aparecen aquí, sino en el archivo que indicamos; en este caso /etc/bind/db.nachintoch.lan Puede tener otro nombre; pero es recomendable crear todos estos archivos en el directorio /etc/bind

Podemos probar que el archivo de configuración sea correcto usando el comando:

# named-checkconf

El contenido de un archivo con declaración de nombres de dominio locales debe verse como el siguiente (en este caso es /etc/bind/db.nachintoch.lan, pero puedes usar otro nombre de archivo):

$TTL 3D
@       IN      SOA     nachintoch.local. root.nachintoch.local. ( 
                        2017070501    ; serie 
                                8H    ; periodo actualizacion 
                                2H    ; reintento de transferencia
                                4W    ; periodo caducidad 
                                1D )  ; TTL 
 ;
                NS      ns            ; direccion del DNS

ns                A       192.168.1.111
nachintoch.local. A       192.168.1.111
server            A       192.168.1.111
router            A       192.168.1.1
gateway           CNAME   router 
gw                CNAME   router 
www               CNAME   server

La configuración anterior indica lo siguiente:

  • El dominio que se está configurando se llama “nachintoch.local” y el responsable de su mantenimiento es root (root.nachintoch.local). Podemos cambiar los nombres a gusto/necesidad.
    • El primer número es la serie de la configuración. Cada vez que se modifique este archivo, es importante incrementarlo para evitar anomalías.
    • Indicamos el tiempo con el que deseamos que otros DNS actualicen esta información.
    • Indicamos el tiempo que puede esperar para volver a intentar tranferir la zona que se está configurando.
    • Indicamos el tiempo tras el que haber actualizado se debe borrar la información de la base de datos del DNS porque puede quedar obsoleta.
    • Indicamos el tiempo de vida de la configuración (tras la que se debería de actualizar).
  • La dirección del servidor DNS. Note que no estamos indicando el nobre de dominio tal cual, sino un “nombre de varable” que se define más adelante. En todo caso, el valor se debe resolver a una dirección IP o un nombre de dominio.
  • Indicamos quién es realmente el DNS.
  • Indicamos quién responde por el dominio. Debe llamarse igual que la zona, o el archivo de configuración no tendrá efecto. Note que se debe terminar con un punto ‘.’
  • Indicamos quién es el servidor.
  • Indicamos quién es el gateway-router.
  • Finalmente, aparece un subdominio conocido; www.

Note que una vez más uso en el ejemplo las IP que me funcionaron en mi configuración (192.168.1.111 es la dirección local de mi laptop y 192.168.1.1 es la dirección local de mi enrutador).

Si nuestro equipo ha obtenido su dirección IP por medio de un DHCP, esta dirección puede cambiar y el DNS empezará a otorgar una IP que posiblemente no tiene un servidor web (que es lo que se espera atienda a www). Para resolver esto, podemos usar una configuración de IP estática, o configurar nuestro servidor DHCP para que le asigne siempre la misma IP al equipo. Veremos cómo hacer esto más adelante en posts futuros.

Podemos comprobar que la configuración sea correcta usando:

# named-checkzone nacintoch.local /etc/bind/db.nachintoch.local

Donde “nachintoch.local” es el nombre de la zona tal y como lo indicamos en el archivo /etc/bind/named.conf y “/etc/bind/db.nachintoch.local” es el archivo asociado a la zona también indicado en /etc/bind/named.conf (y el mismo que acabamos de editar y queremos probar).


Finalmente, modificamos el archivo /etc/resolv.conf; el contenido del archivo debería únicamente contener tres líneas como las del ejemplo (en mi caso, uso nachintoch.local porque es la zona que acabo de definir)

domain nachintoch.local
search nachintoch.local
nameserver 127.0.0.1

 


Ahora podemos reiniciar los servicios (sino usas Network Manager, omite network-manager)

# service networking restart
# service network-manager restart
# service bind9 restart

Y finalmente podemos verificar que el DNS funciona usando

nslookup www

Deberíamos ver una respuesta similar a la siguiente:

Server:         127.0.0.1 
Address:        127.0.0.1#53 
 
www.nachintoch.local    canonical name = server.nachintoch.local. 
Name:   server.nachintoch.local 
Address: 192.168.1.111

Por supuesto estamos viendo reflejada la configuración que acabamos de asentar, lo que en efecto significa que hemos terminado.


¡Y listo! Podemos configurar nuestro router para fijar la IP que se asigna por DHCP a nuestro equipo con DNS e incluir esa misma dirección a los DNS que usa el router. De esa forma, otros equipos en la subred podrán acceder a servicios que ofrezcamos en este equipo usando cómodamente nombres de dominio.

Y por si fuera poco, estas configuraciones pueden usarse también para administrar nuestra propia subred, usando la PC como router; esa es la historia de la próxima semana.


Si queremos deshabilitar las configuraciones que acabamos de dar, podemos simplemente comentar las siguientes líneas del archivo /etc/bind/named.conf.options

options { 
        directory "/var/cache/bind"; 
 
        forwarders { 
                // Google DNS 
                8.8.8.8; 
                8.8.4.4; 
                // Local 
                //192.168.1.1; 
        }; 
 
        dnssec-validation auto; 
 
        //listen-on port 53 { 127.0.0.1; 192.168.1.111; }; 
        //allow-query { 127.0.0.1; 192.168.1.0/24; }; 
        //allow-recursion { 127.0.0.1; 192.168.1.0/24; ::1; }; 
        //allow-transfer { none; }; 
 
        auth-nxdomain no;
};

Y reiniciar bind:

# service bind9 restart

Espero les sea de utilidad. A mi en lo personal se me ocurren muchas cosas divertidas que se pueden hacer con un DNS local; y productivas también, pues podríamos ofrecer servicios web (entre otros) en un salón de clase o una oficina.

Que el límite sea la imaginación. Y el periodo de espera entre actualizaciones del DNS.

Debian: cómo ejecutar un programa o script al inicio del sistema

11 julio, 2017

Hola a todos!

Para posts futuros, estoy trabajando en tutoriales para usar un equipo con Debian como un equipo de red (router + DNS); sin perder la funcionalidad de poderse usar como un sistema de propósito general. Para esto, podemos requerir de ejecutar una configuración que se inicia convenientemente cada vez que arranca el SO.

Hoy les comparto una forma en la que podemos iniciar un programa cualquiera durante el arranque de Debian. Debian define siete estados de ejecución (conocidos como RunLevel) que podemos usar como referencia para ejecutar un programa cuando el sistema cambia de estado. Estos estados son:

0. Apagado. El sistema está operando, pero ha comenzado el procedimiento de apagado (no reinicio).

  1. Un sólo usuario. Se usa principalmente para operaciones de mantenimiento. En este estado, no es posible utilizar todos los recursos del sistema y/o aplicaciones del usuario.

2 a 5. Multiusuario. La instalación por defecto de Debian no define diferencia alguna entre los estados 2, 3, 4 y 5; permitiéndole al usuario del sistema definir estos estados a su conveniencia.

6. Reinicio. El sistema estaba en un estado entre el 1 y el 5 y se está apagando para volver a iniciar instantáneamente. El estado 6 solo abarca la fase de apagado: cuando el sistema reinicia, pasa a estado 1. Esto es importante; ya que por ejemplo, en sistemas multiboot, al reiniciar el sistema el usuario puede elegir cargar un SO diferente.


Para ejecutar un programa durante el cambio de nivel de ejecución, empezamos por crear un archivo (cuyo nombre es indiferente) en el directorio /etc/init.d

Por ejemplo, el siguiente script se llama /etc/init.d/ejemplo.sh (sólo es una instrucción)

#! /bin/bash
### BEGIN INIT INFO
# Provides: Example loging
# Required-Start: $syslog
# Required-Stop: $syslog
# Default-Start: 1 2 3 4 5
# Default-Stop: 0 6
# Short-Description: Example
# Description: Created & tested by Nachintoch, contact@nachintoch.mx
#
### END INIT INFO
echo "Loging"
case "$1" in
 start)
 echo `date` >> /home/nachintoch/boot_log.txt
 ;;
 stop)
 echo `date` >> /home/nachintoch/shutdown.txt
 ;;
 *)
 echo "Uso: ejemplo.sh {start|stop}"
 exit 1
 ;;
esac
exit 0

Para asegurarnos que el script será ejecutado, cambiamos los permisos del mismo (puede que requieras permisos de super usaurio):

# chmod 755 /etc/init.d/ejemplo.sh

Ahora, este programa (script) no será ejecutado en ningún momento durante el ciclo de vida del sistema, a menos de que sea invocado manualmente… Necesitamos indicarle al sistema el o los niveles de ejecución en los que queremos que se ejecute.

Para ello, debemos crear un enlace simbólico hacia alguno de los descriptores de estados del sistema. Estos son siete sabios de Hyrule directorios que en principio contienen los scripts que se deben ejecutar cuando el sistema cambia a su nivel…. Digo en principio, porque las buenas prácticas prefieren contener los scripts en el directorio que acabamos de estudiar /etc/init.d, pues es posible que queramos ejecutar el mismo programa durante el arraque y el reinicio; por ejemplo.

Estos siete directorios con los scripts de arranque son:

  • /etc/rc0.d
  • /etc/rc1.d
  • /etc/rc2.d
  • /etc/rc3.d
  • /etc/rc4.d
  • /etc/rc5.d
  • /etc/rc6.d

El sistema usa los nombres de los enlaces simbólicos en los siete directorios mencionados, para distinguir arranques (1, 2, 3, 4, 5) de apagados (0 y 6)… Para simplificar las cosas, al crear el enlace simbólico, podemos usar el comando update-rc.d

# update-rc.d ejemplo.sh defaults

Si queremos evitar que los scripts sean invocados cuando cambie el estado del sistema, podemos eliminar los enlaces simbólicos de los directorios /etc/rcN.d o usar update-rc.d nuevamente:

# update-rc.d -f ejemplo.sh remove

Esto conserva el script original /etc/init.d/ejemplo.sh


Antes de terminar, necesito hacer una aclaración importante. Al terminar de explicar los siete niveles de ejecución de Debian, agregué un asterisco; porque si bien lo que dice ese párrafo es cierto, hay un detalle: no necesariamente la interfaz gráfica forma parte de los estados de ejecución. Esta es una diferencia importante que hacemos con sistemas basados en Debian y otros sistemas operativos como Gentoo o Windows, donde es posible definir el arranque del sistema como el inicio de la interfaz gráfica.

Dependiendo el entorno gráfico que utilices, puedes agregar scripts también para ejecutar durante su arranque. En mi caso, uso GTK+ porque Gnome3 es demasiado pesado para mi portatil de museo. Podemos ejecutar programas al inicio de sesión gráfica de un usuario para ejecutar programas que usan la interfaz gráfica. Yo hago esto para iniciar el salvapantalla, no porque me preocupe que una imagen se quede en el monitor para siempre (es LCD), pero porque dejar el escritorio y regresar para ver la matrix es bastante satisfactorio 🙂

Además, recordemos que los estados de ejecución del 2 al 5 son personalizables; por lo que podemos modificar las instrucciones de ejecución del inicio y del arranque del escritorio para definir uno de estos estados como “entorno gráfico”; pero esa será quizá historia de otro día.


Y bien, esto es lo que hacemos para dar de alta y baja potenciales servicios durante los cambios del ciclo de vida del sistema. Espero les sea de utilidad y que el límite sea la imaginación.

DNS – Domain Name System – ¿qué es? ¿para qué sirve?

4 julio, 2017

Hola a todos!

Este es el segundo post en una serie que pretende ser “la navaja suiza” para el administrador de redes junior (muy junior 😛 ). La semana pasada hablamos sobre DHCP, ese protocolo mágico que nos permite conectarnos a internet de forma instantánea y sin mayores complicaciones.

Sin embargo, en nuestra explicación aparece otro servicio; quizá misterioso para algunos: el DNS. Hoy vamos a entender qué es DNS, para qué sirve y porqué es importante conocerlo antes de configurar un servidor DHCP en nuestro sistema; pues puede que asigne direcciones IP correctamente, pero a menos que sepas de memoria todas las IP que necesitas para navegar por la web, no es de gran utilidad obtener dicha IP automáticamente.


Introducción – El lenguaje habitual VS el lenguaje de las máquinas

Hace algunas décadas que las computadoras dejaron de ser cosas de expertos y cada ves son más user-friendly. La mayoría de los usuarios no usa consolas de comandos, no conecta todos los periferios antes de encender el equipo y no navega la web usando IPs.

Los nombres de dominio; como se le llama a los identificadores de servidores en internet, son una forma de abstraer las IPs y  permitir acceso a servicios en internet sin tener que memorizar las direcciones IP; que pueden ser difíciles de retener (sobre todo las direcciones IPv6) o fáciles de confundir. Los nombres de dominio, pretenden ser un equivalente que las personas podamos recordar fácilmente… Aunque hoy en día la mayoría de las personas ni siquiera usa los nombres de dominio (completamente) y le delega toda la responsabilidad al buscador de Google. Sin ese buscador, la civilización como la conocemos terminaría.

Sin embargo, es importante mencionar que para establecer una conexión por la red, los nombres de dominio no son útiles. Para establecer una conexión por red, es indispensable contar con la dirección IP. Cuando escribimos en el navegador “nachitnoch.mx” o “twitter.com”, el navegador debe resolver el nombre de dominio antes de intentar conectarse a quien sea que sea el equipo con la IP a la que se resuelva el nombre. Y justo allí, es donde entra en acción el DNS.


DNS

DNS o Domain Name System (Sistema de Nombres de Dominio), es una red de clientes y servidores que opera en internet. ¿alguna vez te han comentado que la web no es internet, sino que es un subconjunto de internet? Bueno, es algo parecido.

DNS funciona como un directorio telefónico. Si eres muy joven para recordar uno de estos: es como la app de contactos. Básicamente es un directorio donde se mapea cada nombre en una (o varias) direcciones IP, de forma que el equipo pueda conectarse con un equipo, aún cuando el usuario use el nombre de dominio en lugar de la IP. Bastante conveniente ¿no?

Un servidor DNS tiene definiciones de nombres y las IP a las que resuelven. Por ejemplo:

  • google.com –> 172.217.9.174
  • twitter.com –> 104.244.42.193
  • wordpress.com –> 192.0.78.17
  • nachintoch.mx –> 198.91.81.6

Un cliente DNS, pregunta por la IP asociada a un nombre de dominio. Los clientes DNS más populares son los navegadores web; como firefox, chrome, opera, etc. Hay una herramienta que puede usarse en consola que funciona como cliente DNS, el comando host.

Los DNS están organizados de forma jerárquica y no es indispensable que cada uno tenga el catalogo completo de internet para operar. Si cada servidor DNS usara el catálogo completo de internet; sería un caos: el tráfico que cada servidor DNS generaría para mantener su catálogo actualizado sería muy intenso y no necesariamente todos se mantendrían al día; por lo que habría nombres de dominio que no sabrían resolver o que resolverían en direcciones equivocadas.

Los servidores DNS se limitan a mantener un caché de ciertos servicios que son accedidos por regularidad por los clientes y además se actualizan periódicamente cada cierto intervalo de tiempo. Algunos lo hacen cada 6 horas (por ejemplo, los primarios que deben conocer a todos los sitios .com); mientras que otros lo pueden hacer hasta cada 48 horas (hace un par de años cuando compré mi nombre de dominio, se me indicó que los DNS que conocen los sitios .mx pueden tomarse hasta ese tiempo en actualizarse).

Cuando se le hace una pregunta por un nombre de dominio a un servidor DNS y este no conoce dicho nombre de dominio, entonces el servidor replica la pregunta y espera una respuesta. Eventualmente la pregunta llegará a un servidor DNS que conoce el nombre de dominio en cuestión y responderán en cadena a quién les haya preguntado. El proceso no es lineal: un DNS puede preguntar a varios DNS por un mismo nombre de dominio; y se conformará con la primera respuesta que obtenga.

Como mencioné anteriormente, los DNS están organizados en niveles (de forma jerárquica); de forma que las consultas pueden irse canalizando por nos niveles hasta que algún DNS intermedio; o el responsable por ese subdominio, responda con la dirección adecuada.

La forma en la que se componen los nombres de dominio, indican la estructura jerárquica de los DNS. Por ejemplo:

  • nachintoch.wordpress.com –> Para acceder a este sitio, primero se intenta preguntar al DNS .com (o algún intermedio que lo conozca) quién es wordpress. Luego, se debe preguntar a wordpress quién es nachintoch.
  • es.wikipedia.com –> De forma similar, se debe primero preguntar quién es wikipedia,  para poder preguntarle a Wikipedia quén es “es”.
  • mail.google.com –> Análogamente, se debe conocer primero quién es google; para preguntarle quién es mail.

Si hubiera más subdominios (palabras a la izquierda separadas por punto), se le debe preguntar al último dominio conocido, quién es el subdominio; hasta resolver el nombre completo.


En todo caso, cuando no se logra resolver un nombre de dominio; una conexión a internet fallará, pues recordemos que la IP es indispensable.


DNS va de la mano con DHCP en las configuraciones dinámicas que estudiamos la semana pasada, ya que si el nuevo cliente (huésped) tiene una IP asignada, pero no sabe quién le puede decir quién en el mundo es nintendo.com o cualquier otro nombre de dominio, está bastante atado de manos…

Podemos navegar usando directamente las IP de los sitios y servicios a los que quiera acceder; lo cual en principio es buena idea, ya que solicitar una conexión usando directamente una IP es más rápido que usando un nombre de dominio. Recordemos que las consultas DNS se propagan por la red, y los tiempos de espera de respuesta son arbitrarios (pero nunca infinitos); por lo que debemos sumar estos tiempos de espera al tiempo en general de conexión con un servicio en internet.

Entonces…


¿Porqué resolver nombres de dominio en lugar de usar IPs?

La principal razón para usar nombres de dominio en lugar de IPs (además de su propósito original de hacer accesibles los servicios de internet), es que no todos los servicios están fijados una sola IP eternamente.

Por diversas razones, las direcciones IP de un equipo conectado a internet puede cambiar y si tenías por seguro que google es 172.217.9.174; pues consúltalo de nuevo, pues la dirección pudo haber cambiado.

Esta es la principal razón por la que es preferible siempre hacer conexiones a internet usando DNS; no solo desde el navegador, sino también al “hardcodear” direcciones en programas y aplicaciones.


Y bien; me parece que con esto, puedo dar por concluida nuestra breve introducción a los DNS. Vamos a volver a referirnos a ellos en las siguientes semanas, cuando configuremos primero un servidor DHCP que asume que existe un DNS en algún lado y posteriormente aprenderemos a configurar un servidor DNS incluyendo nombres de dominio locales para nuestras subredes.

Por lo pronto, que el límite sea la imaginación… y el precio del dominio que quieres.

DHCP – Dinamic Host Configuration Protocol – ¿qué es? ¿para qué sirve?

27 junio, 2017

Hola a todos!

En las siguientes semanas, estaré publicando una serie de post que serán la navaja suiza del principiante en administración de redes. Vamos a aprender un poco sobre los protocolos de red más utilizados al configurar una red: DHCP, DNS y posteriormente SNMP, a configurar corta fuegos para un poco de protección; hasta usar una PC como AP inalámbrico o como “antena” de WiFi para otra máquina sin WiFi.

Vamos a empezar por lo que considero lo más básico: DHCP.


Introducción

Quizá alguna vez al curiosear por las configuraciones de tu equipo, te has encontrado que la tarjeta de red puede configurarse de forma automática o estática. La mayoría de los usuarios está tan acostumbrado a que la configuración sea dinámica, que ignoran que es posible usar una configuración estática. Si es tu caso; pues enhorabuena, vamos a aprender qué son ambas configuraciones y cómo usarlas.


IP – Internet Protocol

Cómo quizá muchos de ustedes ya sepan, para que dos equipos de computo puedan comunicarse a través de intenet; es necesario que ambos tengan una dirección IP que en principio es única en todo el mundo. Digo en principio, porque actualmente no hay forma de garantizarlo, pues bajo el estándar IPv4; hay más dispositivos que acceden a Internet que direcciones IP. Si cada uno tuviera una dirección IP única, entonces habría dispositivos que no podrían acceder a internet, porque ya no quedaría ninguna dirección que otorgarles, y puesto que las IP son el equivalente a las direcciones postales, tener dos equipos con la misma IP provocará conflictos entre ambas máquinas.

El “nuevo” (ya no tan nuevo) estándar IPv6, pretende resolver este problema de forma muy “sencilla”: las direcciones de IPv4 son de 32 bits, habilitando un máximo de 4,294’967,295 direcciones IP (sí, hay más dispositivos que quieren acceder a internet que ese número. Cuentan las PC, laptops, smartphones, tablets, PDAs, consolas de videojuegos, smartTVs, etc…)

Las direcciones IPv6 son de 64 bits; es decir, el numero anterior al cuadrado, o 2⁶⁴. Es un número gigantesco. No creo que la humanidad (o las máquinas) tengan que preocuparse por agotar las direcciones IP bajo el estándar IPv6 por un buen rato. Entonces ¿donde está el problema? ¿porqué no simplemente todos usamos IPv6 y nos olvidamos de problemas?

Detrás de toda supercomputadora, hay un sysadmin que no va a dejar que se use más del 5% del procesador en todo tiempo entre todos los usuarios.

Hay varios problemas administrativos para que todos podamos aprovechar IPv6. Para empezar, a forma en la que se asignan direcciones “de alto nivel” es gestionado por una organización llamada ICCAN,  y la forma en la que IPv4 e IPv6 asignan direcciones es diferente, por lo que es necesario que expertos configuren tablas de DNS y routers para direccionar correctamente los paquetes.

Esto también implica que es necesario que todas las organizaciones cambien su configuración e infraestructura para usar IPv6, y esto es costoso; por lo que muchas no lo han hecho.

Trivia: IPv5 si existe, pero fue un desarrollo experimental y nunca se publicó concretamente. Fue inmediatamente sustituido por su sucesor IPv6 por sus diversas mejoras de carácter “urgente”. Windows 9 sí es un mito.


Gracias a la forma en la que funciona el Internet, podemos repetir direcciones IP sin causar anomalías en los equipos con las mismas IP.

El Internet es como las cebollas o como los ogros: tienen capas. Y no, no me refiero precisamente a las capas de “visibilidad” cómo la web, depweb, etc. Esos son cuentos para otra historia.

Las capas a las que me refiero, son capas de redes: subredes. La red que tenemos en casa o en el trabajo es una subred; que puede formar parte de una subred más grande y/o contener otras subredes. El módem o router que el ISP nos pone y conecta a Internet, es lo que se conoce como un Gateway. Un gateway no es más que un equipo de red que transmite mensajes hacia una red externa.

Por ejemplo, en casa, está el módem con IP:168.192.1.1, una PC con IP:192.168.1.2 y su smartphone con IP:192.168.1.3 Suponga que quiere acceder desde su PC a google.com Por ahora, supongamos que el módem sabe de antemano quién es google.com; en un post futuro aprenderemos más sobre DNS; pues los nombres de dominio son medio inútiles para las computadoras: cualquier conexión debe hacerse usando direcciones IP, los nombres de dominio sólo son una forma de hacer direcciones IP “legibles para humanos”.

Suponga que google.com es 172.217.5.174 por lo que el módem envía el mensaje a esa dirección… El origen es 192.168.1.2, hay un dispositivo con la dirección 192.168.1.3 y sólo queda el módem que es 168.192.1.1… Ninguno de los dispositivos en la subred es Google (172.217.5.174).

Cuando esto pasa; que ninguno de los equipos en la subred tiene la dirección de destino, el gateway puede enviar el mensaje por su salida a la red externa. La red externa estará compuesta por otros equipos de red; pudiendo incluir más gateways. El proceso se repetirá hasta que el mensaje llegue a una red que tenga un equipo de red que sepa que en su subred está 172.217.5.174; o que él sea ese equipo destino (Google).

El proceso real es un poco más enredado que esto, pero la idea es la misma.

Espero que lo anterior deje un poco más en claro qué son las subredes. Lo importante que debemos notar aquí, es que si dos equipos en dos subredes distintas tienen la IP 192.168.1.1 (la misma); no pasa nada: los mensajes de los equipos en una subred no alcanzarán a los equipos en otra subred (a menos de que exista una configuración especial).

La desventaja de hacer esto, es que no es posible acceder a equipos en una subred de forma remota (salvo que se realicen configuraciones especiales en el gateway); pero dependiendo de la estructura de la red del ISP, puede ser un poco más complicado (y costoso) que esto.


Direcciones estáticas

Bien, ya sabemos a grandes rasgos como se comunican los equipos por Internet y porqué las IP son tan importantes… Pero ¿de donde vienen? Como mencioné anteriormente, existe una organización que gestiona la asginación de IPs, la YoPuedo ICCAN.

La ICCAN asigna “segmentos” de direcciones IP a países y organizaciones para su uso, No gestiona todas las asignación, sólo las de nivel superior; organizaciones internas en cada país, en coordinación con la ICCAN, son las que terminan de asignar IPs.

Así, grandes corporativos tienen sus propios subsegmentos de direcciones IP en un país, instituciones de educación y gobierno tienen sus propios subsegmentos; y por supuesto: los proveedores de servicios de internet; o ISP por sus siglas en inglés (Internet Service Provider), tienen sus propios subsegmentos de red, que al final son ellos quienes terminan por asignarnos una dirección al contratar sus servicios.

Es importante notar que en general, nos dan una subred privada; es muy probable que tu dirección IP comience con 192.168. y no lo sé por que te esté espiando: eso lo hace el gobierno. Esta subred, la 192.168. es una de las que se usa por defecto para crear subredes privadas que no pueden ser accedidas públicamente desde internet.

Es decir; con las configuraciones habituales, si montas un servidor web en tu casa y copias la dirección IP que tenga asignado el equipo que hospeda al servidor e intentas conectarte a tu página web desde otra red, no podrás hacerlo. Por eso se ofrecen servicios de hosting y las IP públicas tienen un costo adicional; pero en general son ofrecidas también por los ISP para hogares y pequeñas oficinas.


Ahora, es posible que te preguntes cómo es que tu computadora sabe cuál es la IP que le corresponde. Seguramente has usado tu smartphone, tablet o laptop en un café o en una plaza con WiFi y jamás te has preocupado por configurar o preguntar por la IP que deberías usar… ¿cómo es que la máquina lo sabe?

Screenshot_2017-06-26-19-02-13

¿Qué clase de brujería es esta?

Pues parafrasee desde el principio: hay dos formas de asignarle una dirección IP a un equipo; de forma estática o de forma dinámica.


El método estático, es el más simple. Consiste en indicar de forma “permanente” la dirección que usará una interfaz de red.  Este tipo de configuraciones son usualmente usadas solo en redes de organizaciones y la mayoría de los usuarios no la usa.

Sin embargo, es muy probable que el modem o router que tengas en casa te permita configurarlo para usar direcciones IP estáticas; por lo que puedes intentarlo si quieres. Para configurar una IP estática, necesitas conocer la dirección física de la interfaz de red que vas a conectar. Esta es la “dirección MAC” que aparece listada en los detalles de una conexión.

Las direcciones MAC son asignadas por los fabricantes de las interfaces de red y se supone que estas sí son únicas en el mundo; pero todo puede pasar en este mundo.

Así, si indicarías al router a través de su interfaz de configuración (usualmente una pequeña web a la que puedes acceder si pones en el navegador la dirección de la “puerta de enlace”; como se suele mostrar al gateway) la dirección MAC de tu interfaz; no importa si es WiFi o Ethernet y una dirección IP (única en tu subred), puedes indicar explícitamente esta configuración también en tu equipo y conectarte a internet con una IP estática.

El pase de diapositivas requiere JavaScript.

En Windows podemos hacer estas configuraciones en Centro de redes > Cambiar a configuración del adaptador


Direcciones dinámicas – DHCP

Es posible que salvo que hayas tomado un curso de redes o por alguna razón hayas tenido que configurar una red, jamás hayas usado las configuraciones anteriores. Por defecto, hoy en día todos los dispositivos de red esperan ser configurados automáticamente, lo que nos permite desentendernos de todo lo anterior y simplemente esperar a que desaparezca el mensaje “obteniendo dirección IP” (que de hecho, indica que los equipos están intercambiando los parámetros de configuración de red para que puedas leer este blog y ver muchas fotos de gatitos).

DHCP o Dynamic Host Configuration Protocol (Protocolo de configuración dinámica de anfitrión/huésped), es uno de tantos protocolos de red que usamos casi todo el tiempo (sin que nos demos cuenta o lo sepamos); como HTTP, SMNP, SMTP; entre otros…

DHCP es el ente mágico que nos permite conectarnos a distintas redes sin mayor esfuerzo. Consiste en una serie de intercambio de mensajes entre un anfitrión y un huesped. En nuestras redes domésticas, el anfitrión es el módem o router que nos instala el ISP, y los huéspedes son nuestras computadoras, dispositivos móviles y electrodomésticos inteligentes.

A grandes rasgos así es como interactúa un huésped con un anfitrión; verás que es muy similar a lo que pasa cuando llegas a un hotel (sin albur):

  • HUÉSPED – ¡Hola! Quiero pertenecer a tu red.
  • ANFITRIÓN – (Revisa si hay IPs disponibles en el segmento asignado).
    • Si hay IPs disponibles:
      • ANFITRIÓN – ¡De acuerdo! Esta es tu IP, el DNS y la dirección del gateway.
      • HUÉSPED – ¡Genial! ¡Ya puedo ver gatitos!
    • Si no hay IPs disponibles:
      • ANFITRIÓN – Lo siento, pero no hay más IPs disponibles. Puedes intentarlo más tarde si lo deseas.
      • HUÉSPED – (llora).

Ya para terminar, mencionaré que un DHCP no es más que un programa de computadora: no se necesita de un dispositivo o hardware sofisticado y especializado para realizar la tarea (aunque es recomendado para redes grandes). Podemos configurar básicamente cualquier equipo de red como un DHCP y justo ese será tema de semanas siguientes. Por ahora, sólo quería dar una breve introducción; amistosa y sin detalles técnicos.

Así que me despido como siempre, deseando que el límite sea la imaginación.

Android Studio: Error “Unable to detect adb version…” al actualizar platform-tools o el IDE

6 junio, 2017

Hola a todos!

Ya hemos resuelto algunos de los errores comunes que ocurren al usar Andorid Studio y el Android SDK en sus versiones más recientes en sistemas de 32 bits: es posible hacerlo sin tener que apuntar completamente a versiones previas, como hemos visto hasta ahora.

Esta semana vamos a resolver el problema de no ver nuestros dispositivos o emuladores para ejecutar una aplicación en desarrollo, o que el sistema no reconozca el ADB como un programa válido

unable-detect-adb


Esto se debe a que las nuevas versiones del ADB son programas de 64 bits y como ya he comentado en post anteriores, no es posible ejecutar estos programas en sistemas de 32 bits; por limitaciones físicas de los equipos…. Y no; instalar 2 veces el sistema operativo, no lo hace de 64 bits.

Puesto que no podemos ejecutar un programa de 64 bits por esta limitaciones, la solución es reemplazar el binario del ADB por uno de 32 bits. Podemos usar el que viene incluido con platform-tools v23.0.1, que podemos descargar a continuación:

https://dl-ssl.google.com/android/repository/platform-tools_r23.0.1-linux.zip

Descomprimimos el archivo y en el primer nivel jerárquico de directorios que contiene el ZIP, debe aparecer un archivo llamado “adb”

platform-tools

Copiamos el archivo “adb” y lo pegamos en

<android_sdk_home>/platform-tools

En este directorio ya exista un archivo llamado “adb”; debemos sobreescribirlo, pues al actualizar Android Studio o platform-tools se inserta la nueva versión de ADB; esa de 64 bits que nos da problemas, y debemos reemplazarla por esta versión de 32 bits para poderlo ejecutar.


Una vez que hayamos sobreescrito el archivo adb, Android Studio y el sistema deberían reconocer y ejecutar correctamente el ADB y deberíamos poder contactar nuestros dispositivos y emuladores Android.

correct-adb


-El límite es la imaginación-


A %d blogueros les gusta esto: