TELNET
Introducción a Telnet Telnet
es un protocolo que sirve para emular una terminal remota, lo que significa que
se puede utilizar para ejecutar comandos introducidos con un teclado en un
equipo remoto. La herramienta Telnet está implementada por el protocolo Telnet.
Esto significa que traduce las especificaciones del protocolo al lenguaje de
programación a fin de crear un programa que pueda emular una terminal. Telnet
opera en un entorno de cliente/servidor, lo que implica que el equipo remoto se
configura como servidor, por lo que espera que el otro equipo le solicite un
servicio. Por lo tanto, dado que este equipo remoto envía datos que se deben
mostrar, el usuario siente que está trabajando directamente en un ordenador
remoto. En UNIX, este servicio se brinda por medio de lo que se conoce como un
daemon (daemon), una tarea pequeña que se ejecuta de fondo. El daemon de Telnet
se denomina Telnetd. Protocolos e implementación Telnet también es un protocolo,
un conjunto de reglas y procedimientos que se definieron para estandarizar la
comunicación de Telnet. Por esta razón, Telnet se implementó en muchas
plataformas, en base a las especificaciones del protocolo. Cómo ejecutar Telnet
Telnet se proporciona con varias plataformas, incluidas UNIX, Windows 95,
Windows NT, y Linux. El comando para iniciar una sesión Telnet generalmente es:
telnet nombre_del_servidor nombre_del_servidor representa el nombre o la
dirección IP del equipo remoto al que se quiere conectar el usuario. También
puede usar su dirección IP, por ejemplo: telnet 125.64.124.77 Por último,
también puede especificar el puerto que desea usar introduciendo el número de
puerto después de la dirección IP o el nombre del servidor: telnet
125.64.124.77 80 Comandos en Telnet Una vez conectado al equipo remoto, se le
solicitará que introduzca un nombre de usuario y una contraseña por razones de
seguridad para permitir el acceso únicamente a los individuos autorizados. De
hecho, la razón por la que Telnet es un protocolo tan potente es el hecho de
que permite que los comandos se ejecuten en forma remota. El administrador de
red define los comandos que se pueden ejecutar en una sesión Telnet.
Generalmente son comandos UNIX, ya que la mayoría de los servidores Telnet
pueden ejecutar UNIX. Los comandos estándar son:
Comando Descripción
? mostrar ayuda
close Cerrar sesión
Telnet display Mostrar la
configuración de la conexión en pantalla (tipo de terminal y puerto)
entorno Para definir las
variables del entorno del sistema operativo
logout Para cerrar la sesión
mode Cambia entre los modos
de transferencia ASCII (transferencia de un archivo como texto) y los modos
BINARIOS (transferencia de un archivo en modo binario)
open Abre otra conexión de
la actual
quit Sale de la aplicación
Telnet
set Cambia la configuración
de conexión
unset Carga la configuración
de conexión predeterminada
Introducción al conjunto de protocolos TCP/IP
Esta sección incluye
una introducción detallada a los protocolos que se incluyen en TCP/IP. Aunque
la información es conceptual, debe conocer los nombres de los protocolos.
También aprenderá las acciones que lleva a cabo cada protocolo.
"TCP/IP" es el acrónimo que se
utiliza comúnmente para el conjunto de protocolos de red que componen el conjunto
de protocolos de Internet. Muchos textos utilizan el término
"Internet" para describir tanto el conjunto de protocolos como la red
de área global. En este manual, "TCP/IP" hace referencia
específicamente al conjunto de protocolos de Internet. "Internet"
hace referencia a la red de área extensa y los elementos que rigen Internet.
Para interconectar la red TCP/IP con otras redes, debe obtener una
dirección IP única para la red. En el momento en que se redacta esta guía, esta
dirección se obtiene a través de un proveedor de servicios de Internet (ISP).
Si los hosts de la red
tienen que participar en el sistema de nombre de dominio (DNS), debe obtener y
registrar un nombre de dominio único. InterNIC coordina el registro de nombres
de dominio a través de un grupo de registros mundiales. Para obtener más
información acerca de DNS, consulte System Administration Guide: Naming and
Directory Services (DNS, NIS, and LDAP) .
La mayoría de los conjuntos de
protocolos de red se estructuran como series de capas, que en ocasiones se
denominan pila de protocolos. Cada capa está diseñada para una
finalidad específica. Cada capa existe tanto en los sistemas de envío como en
los de recepción. Una capa específica de un sistema envía o recibe exactamente
el mismo objeto que envía o recibe el proceso equivalente de
otro sistema. Estas actividades tienen lugar independientemente de las
actividades de las capas por encima o por debajo de la capa que se está
considerando. Básicamente, cada capa de un sistema actúa independientemente de
las demás capas del mismo sistema. Cada capa actúa en paralelo con la misma
capa en otros sistemas.
La mayoría de los conjuntos de
protocolos de red se estructuran en capas. La Organización Internacional para
la Estandarización (ISO) ha diseñado el modelo de referencia de Interconexión
de Sistemas Abiertos (OSI) que utiliza capas estructuradas. El modelo OSI
describe una estructura con siete capas para las actividades de red. Cada capa
tiene asociados uno o más protocolos. Las capas representan las operaciones de
transferencia de datos comunes a todos los tipos de transferencias de datos
entre las redes de cooperación.
El modelo OSI enumera las capas de
protocolos desde la superior (capa 7) hasta la inferior (capa 1). La tabla
siguiente muestra el modelo.
Nº de capa
|
Nombre de capa
|
Descripción
|
7
|
Se compone de los servicios y
aplicaciones de comunicación estándar que puede utilizar todo el mundo.
|
|
6
|
Se asegura de que la información se
transfiera al sistema receptor de un modo comprensible para el sistema.
|
|
5
|
Administra las conexiones y
terminaciones entre los sistemas que cooperan.
|
|
4
|
Administra la transferencia de datos.
Asimismo, garantiza que los datos recibidos sean idénticos a los
transmitidos.
|
|
3
|
Administra las direcciones de datos y
la transferencia entre redes.
|
|
2
|
Administra la transferencia de datos
en el medio de red.
|
|
1
|
Define las características del
hardware de red.
|
|
El modelo de referencia OSI define las operaciones conceptuales
que no son exclusivas de un conjunto de protocolos de red particular. Por
ejemplo, el conjunto de protocolos de red OSI implementa las siete capas del
modelo OSI. TCP/IP utiliza algunas de las capas del modelo OSI. TCP/IP también
combina otras capas. Otros protocolos de red, como SNA, agregan una octava
capa.
Modelo de arquitectura del protocolo TCP/IP
El modelo OSI describe las comunicaciones de red ideales con una
familia de protocolos. TCP/IP no se corresponde directamente con este modelo.
TCP/IP combina varias capas OSI en una única capa, o no utiliza determinadas
capas. La tabla siguiente muestra las capas de la implementación de Oracle
Solaris de TCP/IP. La tabla enumera las capas desde la capa superior
(aplicación) hasta la capa inferior (red física).
Ref. OSI Nº de capa
|
Equivalente de capa OSI
|
Capa TCP/IP
|
Ejemplos de protocolos TCP/IP
|
5,6,7
|
Aplicación, sesión, presentación
|
NFS, NIS, DNS, LDAP, telnet, ftp, rlogin, rsh, rcp, RIP, RDISC, SNMP y otros.
|
|
4
|
Transporte
|
TCP, UDP, SCTP
|
|
3
|
Red
|
IPv4, IPv6, ARP, ICMP
|
|
2
|
Vínculo de datos
|
PPP, IEEE 802.2
|
|
1
|
Física
|
Ethernet (IEEE 802.3), Token Ring,
RS-232, FDDI y otros.
|
Capa de red física
La capa de red física especifica las
características del hardware que se utilizará para la red. Por ejemplo, la capa
de red física especifica las características físicas del medio de comunicaciones.
La capa física de TCP/IP describe los estándares de hardware como IEEE 802.3,
la especificación del medio de red Ethernet, y RS-232, la especificación para
los conectores estándar.
Capa de vínculo de datos
La capa de vínculo de datos identifica el tipo de protocolo de red del paquete, en este caso
TCP/IP. La capa de vínculo de datos proporciona también control de errores y
estructuras. Algunos ejemplos de protocolos de capa de vínculo de datos son las
estructuras Ethernet IEEE 802.2 y Protocolo punto a punto (PPP).
Capa de Internet
La capa de Internet, también conocida como capa de red o capa IP, acepta y transfiere paquetes para la red. Esta capa incluye el
potente Protocolo de Internet (IP), el protocolo de resolución de direcciones (ARP)
y el protocolo de mensajes de control de Internet (ICMP).
Protocolo IP
El
protocolo IP y sus protocolos de enrutamiento asociados son posiblemente la
parte más significativa del conjunto TCP/IP. El protocolo IP se encarga de:
·
Comunicaciones de host a host: El protocolo IP
determina la ruta que debe utilizar un paquete, basándose en la dirección IP
del sistema receptor.
·
Fragmentación: Si un paquete es demasiado grande para su transmisión a través
del medio de red, el protocolo IP del sistema de envío divide el paquete en
fragmentos de menor tamaño. A continuación, el protocolo IP del sistema
receptor reconstruye los fragmentos y crea el paquete original.
Oracle Solaris admite los formatos de direcciones IPv4 e IPv6,
que se describen en este manual. Para evitar confusiones con el uso del Protocolo
de Internet, se utiliza una de las convenciones siguientes:
·
Cuando se utiliza el término "IP" en una descripción,
ésta se aplica tanto a IPv4 como a IPv6.
·
Cuando se utiliza el término "IPv4" en una
descripción, ésta sólo se aplica a IPv4.
·
Cuando se utiliza el término "IPv6" en una
descripción, ésta sólo se aplica a IPv6.
Protocolo ARP
El protocolo de resolución de direcciones (ARP) se encuentra
conceptualmente entre el vínculo de datos y las capas de Internet. ARP ayuda al
protocolo IP a dirigir los datagramas al sistema receptor adecuado asignando
direcciones Ethernet (de 48 bits de longitud) a direcciones IP conocidas (de 32
bits de longitud).
Protocolo ICMP
El protocolo de mensajes
de control de Internet (ICMP) detecta y registra las condiciones de error de la
red. ICMP registra:
·
Fallo de conectividad: No se puede alcanzar un sistema de
destino.
·
Redirección: Redirige un sistema de envío para utilizar otro enrutador.
Capa de
transporte
La capa de transporte TCP/IP garantiza que los
paquetes lleguen en secuencia y sin errores, al intercambiar la confirmación de
la recepción de los datos y retransmitir los paquetes perdidos. Este tipo de
comunicación se conoce como transmisión de punto a
punto.
Los protocolos de capa de transporte de este nivel son el Protocolo de control
de transmisión (TCP), el Protocolo de datagramas de usuario (UDP) y el
Protocolo de transmisión para el control de flujo (SCTP). Los protocolos TCP y
SCTP proporcionan un servicio completo y fiable. UDP proporciona un servicio de
datagrama poco fiable.
Protocolo TCP
TCP permite a las aplicaciones comunicarse entre sí como si
estuvieran conectadas físicamente. TCP envía los datos en un formato que se
transmite carácter por carácter, en lugar de transmitirse por paquetes
discretos. Esta transmisión consiste en lo siguiente:
·
Punto de partida, que abre la conexión.
·
Transmisión completa en orden de bytes.
·
Punto de fin, que cierra la conexión.
TCP
conecta un encabezado a los datos transmitidos. Este encabezado contiene
múltiples parámetros que ayudan a los procesos del sistema transmisor a
conectarse a sus procesos correspondientes en el sistema receptor.TCP confirma que un paquete ha alcanzado su destino estableciendo una conexión de punto a punto entre los hosts de envío y recepción. Por tanto, el protocolo TCP se considera un protocolo fiable orientado a la conexión.
Protocolo SCTP
SCTP es un protocolo de capa de transporte fiable orientado a la
conexión que ofrece los mismos servicios a las aplicaciones que TCP. Además,
SCTP admite conexiones entre sistema que tienen más de una dirección, o de host múltiple. La conexión SCTP entre el sistema transmisor y receptor se
denomina asociación. Los datos de la asociación se organizan en bloques. Dado que
el protocolo SCTP admite varios hosts, determinadas aplicaciones, en especial
las que se utilizan en el sector de las telecomunicaciones, necesitan ejecutar
SCTP en lugar de TCP.
Protocolo UDP
UDP
proporciona un servicio de entrega de datagramas. UDP no verifica las
conexiones entre los hosts transmisores y receptores. Dado que el protocolo UDP
elimina los procesos de establecimiento y verificación de las conexiones,
resulta ideal para las aplicaciones que envían pequeñas cantidades de datos.
Capa de aplicación
La capa de aplicación define las aplicaciones
de red y los servicios de Internet estándar que puede utilizar un usuario.
Estos servicios utilizan la capa de transporte para enviar y recibir datos.
Existen varios protocolos de capa de aplicación. En la lista siguiente se
incluyen ejemplos de protocolos de capa de aplicación:
·
Servicios TCP/IP estándar como los comandos ftp, tftp y telnet.
·
Comandos UNIX "r", como rlogin o rsh.
·
Servicios de nombres, como NIS o el sistema de nombre de dominio
(DNS).
·
Servicios de directorio (LDAP).
·
Servicios de archivos, como el servicio NFS.
·
Protocolo simple de administración de red (SNMP), que permite
administrar la red.
Servicios TCP/IP estándar
·
FTP y FTP anónimo: El Protocolo de transferencia de archivos (FTP) transfiere
archivos a una red remota y desde ella. El protocolo incluye el comando ftp y el daemon in.ftpd. FTP permite a un usuario
especificar el nombre del host remoto y las opciones de comandos de
transferencia de archivos en la línea de comandos del host local. El daemon in.ftpd del host remoto administra las solicitudes del host local. A diferencia
de rcp, ftp funciona aunque el equipo remoto no ejecute un sistema operativo
basado en UNIX. Para realizar una conexión ftp, el usuario debe
iniciar sesión en un sistema remoto, aunque éste se haya configurado para
permitir FTP anónimo.
Puede obtener una gran cantidad de material de servidores FTP anónimos conectados a Internet. Las universidades y otras instituciones
configuran estos servidores para ofrecer software, trabajos de investigación y
otra información al dominio público. Al iniciar sesión en este tipo de
servidor, se utiliza el nombre de inicio de sesión anonymous, que da nombre al
"servidor FTP anónimo"
Este manual no describe el uso del FTP anónimo ni la
configuración de servidores FTP anónimos. Existen múltiples libros, comoConéctate
al mundo de Internet. Guía y catálogo, que describen el protocolo FTP
anónimo de manera pormenorizada. Encontrará información sobre el uso de FTP en
la System Administration Guide: Network Services.
·
Telnet: El protocolo Telnet permite la comunicación entre los
terminales y los procesos orientados a los terminales de una red que ejecuta
TCP/IP. Este protocolo se implementa como programa telnet en los sistemas locales y como daemon in.telnetd en los equipos remotos. Telnet proporciona una interfaz de
usuario a través de la cual se pueden comunicar dos hosts carácter por carácter
o línea por línea.
·
TFTP: el protocolo de transferencia de archivos trivial (tftp) ofrece funciones similares a ftp, pero no establece la
conexión interactiva de ftp. Como consecuencia, los usuarios no pueden ver el contenido de
un directorio ni cambiar directorios. Los usuarios deben conocer el nombre
completo del archivo que se va a copiar.
Comandos UNIX "r"
Los comandos UNIX
"r" permiten a los usuarios ejecutar comandos en sus equipos locales
que se ejecutan en el host remoto. Estos comandos incluyen:
·
rcp
·
rlogin
·
rsh.
Servicios de nombres
·
DNS: El sistema de nombre de dominio (DNS) es el servicio de
nombres que proporciona Internet para las redes TCP/IP. DNS proporciona nombres
de host al servicio de direcciones IP. También actúa como base de datos para la
administración del correo.
·
Archivos /etc : El sistema de nombres
UNIX basado en host se desarrolló para equipos UNIX autónomos y posteriormente
se adaptó para el uso en red. Muchos de los antiguos sistemas operativos y
equipos UNIX siguen utilizando este sistema, pero no resulta adecuado para
redes complejas de gran tamaño.
·
NIS: El Servicio de información de la red (NIS) se desarrolló
independientemente de DNS y tiene un enfoque ligeramente distinto. Mientras que
DNS trata de facilitar la comunicación con el uso de nombres de equipos en
lugar de direcciones IP numéricas, NIS se centra en facilitar la administración
de la red al proporcionar control centralizado sobre distintos tipos de
información de red. NIS almacena información sobre los nombres de equipo y las
direcciones, los usuarios, la red y los servicios de red. La información de
espacio de nombres NIS se almacena en asignaciones NIS.
Servicio de directorios
Oracle Solaris admite
LDAP (Protocolo ligero de acceso a directorios) junto con el servidor de directorios
Sun ONE (Sun Open Net Environment), así como otros servidores de directorios
LDAP. La diferencia entre un servicio de nombres y un servicio de directorios
radica en la extensión de las funciones. Un servicio de directorios proporciona
las mismas funciones que un servicio de nombres, pero además cuenta con
funciones adicionales. Consulte la System Administration Guide:
Naming and Directory Services (DNS, NIS, and LDAP).
Servicios de archivos
Administración de la red
El Protocolo simple de administración de red (SNMP) permite ver
la distribución de la red y el estado de los equipos clave. SNMP también
permite obtener estadísticas de red complejas del software basado en una
interfaz gráfica de usuario (GUI). Muchas compañías ofrecen paquetes de
administración de red que implementan SNMP.
Protocolos de enrutamiento
Los protocolos RIP y
RDISC son dos protocolos de enrutamiento disponibles para las redes TCP/IP.
Para ver una lista completa de los protocolos de enrutamiento disponibles para
Oracle Solaris 10
RUTEO
Como se describió
previamente, la principal responsabilidad del protocolo IP es determinar qué
camino deben tomar los paquetes para llegar al punto de destino. La tarea de
determinar ese camino es lo que se conoce como ruteo (o encaminamiento).
IP asume que la
computadora está directamente conectada a una red local (por
ejemplo, una LAN Ethernet) y que puede enviar paquetes directamente a cualquier
otra computadora sobre esa misma red; si la dirección de destino es en la red
local, IP simplemente accede al medio físico de transmisión y envía el paquete.
En la figura siguiente, Antares y Rigel están
sobre la misma red, por lo que pueden comunicarse directamente:
El problema aparece
cuando la dirección de destino queda en otra red, en cuyo caso IP recurrirá a
un gateway para enviar indirectamente los paquetes. Como se
recordará, se denomina gateway19 a un
dispositivo (ya sea otra computadora o un dispositivo específicamente diseñado
a tal efecto) que está conectado a más de una red y tiene la capacidad para
redirigir (forward) paquetes entre esas redes. En la figura, Orión, Andrómeda,
Cygni y Centauri son los gateways de la red.
Para determinar a qué
gateway deberán enviarse los paquetes, IP extrae la dirección de red del nodo
de destino y consulta una tabla, denominada tabla de ruteo, en la
cual se listan las redes conocidas y los gateways que pueden utilizarse para
alcanzarlas. Por ejemplo, la tabla de ruteo de Aldebarán contiene
la siguiente información:
Red
|
Gateway
|
170.25.1.0
|
170.25.3.254
|
170.25.2.0
|
170.25.3.254
|
170.25.3.0
|
*
|
170.25.4.0
|
170.25.3.253
|
en donde el asterisco
indica que no es necesario ningún gateway para llegar a la red en cuestión dado
que la máquina tiene conexión directa a la misma. Obsérvese en primer lugar que
el ruteo hacia redes remotas se realiza en base a direcciones de red (esto es,
la parte de host de la dirección IP se ignora); además, la tabla de ruteo
especifica tanto la red local como las remotas, y que para el caso de éstas
últimas, indica la dirección IP de alguna máquina en la red local que puede ser
utilizada para alcanzarla.
Supongamos, por ejemplo,
que Altair requiere enviar datos a Canopus. El
módulo IP de Altair determina que la computadora de destino no
pertenece a su misma red; consultando su tabla de ruteo, determina que puede
llegarse a la red de Canopus a través de Orión,
por lo que le envía los paquetes a dicha computadora. El módulo IP residente en Orión,
por su parte, sabe que para llegar a Canopushay dos vías posibles:
pasando por Andrómeda o por Cygni. Aplicando algún
criterio para evaluar ambas rutas y seleccionar la mejor de ellas, Orión envía
cada paquete a, por ejemplo, Andrómeda. Esta última determina que
la dirección de destino está en una de las redes a las que se encuentra
directamente conectada, por lo que los envía diretamente a Canopus.
Es importante observar
que la ruta que seguirán los paquetes desde el origen hasta su destino se va
decidiendo a medida que los mismos viajan por la red. Cada nodo es responsable
de determinar cual es el proximo "salto" en dirección al nodo
final, en función del contenido de su tabla de ruteo. Este modelo de ruteo
asume que si el nodo de destino no pertenece a la red local, deberá haber una
entrada en la tabla de ruteo que especifique el gateway a utilizar. En otras
palabras, asume que todos los nodos están al tanto de la estructura de la red.
En consecuencia, cada
vez que la estructura de la red cambia (por ejemplo, cuando se agrega o elimina
una subred), el administrador debería actualizar las tablas de ruteo en todos
los nodos. Igualmente, si la red se interconectara a otra red, una nueva
entrada debería agregarse en las tablas de ruteo de cada máquina.
Siguiendo con este
razonamiento, a medida que la red crece y se interconecta a otras redes las
tablas de ruteo se hacen mas largas y complejas; inclusive sería posible que
fueran virtualmente imposibles de construir o mantener, en especial si la red
se conecta a Internet (formada por miles de redes independientes).
Por supuesto, existen
previsiones para enfrentar estos problemas: el ruteo dinámico o adaptativo y
las rutas por defecto.
La tabla de ruteo de un
host puede construirse de dos maneras. Una posibilidad consiste en que el
administrador (por medio de scripts que se ejecutan al inicializar el sistema,
o por medio de comandos ejecutados interactivamente) introduzca manualmente las
entradas de la tabla. Esta técnica se denomina ruteo estático,
debido a que la tabla de ruteo se construye cuando la computadora se prende y
no varia con el tiempo.
La otra posibilidad es
ejecutar en cada host un programa que actualice automática y periódicamente la
tabla de ruteo. Dichos programas se basan en el hecho de que una computadora
siempre tiene acceso a otras computadoras conectadas a la red local; esto se
traduce en que las tablas de ruteo contienen inicialmente al menos las
direcciones de las redes locales. Si tomamos por caso a Orión, su
tabla de ruteo inicialmente contendría la siguiente información:
Red
|
Gateway
|
170.25.1.0
|
*
|
170.25.2.0
|
*
|
170.25.3.0
|
*
|
De manera similar, la
tabla de Andrómeda contendrá lo siguiente:
Red
|
Gateway
|
170.25.3.0
|
*
|
170.25.4.0
|
*
|
Si Orión y Andrómeda intercambiaran
sus tablas de ruteo, cada una podría "aprender" de la otra qué
redes son alcanzables por esa vía. Así, Andrómeda podría
concluir lo siguiente:
Red
|
Gateway
|
170.25.1.0
|
170.25.3.254
|
170.25.2.0
|
170.25.3.254
|
170.25.3.0
|
*
|
170.25.4.0
|
*
|
Así, si todos los nodos
de la red ejecutan un programa de estas características (llamado demonio
de ruteo) al cabo de cierto tiempo habrán "descubierto"
por si mismas la estructura de la red y construido sus tablas automáticamente.
Mas aún, si se produjera algún cambio en la estructura de la red, bastaría con
que alguna de las computadoras lo detectara para que en pocos segundos esa
nueva información se propagara por toda la red.
Esta estrategia se
denomina ruteo dinámico o adaptativo y tiene
la ventaja de que, al ser automático, permite eliminar las tareas
administrativas relacionadas con el mantenimiento de las tablas de ruteo.
En ambientes Unix se
dispone de dos programas que implementan este tipo de protocolos de
ruteo: routed y gated.
El uso de ruteo dinámico
elimina la necesidad de modificar las tablas de ruteo cuando la red cambia. Sin
embargo, no resuelve el problema de las abultadas tablas de ruteo resultantes
de conectar una red a muchas otras.
Consideremos la tabla de
ruteo que construiría una máquina como Altair:
Red
|
Gateway
|
170.25.1.0
|
170.25.2.254
|
170.25.2.0
|
*
|
170.25.3.0
|
170.25.2.254
|
170.25.4.0
|
170.25.2.254
|
Como puede verse, Altair ha
aprendido las rutas a todas las subredes de la red, pero el único gateway que
puede utilizar es Orión. De manera similar, si fuera posible que
todas las computadoras de la red del ejemplo aprendieran las direcciones de
todas las redes que forman la Internet, Altair eventualmente
construiría una tabla de ruteo con miles de entradas, en donde todas tendrían a Orión como
gateway. En ambos casos, el resultado es una tabla de ruteo con información
altamente redundante.
Para eliminar este
problema, es que puede instalarse en la tabla de ruteo una ruta por
defecto (conocida también como default gateway). IP
utiliza la ruta por defecto (que se indica con el número 0.0.0.0) cada vez que
no se encuentra en la tabla de ruteo una ruta hacia una red específica. Aplicando
éste criterio, la tabla de Altair se reduciría a lo siguiente:
Red
|
Gateway
|
170.25.2.0
|
*
|
0.0.0.0
|
170.25.2.254
|
que sencillamente indica
que si la dirección de destino está en la red local, es accesible directamente,
y que en caso contrario (independientemente de cual sea el destino), los
paquetes deberán enviarse a 170.25.2.254 (es decir, Orión).
En este caso, se tiene
una red pequeña, en la que todas las computadoras están ubicadas sobre el mismo
segmento físico y no hay ninguna conexión a otras redes TCP/IP:
Como se puede ver, todas
las computadoras tienen acceso directo a todas las demás. La tabla de ruteo
será mínima; solo contendrá una referencia a la red local y a la red de
loopback instaladas automáticamente por ifconfig al
inicializar las interfaces correspondientes.
Puede utilizarse el
comando route -n para examinar el contenido de la tabla
de ruteo (-n indica a route que
utilice formato numérico):
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.0 0.0.0.0 255.0.0.0 U 0 1 298 lo
205.12.9.0 0.0.0.0 255.255.255.0 U 0 40 1252 eth0
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.0 0.0.0.0 255.0.0.0 U 0 1 298 lo
205.12.9.0 0.0.0.0 255.255.255.0 U 0 40 1252 eth0
En el listado anterior,
la primera columna indica dirección de red (que debe interpretarse de acuerdo a
la mascara de la tercera columna) y la segunda columna indica el gateway a
utilizar (0.0.0.0 se utiliza para indicar que hay conexión directa a la red en
cuestión. Route también muestra información adicional
sobre cada ruta:
Flag: Se compone de una
serie de caracteres que indican las características de la ruta. Por ejemplo, U
indica que la ruta está operacional (por Up), G que es una ruta a
un gateway, H que es una ruta a un host, etc.
Metric: Valor utilizado
para cuantificar la ruta. IP utiliza este valor para seleccionar la mejor de
dos o más rutas alternativas a la misma red.
Ref: Cantidad de veces
que ésta ruta fue utilizada para establecer una conexión.
Use: Cantidad de
paquetes trasmitidos a través de esa ruta.
Si esta misma red se
conectara a otras redes (por ejemplo, la Internet), sería necesario indicar en
cada uno de los hosts de la red una ruta estática por defecto hacia el gateway
a las otras redes:
Las rutas por defecto
puede instalarse en las estaciones por medio del siguiente comando route:
# route add -net default 205.12.9.254
Si ahora se reexaminara
la tabla de ruteo en dichas estaciones, se obtendría el siguiente resultado:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.0 0.0.0.0 255.0.0.0 U 0 1 298 lo
205.12.9.0 0.0.0.0 255.255.255.0 U 0 40 1252 eth0
0.0.0.0 205.12.9.254 0.0.0.0 UG 0 0 0 eth0
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.0 0.0.0.0 255.0.0.0 U 0 1 298 lo
205.12.9.0 0.0.0.0 255.255.255.0 U 0 40 1252 eth0
0.0.0.0 205.12.9.254 0.0.0.0 UG 0 0 0 eth0
Obsérvese que Orión interconecta
nuestra red con el exterior, por lo que tiene una dirección en la red local
(170.25.9.254) y otra en la red del proveedor de acceso a la otra red (en este
caso, la Internet). A fin de lograr la conectividad, deberá instalarse en Orión una
ruta por defecto hacia el exterior, utilizando como gateway una dirección que
el proveedor especifique, por ejemplo:
# route add -net default 150.104.3.254
Por otra parte, el
proveedor deberá instalar en sus ruteadores alguna ruta que indique que nuestra
red es alcanzable a través de la dirección 150.104.3.21, cerrando así el ciclo
de entrada y salida a nuestra red.
En este caso, la red
está compuesta por varios segmentos unidos entre sí por gateways. Una primera
opción sería ejecutar un demonio de ruteo dinámico en todas las computadoras, y
dejar que las tablas se actualicen automáticamente. Sin embargo si tal programa
no estuviera disponible (o por alguna razón se decide no emplearlo) bastaría
con instalar en las computadoras de cada segmento una ruta estática por defecto
hacia el gateway Orión, tal como se muestra en la siguiente figura:
Para obtener esta
configuración, en Antares y Rigel habría que
ejecutar el siguiente comando:
# route add -net default gw 170.25.1.254
mientras que en Altair y Aldebarán el
comando sería:
# route add -net default gw 170.25.2.254
No es necesario instalar
manualmente ninguna ruta en Orión, debido a que todas las
necesarias serán instaladas automáticamente por ifconfig.
Sería diferente si la
red tuviera más subredes:
En éste caso, sería
necesario informar a Orión acerca de la existencia de la red
170.25.4.0, y a Andrómeda acerca de las redes 170.25.1.0 y
170.25.2.0. Una vez mas, puede utilizarse el comando routepara
instalar las rutas, utilizando la siguiente sintaxis:
# route add -net red netmask máscara gw gateway
Por ejemplo, en Andrómeda habría
que ejecutar los siguientes comandos:
# route add -net 170.25.1.0 netmask 255.255.255.0 gw 170.25.3.254
# route add -net 170.25.2.0 netmask 255.255.255.0 gw 170.25.3.254
# route add -net 170.25.2.0 netmask 255.255.255.0 gw 170.25.3.254
con lo que la tabla de
ruteo quedaría conformada de la siguiente manera:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.0 0.0.0.0 255.0.0.0 U 0 1 298 lo
170.25.3.0 0.0.0.0 255.255.255.0 U 0 105 11252 eth0
170.25.4.0 0.0.0.0 255.255.255.0 U 0 55 1976 eth1
170.25.1.0 170.25.3.254 255.255.255.0 UG 0 20 841 eth0
170.25.2.0 170.25.3.254 255.255.255.0 UG 0 33 976 eth0
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.0 0.0.0.0 255.0.0.0 U 0 1 298 lo
170.25.3.0 0.0.0.0 255.255.255.0 U 0 105 11252 eth0
170.25.4.0 0.0.0.0 255.255.255.0 U 0 55 1976 eth1
170.25.1.0 170.25.3.254 255.255.255.0 UG 0 20 841 eth0
170.25.2.0 170.25.3.254 255.255.255.0 UG 0 33 976 eth0
Finalmente, si la red
tuviera conexión a redes externas, sería necesario instalar en los gateways una
ruta por defecto que conduzca hacia el gateway al exterior:
En Orión:
# route add -net default
gw 170.25.3.253
En Andrómeda:
# route add -net default gw 170.25.4.253
En todos los ejemplos
anteriores se utilizó el comando route para instalar
rutas manualmente en la tabla de ruteo. Sin embargo, al igual que ocurre con ifconfig,
usualmente el administrador no instala las rutas introduciendo comandos
manualmente (o modificando scripts de inicialización del sistema), sino que se
limita a modificar archivos de configuración o utilizar alguna herramienta
gráfica.
En el caso de Red Hat
Linux, la utilidad netcfg que se mencionó con anterioridad puede
utilizarse para configurar la ruta por defecto e instalar rutas estáticas.
También pueden realizarse estas tareas modificando manualmente archivos de
configuración network y static-routes respectivamente,
ubicados ambos bajo /etc/sysconfig.
No hay comentarios:
Publicar un comentario