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

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.

Configurar una interfaz de red en Solaris (parte 1)

Para que nuestro equipo Solaris (estación de trabajo o servidor) se pueda conectar a una red es necesario configurar, al menos, una interfaz de red con una IP estática o dinámica (la diferencia entre una IP estática y dinámica es que la primera debe ser proporcionada en forma manual y la segunda será proporcionada por otro servidor dedicado a esto a través del protocolo DHCP).

Si bien, es cierto, podemos configurar a una interfaz de red desde la instalación de sistema operativo, muchas veces requeriremos de configurar interfaces después de la instalación.

El primer paso es identificar la NIC que debemos activar, aunque es, en apariencia, muy obvio en realidad es sorprendente el número de ocasiones que tendremos que “sufrir” un poco para encontrar el dispositivo que corresponde. Aunque existen otros métodos, creo que el más genérico es por medio del comando prtdiag.

# prtdiag –v | less

Yo en lo personal, prefiero utilizar less en lugar de more debido a que es más fácil navegar a través de la salida del comando prtdiag.

Buscamos la cadena “net” y revisamos el dispositivo, en mi ejemplo, éste fue el dispositivo que encontré:

name='model' type=string items=1              value='Ethernet controller'          name='power-consumption' type=int items=2              value=00000001.00000001          name='66mhz-capable' type=boolean          name='devsel-speed' type=int items=1              value=00000001          name='interrupts' type=int items=1              value=00000001          name='max-latency' type=int items=1              value=00000000          name='min-grant' type=int items=1              value=000000ff          name='subsystem-vendor-id' type=int items=1              value=000015ad          name='subsystem-id' type=int items=1              value=00000750          name='unit-address' type=string items=1              value='0'          name='class-code' type=int items=1              value=00020000          name='revision-id' type=int items=1              value=00000001          name='vendor-id' type=int items=1              value=00008086          name='device-id' type=int items=1              value=0000100f      Interrupt Specifications:          Interrupt Priority=0x6 (ipl 6), vector=0xa (10)      Device Minor Nodes:          dev=(71,1)              dev_path=/pci@0,0/pci15ad,790@11/pci15ad,750@0:e1000g0                  spectype=chr type=minor                  dev_link=/dev/e1000g0          dev=(71,1002)              dev_path=<clone>              Device Minor Layered Under:                  mod=udp accesstype=chr                      dev_path=/pseudo/udp@0          dev=(71,1003)              dev_path=<clone>              Device Minor Layered Under:                  mod=udp accesstype=chr                      dev_path=/pseudo/udp@0

Observen que indica que se trata de un dispositivo Ethernet y que la ruta del dispositivo es la que está indicada como dev_link y que corresponde a /dev/e1000g0

En este caso, es la única interfaz que posee el equipo, por lo que este debe ser el dispositivo que busco sin duda alguna, sin embargo, ya es muy común encontrar servidores con más de una interfaz, por lo que debemos constatar que si corresponde a la interfaz con la que debemos trabajar, habrá ocasiones en la que debamos utilizar el método de prueba y error.

Ya seleccionado el dispositivo de la interfaz vamos proceder a activarla con el comando ifconfig.

# ifconfig e1000g0 plumb

Con el primer parámetro le indicamos el dispositivo con el que vamos a trabajar, no es necesario indicar toda la ruta /dev/e1000g0. El siguiente es la instrucción plumb, la cual, activa al dispositivo.

A continuación, procedemos a configurar la interfaz, también con el comando ifconfig.

# ifconfig e1000g0 inet 192.168.188.22 netmask 255.255.255.0 broadcast + up

Los parámetros son:

• e1000g0: El dispositivo
• inet 192.168.188.22: La IP fija que vamos a asignarle a la interfaz
• netmask 255.255.255.0: La máscara de red
• broadcast +: Que utilice como dirección reservada para el broadcast la última dirección del segmento
• up: Que deje a la interfaz arriba (es decir, encendida)

