<!doctype linuxdoc system>

<article>

<title>Diald Como

<author>Andrés Seco <tt><htmlurl url="mailto:AndresSH@ctv.es"
name="AndresSH@ctv.es"></tt>

<date>v1.0, 15 de Febrero de 2000

<abstract>
Este documento trata de mostrar varios escenarios típicos de utilización
de <em/Diald/ para facilitar su puesta en marcha.
Los escenarios presentados varían desde una conexión para uso personal en
un equipo conectado mediante módem y PPP a un proveedor de servicios de
internet (ISP), de manera que no haya que utilizar scripts del tipo
<tt>pon/poff</tt> o <tt>ppp-on/ppp-off</tt>, hasta un servidor
proxy/firewall con diferentes ISPs para acceder a internet.
</abstract>

<toc>

<sect>Introducción

<sect1>Objetivos
<p>

Este documento trata de mostrar varios escenarios típicos de utilización
de <em/Diald/ para facilitar su puesta en marcha.

Los escenarios presentados varían desde una conexión para uso personal en
un equipo conectado mediante módem y PPP a un proveedor de servicios de
internet (ISP), de manera que no haya que utilizar scripts del tipo
<tt>pon/poff</tt> o <tt>ppp-on/ppp-off</tt>, hasta un servidor
proxy/firewall con diferentes ISPs para acceder a internet.

En el presente documento se tratan los siguientes escenarios:
<itemize>
<item>Conexión mediante módem y PPP de un equipo aislado a un proveedor de
servicios de internet (ISP).
<item>Conexión mediante módem y PPP de un equipo aislado a varios
proveedores de servicios de internet (ISPs) no simultáneamente.
<item>Conexión mediante módem y PPP de un proxy/firewall a un proveedor de
servicios de internet (ISP).
</itemize>

En sucesivas versiones de este documento se cubrirán otros escenarios,
como múltiples instancias de <em/Diald/ en ejecución, uso de lineas RDSI y
lineas usadas tanto para generar llamadas como para recibirlas.

Anteriormente, existía un Diald-mini-Como realizado por Harish Pillay
<tt><htmlurl url="mailto:h.pillay@ieee.org"
name="h.pillay@ieee.org"></tt>, que presentaba una conexión a un ISP
usando autentificación basada en chat (login y password previos al
arranque de pppd, sin usar PAP ni CHAP).

En el documento se incluirán ficheros de configuración de ejemplo que
servirán para la puesta en marcha. Para obtener el máximo rendimiento y
usar todas las características de los programas que se utilizarán será
necesario leer la documentación adjunta a cada programa y reconfigurar
dichos ficheros de configuración que se incluyen como ejemplos.

Así mismo, los directorios en los que se sitúan los ficheros de
configuración pueden variar dependiendo de la distribución Linux que se
use. Si en la distribución de Linux que usted usa algún fichero se
encuentra en directorio diferente al indicado, por favor, hágamelo saber
para incluir una nota al respecto.

<sect1>Nuevas versiones
<p>

La ultima versión de este documento puede ser encontrada en mi pagina web
<tt><htmlurl url="http://www.ctv.es/USERS/andressh/linux"
name="http://www.ctv.es/USERS/andressh/linux"></tt>, en formato SGML y
HTML.
Otras versiones y formatos pueden ser encontrados en castellano en el
Insflug, <tt><htmlurl url="http://www.insflug.org/documentos/Diald-Como/"
name="http://www.insflug.org/documentos/Diald-Como/">,</tt> y en otros idiomas
en el LDP - Proyecto de Documentación de Linux, <tt><htmlurl
url="http://www.linuxdoc.org" name="http://www.linuxdoc.org"></tt>.

<sect1>Agradecimientos
<p>

Quiero dar las gracias a las personas que me ayudaron a poner en marcha mi
primer Diald con sus ficheros de ejemplo (alguien de quien no me acuerdo
como se llamaba, Mr Cornish Rex y Hoo Kok Mun), a los que me han aportado
sugerencias y correcciones a este documento, a los futuros traductores de
este documento a otros idiomas y sobre todo a la gente que ha desarrollado
y desarrolla <em/Diald/ para los que lo usamos.  

<sect>Copyright y renuncia de responsabilidad
<p>

Este documento es <tt>copyright &copy; 2000 Andres Seco</tt>, y es un
documento libre. Puede distribuirlo bajo los términos de la <bf>GNU
General Public License</bf>, que puede encontrar en <tt><htmlurl
url="http://www.gnu.org/copyleft/gpl.html"
name="http://www.gnu.org/copyleft/gpl.html"></tt>. Una copia
de ésta traducida al castellano la puede encontrar en <tt><htmlurl
url="http://visar.csustan.edu/~carlos/gpl-es.html"
name="http://visar.csustan.edu/~carlos/gpl-es.html"></tt>.

La información y otros contenidos en este documento son lo mejor de mis
conocimientos. Sin embargo, he podido cometer errores. Así que debería
determinar si desea seguir las instrucciones que se encuentran en este
documento.

Nadie es responsable de cualquier daño en sus ordenadores y cualquier otra
pérdida por el uso de la información contenida aquí.

EL AUTOR Y MANTENEDORES NO SON RESPONSABLES DE CUALQUIER DAÑO INCURRIDO A
CAUSA DE ACCIONES TOMADAS EN BASE A LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO. 

Por supuesto, estoy abierto a todo tipo de sugerencias y correcciones
sobre el contenido de este documento.

<sect>Descripción rápida del funcionamiento de Diald
<p>

En pocas palabras, <em/Diald/ lo que hace es generar un interfaz de red
nuevo y establecerlo como ruta por defecto. Este interfaz no es real (en
la documentación original lo llaman <tt/proxy interface/). <em/Diald/
monitoriza este interfaz y cuando llegan paquetes hacia él, lanza la
conexión <tt/ppp/, espera a que se establezca y cambia la dirección de la
ruta por defecto sobre la nueva interface <tt/ppp/ (normalmente
<tt/ppp0/).

<em/Diald/ controla qué paquetes han llegado al interface y de qué tipo
para decidir si los considera a efectos de lanzar la conexión <tt/ppp/,
mantenerla activa, hacerla caer o no hacer nada, y en caso de que hayan
sido paquetes para tener en cuenta, cuánto tiempo debe estar levantado el
interface después de que haya llegado el paquete.

Finalmente, si no hay más tráfico y se acaba el tiempo de espera que el
último de los paquetes enviados estableció, <em/Diald/ finaliza la
conexión.

