tredirtredir es una de las utilidades más potentes de term, permitiendo que la
mayoria de los servicios de red importantes puedan obtenerse en un enlace
term. Antes de explicar como 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 lo que 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 envia 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 obtinene conectando con un puerto inetd en particular. Cuando se hace una solicitud de red, inetd conoce exactamente que 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.b. no termtelnet). Por ejemplo, para hablar con el demonio de sendmail
(o smtp) en la máquina machine_name, se puede hacer un 'telnet machine_name
smtp', o 'telnet machine_name 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 muy parecido 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
envia 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. Aqui 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
conectandome al puerto redirigido de la máquina en red (usando telnet) -
i.e. '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 que 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 via term. (n.b., si
lee las News de este modo, asegurese 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:).
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 asi 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 linea correspondiente al servicio poniendo
un caracter # al comienzo de la misma. El superusuario tiene que mandar una
señal HUP a inetd (kill -1 <inetd-pid>) para hacerle que vuelva a leer su
configuración.
tredirEn 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.
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:
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
propia opción, 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.
TERMEstá 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 alla 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
rtfm.mit.edu en 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 envio 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 envio
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 donde enviarlo observando la
dirección, y finalmente lo envian 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 este corriendo en otra
máquina de la red que sepa que 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 envie 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 maquina 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. Ovservar que presumimos que ya ha configurado
smail correctamente para el correo local - envio a ficheros y tuberias 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=YOUR_SMTP_SERVICE,
En el de arriba, las lineas 'header' cambian la cabecera From en todos los
correos salientes por la dirección, SU_DIRECCION_DE_RED, que será la
dirección de red a la que quiere que le envien 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
multiples encolados a través de un puerto redirigido; el sendmail 8.6.9 de
BSD funciona bien. El 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 envía 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. Seguido le
decimos a sendmail a que máquina conectarse, y punemos 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 envia 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 mi 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.