Archivo de la etiqueta: red

Firewall ¿qué es? ¿para qué sirve?

Hola a todos,

acercándonos a la recta final de esta larga serie de posts sobre configuraciones de red para sistemas Debian, vamos a terminar aplicando un firewall para tener un mejor control sobre el contenido al que tienen acceso los usuarios.


Pero, ¿qué es un firewall? ¿para qué precisamente sirve? Bueno, empecemos por responder la primer pregunta.

Un firewall es un software; un programa de computadora, que restringe tráfico con ciertas características de forma local en un equipo. Es importante notar que las restricciones de tráfico son locales: un firewall (en principio) no afectan a otros equipos.

Estas restricciones de tráfico pueden realizarse por dos motivos principales:

  • Seguridad. Una de las prácticas de seguridad más importantes y básicas es “cerrar” todos los puertos que no usemos en nuestros equipos.
  • Productividad. El administrador de red puede restringir las páginas que son visitadas para evitar distracciones; principalmente en ambientes laborales.

Vamos a detallar un poco lo que quiere decir el primer punto.


Para que un programa pueda conectarse a internet (en general, para que un programa pueda comunicarse con otro remoto), necesita de un “puerto” o “socket”.  Los puertos son una de las varias abstracciones que se hacen para comunicar dos programas que se ejecutan en equipos diferentes.

Esto se debe principalmente al deseo de poder comunicar dos equipos que pueden tener una arquitectura completamente diferente, sistemas operativos diferentes e incluso usar tecnologías diferentes para conectarse a la red.

Por ejemplo, podemos suponer que el servidor que hospeda este blog, es parte de una gran infraestructura distribuída de muchos racks de servidores que ejecutan Linux y se conectan entre sí por Ethernet, pero muy probablemente tienen salida a internet por fibra óptica.

Pero por otro lado, podemos leer el blog usando cualquier tipo de laptop; manufacturada por cualquier fabricante y que ejecuta distintos sistemas operativos; no necesariamente linux. Puede ser un equipo de sobremesa e incluso cualquier variedad de dispositivo móvil. Además, todos estos pueden conectarse a la red usando tecnologías muy diferentes; como USB, Ethernet, WiFi, 3G, 4G, etc…

Para que pueda existir todo este ecosistema de equipos tan diferentes que al final de cuentas pueden comunicarse por red, las redes IP (y muchas otras) utilizan un “stack”, una pila de capas de abstracción; donde cada capa se encarga de abstraer uno o varios aspectos que podrían ser diferentes en los equipos que se comunican: como el sistema operativo, el tipo de la interfaz de red, la velocidad de procesamiento, etc. Este stack a su vez está basado en un estándar (teórico) llamda “modelo OSI”.

Sin entrar en mucho detalle en estas capas de abstracción (las más “profundas” pueden confundir a aquellos que no estén acostumbrados a términos técnicos o no programadores); la primer capa se conoce como la de aplicación. Es decir, esta “capa” no son más que los programas que se conectan a la red. Aquí también están los servidores web, los servidores DNS y DHCP; de los que hemos hablado en post-anterior.

La segunda capa es la de transporte. Esta abstrae los mensajes que producen las aplicaciones; cualesquiera que sean y los envuelven en otro tipo de mensaje. Aquí es donde involucramos a los puertos.

En la mayoría de los casos, una computadora tiene una o dos tarjetas de red; pero también ejecuta muchas más aplicaciones que desean conctarse a internet. Por ejemplo, puede haber múltiples servicios preguntando por actualizaciones de las aplicaciones a las que pertenecen cada cierto tiempo; y cada pestaña de un navegador web, suele solicitar su propia conexión a la red.

Si el sistema operativo le asignara la tarjeta de red completa a la primer aplicación que solicitara acceso a internet, todas las demás quedarían bloqueadas y esperando por tiempos indefinidos por acceder a la red. Sería casi imposible usar un navegador sin obtener frecuentemente un mensaje de error porque “no es posible conectar”.

Para que todas (o la mayoría) de todas estas aplicaciones que desean conectarse al mismo tiempo a la red puedan hacerlo; al solicitar acceso, deben de indicar el número de puerto por el cuál quieren recibir mensajes del exterior.