Asimismo, es posible controlar los días y horas a los que se puede
conectar y los que no, de modo que se puedan aprovechar tarifas bajas u
horarios de bajo tráfico.

Hasta aquí, la descripción es válida tanto para la versión 0.16.5 de
<em/Diald/ como para las posteriores, pero las versiones posteriores a
esta también incluyen funcionalidades adicionales, tales como lista de
permisos para decidir a qué usuarios se aplican las normas que deciden si
el enlace se levanta, se mantiene o se tira, contabilización avanzada de
paquetes transmitidos, mejor integración con lineas RDSI, mejora de
rendimiento en base a usar como interfaz proxy un dispositivo
<tt/ethertap/ (algo así como un interfaz de red que lee/escribe sobre
un socket en vez de una tarjeta de red física) en vez de <tt/slip/,
conexiones de backup y algunas otras funcionalidades.

<sect>Notas sobre la identificación en el momento de la conexión
<p>

Siempre que nos conectemos a un proveedor de acceso a internet, será
necesario enviar un nombre de usuario y una contraseña. Para ello hay
diversas posibilidades que nos vendrán impuestas por el proveedor.

Además de las 3 opciones expuestas, también es posible que la conexión no
necesite autentificación (normalmente cuando el destino de la llamada es
otro ordenador también nuestro y no deseamos autentificar).

<sect1>Usuario y contraseña - Login y password
<p>

Actualmente no es un método muy utilizado en entornos de acceso a
internet.

La identificación se realiza antes de lanzar el demonio <tt/pppd/, y es el
propio programa marcador, normalmente <tt/chat/, el que envía los
identificadores de usuario y clave. Este envío de usuario y clave se
realiza «en claro», por lo que no puede ser considerado seguro.

Un ejemplo de script para el programa <tt/chat/ en el que sea necesario
indicar usuario y contraseña antes de lanzar <tt/pppd/ podría ser el
siguiente: 

<tscreen><verb>
ABORT BUSY
ABORT "NO CARRIER"
ABORT VOICE
ABORT "NO DIALTONE" 
ABORT "NO ANSWER"
"" ATZ
OK ATDT_NumeroDeTelefono_
CONNECT \d\c
ogin _NombreUsuario_
assword _Contraseña_
</verb></tscreen>

Las 2 ultimas lineas son las que definen el nombre del usuario y la
contraseña y cuando deben ser enviadas (después de recibir
«ogin» y «assword» respectivamente. No se suelen
poner las primeras letras de dichas palabras para no preocuparse de que
unos servidores las envíen en mayúsculas y otros en minúsculas).

Este script suele estar en un fichero en el directorio
<tt>/etc/chatscripts</tt>, y, suponiendo que el fichero de script se llama
<tt/provider/, puede ser llamado con la linea siguiente:

<tscreen><verb>
/usr/sbin/chat -v -f /etc/chatscripts/provider
</verb></tscreen>

<sect1>PAP - Password Authentication Protocol
<p>

En caso de que el servidor de acceso al que nos conectamos requiera PAP
como protocolo para realizar la autentificación de nuestra conexión,
durante el establecimiento de la sesión LCP de PPP se negociará dicho
protocolo, es decir, una vez establecida la conexión de <tt/chat/ y
lanzado <tt/pppd/, será este quien realice el envio del nombre de
usuario y clave, buscando en el fichero <tt>/etc/ppp/pap-secrets</tt> los
valores que debe usar. Este fichero tiene acceso de lectura y escritura
solo para <tt/root/, de modo que nadie que no sea el administrador vea su
contenido con las claves.

PAP es un protocolo poco seguro, ya que envía la clave sin cifrar, como
texto libre, por lo que puede ser leída por alguien que analice la linea
de transmisión.

Ejemplo de contenido de <tt>/etc/ppp/pap-secrets</tt>:

<tscreen><verb>
_NombreUsuario_ * _Contraseña_
</verb></tscreen>

<sect1>CHAP - Challenge Authentication Protocol
<p>

En caso de que el servidor de acceso al que nos conectamos requiera CHAP
como protocolo para realizar la autentificación de nuestra conexión,
durante el establecimiento de la sesión LCP de PPP se negociará dicho
protocolo, es decir, una vez establecida la conexión de <tt/chat/ y
lanzado <tt/pppd/, será este quien realice el envio del nombre de
usuario y clave, buscando en el fichero <tt>/etc/ppp/chap-secrets</tt> los
valores que debe usar. Este fichero tiene acceso de lectura y escritura
solo para <tt>root</tt>, de modo que nadie que no sea el administrador vea
su contenido con las claves.

CHAP es un protocolo más seguro que PAP, ya que nunca se envía la clave
por la linea de transmisión sin cifrar. En su lugar, el equipo que realiza
la autentificación envía un identificador aleatorio con el que codificar
la clave en el lado del cliente para después enviar esta clave codificada.

Ejemplo de contenido de <tt>/etc/ppp/chap-secrets</tt>:

<tscreen><verb>
_NombreUsuario_ * _Contraseña_
</verb></tscreen>

Es posible que un proveedor de acceso en ocasiones utilice PAP y en otras
ocasiones utilice CHAP, por lo que es común definir en ambos sitios el
usuario y la clave a utilizar.

<sect>Notas sobre la resolución de nombres DNS
<p>

En todas las conexiones a un ISP es necesario configurar la resolución de
nombres DNS, de modo que nuestro ordenador pueda encontrar las direcciones
IP asociadas a un nombre de ordenador en internet.

Las direcciones IP de los servidores encargados de realizar esta
traducción de direcciones se encuentran en el fichero
<tt>/etc/resolv.conf</tt>.

Lo habitual en un equipo aislado que accede a internet es que este fichero
contenga las direcciones IP de los servidores DNS que el proveedor
indique:

<tscreen><verb>
#Fichero /etc/resolv.conf para acceso a internet mediante nombreISP
nameserver 111.222.333.444
nameserver 222.333.444.555
</verb></tscreen>

En los equipos que realizan tareas de firewall/proxy, es habitual que el
fichero contenga la dirección del propio servidor (o la dirección del
interfaz loopback, 127.0.0.1) y este además incluya un servidor de nombres
DNS que a su vez realizará las traducciones de nombres a direcciones IP
poniéndose en contacto con otros servidores DNS.  

<tscreen><verb>
#Fichero /etc/resolv.conf para resolución local de nombres DNS
nameserver 127.0.0.1
</verb></tscreen>