Es una buena práctica el indicarle todos estos parámetros ya que de lo contrario corremos el riesgo de que quede mal establecido el segmento de red y el equipo no pueda localizar algunas direcciones (Nota: en la práctica real, observarán que en algunas ocasiones el servidor no puede conectarse con algunas direcciones, pero con otras si, en esos casos lo primero que debemos revisar es si los parámetros de subnet mask y brodcast están bien designados).

Una vez realizado lo anterior, podemos decir que ya tenemos el equipo en red, sin embargo, hasta este punto solo va a ser posible su comunicación con otros equipos de la red local, es necesario configurar un ruteador para que puede comunicarse con equipos remotos.

En este ejemplo, vamos a configurar el ruteador por default utilizando el comando route.

# route add default 192.168.188.2

Los parámetros que utilizamos indican lo siguiente:

• add: Le indica que vamos a agregar una ruta, la instrucción contraria es delete
• default: Esta palabra indica que ésta es la ruta por default, en su lugar, puede ser la dirección de una red o la de un host (por ejemplo: host 192.168.190.2 ó net 192.168.190.0)
• 192.168.188.2: La IP del ruteador, esta IP debe ser local

La forma de revisar la configuración con los comandos ifconfig (para la interfaz) y netstat (para el ruteador) es la siguiente:

# 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.188.22 netmask ffffff00 broadcast 192.168.188.255         ether 0:c:29:4b:86:96 # route add default 192.168.188.2 add net default: gateway 192.168.188.2 # netstat -rn Routing Table: IPv4   Destination           Gateway           Flags  Ref     Use     Interface -------------------- -------------------- ----- ----- ---------- --------- default              192.168.188.2        UG        1          0 192.168.188.0        192.168.188.22       U         1          1 e1000g0 224.0.0.0            127.0.0.1            U         1          0 lo0 127.0.0.1            127.0.0.1            UH        9        463 lo0

Por último, vamos a configurar al equipo para que esta configuración quede en forma permanente, para la configuración de la interfaz, vamos a crear en el directorio /etc un archivo llamado hostname.nic donde nic es el nombre de la interfaz, en este ejemplo: hostname.e1000g0. En este archivo podemos, simplemente, agregar la dirección IP. Sin embargo, en muchos manuales encontrarán que en este archivo por lo regular se escribe un nombre de host (hostname) en la forma canónica, dicho hostname debe existir en el archivo /etc/hosts. Adicional a esto, lo normal es que una de las interfaces utilice como hostname el mismo nombre definido para el equipo (a esta interfaz se le conoce como la interfaz principal). Para este ejemplo, en el que solo va a quedar configurada una sola interfaz, vamos a utilizar el modo canónico escribiendo en el archivo hostname.e1000g0 el nombre del equipo (solaris10) y el archivo /etc/hosts lo dejaremos de la siguiente forma:

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

También es importante indicar la máscara de red, para lo cual, utilizamos el archivo /etc/inet/netmasks para indicar la máscara que corresponde a la red, recuerden que la máscara para este ejemplo es la 255.255.255.0, por lo que la red es la 192.168.188.0/24 (en un artículo anterior se muestra cómo se definen los segmentos). El archivo quedará en la siguiente forma:

# cat /etc/inet/netmasks # # The netmasks file associates Internet Protocol (IP) address # masks with IP network numbers. # #       network-number  netmask # # The term network-number refers to a number obtained from the Internet Network # Information Center. # # Both the network-number and the netmasks are specified in # "decimal dot" notation, e.g: # #               128.32.0.0 255.255.255.0 # 192.168.188.0   255.255.255.0

Y por último, el ruteador por default se define mediante el archivo /etc/defaultrouter, al cual, contendrá la dirección del ruteador, en este ejemplo, la 192.168.188.2.

De esta forma, nuestra interfaz quedará configurada con una IP fija, en el siguiente artículo veremos como utilizar una IP dinámica.

Dennis Ritchie (1941 - 2011)

Como muchos de ustedes seguramente ya lo saben, hoy se dio a conocer que el pasado 9 de octubre murió a la edad de 70 años Dennis MacAlistair Ritchie.

