Anterior Siguiente Indice

7. tredir

tredir es una de las utilidades más potentes de term, permitiendo que la mayoría de los servicios de red importantes puedan obtenerse en un enlace term. Antes de explicar cómo se usa tredir, es necesario dar algunas nociones sobre los servicios de red.

Ya se ha hablado antes sobre los servicios de red, pero no se ha dicho exactamente qué son. Los servicios son justo eso - servicios que proporciona la red. Ejemplos de servicios incluyen telnet, que proporciona logins entre máquinas, el ftp (File Transfer Protocol), o Protocolo de Transferencia de Ficheros, que transfiere ficheros entre máquinas, y smtp, el protocolo de transmisión de correo, que se usa siempre que se envía un correo electrónico.

Cada servicio de red tiene un número de puerto asociado a él. El mapeo de números de puerto con los servicios correspondientes se da en el fichero /etc/services. Este fichero debería ser el mismo en todas las máquinas conectadas a Internet.

¿Como se accede a estos servicios? Cada máquina en red corre un demonio llamado inetd, el cual escucha los intentos de conexión a los puertos de red. Estas peticiones pueden llegar tanto desde la red, como desde la propia máquina. Un servicio de red se obtiene conectando con un puerto inetd en particular. Cuando se hace una solicitud de red, inetd conoce exactamente qué servicio está implicado, por el número de puerto al que se hizo la solicitud. Si se configura inetd para hacerlo, proporcionará el servicio adecuado a la conexión que lo solicita. La configuración de inetd es la que se da en el fichero /etc/inetd.conf, que contiene una lista de los servicios que proporciona inetd. Para más información vea las páginas de manual de inetd e inetd.conf.

Se puede comunicar directamente con los servicios de red usando telnet (nótese bien, no termtelnet). Por ejemplo, para hablar con el demonio de sendmail (o smtp) en la máquina nombre_de_máquina;, se puede hacer un telnet nombre_de_máquina smtp , o telnet nombre_de_máquina 25, (ya que 25 es el puerto asignado a smtp en /etc/services). Debería obtener una agradable bienvenida del demonio de la máquina remota. Este es un truco muy útil para depurar problemas de red y chequear puertos redirigidos con tredir (ver abajo).

tredir funciona de modo similar a inetd. Funciona en background como un demonio, escuchando los puertos de red, esperando a una petición. Cuando se hace una solicitud de un servicio, en vez de proporcionar ese servicio, como hace inetd, tredir traslada la solicitud a través del enlace term hasta el term remoto, quien hace la solicitud a la red, devolviendo el resultado de nuevo por el enlace hasta el cliente local. tredir puede trasladar la solicitud a cualquier máquina de la red, pero por defecto la envía a la máquina al otro extremo del enlace term. tredir ``redirige'' los servicios TCP (Transmision Control Protocol) a través del enlace term.

Un ejemplo lo aclarará. Vamos a redirigir un puerto local al puerto telnet de la máquina remota. Para hacer esto pondríamos tredir 2023 23. Ahora, cualquiera que conecte al puerto 2023 de la máquina local será redirigido al puerto 23 (telnet) de la máquina remota. Aquí va una sesión de ejemplo; la máquina local es mimaquina.modem.casa y la remota es netsun.

$ tredir 2023 23
Redirecting 2023 to 23
$ telnet localhost 2023
Trying 127.0.0.1...
Connected to mimaquina.modem.casa
Escape character is '^]'.


SunOS UNIX (netsun)
login:

Este ejemplo es realmente muy útil. Si en su lugar hiciera el tredir sobre netsun, entonces podría hacer telnet a mimaquina desde la red simplemente conectándome al puerto redirigido de la máquina en red (usando telnet) - esto es, telnet netsun 2023.

El principio general de uso del tredir es redirigir el servicio deseado a una máquina de la red. El siguiente ejemplo nos permitirá leer las News en la máquina local a través del enlace term desde un servidor de News de la red. Las News las proporciona el servicio nntp, puerto 119. Todos los lectores de News decentes permiten especificar qué puerto van a utilizar, ya sea en un fichero de configuración o en una variable de entorno. Vamos a especificar que el puerto local sea el 2119. Ahora supongamos que el servidor de News es news.domain.org; entonces le diremos al software de lectura de News que el servidor nntp se encuentra en el puerto 2119 del host local. Como esto dependerá del lector de News que se use, probaremos el enlace con telnet en lugar de ejecutar un lector de News:

$ tredir 2119 news.domain.org:119
Redirecting 2119 to news.domain.org:119
$ telnet localhost 2119
Trying 127.0.0.1...
Connected to mimaquina.modem.casa.
Escape character is '^]'.
200 news.domain.org InterNetNews NNRP server INN 1.4 07-Dec-41 ready
(posting ok).

Si ha podido llegar tan lejos, todo lo que tiene que hacer es configurar su lector de News para poder leer las News desde casa vía term. (nótese bien, si lee las News de este modo, asegúrese de que en todos los mensajes que deje ponga una cabecera Reply-To: a una dirección de correo en la que pueda ser localizado, o de lo contrario la gente que quiera ponerse en contacto con Ud. mandará el correo a cualquier dato que su lector de News ponga en la cabecera From:).

7.1 ¡tredir puede morder!

El astuto lector, tras leer el último ejemplo se preguntará porqué se redirigió en puerto 2119 al puerto 119 --ya que el puerto por defecto de los lectores de News es el 119--, ¿porqué no podría hacer un tredir 119 news.domain.org:119 y evitar la configuración del lector de News? La respuesta es que todos los puertos con números inferiores a 1024 son ``puertos reservados'', y únicamente el superusuario puede escucharlos. Si se desea tomar un riesgo en seguridad y hacer de tredir un programa suid, o ejecutar tredir como root, entonces se pueden redirigir puertos reservados y evitar así la molestia de renombrar servicios.

Otro problema de usar los puertos reservados es que inetd a menudo ya está escuchando en esos puertos, y solamente un programa puede escuchar un puerto a la vez. Si se quiere usar tal puerto, se debe cambiar inetd.conf de modo que inetd ya no escuche en ese puerto que se quiere redirigir. Esto se hace fácilmente comentando la línea correspondiente al servicio poniendo el carácter # al comienzo de la misma. El superusuario tiene que mandar una señal HUP a inetd (kill -1 <inetd-pid>) para hacer que vuelva a leer su configuración.

7.2 Trucos tontos de tredir

En esta sección describiremos algunos de los usos más comunes de tredir. Ya hemos descrito como redirigir los servicios nntp y telnet; Ahora daremos algunos ejemplos más complicados.

X window

En una sección previa, se describió como hacer que un cliente X que corre en la red abra una ventana en la máquina de casa usando txconn. La misma técnica se podría usar en la máquina de casa para mostrar un cliente en la máquina del lado remoto del enlace term. ¿Pero cómo puede uno ver un cliente X en una máquina de red que no es el extremo remoto? La respuesta se basa en conocer que X usa un servicio de red concreto igual que los otros programas que hemos explicado. Un servidor X escucha peticiones de red en un puerto cuyo número viene dado por la fórmula: puerto = 6000 + número de display, p.ej. un servidor X manejando la pantalla 0 en una máquina escucharía el puerto 6000, si estuviéramos manejando la pantalla 2, escucharía el puerto 6002. Si se pone la variable de entorno DISPLAY en maquinaX:n, los clientes X tratarán de conectar con el puerto 6000+n de maquinaX.

Podemos usar esto para trucar los clientes X de la máquina local y abrir ventanas en displays remotos. Supongamos que quiero abrir un xterm, corriendo en mi máquina local, en el display 0 de la máquina maquinaX, que esta corriendo en algún lugar de la red. Primero escogeré un número de display local, digamos que el 2 (no se usa el 0, ya que es el que estará usando el servidor X local). Mapearé este display al display 0 de maquinaX. En término de puertos, esto significa que quiero redirigir el puerto local 6002 al puerto remoto 6000. Haré lo siguiente:

$ tredir 6002 xmachine:6000 
$ setenv DISPLAY localhost:2
$ xterm 

Esto debería abrir un xterm en la máquina maquinaX. Observe que he puesto el DISPLAY a localhost:2. Esto es porque los clientes X usan a veces sockets de dominio unix en lugar de sockets de dominio Internet, a su propio criterio, cuando conectan con un display local, si DISPLAY se pone a :2. localhost:2 indica que use una conexión TCP.