La puesta en marcha de un servidor DNS está fuera del alcance de este
documento. Existe mucha documentación al respecto, pero una aproximación
rápida puede obtenerse en el DNS-Howto (<tt><htmlurl
url="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html"></tt>) cuenta con una
traducción en <tt><htmlurl url="http://www.insflug.org/documentos/DNS-Como/"
name="http://www.insflug.org/documentos/DNS-Como/"></tt>.

<sect>Conexión mediante módem y PPP de un puesto aislado a un ISP
<p>

De forma esquemática, serán necesarios los siguientes pasos previos:
<itemize>
<item>Tener montado el paquete <em/Diald/. Lo más rápido será montar
el que la distribución de Linux que usemos incluya.
<item>Configurar la resolución de nombres DNS (fichero
<tt>/etc/resolv.conf</tt>).
<item>Comprobar que es posible establecer una conexión con el ISP. Si la
distribución incluye utilidades para configurar una conexión, será más
rápido usarlas (pppconfig en Debian, kppp si usas KDE, etc). Si tiene
problemas para establecer la conexión, los documentos PPP-Howto
(<tt><htmlurl url="http://www.linuxdoc.org/HOWTO/PPP-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/PPP-HOWTO.html"></tt>), Modem-Howto
(<tt><htmlurl url="http://www.linuxdoc.org/HOWTO/Modem-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/Modem-HOWTO.html"></tt>) y
Serial-Howto (<tt><htmlurl
url="http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html"></tt>) pueden
resultar de ayuda. Ver sección <ref id="masinfo" name="Más información"> si
busca traducciones de dichos documentos.

<item>Establecer los nombres de usuario y contraseña en los ficheros
<tt>/etc/ppp/pap-secrets</tt> y <tt>/etc/ppp/chap-secrets</tt>, como se
comentó anteriormente.
</itemize>

Y ya entrando definitivamente en <em/Diald/:

<itemize>
<item>Preparar el fichero de configuración de <em/Diald/
(<tt>/etc/diald/diald.options</tt> para la versión 0.16.5 de
<em/Diald/ y <tt>/etc/diald/diald.conf</tt> para las demás).
<item>Preparar el fichero de filtros <tt>/etc/diald/standard.filter</tt>,
o mejor, dejar ese como está y modificar una copia suya que podemos llamar
<tt>/etc/diald/personal.filter</tt>.
<item>Preparar archivo de comandos para realizar la llamada
(<tt>/etc/diald/diald.connect</tt> con permiso de ejecución) y fichero de
instrucciones para <tt/chat/ (<tt>/etc/chatscripts/provider</tt>), que
será utilizado por el anterior.
<item>Preparar los archivos de comandos <tt>/etc/diald/ip-up</tt> y
<tt>/etc/diald/ip-down</tt> si se quieren utilizar (deben tener permiso de
ejecución).
<item>Preparar los archivos de establecimiento de rutas
<tt>/etc/diald/addroute</tt> y <tt>/etc/diald/delroute</tt> si se quieren
utilizar (deben tener permiso de ejecución). Este paso no suele ser
necesario cuando solo se usa una instancia de <em/Diald/.
<item>Finalmente, lanzar el demonio <tt>diald</tt>
(«<tt>/etc/init.d/diald start</tt>» para Debian,
«<tt>/etc/rc.d/init.d/diald start</tt>» en RedHat).
Normalmente, la instalación del paquete <em/Diald/ habrá generado los
scripts necesarios para que arranque cuando se enciende el equipo en los
directorios /etc/rcX.d que corresponda.
</itemize>

Si se realiza algún cambio en el fichero de configuración de <em/Diald/
posteriormente a su lanzamiento, deberá ser relanzado
(«<tt>/etc/init.d/diald restart</tt>» en Debian,
«<tt>/etc/rc.d/init.d/diald restart</tt>» en RedHat).

<sect1>Fichero <tt>/etc/diald/diald.options</tt> o <tt>diald.conf</tt>
<p>

En este fichero de ejemplo que se muestra hay que revisar:
<itemize>
<item>Puerto en donde se encuentra conectado el módem. Opción <tt/device/.
<item>Velocidad del módem. Opción <tt/speed/.
<item>Nombre del usuario para la conexión ppp. Opción <tt/pppd-options/.
<item>Temporizadores de reintentos.
<item>Horario de conexión habilitada. Opciones <tt/restrict/.
<item>Decidir si se usan los archivos de comandos <tt/ip-up/ e
<tt/ip-down/. Opciones <tt/ip-up/ e <tt/ip-down/.
<item>Decidir si se usan los archivos de comandos <tt/addroute/ y
<tt/delroute/. Opciones <tt/addroute/ y <tt/delroute/. Normalmente solo se
usan para configuraciones de enrutamiento complejas o varias instancias de
<em/Diald/ en ejecución simultanea.
<item>Decidir si se usan los filtros estándar o personales. Opciones
<tt/include/.
</itemize>

<tscreen><verb>
##########################
# /etc/diald/diald.options

# Dispositivo donde esta conectado el módem
device /dev/ttyS0

# Archivo de log de diald
accounting-log /var/log/diald.log

# Cola de monitorización de diald
#fifo /var/run/diald/diald.fifo

# Depuración activada al máximo
# Activar la depuración disminuye el rendimiento
#debug 31

# Usamos PPP sobre la linea de transmisión
mode ppp

# Direcciona IP de mi equipo (al conectar se modifica automáticamente con
# la IP asignada por el ISP)
local 127.0.0.5

# Direccion IP del equipo remoto (al conectar se modifica automáticamente
# con la IP del equipo que recibe nuestra llamada)
remote 127.0.0.4

# Mascara de subred
netmask 255.255.255.0

# Indica que las direcciones IP serán asignadas en el momento del
# establecimiento de la conexión
dynamic 

# Si la conexión se cae, restablecerla solo si hay trafico de salida
two-way

# Cuando la conexión esta establecida, cambiar las rutas para que apunten
# al interface real, en vez de al interface proxy. No hacer esto implica
# una perdida de rendimiento de un 20 por ciento. Hay kernels antiguos que
# no soportan reroute. Ver el manual de diald para mas información
reroute

# Diald deberá establecer la ruta por defecto al interface SLIP usado como
# proxy
defaultroute

# Script para establecer rutas personalizadas
#addroute "/etc/diald/addroute"
#delroute "/etc/diald/delroute"

# Scripts para ejecutar cuando el enlace se activa o se desactiva.
# En las versiones 0.9x de Diald hay una opción llamada ip-goingdown para
# ser lanzado al finalizar pero cuando todavía está activo el enlace.
ip-up /etc/diald/ip-up
#ip-down /etc/diald/ip-down