Ahora que esta tan de moda desgarrarse en llanto por la muerte de Steve Jobs no quisiera que pasara desapercibida la falta de este hombre, del cual, es indudable su gran aportación a la informática actual, de hecho, puedo asegurar sin temor a exagerar que nos sería difícil entender cómo sería la informática sin él.

Junto con Ken Thompson creó al Sistema Operativo UNIX y es claro que la mayor parte de los sistemas operativos actuales o descienden de UNIX o están basados en éste, sistemas tales como: Solaris, HP-UX, AIX, OpenBSD, GNU/Linux, Mac OS X, Android, iOS, etc. Además de sistemas que, aunque han dejado de existir, han dejado una huella detrás: NEXTSTEP, DG-UX, IRIX, SCO Unix, XENIX, etc.

Además de esto y, por si fuera poco, fue el creador del Lenguaje C, su sintaxis tan simple es la base de los modernos lenguajes de programación: Java, Python, Perl, PHP, etc.

(Fuente de imágenes: wikipedia)

Redes TCP/IP (parte 3)

En este artículo voy a intentar describir de una forma muy simple cómo es la comunicación en una red TCP/IP, pero antes quisiera aclarar que esta descripción no pretende ser un documento técnico, de hecho, pretende ser sólo un resumen en el que describo los aspectos que, a mi juicio, son los más relevantes.

Vamos a utilizar la siguiente red para mostrar cómo se comunica el equipo con IP 192.168.1.101 con los demás equipos.

De acuerdo al diagrama podemos resumir que vamos a analizar 3 tipos de acceso:

• A la 192.168.1.102 en la misma LAN
• A la 192.168.5.101 en otra LAN (posiblemente en el mismo edificio)
• A un equipo en Internet donde yyy.yyy.yyy.yyy puede ser cualquier dirección válida en Internet

Comunicación en una red local

Cualquier dato que sea transmitido a través en una interfaz de red empleará tramas (generalmente 802.3 ó compatibles) que contienen (entre otros datos) la dirección MAC origen y la MAC destino, por lo que cualquier intercambio de datos se hará siempre entre dispositivos en la misma LAN.

En nuestro equipo tenemos configurada una IP, la 192.168.1.101 y (para este ejemplo) tenemos configurada la máscara 255.255.255.0, por lo cual, la 192.168.1.102 pertenece a la misma LAN, es decir, es local.

A continuación, el protocolo procede a indagar a qué MAC corresponde la 192.168.1.102, primero consulta en su tabla de direcciones locales llamada tabla ARP si ya esta asociada la IP a una MAC, si es así utiliza esta MAC para transmitir, si no, lo averigua utilizando tramas con la MAC destino FF:FF:FF:FF:FF:FF (esta dirección en realidad representa a todos los dispositivos de la red local, por lo que todos reciben las tramas y las procesan según sea el caso) esperando que algún dispositivo se reporte con esa IP.

Teniendo ya la MAC asociada a la IP, el protocolo transmite empleando tramas con esa dirección física como destino.

Debido a que esta comunicación únicamente va de interfaz a switch y de switch a interfaz y es el mismo protocolo es que se encarga de hacer la "conversión" de IP a MAC, el switch sólo se encarga de transmitir las tramas al dispositivo que corresponde. Es por esto que se dice que el switch es un dispositivo de capa 2 (aunque en realidad ya existen switches que hacen más que eso).

Comunicación en red extendida

Para la comunicación con la 192.168.5.101, de acuerdo con la máscara, se encuentra fuera de nuestra LAN, es decir, es remota.

Para comunicarnos con una IP externa es necesario tener definido un ruteador, normalmente tenemos definido uno solo al que denominamos el default gateway ó default router, en este ejemplo el que tenemos definido en este equipo es el 192.168.1.1

Observen que esa IP es local para la 192.168.1.101 y, como comenté anteriormente, la comunicación siempre es utilizando dispositivos locales, por lo  que, todos los paquetes que vayan dirigidos a IP's remotas serán enviados a la IP del ruteador. Es por esta razón que se dice que un ruteador es un dispositivo de capa 3.