Observe que en lo que concierne a maquinaX, la solicitud X viene de la máquina del extremo remoto del enlace term (máquinaremota) - de modo que si necesita autorizar la conexión, debería hacer bien xhost + máquinaremota en maquinaX, o bien usar xauth para actualizar el fichero .Xauthority en su máquina local para el display número 2, usando la clave de maquinaX.

De nuevo, para acelerar las conexiones X, se puede usar el programa sxpc, que incluye una explicación sobre cómo usar tredir para establecer el enlace y autorizarlo usando xauth.

Correo con TERM

Está bien, vosotros lo pedísteis. El correo electrónico tiene la justificada reputación de ser una de las cosas más dificiles de hacer funcionar bien en un sistema UNIX. Para conseguir que el term funcione correctamente con el correo es preciso entender cómo funciona el correo, lo cual va más allá del objetivo de este documento.

Para aprender más sobre correo, debería consultar un libro de administración de sistemas UNIX y/o la FAQ de la conferencia comp.mail.misc, disponible en el ftp anónimo de ftp://rtfm.mit.edu/pub/usenet/comp.mail.misc.

También tiene a su disposición 2 paquetes en el ftp anónimo de sunsite.unc.edu que le ayudarán a poner en marcha el correo bajo term - son term.mailerd+smail de Byron A. Jeff y BCRMailHandlerXXX de Bill C. Riemers.

Como se ha dicho, haremos una breve descripción de como funciona el correo electrónico. Hay dos partes que hacen funcionar el correo, el envío de mensajes y la recepción de los mismos. Comenzaremos con el envío de mensajes desde su ordenador local a la red.

Hay dos clases de programas de correo. El primero es el Agente de Correo de Usuario (MUA - Mail User Agent). Los MUAs ayudan a leer, componer y mandar mensajes. Ejemplos de MUAs son el elm, pine, mail y vm. Los MUAs no usan para nada la red; solamente agrupan los mensajes - el trabajo duro de envío de correo se hace a través de la segunda clase de programas, los agentes de transferencia de correo (MTA - Mail Transfer Agent). Estos son invocados desde los MUAs. Toman el mensaje, deciden dónde enviarlo observando la dirección, y finalmente lo envían a través de la red.

Los dos MTAs mas comunes en sistemas Linux son sendmail y smail. La idea básica es hacer que su MTA se conecte a otro MTA que esté corriendo en otra máquina de la red que sepa qué hacer con su mensaje. Esto se consigue redirigiendo un puerto local hacia el puerto smtp de la máquina en red. Entonces debe indicar a su MTA que tome todos los mensajes con los que no sepa que hacer, y los envíe fuera a través del puerto redirigido de su máquina local al MTA de la máquina remota, la cual encaminará los mensajes hacia su destino correcto.

¿Cómo hacemos esto usando smail? Primero redirigiremos un puerto al puerto smtp de la máquina de correo de la red (mailhost):

tredir XXXX mailhost:25

donde XXXX es el número de puerto al que se conecta smail en el host local (tenga en cuenta que hay que dar un nombre al puerto en /etc/services para hacer que smail lo reconozca). smail tiene varios ficheros de configuración que generalmente están en /usr/local/lib/smail. Los que nos interesan son config, routers y transports. Observar que presumimos que ya ha configurado smail correctamente para el correo local - envío a ficheros y tuberías y demás cosas. De nuevo, consulte la documentación si no lo ha hecho.

En el fichero config, ponemos la siguiente definición:

smart_path=localhost

localhost es la máquina a la que se conecta smail cuando no sabe que hacer con un mensaje.

En routers ponemos:

 
smart_host: 
driver=smarthost, 
transport=termsmtp; 
path = localhost 

En transports ponemos:

  
termsmtp:        driver=tcpsmtp, 
        inet,                    
        return_path, 
        remove_header="From", 
        append_header="From: SU_DIRECCION_DE_RED", 
        -received, 
        -max_addrs, -max_chars; 
        service=SU_SERVICIO_SMTP, 

En el de arriba, las líneas header cambian la cabecera From en todo correo saliente por la dirección SU_DIRECCION_DE_RED, que será la dirección de red a la que quiere que le envíen el correo. Si su enlace term va a ser usado por más de una persona, tendrá que hacer algo más laborioso, como mantener una base de datos de direcciones de red de usuarios locales e insertar las mismas en las cabeceras From:.