# Scripts usados para establecer la comunicación y pararla
connect "/etc/diald/diald.connect"
#disconnect "/etc/diald/diald.disconnect"

# Usar bloqueo UUCP
#lock

# Conectamos a través de módem. ATENCIÓN: No especificar estas opciones
# en las opciones para PPP, ya que entrarían en conflicto. Para ver las
# opciones de PPP que no se pueden usar en pppd-options ver la pagina
# de manual de diald y buscar pppd-options
modem
crtscts
speed 115200

# Algunos temporizadores
# para información detallada, ver manual de Diald
connect-timeout 120
redial-timeout 60
start-pppd-timeout 120
died-retry-count 0
redial-backoff-start 4
redial-backoff-limit 300
dial-fail-limit 10

# Opciones para pasar a pppd
# Estas opciones también se pueden poner en /etc/ppp/options, que son las
# opciones por defecto de pppd, pero si es necesario tener diferentes
# configuraciones de diald es necesario ponerlas aquí
# noauth - no autentificar al destino de la llamada.
#          "Infovía Plus" (España) no se identifica frente a nuestro
#          equipo.
# user - poner aquí el usuario y el isp separados por la arroba (@).
pppd-options noauth user usuario@isp

# Restricciones de horario de uso.
# Esta sección debe estar antes de los filtros.
# El comando restrict es experimental y puede cambiar en futuras versiones
# de diald (esta sintaxis es para la versión 0.16)
# Solo usar en horario nocturno para plan
# Bononet Noche (España-Telefónica)
# Lunes a Viernes de 0 a 8 y de 18 a 24
# Domingos de 0 a 24
restrict 8:00:00 18:00:00 1-5 * *
down
restrict * * * * *

# Sin condiciones especiales de tarificación
# (primeros segundos cobrados de una vez, unidad de tarificación en
# segundos, tiempo en segundos para comprobar desconexión)
#impulse 0,0,0
# Bononet Noche (España-Telefónica) tarifica por segundos a partir del 160
impulse 160,0,0
# si se tarificase por minutos y cobrasen los 10 primeros de una vez:
#impulse 600,60,10

# Filtros estándar
#include /etc/diald/standard.filter
# o Filtros personales
include /etc/diald/personal.filter
</verb></tscreen>

<sect1>Fichero de filtros personal
<p>

La manipulación de este fichero debe ser realizada de forma muy cuidadosa.
Es en este fichero en el que se decide cuándo y porqué se trata de
levantar el enlace, mantenerlo, tirarlo o ignorarlo, dependiendo del tipo
de tráfico.

En general, el fichero de filtros standard de <em/Diald/ es suficiente
para la mayoría de los casos, aunque quizá sea poco restrictivo en
determinados entornos. El <tt/personal.filter/ que se muestra a
continuación tiene algunas correcciones sobre el original de la versión
0.16.

En sucesivas versiones de este documento se presentarán otros ejemplos más
restrictivos comentados.

<tscreen><verb>
# /etc/diald/personal.filter
# Las reglas de filtrado a continuación son las mismas que las de
# standard.filter con las siguientes correcciones:
#
# Cambio de 10 minutos por 4 en "cualquier otra conexión TCP".
# Añadido para ignorar los FIN ACK con "ignore tcp tcp.fin".
# Ignorar paquetes icmp (con ping y traceroute no se realizará llamada).
#

# This is a pretty complicated set of filter rules.
# (These are the rules I use myself.)
#
# I've divided the rules up into four sections.
# TCP packets, UDP packets, ICMP packets and a general catch all rule
# at the end.

ignore icmp any

#------------------------------------------------------------------------------
# Rules for TCP packets.
#------------------------------------------------------------------------------
# General comments on the rule set:
#
# In general we would like to treat only data on a TCP link as significant
# for timeouts. Therefore, we try to ignore packets with no data.
# Since the shortest possible set of headers in a TCP/IP packet is 40 bytes,
# any packet with length 40 must have no data riding in it.
# We may miss some empty packets this way (optional routing information
# and other extras may be present in the IP header), but we should get
# most of them. Note that we don't want to filter out packets with
# tcp.live clear, since we use them later to speedup disconnects
# on some TCP links.
#
# We also want to make sure WWW packets live even if the TCP socket
# is shut down. We do this because WWW doesn't keep connections open
# once the data has been transfered, and it would be annoying to have the link
# keep bouncing up and down every time you get a document.
#
# Outside of WWW the most common use of TCP is for long lived connections,
# that once they are gone mean we no longer need the network connection.
# We don't neccessarily want to wait 10 minutes for the connection
# to go down when we don't have any telnet's or rlogin's running,
# so we want to speed up the timeout on TCP connections that have
# shutdown. We do this by catching packets that do not have the live flag set.

# --- start of rule set proper ---

# When initiating a connection we only give the link 15 seconds initially.
# The idea here is to deal with possibility that the network on the opposite
# end of the connection is unreachable. In this case you don't really
# want to give the link 10 minutes up time. With the rule below
# we only give the link 15 seconds initially. If the network is reachable
# then we will normally get a response that actually contains some
# data within 15 seconds. If this causes problems because you have a slow
# response time at some site you want to regularly access, you can either
# increase the timeout or remove this rule.
accept tcp 15 tcp.syn

# Keep named xfers from holding the link up
ignore tcp tcp.dest=tcp.domain
ignore tcp tcp.source=tcp.domain

# (Ack! SCO telnet starts by sending empty SYNs and only opens the
# connection if it gets a response. Sheesh..)
accept tcp 5 ip.tot_len=40,tcp.syn

# keep empty packets from holding the link up (other than empty SYN packets)
ignore tcp ip.tot_len=40,tcp.live

# Modificacion de Andres Seco. Ignorar los FIN ACK.
ignore tcp tcp.fin

# make sure http transfers hold the link for 2 minutes, even after they end.
# NOTE: Your /etc/services may not define the tcp service www, in which
# case you should comment out the following two lines or get a more
# up to date /etc/services file. See the FAQ for information on obtaining
# a new /etc/services file.
accept tcp 120 tcp.dest=tcp.www
accept tcp 120 tcp.source=tcp.www
# Same for https
accept tcp 120 tcp.dest=tcp.443
accept tcp 120 tcp.source=tcp.443

# Once the link is no longer live, we try to shut down the connection
# quickly. Note that if the link is already down, a state change
# will not bring it back up.
keepup tcp 5 !tcp.live
ignore tcp !tcp.live

