jueves, 26 de septiembre de 2013

Revisar si un puerto esta escuchando en un servidor remoto en LINUX

Como Revisar si un puerto esta escuchando en un servidor remoto:

Normalmente se utiliza telnet hotname y el puerto

Sin embargo en caso de no contar con Telnet es posible usar

nc -v hostname 80 
 
o tambien
 
curl hostname:80
 
 
Espero y les sirva 


M.MGZ
 

miércoles, 14 de agosto de 2013

Informacion UNIX

Favor de enviarnos todas sus preguntas al blog, en cuanto sean recibidas, se analizan y se resuelven en menos de 24 horas.

TODO es


TOTALMENTE GRATIS, NO COBRAMOS POR CONSULTORIAS.

martes, 6 de diciembre de 2011

Cambiar el nombre de un equipo Solaris

Cambiar el nombre a un equipo Solaris en realidad es algo muy sencillo, simplemente se debe modificar el archivo /etc/nodename con el nuevo nombre.

También debemos hacer algunas modificaciones en los archivos de configuración de red para que funcione correctamente, se debe modificar el archivo de la interfaz de red principal /etc/hostname.interfaz y en el caso de usar una IP fija, también se deberá modificar el archivo /etc/hosts

Una vez realizados estos cambios se debe reiniciar el equipo para que utilice la nueva configuración.

También es cierto que este cambio se puede realizar en línea por medio del comando hostname, en cualquier caso, los archivos deben modificarse para que el cambio sea “permanente”. El cambio en línea no es recomendable en servidores en producción debido a que hay aplicaciones que al iniciar indagan el nombre del equipo y lo utilizan durante la “corrida” del programa como parte de su funcionalidad, por lo que siempre se recomienda hacer el cambio con aplicaciones abajo.

lunes, 28 de noviembre de 2011

Configuración avanzada de un servidor DNS BIND

En una entrada anterior vimos cómo configurar a un servidor DNS BIND para contener un dominio, el loopback y una zona con los servidores raíz de Internet.

En esta ocasión veremos cómo activar el rndc y la actualización dinámica (DDNS).

Para esto utilizaré dos equipos Solaris 10, uno contendrá el servidor y otro lo utilizaremos como cliente.

Además del archivo con los servidores raíz (db.cache) y del loopback (db.127.0.0) voy a crear dos archivos más, uno para el dominio y otro para la resolución inversa de mi red local (192.168.100.0/24)

db.unixymas.com.mx

$TTL 3h
; Zona unixymas.com.mx
@       IN SOA draco.unixymas.com.mx. administrator.unixymas.com.mx. (
                01 ; serial
                3h ; refresh
                1h ; retry
                1w ; expire
                1h ) ; negative ttl
@       IN NS draco.unixymas.com.mx.
draco   IN A 192.168.100.10

db.192.168.100

$TTL 3h
; Zona 100.168.192.in-addr.arpa
@       IN SOA draco.unixymas.com.mx. administrator.unixymas.com.mx. (
                01 ; serial
                3h ; refresh
                1h ; retry
                1w ; expire
                1h ) ; negative ttl
@       IN NS draco.unixymas.com.mx.
10      IN PTR draco.unixymas.com.mx.

Observen que en realidad los dos archivos solo contienen los registros SOA y NS, esto es porque los vamos a actualizar en forma dinámica.

Para actualizar en forma dinámica una zona es necesario otorgarle la autoridad a la zona mediante la opción allow-update en el archivo de configuración /etc/named.conf . Se le puede otorgar la autoridad a una IP, a una lista; pero la forma más segura es por medio de una llave. Dicha llave es una cadena cifrada con el algoritmo HMAC-MD5.

Lo primero es crear la llave por medio del comando dnssec-keygen en la forma: dnssec-keygen –a HMAC-MD5 –b 128 –n HOST llave

# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST update-key
Kupdate-key.+157+04139

Con este comando generamos 2 archivos uno con terminación .key y otro con .private . En el caso de este algoritmo en realidad los dos archivos contienen información similar, vamos a revisar el .private

Kupdate-key.+157+04139.private

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: onuHJl6U5lqKEk8/9mbMQw==
Bits: AAA=

La cadena señalada como key es la que vamos a utilizar.

El archivo de configuración queda de la siguiente forma:

options {
        directory "/var/named";
};

