Archivo de la categoría: web

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

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 configurar Apache para usar archivos de configuración locales .htacces con RewriteEngine

Hola a todos!

Esta es una pequeña guía/mini-tutorial en el que explico brevemente cómo configurar un servidor web Apache en sistemas basados en Debian (estos pasos me han servido en un host con Debian 8 y Apache2), para usar archivos de configuración locales .htacces y permitir servir más de un sitio web con distintas preferencias entre ellos sin tener que declararlo directamente en el servidor; o simplemente para usar distintas configuraciones en distintas secciones de una misma página web.

Comencemos con los pasos que debemos seguir:

  1. Para empezar, debemos modificar el archivo “/etc/apache2/sites-available/000-default.conf”. Debemos agregar una linea como la siguiente:
    <Directory /var/www/ >
        Options Indexes FollowSymLinks
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>
    

    Lo que acabamos de hacer fue indicar desde el directorio raíz del servidor (en este caso /var/www/, si usas una ruta distinta debes hacerla explícita en lugar de /var/www) que vamos a permitir: redireccionamientos y sobreescritura de las configuraciones de forma local desde cualquier sub-directorio a partir de la raíz indicada (insisto, en este caso /var/www).

  2. Ahora vamos a habilitar el RewriteEngine, para esto creamos un enlace simbólico al RewriteEngine desde el directorio de mods habilitados:
    ln -s /etc/apache2/mods-available/rewrite.load
     /etc/apache2/mods-enabled/rewrite.load

    De esta forma podemos usar RewriteEngine para hacer redireccionamientos, acortar URL y parámetros de formularios.

  3. Finalmente, sólo nos hará falta agregar el MIME Type de plataforma de desarrollo; por ejemplo PHP, para que al hacer redireccionamientos con RewriteEngine dentro de los .htaccess a páginas que deben ser procesadas por la plataforma de desarrollo se haga en efecto y no le envíe al cliente el fuente del código de la página. Para ello modificamos el archivo
    /etc/apache2/mods-available/mime.conf

    Por ejemplo, para habilitar la interpretación de scripts PHP, agregamos la línea:

    AddType application/x-httpd-php .php

Podemos hacer lo mismo para habilitar Python-Django, Java EE, Ruby on Rails, etc…

¡Y listo! Ahora podemos crear archivos de configuración locales .htaccess y agregar en el las instrucciones que deseamos, como RewriteEngine On y redireccionamientos… Puesto que hemos permitido la configuración local en cascada en el paso 1, recuerda que las instrucciones de un .htaccess en un directorio afectará a todos los sub-directorios que no cuenten con un .htaccess que sobrescriba (redefina) las instrucciones de este.

Espero les sea de utilidad. Que el límite sea la imaginación.