La línea service es el nombre del número de puerto local que ha redirigido al puerto smtp de la máquina conectada a la red. En mi versión de smail no es posible ponerlo como un número, asi que tengo que ponerlo como un nombre, como ``foo'', y entonces definir ``foo'' en /etc/services de modo que sea el número del puerto redirigido. Si usa un suid de tredir y se redirige el puerto smtp (25), no es necesario definir esto.

Esto debería ser suficiente para hacerlo funcionar. Si decide usar sendmail la base es la misma pero difiere en los detalles. Ronald Florence ( ron@mlfarm.com) me dijo que el sendmail de Sun no mandará mensajes múltiples encolados a través de un puerto redirigido; el sendmail 8.6.9 de BSD funciona bien. Él hizo los siguientes cambios al sendmail.cf para que funcionase con term. En este caso se usa el puerto por defecto de sendmail (25) para el tráfico sobre una ethernet local de forma que el correo Internet se pasa al puerto TCP redirigido.

#
# Crear el mailer termsmtp, el cual envia el correo via el puerto TCP 
# redirigido
#
Mtermsmtp,P=[TCP], F=mDFMuCXe, S=22, R=22, A=TCP $h PORTNUMBER

Aquí, PORTNUMBER es el número del puerto redirigido en la máquina local. Este debería ser un puerto sin usar por encima del 2000. Seguidamente le decimos a sendmail a que máquina conectarse, y ponemos a termsmtp como mailer por defecto.

#
# relevo de correo principal
#
DMtermsmtp
#
# maquina del relevo principal: usa el mailer $M para enviar el
# correo de otros dominios
#
DR HOSTNAME
CR HOSTNAME

Aquí HOSTNAME es el nombre de tu host local (¿funcionará localhost?). La última entrada va debajo de Rule 0 para pasar el correo Internet.

# Pass other valid names up the ladder to our forwarder
R$*<@$*.$+>$*           $#$M    $@$R $:$1<@$2.$3>$4     user@any.domain

Cuando la conexión term se haya establecido con el host Internet, ejecute los siguientes comandos en la máquina local.

tredir PORTNUMBER internet.host:25
/usr/lib/sendmail -q

Pasamos ahora a la recepción de correo electrónico usando term. Asumiremos que el correo se envía a su cuenta en el servidor de correo (mailhost) de la red. La solución más simple es usar trsh o termtelnet para acceder al servidor y leer su correo allí.

Sin embargo, también es posible hacer pasar el correo automáticamente a su máquina local. Una forma de hacer esto es usar el Post Office Protocol, (POP). POP fue diseñado precisamente para este propósito: enviar correo a máquinas que tienen conexiones de red esporádicas.

Para usar POP ha de tener instalado un servidor POP en mailhost. Suponiendo que lo tiene, puede usar entonces un cliente POP para recoger su correo cada poco tiempo. Esto se hace, como podría esperar, usando tredir. El servicio POP es el 110 (Observe que hay un protocolo más antiguo, POP-2, que usa el puerto 109; en este documento describiremos POP-3, que es la última versión de POP). Hay varios clientes POP disponibles. Uno, escrito en el lenguaje de scripts perl, es pop-perl-1.X, escrito por William Perry y mantenido por mí mismo - puede encontrarse en sunsite en /pub/Linux/system/Mail.

Para usar POP se redirige un puerto local al puerto 110 de mailhost y se configura el cliente para recoger su correo de localhost usando el puerto local. Como ejemplo, supongamos que hay un servidor POP corriendo en mailhost. Redirigiremos en puerto local 2110, y ejecutamos el cliente pop-perl:

$ tredir 2110 mailhost:110
Redirecting 2110 to mailhost:110
$ pop 
Username: bill
Password: <introduzca su password para mailhost>
Pop Host: name of local 
Pop Port: 2110 
Starting popmail daemon for bill 

Si no tiene un servidor POP disponible, el paquete BCRMailHandler tiene un programa para capturar su correo desde un enlace term hasta su máquina local. No lo he usado, pero cualquier comentario de alguien que lo haya hecho será bienvenido. También puede usar el paquete term.mailerd+smail para este propósito. Sin embargo, BCRMailHandler y term.mailerd+smail ya no funcionan con versiones de term 2.0.0 o superiores.


Anterior Siguiente Indice

Hosting by: hurra.com
Generated: 2007-01-26 18:00:37