En nuestro ejemplo, el ruteador tiene una interfaz en la red 192.168.1.0/24 y otra en la red 192.168.5.0/24, por lo que "pasa" el paquete de una interfaz a otra y desde la 192.168.5.1 hace el envío a la 192.168.5.101

Por supuesto que en la vida real, en una organización difícilmente hay un solo ruteador, lo más probable es que tenga varios y que éstos estén interconectados entre sí por medio de switches o de otros ruteadores, por lo que en la configuración de los ruteadores hay listas que indican dónde localizar una red u otra, estas listas se llaman tablas de ruteo.

La definición del default router nuestros equipos (que, normalmente se les llaman hosts) no solo nos permite transmitir a redes remotas, si no que, además, nos permite recibir paquetes remotos. Esto es debido a que sólo recibe paquetes que provienen de redes remotas de IP's definidas como ruteadores. Las IP's que son definidas así se encuentran en su tabla de ruteo y si, efectivamente, es igual a las tablas de ruteo que se encuentran en los ruteadores. De hecho, al menos en teoría, cualquier host podría ser capaz de ser un ruteador, siempre y cuando tenga las suficientes interfaces de red.

Comunicación de redes privadas a Internet

Por supuesto que en toda organización actual el acceso a Internet es indispensable, como comenté en artículos anteriores, la redes privadas no pueden accesar directamente a Internet, por lo que es necesario un dispositivo que haga la "conversión" de las peticiones que provienen de IP's de la red privada a una IP pública que, en este caso, denominé como xxx.xxx.xxx.xxx (la cual, puede ser cualquier dirección válida proporcionada por nuestro proveedor de Internet). A esta "conversión" se le llama traducción de dirección de red (NAT) y el dispositivo encargado de ésta se llama firewall.

Además de permitir el uso de una NAT para las peticiones de salida de la red privada, es posible el asociar una IP pública a un host dentro de la red privada, además de poseer filtros para permitir el acceso de un lado a otro de solo unos servicios. Por ejemplo, es posible tener un servidor web dentro de nuestra red privada y por medio del firewall definir una NAT que traduzca las peticiones a una IP pública hacia la IP privada del servidor bloqueando cualquier petición que no sea al servicio web (ftp, por decir alguno).

En organizaciones reales es frecuente encontrar definidas por medio de firewalls varias "zonas" que, normalmente, son de tres tipos: zona privada en la que se encuentran usuarios y servidores con aplicaciones propias de la organización; zona desmilitarizada (DMZ) en la que se encuentran los servidores a los que se requiere tenga acceso personas externas, y la zona pública que, prácticamente, es lo que se encuentra fuera de la organización.

Ya que los bloqueos o filtros se pueden hacer a nivel servicio, se dice que el firewall es un dispositivo de capa 4, sin embargo, en la actualidad hay firewalls que permiten monitorear y analizar si las peticiones a ciertos servicios tratan de hallar una vulnerabilidad haciendo una serie de peticiones inválidas, este tipo de firewall es un dispositivo de capa 7.

Con esto doy por terminado el tema, espero les sea de utilidad y si alguien tiene algún comentario, por favor, no duden en compartirlo.

Redes TCP/IP (parte 2)

Continuando con el tema de redes TCP/IP vamos a profundizar un poco más en lo que corresponde al direccionamiento IP.

El hecho de que las direcciones IP son números jerárquicos e independientes de las direcciones físicas debería ser una razón más que suficiente para que este protocolo tuviera el éxito que tuvo, sin embargo, en realidad su éxito se debió solo a que la Internet está basada en este protocolo.  Una prueba de ello es que en Windows el driver TCP/IP estuvo disponible de forma nativa hasta la versión 95, antes de esa versión era necesario adquirir un software adicional generalmente llamado winsock, además de que el NetBIOS solo podía ser utilizado con el NetBEUI en forma local y con el IPX/SPX para redes extendidas.