zone "." {
        type hint;
        file "db.cache";
};

zone "0.0.127.in.addr.arpa" {
        type master;
        file "db.127.0.0";
};

zone "unixymas.com.mx" {
        type master;
        file "db.unixymas.com.mx";
        allow-update { key "update-key"; };
};

zone "100.168.192.in-addr.arpa" {
        type master;
        file "db.192.168.100";
        allow-update { key "update-key"; };
};

key "update-key" {
        algorithm hmac-md5;
        secret "onuHJl6U5lqKEk8/9mbMQw==";
};

Ahora ya podemos iniciar el BIND, desde otro equipo, en el que ya configuramos al servidor draco.unixymas.com.mx como su servidor de dominio, vamos a agregar un nuevo nombre por medio del comando nsupdate en la formal: nsupdate –k archivo.key ó nsupdate –k archivo.private

Esto nos va a llevar al modo interactivo, desde el cual, podemos agregar o eliminar nombres con los siguientes comandos:

update add nombre ttl tipo dato

update delete nombre

En este ejemplo, vamos a agregar una dirección en el dominio unixymas.com.mx

# nsupdate -k Kupdate-key.+157+04139.private
> update add equuleus.unixymas.com.mx 10800 a 192.168.100.20
>

La línea en blanco al final, le indica que ejecute el cambio.

Para la resolución inversa la actualización es similar:

# nsupdate -k Kupdate-key.+157+04139.private
> update add 20.100.168.192.in-addr.arpa 10800 ptr equuleus.unixymas.com.mx
>

Ahora vamos a ver cómo se activa el rndc, necesitamos como requisito indispensable una llave, puede ser la misma para el DNS dinámico, pero en este ejemplo vamos a crear una nueva:

# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST rndc-key
Krndc-key.+157+11727

Ahora vamos a activarlo en el archivo de configuración con la opción controls, el archivo queda finalmente así:

/etc/named.conf

options {
        directory "/var/named";
};

zone "." {
        type hint;
        file "db.cache";
};

zone "0.0.127.in.addr.arpa" {
        type master;
        file "db.127.0.0";
};

zone "unixymas.com.mx" {
        type master;
        file "db.unixymas.com.mx";
        allow-update { key "update-key"; };
};

zone "100.168.192.in-addr.arpa" {
        type master;
        file "db.192.168.100";
        allow-update { key "update-key"; };
};

key "update-key" {
        algorithm hmac-md5;
        secret "onuHJl6U5lqKEk8/9mbMQw==";
};

controls {
        inet * allow { any; } keys { "rndc-key"; };
};

key "rndc-key" {
        algorithm hmac-md5;
        secret "5V73kf47NK6HjvygCjCJ9w==";
};

En el cliente, es necesario crear el archivo /etc/rndc.conf

/etc/rndc.conf

options {
        default-server 192.168.100.10;
        default-key "rndc-key";
};

key "rndc-key" {
        algorithm hmac-md5;
        secret "5V73kf47NK6HjvygCjCJ9w==";
};

Por último observen que los archivos de zona ya fueron actualizados por el BIND:

db.unixymas.com.mx

$ORIGIN .
$TTL 10800      ; 3 hours
unixymas.com.mx         IN SOA  draco.unixymas.com.mx. administrator.unixymas.com.mx. (
                                2          ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                3600       ; minimum (1 hour)
                                )
                        NS      draco.unixymas.com.mx.
$ORIGIN unixymas.com.mx.
draco                   A       192.168.100.10
equuleus                A       192.168.100.20

db.192.168.100

$ORIGIN .
$TTL 10800      ; 3 hours
100.168.192.in-addr.arpa IN SOA draco.unixymas.com.mx. administrator.unixymas.com.mx. (
                                2          ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                3600       ; minimum (1 hour)
                                )
                        NS      draco.unixymas.com.mx.
$ORIGIN 100.168.192.in-addr.arpa.
10                      PTR     draco.unixymas.com.mx.
20                      PTR     equuleus.unixymas.com.mx.

lunes, 7 de noviembre de 2011

Trabajando con aplicaciones gráficas en Unix (X Window System)