Podemos pensar en los números de puertos cómo en direcciones que tendrían plataformas en un puerto real. Los botes o barcos que lleguen al muelle (la tarjeta de red), tendrán que dirijirse a una y una sola plataforma específica para anclar y desembarcar. Así, los barcos deben sber a cual de las plataformas deben anclarse y entregar su carga, para que llegue a su destino.

Los mensajes en los que son envueltos los mensajes que salen de la capa de aplicación, indican el número de puerto por el que deben salir; mismo por el que se espera que llegue la respuesta del programa remoto al que está destinado el mensaje original. La capa de transporte tiene algunas funcionalidades adicionales, pero por simplicidad y para los fines de este post; vamos a quedarnos sólo con esta de los números de puerto.

Los números de puerto son tan importantes para la comunicación en redes IP, que de hecho los primeros números de puerto; entre el 1 y el 1024 están reservados y usualmente se requieren privilegios de administrador o súper-usuario para permitir que una aplicación haga uso de ellos. Se dice que están reservados, porque están asociados a programas o protocolos muy comunes en internet; y básicamente se da por hecho que si un mensaje está destinado a un cierto número de puerto reservado, podemos estar casi seguros de que se trata de un mensaje en cierto formato, con cierto protocolo o creado por cierta aplicación.

Algunos de los números de puerto reservado son los siguientes:

  • 20 FTP
  • 21 FTP
  • 22 SSH (SFTP)
  • 23 Telnet
  • 53 DNS
  • 67 DHCP
  • 80 HTTP
  • 161 SNMP
  • 443 HTTPS
  • 666 Doom

Cuando un puerto no está asociado a ninguna aplicación ene ejecución y el sistema recibe un mensaje dirigido a ese puerto, el sistema simplemente descarta el mensaje; pues el destinatario no existe en ese momento. Es como recibir una carta dirigida a alguien que ya no vive en una casa.

Sin embargo, los distintos programas que se ejecutan en el sistema; incluyendo aquellos propios del sistema operativo que se encargan de la administración de la tarjeta de red y la asignación de puertos, pueden ser vulnerables a la recepción de ciertos mensajes con un formato especial que permite explotar vulnerabilidades de estos programas.

Algunos ataques por parte de hackers de sombrero negro, son perpetrados de esta forma; uno de los casos más conocidos recientemente fue heartbleed, que explotó una vulnerabilidad de este estilo en los certificados que usa HTTPS para obtener un pequeño segmento de memoria que permitía desencriptar los mensajes seguros.

Por esta razón es útil restringir el acceso remoto a ciertos puertos; cerrándolos a pesar de que puedan estar ligados a una aplicación en ejecución. Esta es una de las principales funciones de un firewall, una forma de evitar el acceso de terceros a nuestro equipo.

Un firewall puede evitar que mensajes de red que procedan de ciertos puertos, direcciones IP o usuarios no conocidos sean rechazados ANTES de que pasen a la aplicación que los espera, justamente para evitar este tipo de ataques. También permite que el equipo local se concecte a ciertos puertos, direcciones IP o nombres de dominio (aka páginas web), creando limitaciones en las conexiones que se puede crear el equipo.


En resumen: los firewall son un programa de computadora bastante útil que puede ayudarnos a aumentar nuestra seguridad en línea al evitar que ciertos equipos o usuarios remotos; o cualquiera, se conecte con cierta aplicación o número de puerto en nuestro equipo.

También son usados para evitar la intercepción de mensajes en línea y reducir el SPAM. Por lo que antes de simplemente cerrar el diálogo del sistema que te invita a configurar un firewall, deberías considerar hacerlo seriamente (además de actualziar el equipo).

Justo en el siguiente post y último de esta serie, aprenderemos a configurar un firewall en Debian usando IPTables. Otros firewall para otras plataformas son más amigables con el usuario y pueden resultar más fáciles de usar; por lo que si usas otro sistema operativo que no sea Debian, recomiendo arduamente que revises tu configuración para mantenerte seguro.


El límite es la imaginación. Y el número de puertos seguros en un servidor remoto.

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 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.

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.

Android: Cómo actualizar un Samsung Galaxy A5 (SM-A500M) a Lollipop

Hola a todos!

He vuelto para compartirles un método muy bueno que enocntré para actualizar un Galaxy A5 a Android 5.0.2 Lollipop. Esta actualización puede hacerse usando Kies, pero decidí hacerla con Odin para instalar una ROM no asociada a ningún proveedor de servicio de telefonía celular.