Direcciones IP

Las direcciones IP en realidad son números de 32 bits lo cual, en teoría, nos da la capacidad de 2 a la 32 direcciones, es decir, 4,294,967,296 posibles direcciones. Este número binario de 32 posiciones se divide en 4 grupos de 8 posiciones, a cada uno de estos grupos se le llama octeto y regularmente se representa a cada uno con su equivalente decimal y se delimitan por puntos, como ejemplo, vamos a ver la representación de la IP 192.168.1.100:

Cada dirección IP además de darle un número único a cada componente también nos indica a que red pertenece. Como recordarán en el artículo anterior, una red es en realidad una red de redes, cada una de estas "pequeñas redes" se le denomina red de área local (LAN). Imaginemos que una dirección IP es como el nombre de una persona su apellido indica a qué familia pertenece, en este caso, los primeros números de la IP indican a que LAN pertenece, sin embargo, así como en la vida real hay apellidos largos, también los hay en las direcciones IP, por lo que se utiliza una "clave" que nos indica de que "tamaño es el apellido". Esta clave se le llama máscara de subred (subnet mask) y se le llama así porque "rellena" con números 1 la parte que representa el número de red y con números 0 la que representa al número de nodo (recuerden que son números de 32 bits), en este ejemplo vamos a decir que los primeros 24 bits representan a la red y el resto al nodo:

Al igual que las direcciones IP las máscaras se representan también con su decimal, por lo que la máscara queda como 255.255.255.0 y la red queda definida como las posibles direcciones que hay desde la IP 192.168.1.0 hasta la 192.168.1.255

Por una condición de protocolo, la primera dirección IP de una LAN queda reservada como el número de red por lo que en nuestro ejemplo la red es la 192.168.1.0 por lo que una manera muy común y adecuada de representarla es con el número de red y su máscara de esta forma: 192.168.1.0/255.255.255.0

También existe la condición de reservar a un número que represente a todos los nodos de una LAN, un número común a todos, al cual se le llama broadcast y, generalmente, se utiliza el número de la última dirección posible, en este caso el 192.168.1.255

Actualmente se emplea una forma más corta para representar a las redes, con el número de red (o sea, su primer nodo) y el número de 1's de su máscara (en este ejemplo 24) de esta forma: 192.168.1.0/24

Del porqué definir una máscara grande o pequeña, depende de la necesidad que tengamos de más redes pequeñas o menos pero grandes. Por ejemplo, si definimos una red con máscara 24, quiere decir que tenemos 8 bits para direcciones locales, es decir, 2 a la 8 que es igual a 256, si usamos una máscara de 28, entonces tendríamos disponibles 4 bits, o sea, 2 a la 4 que es igual a 16 y se representaría como 255.255.255.240, esto es porque los primeros tres octetos son ocho números 1 (11111111) que en binario representan 255 decimal y el último octeto son cuatro 1's y cuatro 0's (11110000) que en decimal es 240

Comúnmente, la redes que son definidas de 8 bits son llamadas de Clase A, de 16 bits Clase B y de 24 Clase C, sin embargo, esta forma de definir redes no es obligatoria, por lo que no es de extrañar el encontrar redes definidas con máscaras mas "exóticas".

Segmentación

También es una práctica común que a una red ya definida la dividamos en redes aún más pequeñas. Por ejemplo, supongamos que tuviéramos la necesidad de dividir en dos nuestra red 192.168.1.0/24 la podemos segmentar con un bit más quedando dos redes de 128 nodos así: 

También podría segmentarse en 4 redes de 64 nodos cada uno con 26 bits y quedarían como: 192.168.1.0/26, 192.168.1.64/26, 192.168.1.128/26 y 192.168.1.192/26. La máscara para las 4 sería 255.255.255.192

Redes reservadas