Actualmente los sistemas informáticos operan en entornos gráficos otorgando al usuario una sensación de poseer áreas de trabajo similares a lo que en un escritorio podrían ser cuadernos, carpetas y demás objetos. Esta es la razón por la que a las estaciones de trabajo se les denomina escritorios y a las áreas de trabajo que se encuentran en estos escritorios se les conoce como ventanas, debido a que, generalmente, son áreas de forma rectangular y a través de éstas es posible visualizar los contenidos de la información.

Por supuesto que Unix no podría ser la excepción, emplea un sistema que le otorga una apariencia gráfica y que está formado por varios componentes. A dicho sistema se le conoce como Sistema de Ventanas X (X Window System).


Vamos a ver cuáles son los principales componentes de X Window System

  • Servidor X (X Server): Este es el componente gráfico; posee una interfaz humana (teclado y mouse), y se encuentra en una terminal gráfica (X Terminal), en la consola de un equipo *nix ó cómo un emulador (Ej: Xming, OmniX, Reflection/X).
  • Gestor de ventanas (Window Manager): Nombre dado a un programa cuya función es permitir realizar operaciones sobre las ventanas tales como: redimensionar, mover, cerrar, minimizar, etc. Además de proporcionarles bordes, barras, títulos, botones, etc. (Ej: mwm, twm, dtwm, metacity, KWin).
  • Gestor de sesiones o pantalla (Display Manager): Es un programa que permite iniciar una sesión en modo gráfico desde el mismo equipo o desde otro remoto (Ej. xdm, dtlogin, gdm, kdm)
  • Entorno de escritorio (Desktop Environment): Es el conjunto de programas que proporcionan los componentes de un escritorio moderno, dichos componentes van desde los menús desplegables hasta utilerías como agenda, cliente de correo elctrónico, etc. (Ej: CDE, GNOME, KDE, XFCE)
La razón por la que se llama X Server al componente gráfico que permite el despliegue de ventanas es porque en realidad es un servidor que permite "abrir ventanas"

 

(Fuente de imagen: wikipedia)

En este ejemplo es un típico caso de una estación de trabajo desde la cual se están ejecutando 2 aplicaciones locales y 1 remota. La comunicación entre las aplicación y el X Server es por medio del protocolo tcp y normalmente utiliza el puerto 6000 (Es por esto que a las aplicaciones se les llama X Client ó Cliente X).

También es importante señalar que en el X Server es posible tener mas de una pantalla (dependiendo de las características del X Server), por lo que a cada pantalla se le debe etiquetar con una identificación numérica con el formato: X.X. La identificación por default es: 0.0

Con la intención de ilustrar mejor esto, vamos a iniciar un laboratorio para lo cual requerimos lo siguiente:

  • Un equipo Solaris 10 al que le desactivaremos el modo gráfico con el comando: svcadm disable cde-login
  • Un X Server que esté ejecutando en una ventana o en pantalla completa, sin ningún cliente ejecutando y con el control de acceso desactivado. En mi caso, voy a utilizar el Xming corriendo sobre Microsoft Windows en modo de una ventana, con la opción de "Start no client" y con la opción de "No access control"
  • Una sesión con el usuario root en el equipo Solaris 10 utilizando un cliente en modo texto: telnet o ssh (no utilizar la consola)

Al iniciar el X Server aparecerá una ventana con un fondo parecido al de la ilustración con un puntero de mouse con forma de "x" (de hecho, si observan con cuidado el fondo del X Server, notarán que en realidad es un patrón de pequeñas "x")

 Image

Desde la sesión en modo texto, vamos a definir la variable de ambiente DISPLAY de este modo: DISPLAY=192.168.100.1:0.0, donde 192.168.100.1 es la dirección IP del X Server, es decir, en mi caso la de mi equipo Windows; lo que va después de ":" es la identificación  de la pantalla, normalmente será 0.0 . Una vez definida la ambiente la "exportamos": export DISPLAY

Con esta variable de ambiente le estamos indicando a la aplicaciones la dirección del X Server, vamos a ejecutar unas aplicaciones básicas, desde la terminal de texto escribimos: /usr/openwin/bin/xterm -geometry 80x24+20+20 &

 Image [2]

Noten que la ventana solo es un rectángulo sin bordes y ningún tipo de decoración, para poder escribir en ella pasarle por encima el mouse y no hay modo de cambiarla de posición o de tamaño, los parámetros que le dimos al comando xterm fue para indicarle el tamaño y la posición que debe ocupar la ventana en el X Server, desde la ventana que acabamos de abrir ejecutamos:  /usr/openwin/bin/xclock -geometry 100x100+600+400 &

 Image [3]

