Cómo usar una PC con Debian como punto de acceso inalámbrico a internet

Hola a todos!

Este quizá ha sido el post más difícil de redactar de entre todos los que he publicado en este blog. Antes de publicar tutoriales o manuales de cualquier tipo, siempre realizo los pasos que indico; principalmente cuando estoy experimentando o intentando hacer algo nuevo… Y en este caso, me topé con (¿casi?) todos los problemas que me pude haber encontrado… Al final del post dejaré una bociferación; no solo con el afán de desquitarme, sino también con la esperanza de ayudar a otros que pudieran tener los mismo problemas.

Este es un post particularmente útil para los usuarios de laptop; ya que las computadoras portátiles suelen tener más de una tarjeta de red y necesitamos que la PC a configurar como punto de acceso tenga más de una tarjeta de red. No importa cómo sean las tarjetas de red: sí cuenta con red celular, Wi-Fi, Ethernet; y tampoco importa cómo estén conectadas las tarjetas de red a la computadora; es decir, podemos usar una PC de escritorio con tarjeta ethernet tradicional y un “adaptador” Wi-Fi USB (lo que nos permite usar una PC de escritorio como punto de acceso WiFi) y como acceso a internet podemos usar una interfaz de red virtual USB creada al conectar un dispositivo Android que comparte red por USB.

Vamos a compartir internet usando una PC con Debian de forma muy similar a cómo se hace una “Zona WiFi portátil”  en Android. Antes de continuar, toma en cuenta que algunos gestores de red en Debian ya cuentan con una opción que automatiza este proceso, por lo que es conveniente verificar que puedas hacer esto de entrada con tu gestor de red.

 

 

 

El pase de diapositivas requiere JavaScript.


Bien, con esto dicho; empecemos por detectar las tarjetas de red con las que cuenta el equipo y cómo las reconoce (como las nombra) el sistema; de forma que podamos referirnos a ellas adecuadamente durante el proceso de configuración. Para esto, usamos el comando “lshw -class network”:

bash1

En el ejemplo anterior, podemos ver dos interfaces de red; cuya descripción se encuentra después de cada línea que únicamente dice “* network”. El comando nos proporciona cierta información útil para este procedimiento, como el nombre descriptivo de la interfaz, su identificador, su nombre virtual y su tipo.  Como podemos ver en la imagen, “eth0” es el nombre que recibe una interfaz de Ethernet y “wlan0” es una interfaz de WiFi.

Vamos a usar HostAP para proteger nuestra red inalámbrica, por lo que es necesario asegurarnos de que contamos con HostAP. También HostAP nos provee de un driver que nos ayuda a evitar problemas con la administración de la interfaz de red inalámbrica, pues no todos los drivers soportan actuar como punto de acceso inalámbrico. Sin embargo, existen casos donde no será posible configurar la tarjeta de red como punto de acceso inalámbrico por limitaciones de los dirvers o de la interfaz de red misma. Si tienes problemas al intentar seguir estos pasos, lo más recomendable es buscar si es sabido que tu tarjeta o “adaptador” de WiFi soporta funcionar como punto de acceso inalámbrico.

Así, para asegurarnos que tenemos todos los componentes necesarios, ejecutamos el siguiente comando (con permisos de super usuario):

# apt-get install iw wireless-tools hostapd bridge-utils