Debido a que el número de IP's en Internet es limitado, existen 3 redes que se encuentran reservadas para uso interno, esto quiere decir, que la empresa u organización a la que pertenecemos puede usar cualquiera de éstas dentro de su red local según sea su necesidad con la seguridad de que nadie en la red pública la va a utilizar y para "salir a Internet" podrá utilizar uno o varios firewall que se encarguen de hacer la traducción a una IP pública (NAT). Pero, ¿por qué es importante esto?. Supongamos que erróneamente usamos la 172.0.0.0/16 y desde algún nodo necesitamos accesar a un sitio de Internet con la IP 172.0.10.27 (Nota: en realidad no sé si existe tal sitio pero la IP si es válida para ser pública), en ese caso la petición no va a llegar al firewall ya que el equipo de ruteo supondrá que esa IP se encuentra dentro de la red local. Para este ejemplo, lo más probable es que no habría mayor problema que el no poder accesar a alguna página de Internet, pero, si fuera el caso de que ese acceso fuera muy importante, entonces nos encontraríamos en la necesidad de tener que definir nuevamente nuestra red interna.

Las redes reservadas para uso interno son:

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

Finalmente (y no menos importante) existe otra red reservada, la 127.0.0.0/8, esta red es muy especial debido a que en realidad se refiere al mismo equipo por lo que se le llama eco (loopback), así que, en todo equipo hay una dirección 127.0.0.1 y representa a mismo equipo, es muy importante indicar que toda petición que hagamos al loopback, no saldrá del equipo, además de que cualquier programa que tenga abierto un puerto solo en la IP 127.0.0.1 no podrá recibir peticiones de ningún otro equipo.

Redes TCP/IP (parte 1)

Vamos a iniciar con un tema muy teórico, el cual, considero es muy necesario para poder revisar otros temas.

En la actualidad, un sistema de información requiere una red de datos que permita el intercambio de información entre aplicaciones dentro de la misma organización y fuera de ésta, además de el usuario requiere el acceso a este desde dispositivos de diversos tipos (equipos de escritorio, móviles, etc).

A partir del surgimiento de Internet en el mundo comercial su protocolo, el TCP/IP (o en su forma correcta IPv4), se convierte en el estándar de comunicación, por lo que en la actualidad todo dispositivo que trabaja en red, desde un smartphone hasta un servidor, ocupan este protocolo.

Modelo OSI

Haciendo un poco de historia, a principios de los años 80's existían varios tipos de redes, tales como: DECnet, AppleTalk, SNA, etc. Por lo que se adoptó un modelo que debería seguir cualquier tipo de red para poder asegurar la interconexión entre éstas, a esto se le llamo el Modelo OSI y está conformado por 7 capas, esto es, desde como se conectan los equipos físicamente hasta el acceso del usuario a la aplicación. Vamos rápidamente a revisar a cada capa y su correspondencia con el protocolo TCP/IP

Capa 1 Nivel Físico

La forma en la cual los dispositivos que conforma una red se conectan se le llama Topología.

 

En la actualidad las topologías que se utilizan son en estrella y en árbol.

En estrella es cuando todos los nodos que forman parte de la red se conectan a un punto común antes llamado hub, ahora switch. Normalmente se utiliza en empresas muy pequeñas y en casas, si ustedes en casa tienen un ruteador para conectarse a Internet ésta es la topología que utilizan.

En árbol es la topología que utilizan prácticamente todas las empresas en la actualidad y consiste en estrellas interconectadas entre sí en forma jerárquica.

La conexión a la red se logra mediante una interfaz (NIC) la cual se conecta al switch por medio de un cable de cobre, fibra óptica o en forma inalámbrica. Aunque ya está de desuso también es posible al conexión mediante una interfaz serial y un convertidor a señal análoga (módem).

Capa 2 Nivel de enlace

Es la encargada de transferir la información entre dispositivos dentro de una red mediante bloques de información llamados tramas.

Estas tramas se encuentran definidas en una norma que, por lo regular, son Ethernet IEEE 802.3 para la comunicación por medio de cable o fibra, y para el caso de las inalámbricas puede ser Wi-Fi 802.11 y WiMAX 802.16 entre otras (incluyendo la telefonía móvil).