Con lo anterior apareció otra ventana con un reloj y así podría continuar abriendo más ventanas, sin embargo, no es muy práctico el tener que calcular la geometría de éstas. Esta es la razón principal por la que existen los gestores de ventanas, vamos a ejecutar uno muy simple que nos permitirá observar la diferencia, desde el xterm ejecutaremos: /usr/openwin/bin/twm &

 Image [4]

Ahora aparecen las ventanas "decoradas" con una barra de título, con la cual, es posible mover las ventanas, redimensionar y minimizar; también dando clic en el fondo aparece un menú con el que podemos realizar otras operaciones. En este momento ya es posible abrir ventanas sin ser necesario calcular la geometría, ejecutamos desde el xterm: /usr/openwin/bin/xcalc &

 Image [5]

Noten que al momento de abrir la ventana, aparece una silueta en la posición del puntero del mouse, está en espera de que le indiquemos en qué parte de la pantalla deseamos que aparezca la ventana, por lo que movemos el mouse hasta la posición deseada y le damos clic.

Ya que nos queda claro en que sentido va la comunicación de X Client a X Server podemos resumir que para ejecutar aplicaciones gráficas es necesario contar con un X Server, una sesión en el equipo donde residen los X Client y un gestor de ventanas que nos permita operar con éstos. Entonces, ¿por qué no tener todo esto integrado?. Esa es precisamente la función del gestor de sesiones, el cual se encarga de "levantar" el X Server en la consola; permite el inicio de sesión en el equipo, y una vez iniciada la sesión, se encarga de ejecutar el gestor de ventanas. En Solaris, el gestor de sesiones que se utiliza normalmente es el dtlogin, también llamado cde-login, al cual conocemos por ser la pantalla color azul metálico que nos pide usuario y contraseña para iniciar sesión en la consola o desde algún equipo remoto.

A manera de ilustración de cómo funciona el gestor de sesiones, vamos a ejecutar otro más básico que el dtlogin. Vamos a cerrar lo realizado hasta el momento y ya que son aplicaciones en realidad muy simples, podemos simplemente cerrar el X Server y listo. Desde la terminal de texto ejecutamos: /usr/openwin/bin/xdm &

Observen que la consola del Solaris 10 se puso en modo gráfico con una pantalla que solicita usuario, sin embargo, es muy diferente a la pantalla azul que conocemos.

 Image [6]

Este gestor de sesiones nos permite iniciar una sesión desde la consola, pero también podemos iniciar una sesión desde un equipo remoto, nuevamente ejecutamos el X Server desde nuestra estación, en mi caso voy a ejecutar el Xming, también le voy a indicar que lo haga en modo de una ventana pero en esta ocasión le voy a indicar que abra una sesión remota con XDMCP (Open session via XDMCP), en "Connect to host" le doy la dirección IP del equipo Solaris 10 que en mi caso es la 192.168.100.101

Antes de iniciar sesión, permítanme aclarar cómo es esta comunicación, si bien sigue siendo cierto que las ventanas se inician de X Cliente a X Server, la sesión se inicia en sentido inverso, es decir, de equipo con X Server (ó estación) a equipo remoto. La sesión utiliza un protocolo distinto el XDMCP, el cual, se transporta por udp y utiliza el puerto 177.

Iniciamos sesión utilizando un usuario distinto a root (por default, Solaris no permite el inicio de sesiones con root desde estaciones remotas).

 Image [7]

Podemos ya cerrar el X Server y desde la terminal de texto le damos kill al xdm, para restaurar el cde-login, simplemente ejecutamos: svcadm enable cde-login

En resumen, el equipo remoto inicia el gestor de sesiones; la estación se conecta al equipo remoto por medio del protocolo XDMCP; se inicia la sesión, y los X Client se conectan al X Server que se encuentra en la estación.

En un entorno de trabajo real, los sistemas operativos modernos utilizan gestores más complejos adaptados a las "particularidades" de cada plataforma y por lo regular se encuentran limitados para iniciar sesión sólo en la consola del sistema, sin embargo, en casi todos es posible permitir sesiones remotas.