Ahora, debemos configurar HostAP. Abrimos el archivo /etc/default/hostapd y editamos la línea que inicia con DAEMON_CONF. Si está comentada (inicia con el caracter ‘#’), la descomentamos (quitamos el ‘#’).

Debe quedar así:

DAEMON_CONF="/etc/hostapd/hostapd.conf"

Ahora, el archivo al que apunta DAEMON_CONF puede no existir en su sistema. De hecho, este tutorial está hecho pensando en que el archivo /etc/hostapd/hostapd.conf no exista. Si existe, puede comentar o eliminar (bajo su propio riesgo) el contenido anterior, o crear un archivo nuevo y usarlo en lugar de hostapd.conf; por simplicidad, recomendaría crearlo en el mismo directorio /etc/hostapd

Debemos editar el arhcivo /etc/hostapd/hostapd.conf (o el que desee crear/editar), para configurar hostapd y definir nuestro punto de acceso inalámbrico. Sin embargo, aquí es importante hacer una observación aquí: la configuración recomendada por la mayoría, es hacer un puente de red usando una tarjeta de red virtual… Sin embargo, no todas los dirvers y no todas las tarjetas de red permiten crear este puente de red. Así que si esto no es posible, podemos dar la vuelta al problema usando redireccionamiento NAT como puente de red.

Si al intentar efectuar estas configuraciones, no podemos usar exitosamente nuestro punto de acceso inalámrico; podemos intentar buscar el mensaje de error:

can't add wlan0 to bridge br0: Operation not supported

Mediante los comandos:

# systemctl status networking.service
# journalctl -xe

Entonces lo más conveniente es usar la configuración con redireccionamiento NAT.


Si usamos un puente de red

Editamos /etc/hostapd/hostapd.conf de la siguiente forma:

interface=<wlan0>
bridge=br0
driver=nl80211
auth_algs=1
ignore_broadcast_ssid=0
logger_syslog=-1
logger_syslog_level=0
hw_mode=g
ssid=<Nachintoch-CT-WAP>
channel=11
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=<"Si encuentras una SSID con el nombre "Nachintoch-CT-WAP" por allí, ten por seguro que esta no es la contraseña y esa no cuenta como software libre ;)">
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
  • En la primer línea; que dice “interface“, asegúrate de escribir el nombre adecuado de la interfaz de red inalámbrica que quieres usar como punto de acceso inalámbrico. En mi caso (y en la mayoría de ellos), es wlan0.
  • En la línea 9; donde dice “ssid”, escribe el nombre que quieres que vean los posibles usuarios de tu red inalámbrica.
  • En la línea 15, escribe la contraseña que quieres usar en tu red inalámbrica. Está contraseña está asociada a un cifrado WPA2, la cual es relativamente segura (cualquier cosa es mejor que WEP, ¿no?). Debe ser de al menos ocho caracteres, pero usar al menos 12 eleva bastante la seguridad y qué mejor que usar caracteres en mayúscula, minúscula, números, símbolos especiales y la sangre de un unicornio.

Ahora, vamos a definir el puente de red br0 que usamos en la configuración anterior pero no necesariamente existe. Una vez más, el tutorial está pensado en que br0 no existe. Si ya tienes un puente de red configurado, recomendaría crear uno nuevo (br1 por ejemplo). En estos casos, asegúrate de usar el puente de red que configures en el archivo /etc/hostapd/hostapd.conf en lugar de br0.

La configuración anterior puede hacerse una sola vez. La sigueinte debe modificarse cada vez que queramos definir el unto de acceso.

Para crear el puente de red, editamos el archivo /etc/network/interfaces. Agregamos lo siguiente:

auto eth0
allow-hotplug eth0
iface eth0 inet static
    address 10.5.5.1
    netmask 255.255.255.0

auto br0
iface br0 inet dhcp
bridge-ports eth0 wlan0

Aquí es importante que sustituyas adecuadamente los nombres de las interfaces de red que estés usando: en mi caso, la salida a internet está asociada a eth0 y pretendo usar wlan0 como punto de acceso inalámbrico.

Además, si usas una configuración de Ethernet estática, debes cambiar la línea 3 para indicar la dirección IP que utilices; ya que si tu gateway no tiene DHCP configurado, no podrás conectar a Internet, y en consecuencia tu red inalámbrica actuará sólo como red local… Lo cual puede ser suficiente si solo quieres levantar un servidor de juego local o una red para un aula.

Es importante tomar en cuenta que no hemos configurado ningún servidor DHCP, por lo que la máquina que quieres usar como AP tiene una IP fija, no podrá proveer más direcciones para los demás dispositivos que se quieran conectar a la red inalámbrcia y los clientes no se podrán conectar automáticamente. Para sortear este problema, puedes crear una subred y configurar tu propio servidor DHCP dentro de la máquina. También puedes asignarles IP fijas si lo deseas; (casi) todos los dispositivos, incluso los Android, permiten cambiar la configuración IP dinámica en estática.


Si usamos redireccionamiento NAT

Editamos /etc/hostapd/hostapd.conf de la siguiente forma:

interface=<wlan0>
driver=nl80211
hw_mode=g
ssid=<Nachintoch-CT-WAP>
channel=11
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=<"Si encuentras una SSID con el nombre "Nachintoch-CT-WAP" por allí, ten por seguro que esta no es la contraseña y esa no cuenta como software libre ;)"> 
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

El resto de las configuraciones deberían funcionar sin mayor problema. Si tienes problemas con las configuraciones que sugiero, recomiendo que revises las capacidades físicas de tu adaptador de red inalámbrico y del driver; pues por ejemplo, quizá no soporta el modo “g”, pero soporta “a”.

Como en el caso de puente de red; podemos dejar la cnfiguración anterior para todas las veces. La siguiente debe efectuarse cada vez que se quiere definir el acces point.

Ahora, debemos configurar el redireccionamiento NAT. Para ello, damos en consola los siguientes comandos:

# iptables --flush
# iptables --table nat --flush
# iptables --delete-chain
# iptables --table nat --delete-chain
# iptables --table nat --append POSTROUTING --out-interface <eth0> -j MASQUERADE
# iptables --append FORWARD --in-interface <wlan0> -j ACCEPT
# sysctl -w net.ipv4.ip_forward=1

Lo siguiente es configurar un servidor DNS y DHCP. Podemos hacer esto como lo he detallado en post anteriores:

Nota: Para crear el access poont, levanté el servidor DHCP (y DNS) sobre la interfaz wlan0 en lugar de eth0 como hice en los ejemplos.


Debemos apagar el gestor automático de la red; pues vamos a usar la configuración fija que acabamos de describir. Para ello, ejecutamos el siguiente comando con permisos de súper usuario:

# service network-manager stop

Si usamos puente de red

Ahora, reiniciamos el servicio de red, limpiamos la configuración de la interfaz a usar como salida e iniciamos HostAP:

# service networking stop
# ip addr flush dev eth0
# service networking start
# service hostapd restart

Si usamos redireccionamiento NAT

Debemos definir; junto con la configuración de DNS y DHCP el modo de asignacón de IPs en la subred y de la interfaz de saida eh0.

Dejo aquí un par de archivos de configuración que puede ayudarlos a automatizar estas tareas:

http://www.nachintoch.mx/libraries/posix/wap-up.sh

http://www.nachintoch.mx/libraries/posix/wap-down.sh


¡Y listo! ahora nuestro equipo ha quedado configurado como un AP y podemos conectarnos a él desde otros. Si la configuración DHCP o IP es correcta también, tanto el equipo configurado, como los que se conecten a él, deberían poder acceder a internet.


Si usamos puente de red

Para terminar con el punto de acceso, debemos comentar las líneas que agregamos a /etc/network/interfaces:

# auto eth0
# allow-hotplug eth0
# iface eth0 inet dhcp

# auto br0
# iface br0 inet dhcp
# bridge-ports eth0 wlan0

Si usamos redireccionamiento NAT

Debemos eliminar la IP estática que hayamos asociado a la interfaz inalámbrica wlan0 y dar de baja el servidor DHCP y DNS.


En ambos casos, debemos comentar también la referencia al archivo de configuración de HostAP para evitar que se cree el puente de red br0 que puede interferir con la configuración de la tarjeta inalámbrica; por lo que comentamos la línea que creamos/editamos en /etc/default/hostapd:

# DAEMON_CONF="/etc/hostapd/hostapd.conf"

Si usamos puente de red; finalmente, restablecemos los servicios (estos son comandos en consola como súper usuario, no comentarios en un script) y damos de baja el puente de red:

# service hostapd stop
# service networking stop
# ip link set br0 down
# service networking start
# service network-manager start

Recordemos que podemos cambiar eth0; no solo por otra interfaz ethernet, si no por cualquier otra; como modem telefónico, 3G, o interfáz virual USB.


Antes de terminar, quiero compartir mi (frustrante) experiencia al escribir este post…

Antes de publicar cualquiera de mis tutoriales, verifico que su contenido sea correcto y realizo los pasos que describo para verificar que obtengo el resultado deseado. Así, puedo agregar comentarios y posible fallas y soluciones a problemas durante el procedimiento.

En este caso, no pude determinar concretamente qué me dio tantos problemas; si el software o el hardware, pues la tarjeta de red original de mi laptop era una Intel PRO/Wireless 3945ABG y pese a varias horas de esfuerzo, no logré ponerla en modo maestro… Aún desconozco si eran limitaciones del driver o del hardware.

Para que podamos configurar una interfaz de red cómo AP (access point), necesitamos que soporte dos modos: AP y master. Esto debe ser tanto por hardware como por driver. El dirver de Debian para esta tarjeta de red es el iwlegacy; contenido en el paquete iwlwifi; el cual NO es software libre, es provisto por Intel. Pero como es un dispositivo viejo, se cosidera obsoleto e Intel ya no le da mantenimiento… Como a mi ATI Raedon X1300… Gracias Nvidia e Intel, Linus Trovals ya ha hecho el gesto…

Busqué parches, intente cambiar las configuraciones que aquí exhibo, quise darle la vuelta al problema de muchas formas y ninguna me llevó a ningún lado (con la Intel 3945ABG). En todos los foros, la respuesta es “consigue otra interfaz de red” o simplemente no había respuesta; y eso que encontré foros de 2008, 2011… Me desesperé y mejor me puse a cocinar…

Mientras cortaba papas en cuadritos para un arroz que al final quedo bastante bueno; pero que necesitaba un poco más de sal, recordé que tenía una interfaz de red inalámbrica botada por allí…

Parece que a muchos de mis colegas les ofende que les pregunten si les pueden arreglar su compuatadora; a mi no me molesta: sí, si puedo, el precio es accesible y garantizo resultados. A veces de plano me dan máquinas descompuestas para vender por partes. Y en otras veces, yo mismo me quedo con piezas que pienso me pueden servir, porqué son piezas que suelo reemplazar en otras máquinas a reparar o que puedo usar yo mismo (en parte, ¡así es cómo he ido mejorando mi laptop!)

Recordé esto y buscando entre mis curiosidades, en efecto encontré una Qualcomm Atheros AR9285.

Regresé a mi escritorio y empecé a googlear de nuevo. Ambas tarjetas de red son PCI-Express; ¡bien! puedo insertarla en el puerto de la motherboard… Bueno, tuve esperanza de que funcionara por hardware, pues no encontré la lista negra ni blanca de interfaces de red inalámbrica soportada por la motherboard de mi equipo. Sin embargo, la Atheros tiene dos antenas y la Intel 3945ABG también es de dos antenas… Eso es buena señal de que puedan ser compatibles.

El driver de la Atheros viene incluido en el kernel de Linux y en Windows también, es bien sabido que soporta los modos AP y master… Empecé a creer que había encontrado la solución a mis problemas y luego empecé a desarmar mi laptop. Levanté el teclado y el horror: la Intel 3945ABG es una tarjeta PCI-Express de tamaño “normal” y la Atheros AR9285 es mini; y el puerto está sobre la motherboard sin otra placa de la que la pudiera sujetar… Pareciera que no podría reemplazarla… Luego, tuve una idea que aún creo es un poco “loca” pero que al final funcionó; y como decimos con mis colegas: si jala, ¡jala!

Bajo el puerto PCI-Express está el chip del bus norte, y las antenas tienen un cable bastante rígido. Así que conecté las antenas a la tarjeta, la inserté en el puerto PCI-Express y con cinta de aislar traté de pegarla al chip del bus norte y a una etiqueta a un costado del chip… ¡es en serio! Y para evitar que la tarjeta se levante o se mueva (por si fuera poco), puse una “plasta” de cinta de aislar de unos 4mm de altura bajo el teclado para que cuando lo cerrara, haga presión sobre la tarjeta y la termine de fijar en su lugar.

Aún tenía la duda de si la motherboard aceptaría la tarjeta, así que sin ensamblar el resto del gabinete de la portatil, la conecté al toma corriente y la encendí. Inicie sesión en Debian e inmediatamente me apareció una notificación diciéndome que “hay conexiones de red disponible”, ¡eureka! Debian reconoció la tarjeta inmediatamente como la interfaz wlan1. Hice lo mismo en Windows 7 y no tan inmediatamente, Windows también instaló los drivers de la AR9285. Funciona todo a la perfección, incluso el Bluethoot en ambos sistemas operativos.

Usando el contenido de este post, volví a configurar HostAP y etc/network/interfaces tal y como aparecen aquí, ejecuté los comandos para reiniciar los servicios y.. nope… no jaló… pero no iba a darme por vencido tan fácilemnte.

Depurando los problemas que tuve; descubrí que desde cierta versión del kernel de Linux, ya no es posible poner una tarjeta ath5 en un puente de red. Así que pensé inmediatamente, bueno; si el kernel no quiere que establezca un puente de red, usaré NAT. Así nació el post para usar una laptop como “adaptador inalámbrico” y con un poco más de esfuerzo, logré establecer un “puente” entre las interfaces eth0 y wlan1 y crear mi AP; unos dos o tres meses después de que empezara a jugar con esto.

¡voalá! por fin pude conectarme a mi nueva red local inalámbrica desde mi celular. No he probado conectarme a una red de 5GHz (pues la AR9285 soporta WiFi n, cosa que no podía la Intel 3945ABG), tengo entendido que las antenas no necesariamente van a darme toda la latencia de los 5GHz (pues la tarjeta original no la soportaba y quizá las antenas no estén diseñadas para eso), pero también es posible que sí, ya que la fecha de manufactura de esta laptop fue cuando el estándar n comenzaba a ganar presencia (en 2006).

Y bueno, ¿qué aprendí? Las tarjetas de red inalámbricas de Intel viejas, no pueden configurarse como AP y siempre hay forma de usar una tarjeta PCI-Express mini en un “slot” de tamaño tradicional. Tengo entendido que en el peor caso; que la tarjeta quede mal colocada o que la motherboard no la soporte, el riesgo de que la tarjeta o el equipo sufran daños, es mínimo; así que creo que vale la pena intentarlo.

Llevo ya aproximadamente dos meses usando este “hack” para instalar la tarjeta de red y no hay señales de que malfuncione o se esté desconectando; al contrario, creo que funciona mejor la vieja Intel.

Bueno, ya, ya me desquité. Estoy feliz porqué el próximo semestre podré usar todas las herramientas de colaboración en el laboratorio de forma más eficiente para los alumnos.

Si estás interesado en conocer el procedimiento para sustituir la tarjeta de red en una máquina como en la mía, estoy trabajando en un post al respecto que aparecerá en el futuro.


Que el límite sea la imaginación… Y el alcance del WiFi pese a la interferencia que causan los muros y los muebles…

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

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: cómo configurar una PC como servidor DHCP y gestionar una subred con él

Hola a todos!

Continuando con la serie de post para la iniciación en gestión de redes, hoy configuraremos un servidor DHCP en Debian 9.

Antes de empezar, es importante tomar en cuenta que en cada subred debe de haber solamente un servidor DHCP, por lo que debemos tener precaución al hacer estas configuraciones o podemos causar efectos no deseados en otros equipos en la misma subred.

Sin más empecemos.


Lo primero que debemos hacer es instalar un servidor DHCP. Vamos a usar isc. Para ello, hacemos en consola:

# apt-get install isc-dhcp-server

Nota: es posible que debas hacer apt-get update primero.

Al instalar isc-dhcp-server, es posible que nos arroje un error. Esto es normal, ya que la configuración por defecto no especifica ninguna interfaz sobre la que se van a atender peticiones DHCP. Justo lo que debemos hacer ahora es configurar nuestro servidor DHCP.


Editamos el archivo /etc/default/isc-dhcp-server. Agregamos la siguietne líenea:

INTERFACESv4="eth0"

Lo anterior indica que el servidor DHCP atenderá peticiones IPv4 por la tarjeta de red eth0. Podemos coonfigurar el servidor DHCP para IPv6 usando INTERFACESv6 (pueden combinarse ambas), y podemos indicar otra o más interfaces de red para atender peticiones agregado más etiquetas INTERFACES y/o cambiando el valor eth0.


Ahora, vamos a configurar detalladamente cómo queda la configuración de nuestra red. Editamos el archivo /etc/dhcp/dhcpd.conf y agrregamos lo siguiente:

option domain-name "nachintoch.local";
option domain-name-servers 10.5.5.1;
default-lease-time 600; 
max-lease-time 7200;
ddns-update-style none;
authoritative;

subnet 10.5.5.0 netmask 255.255.255.0 { 
        range 10.5.5.2 10.5.5.100; 
        option routers 10.5.5.1; 
        option broadcast-address 10.5.5.255; 
}

Con esto estamos declarando que el nombre de la subred es “nachintoch.local”; pero puede tener cualquier otro nombre que desees.

Indicamos también que los servidores DNS. En mi caso, está alojado en el equipo local, al que le asignaré la dirección IP 10.5.5.1 Podemos incluir más DNS separándolos con coma. Esto nos permite agregar DNS de redes externas (cómo el DNS del gateway), para poder replicar las consultas DNS desconocidas. Puedes omitir este campo si no estas seguro de qué configuración de DNS usar, o puedes consultar el último post en este blog sobre configuración de un serviodor DNS.

Luego se indican los tiempos que durarán las sesiones DHCP e indicamos que el  DHCP es el primario de la subred.

Finalmente, definimos propiamente una subred con dirección IP 10.5.5.0; pero el servidor DHCP sólo asignará direcciones IP entre la 10.5.5.2 y la 10.5.5.100 a los clientes; estamos reservando la dirección 10.5.5.1 como la dirección del equipo local que será el servidor DHCP, DNS y gateway. Se indicará a los clientes que la “puerta de enlace” (gateway) es 10.5.5.1 y la dirección de broadcast es la 10.5.5.255


Las configuraciones suponen que la tarjeta de red eth0 tiene una configuración estatica. Si queremos que esto sea así, una opción es modificar el archivo /etc/network/interfaces para asentar la configuración estática. En este caso es conveniente deshabilitar network-manager. Para esto, el archvo /etc/network/interfaces deberá verse así:

auto eth0
iface eth0 inet static
    address 10.5.5.1
    netmask 255.255.255.0

Recordemos que si queremos que nuestra subred tenga salida a internet, la dirección del gateway debe ser la dirección de un equipo en la súper-red que esté conectada a este equipo por el puerto; en el ejemplo, eth0.

Para deshabilitar network-manager:

# service network-manager stop

Si en lugar de deshabilitar network-manager, queremos hacer uso de él (esta es mi opción preferida por simplicidad), otra opción es abrir la configuraciones de las conexiones de red y fijar la dirección IP de una interfaz como la 10.5.5.1 (o la que queramos usar en nuestro equipo).

Screenshot_20170704_134934


Podemos hacer uso de una configuración IP dinámica, lo más conveniente es indicar en el archivo /etc/dhcp/dhcpf.conf; en la opción option domain-name-servers, la dirección IP del DNS que tenga asignado nuestro equipo y cambiar la dirección estática “10.5.5.1” que usé en los ejemplos por la que se le asigne al equipo por medio de DHCP. Sin embargo, no recomendaría del todo usar esta configuración, ya que:

  • No podemos delegar el DHCP de la red al del gateway de internet, ya que ambos DHCP entrarían en conflico (si la configuración de red no es correcta).
  • El único caso práctico para esto, es cuando tenemos un servior DHCP “esclavo” en nuestra subred, lo que en redes pequeñas puede ser redundante.

Así que por estos motivos, prefiero usar la configuración estática excepto cuando nuestra subred tiene salida a internet (y aún así, es importante configurar el DHCP de la súper-red para que a nuestro equipo siempre se le asigne la misma IP y no tener que estar haciendo cambios a la configuración).


Si estamos usando un servidor DNS como el que indiqué como configurar en el post anteror, es importante recordar que debemos editar su configuración para que corresponda con la que estamos fijando aquí. El DNS debería atender la misma interfaz de red (en este caso, eth0) y usar la dirección estática 10.5.5.1 (en lugar de 192.168.1.111 que usé en el ejemplo anterior).

Una vez que la configuración del  servidor DNS sea correcta, reiniciamos bind:

# servide bind9 restart

Si estamos usnando una configuración estática que NO depende de network-manager, debemos reiniciar networking para que los cambios a /etc/network/interfaces tenga efecto:

# ip addr flush dev eth0
# service networking restart

Estas configuraciones deberían ser suficientes para nuestro servidor DHCP. Para activarlo, sólo hace falta reiniciar el servicio correspondiente para ponerlo en marcha

Reiniciamos el servicio (o la máquina) para que los efectos surtan efecto:

# service isc-dhcp-server restart

Para deshabilitar el servidor DHCP, basta con detener el servicio y re-editar el archivo /etc/default/isc-dhcp-server; comentando la(s) línea(s) INTERFACES que agregamos en el primer paso.

#INTERFACESv4="eth0"

¡Y listo! Ahora podemos configurar la red de cualaquier equipo que se conecte al nuestro por el puerto eth0 o el que sea que configuremos. Podemos aprovechar esta configuración para atender más de un equipo con ayuda de un switch o hacendo un puente de red contra otra tarjeta de red; por ejemplo, una inalámbrica.

Esto lo realizaremos en semanas próximas.

Por lo pronto, que el límite sea la imaginación.

Debian y DNS: cómo montar un DNS local

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

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?

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?

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.

Cómo actualizar Debian de cualquier versión anterior a Stretch ( 9 )

Saludos!

Es la primera vez que lo hago, y quizá sea la primera de algunas, pero este es un repost -editado y actualizado- donde explico cómo actualizar Debian a su versión más reciente. El post original fue publicado para explicar cómo actualizar Debian de su versión 6 a la 7 (¡publicado hace 4 años!) y después olvidé mencionar que el mismo procedimiento se puede aplicar para actualizar a 8…

Para no olvidarlo y darle presencia de nuevo al post (que al parecer fue bastante útil en su momento), hago este repost; tratando de mejorar la redacción (tuve que haber aprendido algo en 4 años ¿no?) y mejorar la explicación.

Conmemoro y celebro el lanzamiento de Debian 9 Stretch con esta guía que espero les ayude a actualizar sin problemas su sistema Debian. Ya son más de cinco o seis años desde que empecé a usar Debian en su versión 6, después de varios intentos frustrados de usar otros SO basados en Linux… Incluso, después de conocer Debian traté de usar otras distros, pero ninguna me terminó por convencer. Debian es por mucho mi amigo fiel sistema operativo favorito; pareciera que no hay nada en el horizonte que pueda hacerme cambiar de opinión a corto plazo.

Desde esta trinchera felicito y saludo a todos aquellos que hacen de este sistema operativo una realidad ¡qué viva el open source! Y bien, con lo anterior dicho, pongamos manos a la obra, que esos apt-get no se van a ejecutar solos 🙂

Trivia: ¿sabias que las versiones de Debian llevan nombres de personajes de Toy Story? Stretch es el (la) pulpo morado de la tercer película que al inicio sigue a Lotso; pero se redime al final.


Antes de empezar, toma en cuenta que no hay garantías de que la actualización sea 100% exitosa. Algunos programas pueden tener conflictos al ser actualizados y puede que tengas que resolverlos de forma manual. Sin embargo, en la mayoría de los casos (o para la mayoría de las aplicaciones que uses), no debería haber problemas con la actualización.

Recomendaría hacer un respaldo de emergencia por si las dudas…


Además, les recomiendo arduamente que si tienen acceso a una red cableada de alta velocidad… ¡Úsenla!


Con las precauciones anteriores señaladas, comenzamos:

1. Es conveniente hacer una última actualización rigurosa de la versión actual que tengamos. Esto nos ayudará a evitar conflictos con las aplicaciones instaladas tras la actualización. Para esto, corremos lo siguiente en la consola y con privilegios de administrador:

# apt-get update
# apt-get upgrade

Si todo sale bien, podemos continuar. En caso de que se presenten errores, lo mejor es revisarlos y resolverlos; o la cosa se podría poner más complicada después de actualizar.


2. Migrar repositorios

Los repositorios están definidos en el archivo /etc/apt/sources.list Si no tienes el disco/USB de instalación (como es mi caso), comenta (pon un # al principio de la línea) los orígenes del disco. En el resto, trata de comprobar que existen para la versión stable.

Si en el arhcivo /etc/apt/sources.list puedes ver nombres de versiones previas de Debian (lenny, squeezy, wheezy, jessie…), es recomendado sustituir el nombre que apareza por stable. De esta manera, siempre tendrás la versión más reciente; y cuando eventualmente Debian 10 sea lanzado, puedas actualizar omitiendo este paso.

De hecho, si en lugar de ver nombres de versiones de Debian; ves puros stable, ¡puedes omitir este paso!

Si quieres apuntar rigurosamente a Debian 9, en lugar de la versión previa o stable, escribe stretch.

En mi caso; obtuve el siguiente resultado:

deb http://ftp.utexas.edu/debian/ stable main non-free contrib
deb-src http://ftp.utexas.edu/debian/ stable main non-free contrib

deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free

Nota: Puedes conservar origines con nombres de versiones previas, principalmente para mantener compatibilidad, evitar y resolver problemas con ciertas aplicaciones que causen conflicto. Esto será notorio al finalizar la actualización; si llegas a tener problemas al usar algún programa previamente instalado.


Es conveniente que los mirrors sean próximos al lugar geográfico donde se encuentre el equipo a actualizar. Por ejemplo; yo vivo en México, pero a pesar de esto, la red de la UNAM es algo lenta y prefiero usar el nodo en la universidad de Texas, EE UU. Está más lejos, pero me da mucho mejor rendimiento.


3. Actualizar los paquetes

En una consola con permisos de súper usuario; (podemos añadir el comando sudo al principio de cada comando), usamos

# apt-get update

Automáticamente deberían descargarse los nuevos paquetes.  Si obtienes un error que le dice que no es posible obtener la clave para deb-multimedia; usamos el comando apt-get install deb-multimedia-keyring y acontinuacín apt-get update nuevamente.


3. Actualizar la base del sistema

En la consola, ingresamos

# apt-get upgrade

Antes de proceder; si usas lilo, es recomendable que ingreses el comando lilo en consola. Durante la actualización, lilo puede desconfigurarse, pero llamando el comando lilo la configuración debería volver a un estado correcto.


4. Actualizar el resto del sistema.

Si usas una versión antigua de Debian, de esas que aún usaban OpenOffice por omisión; es posible que tengas problemas al actualizar, pues tu sistema usa ciertas bibliotecas basadas en Java que ya no son compatibles con Debian. Es necesario permitir al proceso de instalación (o hacerlo manualmente) que se remplacen estas bibliotecas obsoletas. De hecho, recomendaría desinstalar OpenOffice por completo antes de continuar.

Si desarrollas con Java habitualmente; no te preocupes, las nuevas bibliotecas no deberían desestabilizar tus herramientas de trabajo.

Si es el caso que usas la versión 6 o una inferior, puede convenirte agregar a /etc/apt/sources.list la siguiente línea:

deb http://ftp.mx.debian.org/debian/ testing main contrib non-free

Y dar en consola los siguientes comandos (como hasta ahora, con privilegios de súper usuario)

# apt-get update
# apt-get upgrade
# aptitude purge oppenoffice.org-common oppenoffice.org
# apt-get install
# apt-get autoremove

 

Antes de continuar, deberás comentar o borrar la línea “testing” que acabamos de agregar a /etc/apt/sources.list


Para todas las versiones: ahora ingresamos en consola y con permisos de súper usuario el comando

# apt-get dist-upgrade

Tras ingresarlo, puede que el sistema se lleve varias horas reemplazando y configurando paquetes. Si no reciben ningún error; todo ha salido bien. Sólo basta llamar al comando lilo; si es que lo usas. Si te ocurre un error, no dejes de leer lo de abajo, quizá encuentres la solución a tus problemas.


¡Listo! Ahora deberías poder reiniciar tu sistema y disfrutar de Debian 9 Stretch.

5. Para comprobar que tu actualización fue exitosa; podemos ingresar en consola los comandos (una vez que hayas reiniciado):

$ lsb_release -a

La salida del comando, debería informarte que estás en Debian 9.


Cómo comenté antes, haber modificado el archivo /etc/apt/sources.list usando stable en lugar de un nombre fijo de versión, nos permite actualizar Debian de forma más flexible, por lo que en el futuro, para actualizar Debian 9 a la versión 10; debería ser posible usando este mismo tutorial saltando el punto 2 (todos los demás son importantes).


UPDATE

Agrego algunas posibles causas de error al actualizar:

  • Elimina software obsoleto incompatible (de ser posible, sino tendrás que intentar parcharlo). Puedes ayudarte del comando # aptitude search ‘~o’ Este nos dará una lista de software programas que han sido eliminados de los orígenes. Para cada uno de los programas en la lista deberemos ejecutar # apt-get purge nombre_programa
  • Elimina orígenes que no den respuesta o conflictuen con paquetes nuevos.
  • Si obtienes un 404 al hacer # apt-get update en algunos paquetes, es posible que el origen que estés usando no se haya sincronizado por completo y debas esperar hasta 24 horas tras haber obtenido el error. Si tras 24 horas aún obtienes un 404, puedes intentar:
    • Descargar el paquete (.deb) no encontrado manualmente desde otro origen e instalarlo con # dpkg -i paquete.deb
    • Cambiar de origen.

¡Debian 9 está increíble!


Vaya, hace cuatro años todavía no inventaba mi feo slogan y terminaba mis publicaciones de golpe, cómo ha pasado el tiempo… Pero ahora existe y me despido como siempre:

Que el límite sea la imaginación. Y que el proyecto Debian siga creciendo.

Android y Picasso: como resolver cargas infinitas (pérdida de objetivos-Target)

Hola a todos!

Si usas Picasso como una biblioteca tercera en tu aplicación Android, es posible que las descargas de imágenes hechas con Picasso parezcan nunca terminar.

Si activamos la caracterísitca de depuración de Picasso; como se muestra a continuación,

Picasso picasso = new Picasso.Builder(context).loggingEnabled(true).build();

al iniciar una carga con picasso, indicando algún objetivo

picasso.load("http://www.nachintoch.mx/images/shell_sort.gif").into(target);

es posible que veamos el siguiente mensaje en la consola de depuración (“Monitor Android”):

target got garbage collected

Esto significa que se ha ejecutado el recolector de basura y se ha llevado el target que le hayamos dado a Picasso al iniciar la carga. Al haber perdido el target, la imagen nunca se mostrará en el mismo y puede dejar nuestra aplicación en un estado inadecuado.


Esto ocurre debido a que Picasso mantiene referencias débiles a los target, por lo que son susceptibles a ser recolectados. Y aunque nuestra aplicación requiera un bajo consumo de recursos, siempre existe la posibilidad de que existan múltiples servicios en ejecución o alguna otra aplicación de alto consumo de recursos; como los juegos, y el SO al requerir liberar recursos, invoque el recolector de basura y ocurra este problema con los target.

Por lo anterior; considero una buena práctica aplicar siempre esta solución cuando se trabaje con Picasso para mitigar riesgos…


Si alguna vez has trabajado con referencias; por ejemplo, al implementar listas ligadas, probablemente tengas ya una idea de la solución, y es que es bastante simple.

Basta con mantener una referencia a nuestro target en el programa. No importa si declaramos una variable específica para los target, o si los almacenamos en un arreglo o en alguna estructura de datos; como una lista, un mapa o una cola concurrente.

Para hacer esto, podemos hacer lo siguiente. Puesto que Picasso requiere que los target implementen la interfaz com.squareup.picasso.Target podemos aprovechar los métodos que nos obliga a implementar en los target.

Para mantener una referencia a los target y evitar que sean recolectados, al iniciar la carga; hacemos la referencia al target:

Target target = someTarget;

Target[] targets = new Targets[]{someTarget};
LinkedList<Target> targets = new LinkedList<>();
targets.add(someTarget);
picasso.load("http://www.nachintoch.mx/images/rgb.jpg").into(someTarget);

Una vez que se haya realizado la carga, será invocado el método de Target onBitmapLoaded o onBitapFailed; dependiendo de si la carga fue exitosa o no. En ambos, incluimos el siguiente código para liberar los targets y con ellos el espacio en memoria: queremos que el recolector se lleve los targets después de que la carga haya concluido; no antes.

if(target == this) target = null;

int index = Arrays.asList(targets).indexOf(this);
if(index >= 0) targets[index] = null;

targets.remove(this);

Dependiendo de la estrategia que hayas usado para mantener una referencia “fuerte” al target y evitar la recolección de basura sino hasta este punto del programa; donde es esperado que ocurra.


Así que en pocas palabras, la solución a la recolección de los targets durante la carga con Picasso es mantener una referencia al target directamente.

Espero esto saque de algún apuro a alguien, yo perdí un día completo para descubrir esta solución y que el límite sea la imaginación.

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

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-