# an ftp-data or ftp connection can be expected to show reasonably frequent
# traffic.
accept tcp 120 tcp.dest=tcp.ftp
accept tcp 120 tcp.source=tcp.ftp

#NOTE: ftp-data is not defined in the /etc/services file provided with
# the latest versions of NETKIT, so I've got this commented out here.
# If you want to define it add the following line to your /etc/services:
# ftp-data        20/tcp
# and uncomment the following two rules.
#accept tcp 120 tcp.dest=tcp.ftp-data
#accept tcp 120 tcp.source=tcp.ftp-data

# If we don't catch it above, give the link 10 minutes up time.
#accept tcp 600 any
# Modificacion de Andres Seco. Solo dejar 4 minutos mas.
accept tcp 240 any

# Rules for UDP packets
#
# We time out domain requests right away, we just want them to bring
# the link up, not keep it around for very long.
# This is because the network will usually come up on a call
# from the resolver library (unless you have all your commonly
# used addresses in /etc/hosts, in which case you will discover
# other problems.)
# Note that you should not make the timeout shorter than the time you
# might expect your DNS server to take to respond. Otherwise
# when the initial link gets established there might be a delay
# greater than this between the initial series of packets before
# any packets that keep the link up longer pass over the link.

# Don't bring the link up for rwho.
ignore udp udp.dest=udp.who
ignore udp udp.source=udp.who
# Don't bring the link up for RIP.
ignore udp udp.dest=udp.route
ignore udp udp.source=udp.route
# Don't bring the link up for NTP or timed.
ignore udp udp.dest=udp.ntp
ignore udp udp.source=udp.ntp
ignore udp udp.dest=udp.timed
ignore udp udp.source=udp.timed
# Don't bring up on domain name requests between two running nameds.
ignore udp udp.dest=udp.domain,udp.source=udp.domain
# Bring up the network whenever we make a domain request from someplace
# other than named.
accept udp 30 udp.dest=udp.domain 
accept udp 30 udp.source=udp.domain
# Do the same for netbios-ns broadcasts
# NOTE: your /etc/services file may not define the netbios-ns service
# in which case you should comment out the next three lines.
ignore udp udp.source=udp.netbios-ns,udp.dest=udp.netbios-ns
accept udp 30 udp.dest=udp.netbios-ns
accept udp 30 udp.source=udp.netbios-ns
# keep routed and gated transfers from holding the link up
ignore udp tcp.dest=udp.route
ignore udp tcp.source=udp.route
# Anything else gest 2 minutes.
accept udp 120 any

# Catch any packets that we didn't catch above and give the connection
# 30 seconds of live time.
accept any 30 any
</verb></tscreen>

<sect1>Realización de la llamada
<p>

Fichero <tt>/etc/diald/diald.connect</tt> (debe tener permiso de
ejecución):

<tscreen><verb>
/usr/sbin/chat -f /etc/chatscripts/provider
</verb></tscreen>

Fichero <tt>/etc/chatscripts/provider</tt>. En este fichero de ejemplo que
se muestra hay que revisar el numero de teléfono:

<tscreen><verb>
ABORT BUSY
ABORT "NO CARRIER"
ABORT VOICE
ABORT "NO DIALTONE" 
ABORT "NO ANSWER"
"" ATZ
OK ATDT123456789
CONNECT \d\c
</verb></tscreen>

<sect1>Archivo de comandos de inicio de la conexión
<p>

Debe tener permiso de ejecución.

Este archivo puede ser usado para multiples tareas (sincronizar la hora
del equipo, lanzar la entrega de la cola de impresión, la recuperación de
los mensajes desde la oficina de correos externa, etc.).

En el ejemplo, se envia un mensaje a <tt/root/ con los parametros que se le
pasan al archivo de comandos (interface, mascara de subred, dirección IP
local, dirección IP remota y prioridad en la tabla de rutas):

<tscreen><verb>
#!/bin/sh

iface=$1
netmask=$2
localip=$3
remoteip=$4
metric=$5

# Set the time and date
# netdate ntp.server.somecountry

# Run the mail queue
# runq

echo `date` $1 $2 $3 $4 $5 | mail -s "diald - conectado" root@localhost
</verb></tscreen>

<sect>Conexión mediante modem y PPP de un puesto aislado a varios ISPs no simultáneamente
<p>

En muchas ocasiones, un ordenador aislado no se conecta solo a una red, si
no que es común acceder a diferentes redes o a Internet mediante
diferentes proveedores de acceso. En estos casos, modificar los ficheros
de configuración cada vez que se desea acceder a un sitio diferente puede
resultar incómodo.

La solución propuesta aquí consiste en mantener diferentes juegos de
ficheros de configuración para cada conexión a un proveedor diferente y
se incluyen algunos archivos de comandos para automatizar el cambio de uno
a otro.

<sect1>Nota sobre la entrega de correo mediante un servidor de reenvío (relay host)
<p>

Tanto si su correo electrónico usa un Agente de Transferencia de Mensajes local
con un servidor SMTP de reenvío (relay host) para la entrega de todos los
mensajes, como si usa un cliente de correo que directamente entregue los
mensajes al servidor SMTP de su proveedor de acceso, el cambio de acceso
de un proveedor a otro precisará la reconfiguración de este servidor de
relay, ya que los proveedores de acceso normalmente comprueban el origen
de las conexiones que reciben y sólo aceptan mensajes si el buzón del
destinatario está en uno de los dominios que gestiona directamente este
servidor de relay o si la dirección IP del cliente que inicia la conexión
pertenece a una de las direcciones que este proveedor asigna a sus
clientes, para evitar que cualquiera pueda usar este servidor
<tt/smtp/ para objetivos no muy limpios (spam, anónimos, enmascaramiento
del origen, etc.).

En los ejemplos que se ponen a continuación se mostrara cómo hacer este
cambio en los ficheros de configuración de <em/Smail/ suponiendo una
sencilla configuración en la que todos los mensajes con destino fuera del
equipo local se entregan a un servidor <tt/smtp/ de reenvío (relay host). Si
usted usa otro agente de transferencia de mensajes (MTA) en su sistema puede
enviarme los cambios que tuvo que hacer en dicho MTA para incluirlos
aquí. Igualmente si usa un cliente de correo que entrega directamente los
mensajes a un servidor smtp ajeno a su sistema (Kmail, Netscape, etc.).

<sect1>Archivos de comandos para automatizar la creación de las multiples conexiones y su intercambio

<sect2>Puesta en marcha
<p>