Con lo que respecta a la forma de abrir un X Client remoto en nuestra estación, el modo normal es permitiendo el acceso a clientes remotos en nuestra estación, iniciar sesión en el equipo remoto y definir en éste la variable de ambiente DISPLAY que corresponda (Nota: la forma de permitir el acceso a nuestra estación en el caso de que ésta sea un *nix, es por medio del comando xhost). El gestor de ventanas que utilizan los clientes remotos es el mismo que emplean las aplicaciones locales.

Por último y ya en particular con lo que respecta a Microsoft Windows, su sistema de ventanas es completamente diferente, es por esto que se utilizan emuladores, los cuales trabajan en dos modos: de una sola ventana o pantalla completa, la cual se utiliza para iniciar sesiones remotas, y el modo multiventana, con el cual, se utiliza el gestor de ventanas propio de Windows

 Image [8]

Ejemplo de xterm utilizando el gestor de ventanas de Windows

Con esto damos por concluido el tema, espero que haya sido de su agrado y nos vemos a la próxima.

jueves, 27 de octubre de 2011

Configurar una interfaz de red en Solaris (parte 3)

Continuando con el tema de configurar una interfaz de red, en esta ocasión veremos cómo configurar una IP virtual.

Una IP virtual es aquella que se agrega a una interfaz ya configurada con otra IP llamada real, la razón por la que se le denomina IP virtual es porque es necesario crear una nueva instancia del dispositivo, es decir, creamos un dispositivo virtual con la dirección adicional. Normalmente una IP virtual se encuentra en la misma LAN de la IP real, sin embargo, no es una regla, depende del uso que se le va a dar.

Los usos de una IP virtual pueden ser muy variados: es posible que la aplicación requiera una IP para cada componente; puede ser una aplicación que originalmente corría en otro servidor tuvo que ser "migrada" al actual; también es posible que sea una IP asociada a una máquina virtual (un contenedor), o tal vez, se trate de un esquema de alta disponibilidad en el que la ejecución de la aplicación se puede "pasar" de un servidor a otro con todo y su IP (un cluster activo-pasivo). En cualquier caso, aunque la forma de crear las IP's virtuales puede variar, en esencia, es el mismo principio para todas.

Para mostrar cómo se configura la IP virtual, voy a utilizar un servidor llamado solaris10 con la IP fija 192.168.100.51/255.255.255.0 y vamos a crear la IP virtual 192.168.100.50

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.100.51 netmask ffffff00 broadcast 192.168.100.255
        ether 0:c:29:5b:b3:1d
# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              192.168.100.2        UG        1          0
192.168.100.0        192.168.100.51       U         1          3 e1000g0
224.0.0.0            192.168.100.51       U         1          0 e1000g0
127.0.0.1            127.0.0.1            UH        3         68 lo0

Ahora vamos a crear la IP virtual con la instrucción addif del comando ifconfig.

# ifconfig e1000g0 addif 192.168.100.50 netmask + broadcast + up
Created new logical interface e1000g0:1

Con los parámetros netmask + y broadcast + le indico que configure la máscara y el broadcast más convenientes; con up  que deje "encendida" a la interfaz, es decir, que permita el envío y recepción a través de la interfaz. Ahora veamos cómo queda, noten que el dispositivo virtual no posee una MAC, debido a que utiliza la misma que el dispositivo real.

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.100.51 netmask ffffff00 broadcast 192.168.100.255
        ether 0:c:29:5b:b3:1d
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.100.50 netmask ffffff00 broadcast 192.168.100.255
# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              192.168.100.2        UG        1          0
192.168.100.0        192.168.100.51       U         1          5 e1000g0
192.168.100.0        192.168.100.50       U         1          0 e1000g0:1
224.0.0.0            192.168.100.51       U         1          0 e1000g0
127.0.0.1            127.0.0.1            UH        3         68 lo0

Como les mencione anteriormente, existen varias formas de crear las IP's virtuales, una muy usual es crear el dispositivo virtual con plumb de la forma: ifconfig interfaz:instancia plumb; posteriormente se configura la IP igual que un dispositivo real. Mi recomendación es utilizar addif por dos razones: la primera, ahorran el paso de crear el dispositivo; la segunda, no necesitan llevar la cuenta de qué instancia sigue.

Para dejar esta configuración en forma permanente vamos a modificar al archivo /etc/hostname.interfaz que en este caso se llama /etc/hostname.e1000g0:

# cat /etc/hostname.e1000g0
192.168.100.51 netmask + broadcast + up \
addif 192.168.100.50 netmask + broadcast + up

Como podrán observar son los parámetros del comando ifconfig, la función del backslash (\) es simplemente separar lo que corresponde a la IP real de la virtual.

De esta forma, la IP virtual queda operando y podrá el servidor recibir conexiones tanto por la IP real como la virtual, por lo cual, si la IP virtual va a ser utilizada por alguna aplicación que reciba conexiones desde otro equipo (un servidor web, por ejemplo) no tendrá ningún problema (estas conexiones son las conocidas como conexiones entrantes). Sin embargo, quiero resaltar el hecho de que en el caso de las conexiones salientes, por la forma en la que la tabla de ruteo señala la ruta hacia la red local, utilizará ambas IP's para salir, es decir, en algunas ocasiones se conectará por medio de la 192.168.100.51 y en otras por la 192.168.100.50. Menciono ésto porque en algunos sistemas es relevante desde que IP se inicia la conexión y esto puede ser por razones administrativas, funcionales o de seguridad.

La forma de controlar desde qué IP se va conectar el equipo es "depreciando" la IP con la que no queremos se conecte por medio de la instrucción deprecated del comando ifconfig, de la forma: ifconfig interfaz deprecated. En nuestro ejemplo, vamos depreciar la IP real: ifconfig e1000g0 deprecated

# ifconfig e1000g0 deprecated
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4> mtu 1500 index 2
        inet 192.168.100.51 netmask ffffff00 broadcast 192.168.100.255
        ether 0:c:29:5b:b3:1d
e1000g0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 192.168.100.50 netmask ffffff00 broadcast 192.168.100.255
# netstat -rn
Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              192.168.100.2        UG        1          0
192.168.100.0        192.168.100.50       U         1          2 e1000g0:1
192.168.100.0        192.168.100.50       U         1          0 e1000g0
224.0.0.0            192.168.100.51       U         1          0 e1000g0
127.0.0.1            127.0.0.1            UH        4        147 lo0

Observen el cambio en la tabla de ruteo para la red local, le indica que tanto en la interfaz real como en la virtual utilice la IP 192.168.100.50 (Nota: en el caso del multicast 224.0.0.0 no afecta porque no es a la red local). Para que la configuración quede en forma permanente solo basta agregar la instrucción deprecated en el archivo /etc/hostname.interfaz en la línea que corresponda a la IP a depreciar:

# cat /etc/hostname.e1000g0
192.168.100.51 netmask + broadcast + deprecated up \
addif 192.168.100.50 netmask + broadcast + up

miércoles, 26 de octubre de 2011

Configurar una interfaz de red en Solaris (parte 2)

En la entrada anterior vimos cómo configurar a una interfaz de red con una IP fija, en esta ocasión, veremos como configurarla con una IP dinámica por medio del DHCP.

Pero, ¿qué es el DHCP?

Es un servicio TCP/IP que utiliza el protocolo UDP con el puerto 67 y que, básicamente, consiste en asignarle una IP a quién lo “solicite” de un pool de IP’s que posee para este fin.

Lo más lógico sería suponer que este protocolo debería operar en capa 3 pero no es así, opera en capa 5.

¿Cómo es posible tener una comunicación en ese nivel sin tener una dirección IP?. El cliente DHCP, provisionalmente, asigna la IP 0.0.0.0 a la interfaz y envía una petición a la IP 255.255.255.255, esta IP esta reservada como un broadcast en cualquier red local no importando su direccionamiento. El servidor atiende la petición, asigna una IP y la “ofrece” al cliente; el cliente acepta la IP ofrecida y la solicita; el servidor asocia la IP a la MAC del cliente y envía una respuesta de confirmación junto con otros parámetros tales como: máscara, dirección del broadcast y ruteador. Adicional a esto, el servidor puede enviar otros datos y que, por lo regular, incluyen las direcciones de los servidores DNS, el nombre del dominio, las direcciones de los servidores WINS, etc.

En Solaris el cliente DHCP se llama dhcpagent y es controlado por el comando ifconfig utilizando la instrucción dhcp, de la forma: ifconfig interfaz dhcp start

# ifconfig e1000g0 dhcp start

En esta forma, el agente asignará una IP en forma dinámica para la interfaz, además del broadcast y la máscara. Adicionalmente, dará de alta una ruta en la tabla de ruteo.