La forma en la que se reconoce a qué dispositivo está destinada cada trama es por medio de una dirección única de identificación para cada uno llamada dirección MAC, la cual, es un identificador de 48 bits dividido en 6 números hexadecimales en la forma XX:XX:XX:XX:XX:XX, por ejemplo: 04:00:4F:2C:00:3E

Capa 3 Nivel de red

En esta capa se emplea el protocolo IP y a partir de aquí es posible la comunicación de dispositivos de una red a otra, lo que técnicamente se denomina ruteo.

El intercambio de información en este nivel se realiza mediante paquetes y la forma de identificación entre nodos es por medio de un número único de 32 bits divido en 4 números decimales llamados octetos en la forma XXX.XXX.XXX.XXX, por ejemplo: 192.168.1.10

En entregas posteriores explicaré a más detalle acerca de segmentación y el ruteo, aquí solo diré que en el caso de que el nodo al que se requiere enviar información no se encuentra en la red local se realizará el envío por medio del router definido por default o al que se indique para la ruta específica (ruta estática).

Capa 4 Nivel de transporte

La capa anterior se puede decir que es la que permite la conexión entre nodos, una vez que se logra ésta es necesario enviar y recibir datos por medio del protocolo de transporte.

Para esto, regularmente se utilizan datagramas por medio del protocolo TCP de forma sincronizada, esto es, el primer dato enviado es el primero en recibirse.

También es común el uso de segmentos empleando es protocolo UDP de forma asíncrona, es decir, el protocolo carece de un modo de asegurar que los segmentos serán entregados necesariamente en el orden en el que se enviaron, de hecho, ni siquiera asegura por si mismo que sea recibido (regularmente se utiliza en aplicaciones en donde se requiere hacer el envío de mensajes de una forma simple sin importar si es necesario reenviarlos).

Hasta aquí, podemos deducir que TCP/IP en realidad quiere decir TCP sobre IP, ya que la mayor parte de las aplicaciones se comunican utilizando este par de protocolos.

Capas 5, 6 y 7 Niveles de sesión, presentación y aplicación

Los servicios de las últimas 3 capas del modelo OSI son utilizados en forma total o parcial por los llamados servicios o protocolos de alto nivel según sea el caso.

Entre estos servicios se encuentran: ftp, telnet, smtp, imap, http, etc.

Como se podrá observar, posteriormente aunque es posible accesar directamente a la mayor parte de estos protocolos (el caso más evidente es el del protocolo ftp) por lo regular se utilizan aplicaciones cliente para dicho acceso (tales como browsers, clientes de email, etc)

También quisiera hacer mención que en estas capas es donde se realiza la implementación de "viejos protocolos" para su uso a través de las redes IP. Este es el caso de IPX sobre TCP/IP para NetWare y el caso más interesante es el de NetBIOS sobre TCP/IP para redes Microsoft Windows. Por supuesto que esto es posible gracias al modelo OSI, el cual, ha demostrado que no solo es posible la comunicación entre redes de diverso género, también es posible utilizar los servicios de una para el uso de otra.

Por último, si bien es cierto que, aparentemente, el protocolo IPv4 está por ser desplazado por IPv6, lo único que cambiará será la forma en que se conecten los diferentes dispositivos a través de Internet ya que el cambio sería solamente en la capa 3. De hecho, la idea es que se puedan utilizar las direcciones actuales haciendo solo una "traducción" a las nuevas direcciones IPv6.

Retomando el tema

Antes que nada, quisiera pedir una disculpa a mis 2 lectores por la larga ausencia, a partir de hoy, vuelvo a este espacio esperando poder publicar con más frecuencia.

También les comento que voy a realizar algunos cambios en este blog mi intensión es dar la posibilidad a otras personas que quieran colaborar conmigo para enriquecer este espacio, proximamente les comunicaré cómo.

En todo caso, cualquier comentario será bienvenido en mi cuenta de correo: hjaramillomx@gmail.com

¡Nuevamente sean bienvenidos!

Atentamente,

Héctor Alejandro Jaramillo Zavala