En primer lugar, se crea un subdirectorio de <tt>/etc/diald</tt> llamado
<tt/providers/ donde se almacenarán los archivos de comandos para
automatizar el cambio y los subdirectorios con los juegos de ficheros de
configuración para cada uno de los proveedores.

Con el archivo de comandos siguiente se crea este directorio y se
introducen en el los ficheros de configuración de <em/Diald/,
<em/chat/, <em/pppd/ y <em/Smail/ con los que se esté trabajando
actualmente, y que serán tomados como base para las siguientes
configuraciones.

<tscreen><verb>
#!/bin/sh
#Fichero /etc/diald/providers/setupdialdmultiprovider
mkdir /etc/diald/providers
mkdir /etc/diald/providers/setup
cp /etc/ppp/pap-secrets /etc/diald/providers/setup
cp /etc/ppp/chap-secrets /etc/diald/providers/setup
cp /etc/resolv.conf /etc/diald/providers/setup
cp /etc/diald/diald.options /etc/diald/providers/setup
cp /etc/diald/standard.filter /etc/diald/providers/setup
cp /etc/diald/personal.filter /etc/diald/providers/setup
cp /etc/diald/diald.connect /etc/diald/providers/setup
cp /etc/chatscripts/provider /etc/diald/providers/setup
cp /etc/diald/ip-up /etc/diald/providers/setup
cp /etc/diald/ip-down /etc/diald/providers/setup
cp /etc/smail/routers /etc/diald/providers/setup
</verb></tscreen>

<sect2>Nuevo proveedor
<p>

Con el archivo de comandos siguiente se copia la configuración original
que se estaba utilizando cuando se ejecutó
<tt>setupdialdmultiprovider</tt> para prepararla para un nuevo proveedor o
una nueva red. Este archivo de comandos
(<tt>/etc/diald/providers/newdialdprovider</tt>) se lanza con un
parámetro, el nombre del proveedor o el nombre de la red a la que
accedemos.

