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