Lo normal es que este tipo de configuración se utilice sólo para estaciones de trabajo (más adelante comento la razón) y solamente en la interfaz principal. Generalmente se configura en forma permanente de la siguiente manera:

  • Se crea el archivo /etc/dhcp.interfaz en donde interfaz representa el nombre de la interfaz principal, este archivo normalmente esta vacío y puede contener parámetros específicos (consultar archivo /etc/default/dhcpagent)
  • Crear o modificar el archivo /etc/hostname.interfaz para que contenga la línea: inet hostname, donde hostname es un nombre de host que, por lo regular, es el nombre del servidor.

En este ejemplo, creamos el archivo vacío: /etc/dhcp.e1000g0 y en el archivo hostname.e1000g0 dejamos la línea: inet solaris10 (solaris10 es el nombre del equipo).

Después de esto podemos reiniciar el equipo, sin embargo, antes de eso, les recomiendo editar el archivo /etc/hosts, si existe una línea para el hostname del equipo, borrarla, y en la línea de la dirección 127.0.0.1 localhost adicionarle como un nombre adicional loghost de esta forma:

# cat /etc/hosts
#
# Internet host table
#
::1     localhost
127.0.0.1       localhost       loghost

Reiniciamos y observen cómo configura a la interfaz:

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
        inet 192.168.100.101 netmask ffffff00 broadcast 192.168.100.255
        ether 0:c:29:5b:b3:1d
# netstat -rn

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              192.168.100.2        UG        1          0 e1000g0
192.168.100.0        192.168.100.101      U         1         17 e1000g0
224.0.0.0            192.168.100.101      U         1          0 e1000g0
127.0.0.1            127.0.0.1            UH        4        401 lo0
# cat /etc/hosts
#
# Internet host table
#
::1     localhost
127.0.0.1       localhost       loghost
192.168.100.101 solaris10       # Added by DHCP

Adicional a esto, también configura la parte del cliente DNS:

# cat /etc/resolv.conf
domain unixymas.com.mx
nameserver 192.168.100.2

# cat /etc/nsswitch.conf
#
# Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
# ident "@(#)nsswitch.files     1.14    06/05/03 SMI"

#
# /etc/nsswitch.files:
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# does not use any naming service.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.

passwd:     files
group:      files
#hosts:      files # Commented out by DHCP
hosts: files dns # Added by DHCP
#ipnodes:    files # Commented out by DHCP
ipnodes: files dns # Added by DHCP
networks:   files
protocols:  files
rpc:        files
ethers:     files
netmasks:   files
bootparams: files
publickey:  files
# At present there isn't a 'files' backend for netgroup;  the system will
#   figure it out pretty quickly, and won't use netgroups at all.
netgroup:   files
automount:  files
aliases:    files
services:   files
printers:       user files

auth_attr:  files
prof_attr:  files
project:    files

tnrhtp:     files
tnrhdb:     files

En esta forma nuestro equipo queda configurado con una IP dinámica, lo cual es muy conveniente para una estación de trabajo y no importa si es necesario modificar a la red o si es necesario moverla a otra parte, siempre y cuando, en nuestra red exista un servidor DHCP.

Como les comentaba anteriormente, no es recomendable esta configuración para un servidor, menos si se trata de un servidor en producción ya que la IP puede ser modificada por el servidor DHCP. Aunque se realice la modificación en un servidor DNS con la nueva dirección, lo cierto es que existiría un tiempo de desfasamiento entre la IP anterior y la nueva que, simplemente, se puede resolver evitando esta modificación en forma dinámica (Nota: de hecho, este desfasamiento es la razón por la que en los ambientes de alta disponibilidad los servicios siempre van asociados cada uno a una IP, ya que es más rápido migrar una IP de una interfaz a otra que hacer el cambio en un servidor de dominio). Aunque existe la posibilidad de asignar en forma permanente la IP en el servidor DHCP, la mejor práctica es reservar siempre una parte del segmento de red para su uso con IP’s fijas (e incluso reservar segmentos completos para esto) por lo que en el servidor DHCP se configuran fragmentos de segmentos de red como pool de IP’s.

Y ya que mencionamos ambientes de alta disponibilidad, algo muy básico en éstos es el uso de IP’s virtuales por lo que en la siguiente entrega veremos cómo configurarlas en su forma básica.