<tscreen><verb>
#!/bin/sh
#Fichero /etc/diald/providers/newdialdprovider
mkdir /etc/diald/providers/$1
cp /etc/diald/providers/setup/* /etc/diald/providers/$1
</verb></tscreen>

Ahora será necesario modificar como corresponda los ficheros que se
encuentran en el nuevo directorio
<tt>/etc/diald/providers/nombreproveedor</tt>, siendo
<tt>nombreproveedor</tt> el parámetro que se le ha pasado a
<tt>newdialdprovider</tt>.

<sect2>Cambio de uno a otro
<p>

Para finalizar, con este archivo de comandos se realizan los cambios
oportunos para acceder a un proveedor o red u otro. Se utilizan enlaces
simbólicos para evitar tener archivos duplicados. Así mismo, mediante
enlaces simbólicos, en caso de necesitar hacer algún cambio, por ejemplo,
en el fichero <tt>/etc/resolv.conf</tt>, modificando directamente este
fichero quedará modificado el fichero al que apunta el enlace,
<tt>/etc/diald/providers/nombreproveedor/resolv.conf</tt>.

<tscreen><verb>
#!/bin/sh
#Fichero /etc/diald/providers/setdialdprovider
/etc/init.d/diald stop
#espera para dejar tiempo a que Diald finalice.
sleep 4
ln -sf /etc/diald/providers/$1/pap-secrets /etc/ppp
ln -sf /etc/diald/providers/$1/chap-secrets /etc/ppp
ln -sf /etc/diald/providers/$1/resolv.conf /etc
ln -sf /etc/diald/providers/$1/diald.options /etc/diald
ln -sf /etc/diald/providers/$1/standard.filter /etc/diald
ln -sf /etc/diald/providers/$1/personal.filter /etc/diald
ln -sf /etc/diald/providers/$1/diald.connect /etc/diald
ln -sf /etc/diald/providers/$1/provider /etc/chatscripts
ln -sf /etc/diald/providers/$1/ip-up /etc/diald
ln -sf /etc/diald/providers/$1/ip-down /etc/diald
ln -sf /etc/diald/providers/$1/routers /etc/smail
/etc/init.d/diald start
</verb></tscreen>

<sect>Conexión mediante modem y PPP de un proxy/firewall a un ISP
<p>

El asunto de conectar una red a internet de modo que uno de los equipos
trabaje como un servidor de conexión compartida con tareas de proxy/cache
de páginas web y cortafuegos (firewall) de seguridad entre la red interna
y externa es un asunto complejo que escapa al objetivo de este documento y
que ya han tratado de forma fantástica otros documentos «Como»
similares a este. Al final de este documento se pueden encontrar referencias y
enlaces.

Aquí tan solo se va a tratar de configurar <em/Diald/ suponiendo que
el equipo ya hace IP-Masquerading, tiene un proxy como <em/Squid/ o
similar trabajando, una conexión con un ISP configurada correctamente y
que la seguridad de acceso a puertos TCP/UDP ha sido revisada (fichero
<tt>/etc/inetd.conf</tt> y algunos otros como <tt>securetty</tt>,
<tt>host.allow</tt>, etc).

Básicamente, se trata de reconfigurar las reglas de
enmascaramiento/filtrado/acceso cada vez que cambia el conjunto de
interfaces del equipo, es decir, cuando se establece el interface ppp0 y
cuando deja de existir. Un buen sitio para hacer esto son los scripts de
ip-up e ip-down de <em/pppd/.

<sect1>Ejemplo para Debian 2.1
<p>

En Debian, basta con montar el paquete <em/ipmasq/ y durante su
configuración indicar que se desea que se cambien las reglas de forma
sincronizada con <em/pppd/. De esta manera, se crean scripts en los
directorios <tt>/etc/ppp/ip-up.d</tt> y <tt>/etc/ppp/ip-down.d</tt> que
llaman a <tt>/sbin/ipmasq</tt>, un script que analiza las interfaces
actuales y hace una configuración sencilla valida en muchos casos, aunque
se puede personalizar con facilidad revisando los ficheros de reglas de
<tt>/etc/ipmasq/rules</tt>.

Tan solo es necesario realizar una corrección tras la instalación de este
paquete. Se trata de cambiar el orden de ejecución del script de
lanzamiento de <em/ipmasq/ durante el arranque del equipo, eliminandolo
del directorio <tt>/etc/rcS.d</tt> y poniendolo para que se ejecute
despues de <tt/S20diald/ en <tt>/etc/rc2.d</tt> de modo que ya exista la
interface <tt/sl0/. <tt/S90ipmasq/ es un lugar valido para el enlace
simbólico a <tt>/etc/init.d/ipmasq</tt>.

En Debian no es necesario preocuparse de la version del kernel, ya que el
script <tt>/sbin/ipmasq</tt> usa <tt>ipfwadm</tt> o <tt>ipchains</tt>
según corresponda.

<sect1>Ejemplo para Suse 6.1
<p>

Este ejemplo se debe a Mr Cornish Rex, <tt><htmlurl
url="mailto:troll@tnet.com.au" name="troll@tnet.com.au"></tt>.

Los comandos de control de ip-masp y routing que se presentan a
continuación son para kernels de la versión 2.2, mediante ipchains, pero
no son válidos para kernels de las versiones 2.0. Para estos ultimos
habría que traducir dichos comandos a su equivalente en el antiguo comando
ipmasq.

Además, vamos a suponer que la interface ethernet del equipo tiene la
dirección 192.168.1.1 con máscara de 16 bits, es decir, 255.255.0.0.

El fichero <tt>/etc/ppp/ip-up</tt> sería valido de la siguiente forma:

<tscreen><verb>
#!/bin/sh
# $1 = Interface
# $2 = Tty device
# $3 = speed
# $4 = local ip
# $5 = remote ip
# $6 = ipparam
/sbin/ipchains -F input
/sbin/ipchains -P input DENY
/sbin/ipchains -A input -j ACCEPT -i eth0 -s 192.168.0.0/16 -d 0.0.0.0/0
/sbin/ipchains -A input -j DENY -p udp -i $1 -s 0.0.0.0/0 -d $4/32 0:52 -l
/sbin/ipchains -A input -j DENY -p udp -i $1 -s 0.0.0.0/0 -d $4/32 54:1023 -l
/sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 0:112 -l
/sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 114:1023 -l
/sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 6000:6010 -l
/sbin/ipchains -A input -j DENY -p icmp --icmp-type echo-request \
-i $1 -s 0.0.0.0/0 -l
/sbin/ipchains -A input -j DENY -p icmp -f -i $1 -s 0.0.0.0/0 -l
/sbin/ipchains -A input -j DENY -p udp -i $1 -s 0.0.0.0/0 -d $4/32 5555 -l
/sbin/ipchains -A input -j DENY -p udp -i $1 -s 0.0.0.0/0 -d $4/32 8000 -l
/sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 8000 -l
/sbin/ipchains -A input -j DENY -p udp -i $1 -s 0.0.0.0/0 -d $4/32 6667 -l
/sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 6667 -l
/sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 4557 -l
/sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 4559 -l
/sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 4001 -l
/sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 2005 -l
/sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 6711 -l
/sbin/ipchains -A input -j DENY -i $1 -s 192.168.0.0/16 -d 0.0.0.0/0 -l
/sbin/ipchains -A input -j ACCEPT -i $1 -s 0.0.0.0/0 -d $4/32
/sbin/ipchains -A input -j ACCEPT -i lo -s 0.0.0.0/0 -d 0.0.0.0/0
/sbin/ipchains -A input -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 -l

/sbin/ipchains -F output
/sbin/ipchains -P output DENY
/sbin/ipchains -A output -j ACCEPT -i eth0 -s 0.0.0.0/0 -d 192.168.0.0/16
/sbin/ipchains -A output -j DENY -i $1 -s 192.168.0.0/16 -d 0.0.0.0/0 -l
/sbin/ipchains -A output -j ACCEPT -i $1 -s $4/32 -d 0.0.0.0/0
/sbin/ipchains -A output -j ACCEPT -i lo -s 0.0.0.0/0 -d 0.0.0.0/0
/sbin/ipchains -A output -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0

/sbin/ipchains -F forward
/sbin/ipchains -P forward DENY
/sbin/ipchains -M -S 120 120 120
/sbin/ipchains -A forward -j MASQ -s 192.168.1.0/24 
/sbin/ipchains -A forward -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0

exit 0
</verb></tscreen>

El fichero <tt>/etc/ppp/ip-down</tt> sería valido de la siguiente forma:

<tscreen><verb>
#!/bin/sh
# $1 = Interface
# $2 = Tty device
# $3 = Speed
# $4 = Local ip
# $5 = Remote ip
/sbin/ipchains -F input
/sbin/ipchains -F output
/sbin/ipchains -F forward
/sbin/ipchains-restore < /etc/ppp/orig.chains
</verb></tscreen>

Y el fichero que aparece al final del script anterior, orig.chains, es el
siguiente (el estado original de la configuración de ipchains):

<tscreen><verb>
# orig.chains
# creado con: ipchains-save > orig.chains
:input ACCEPT
:forward ACCEPT
:output ACCEPT
-A input -s 0.0.0.0/0.0.0.0 -d 192.168.1.1/255.255.255.255
-A output -s 192.168.1.1/255.255.255.255 -d 0.0.0.0/0.0.0.0
</verb></tscreen>

<sect1>Ejemplo para Slackware 3.6
<p>

Este ejemplo se debe a Hoo Kok Mun, <tt><htmlurl
url="mailto:hkmun@pacific.net.sg" name="hkmun@pacific.net.sg"></tt>.

Este es el ejemplo más sencillo que he visto, aunque perfectamente
funcional. Desde el principio establece la norma de enmascaramiento, antes
de que exista la interface <tt/sl0/, y no cambia cuando se establece
<tt/ppp0/. Si son necesarias medidas de seguridad, probablemente quede un
poco limitado.

<tscreen><verb>
#/etc/rc.d/rc.local
/sbin/ipfwadm -F -p deny
/sbin/ipfwadm  -F -a m -S 192.168.0.0/24 -D 0.0.0.0/0
</verb></tscreen>

Como se puede ver, es para kernels de la versión 2.0.

<sect>Programas y versiones utilizados
<p>

Para el desarrollo de esta documentación he utilizado las siguientes
versiones de diald:

<itemize>
<item>Diald 0.16.5 - La ultima versión que mantuvo el autor original de diald.
<item>Diald 0.99.3 - La ultima versión aparecida hasta el momento de la
primera redacción de este documento.
</itemize>

Y las siguientes versiones de pppd:

<itemize>
<item>pppd 2.3.5
</itemize>

La versión 0.16.5 de Diald es seguramente la más extendida, y la que se
incluye directamente con muchas de las distribuciones de linux. Es
suficiente en la mayoría de los casos y resulta muy estable, aunque, sin
duda, las más modernas versiones, aunque se encuentran en desarrollo,
incluyen funcionalidades muy interesantes.

<sect>Más información
<label id="masinfo">
<p>

La documentación original a partir de la cual ha sido obtenido este
documento puede ser encontrada en las paginas man de <tt/diald/,
<tt/diald-examples/, <tt/diald-control/, <tt/diald-monitor/, <tt/dctrl/,
<tt/pppd/, <tt/chat/, en los directorios correspondientes de /usr/doc y en
las paginas de los paquetes en la World wide web:

<itemize>
<item>Nueva Página Oficial de Diald: <tt><htmlurl
url="http://diald.sourceforge.net/"
name="http://diald.sourceforge.net/"></tt>
<item>Descarga de nuevas versiones: <tt><htmlurl
url="ftp://diald.sourceforge.net/pub/diald/"
name="ftp://diald.sourceforge.net/pub/diald/"></tt>
<item>Página anterior de Diald: <tt><htmlurl url="http://diald.unix.ch"
name="http://diald.unix.ch"></tt>
<item>Página antigua de Diald hasta la versión 0.16.5: <tt><htmlurl
url="http://www.loonie.net/~erics/diald.html"
name="http://www.loonie.net/~erics/diald.html"></tt>
<item>Antiguo sitio FTP para nuevas versiones de pppd: <tt><htmlurl
url="ftp://cs.anu.edu.au/pub/software/ppp/"
name="ftp://cs.anu.edu.au/pub/software/ppp/"></tt>
</itemize>

Existe una lista de correo para hablar y discutir sobre diald en el
servidor de listas de David S. Miller. Para suscribirse, enviar un mensaje
con la linea subscribe linux-diald» EN EL CUERPO DEL MENSAJE
a la dirección <tt><htmlurl url="mailto:Majordomo@vger.rutgers.edu"
name="Majordomo@vger.rutgers.edu"></tt>.

Existen también múltiples documentos RFC (Request For Comments) que
detallan cómo debe ser el funcionamiento de las lineas con encapsulado PPP
y sus protocolos asociados (LCP, IPCP, PAP, CHAP, ...), y pueden ser
encontradas en /usr/doc/doc-rfc y en diversos lugares de la World wide
web, como <tt><htmlurl url="http://metalab.unc.edu"
name="http://metalab.unc.edu"></tt> y <tt><htmlurl
url="http://nic.mil/RFC" name="http://nic.mil/RFC"></tt>. Puedes solicitar
información sobre las RFCs en <tt><htmlurl url="mailto:RFC-INFO@ISI.EDU"
name="RFC-INFO@ISI.EDU"></tt>.

Y también pueden resultar de ayuda los «Comos» siguientes:

<itemize>
<item>DNS-HOWTO - <tt><htmlurl
url="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html"></tt> (traducción:
<tt><htmlurl url="http://www.insflug.org/documentos/DNS-Como/"
name="http://www.insflug.org/documentos/DNS-Como/"></tt>)

<item>Firewall-HOWTO - <tt><htmlurl
url="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html"></tt> (traducción:
<tt><htmlurl url="http://www.insflug.org/documentos/Cortafuegos-Como/"
name="http://www.insflug.org/documentos/Cortafuegos-Como/"></tt>)

<item>IP-Masquerade-HOWTO - <tt><htmlurl
url="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html"></tt>
(traducción: <tt><htmlurl
url="http://www.insflug.org/documentos/IP-Masquerade-Como/"
name="http://www.insflug.org/documentos/IP-Masquerade-Como/"></tt>)

<item>IPCHAINS-HOWTO - <tt><htmlurl
url="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html"></tt>

<item>Modem-HOWTO - <tt><htmlurl
url="http://www.linuxdoc.org/HOWTO/Modem-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/Modem-HOWTO.html"></tt>

<item>NET3-4-HOWTO - <tt><htmlurl
url="http://www.linuxdoc.org/HOWTO/NET3-4-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/NET3-4-HOWTO.html"></tt> (traducción:
<tt><htmlurl url="http://www.insflug.org/documentos/Redes-En-Linux-Como/"
name="http://www.insflug.org/documentos/Redes-En-Linux-Como/"></tt>)

<item>PPP-HOWTO - <tt><htmlurl
url="http://www.linuxdoc.org/HOWTO/PPP-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/PPP-HOWTO.html"></tt> (traducción:
<tt><htmlurl url="http://www.insflug.org/documentos/PPP-Como/"
name="http://www.insflug.org/documentos/PPP-Como/"></tt>) 


<item>Serial-HOWTO - <tt><htmlurl
url="http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html"
name="http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html"></tt> (traducción:
<tt><htmlurl url="http://www.insflug.org/documentos/Serie-Como/"
name="http://www.insflug.org/documentos/Serie-Como/"></tt>) 

</itemize>

<sect>Anexo: El INSFLUG <label id="Insflug">
<p>

El <it/INSFLUG/ forma parte del grupo internacional <it>Linux
Documentation Project</it>, encargándose de las traducciones al castellano
de los Howtos, así como de la producción de documentos originales en
aquellos casos en los que no existe análogo en inglés, centrándose,
preferentemente, en documentos breves, como los <em/COMOs/ y <em/PUFs/
(<bf/P/reguntas de <bf/U/so <bf/F/recuente, las <it/FAQs/. <tt/:)/ ), etc.

Diríjase a la sede del Insflug para más información al respecto.

En ella encontrará siempre las <bf/últimas/ versiones de las traducciones
«oficiales»:  <tt><htmlurl url="http://www.insflug.org"
name="www.insflug.org"></tt>. Asegúrese de comprobar cuál es la última
versión disponible en el Insflug antes de bajar un documento de un
servidor réplica. 

Además, cuenta con un sistema interactivo de gestión de fe de erratas y
sugerencias en línea, motor de búsqueda específico, y más servicios en los
que estamos trabajando incesantemente.  

Se proporciona también una lista de los servidores réplica (<it/mirror/)
del Insflug más cercanos a Vd., e información relativa a otros recursos en
castellano.

En <tt><htmlurl url="http://www.insflug.org/insflug/creditos.php3"
name="http://www.insflug.org/insflug/creditos.php3"></tt> cuenta con una
detallada relación de las personas que hacen posible tanto esto como las
traducciones.

¡Diríjase a <tt><htmlurl
url="http://www.insflug.org/colaboracion/index.php3"
name="http://www.insflug.org/colaboracion/index.php3"></tt> si desea
unirse a nosotros!.

«Cartel» Insflug, <tt><htmlurl url="mailto:cartel@insflug.org"
name="cartel@insflug.org"></tt>. 

</article>