Les dejo a continuación un enlace a un tutorial donde se explica detalladamente e ilustrado, paso a paso cómo hacer la actualización de firmware. Para aquellos usuarios con el modelos A500M, podemos elegir la versión brasileña del SO, esta viene desbloqueada de red, y al hacer la actualización a Lollipop.

http://www.androconsejos.com/2015/09/actualiza-tu-samsung-galaxy-a5-con.html

Espero sea de utilidad!

Cómo liberar un Samsung Galaxy Ace (GT-S5830M y muchos otros modelos de la línea Samsung Galaxy) de la red

Saludos cibernautas!

Les traigo un nuevo post, luego de que Telcel me quedará mal en la liberación de mi teléfono celular… El pésimo servicio de la compañía me ha empujado a cambiar de compañía de telefonía móvil, pero no quiero cambiar el teléfono, así que decidí desbloquear la red “por la buena” asistiendo a un centro de atención. Había intentado el desbloqueo por internet, pero resultó que tenía que ir al centro de atención forzosamente.

Así que fui a un centro de atención Telcel y les dejé en servicio mi celular por hora y media… Todo para que me salieran con que el ingeniero no pudo desbloquearlo porque el teléfono no aceptó la actualización… A pos que ingeniero tan poco ingenioso…

Entonces, tuve que hacerlo por mi cuenta, ya que al parecer Telcel no puede ni siquiera intentar ofrecer un buen servicio aún yendo a sus instalaciones.

Al grano. Cómo desbloquar la red de un Samsung Galaxy Ace (GT-S5830M) para usarlo con cualquier compañía. Según la aplicación, el procedimiento también sirve para los siguientes modelos: GT-S5360, GT-S5360B, GT-S5360B, GT-S5360T, GT-S5363, GT-S5369, GT-B5510, GT-S5570I, GT-S5830I, GT-S5830C, GT-S5830M, GT-S5839I.

Antes de empezar, recomiendo que hagas una copia de tus contactos y de todo el contenido en la memoria de teléfono; ya que si por alguna extraña razón algo saliera mal, el teléfono podría brickearse.

Paréntesis para quejarme. En Telcel me dijeron que en dispositivos con más de un año de antigüedad, anulan la garantía en caso de que ellos mismos brickeen el teléfono y que no hacen respaldos de datos y puedes perder todo lo que haya… Aunque quizá no haya mucho de qué preocuparse, ya que son inútiles y no hacen nada. Tal parece que perro que ladra, no muerde.

Regresando al proceso de liberación. Primero que nada, necesitas ser súper usuario. Ya había compartido un post muy bueno donde explican cómo hacer esto; aquí les dejo el enlace: https://nachintoch.wordpress.com/2013/06/15/rootear-el-samsung-galaxy-ace-gt-s5830m/

Ya que rooteamos el teléfono, vamos a instalar la aplicación desde Google Play, Galaxy ToolBox: https://play.google.com/store/apps/details?id=com.doky.sgtoolbox

Abrimos la aplicación y ya que estemos sobre la pantalla principal, seleccionamos la opción “Respaldo de partición EFS” y en la pantalla que aparece, seleccionamos la opción de hacer un respaldo (backup). Regresamos a la pantalla principal y ahora seleccionamos la opción “Desbloqueo de red”. En la nueva pantalla seleccionamos “Desbloquear mi Galaxy”. Con esto, la red habrá quedado desbloqueada y podremos utilizar nuestro teléfono con cualquier chip de cualquier compañía de cualquier país. Podremos comprobar que la red esta libre yendo al marcador del teléfono e ingresando *#7465625#. Aparecerá un cuadro de diálogo emergente en el que deberíamos leer “Network Lock [OFF]” (si hacemos esto antes de realizar el procedimiento de desbloqueo, aparecerá que el bloqueo de red está activado, o no y entonces este procedimiento no es necesario 😛 ).

El poder de un Android root es muy grande, deja que con él; el límite sea tu imaginación. Y por cierto, usuarios Telcel, les recomiendo ampliamente que desbloqueen sus móviles y cambien de compañía, por que lo único que es todo territorio Telcel, es el mal servicio. Saludos a todos. Espero les sea útil.