path: root/es_ES.ISO_8859-1/FAQ/network.sgml

<!-- $Id: network.sgml,v 1.11 1999-08-04 12:46:47 jesusr Exp $ -->
<!-- The FreeBSD Documentation Spanish Project -->
  <sect>
    <heading>Networking<label id="networking"></heading>

    <sect1>
      <heading>&iquest;D&oacute;nde puedo encontrar informaci&oacute;n sobre "diskless booting"?</heading>

      <p>"Diskless booting" significa que una m&aacute;quina FreeBSD sea 
      arrancada sobre una red, y lea los ficheros necesarios de un servidor y no
      desde su disco duro. Para m&aacute;s detalles, por favor, lee la 
      secci&oacute;n <url url="../../handbook/diskless.html"
      name="diskless booting del manual">

    <sect1>
      <heading>
        &iquest;Puede una m&aacute;quina FreeBSD ser usada como router dedicado?
      </heading>

      <p>Los estandards de Internet y las buenas pr&aacute;cticas de 
      ingenier&iacute;a nos prohiben proveer el forward de paquetes en la 
      distribuci&oacute;n estandard. Aun as&iacute;, puedes activar esta 
      opci&oacute;n cambiando la siguiente variable a <tt/YES/ en el fichero
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?rc.conf"
      name="rc.conf">:

      <verb>
        gateway_enable=YES          # Set to YES if this host will be a gateway
      </verb>

      <p>Esta opci&oacute;n pondr&aacute; la variable <htmlurl
      url="http://www.FreeBSD.org/cgi/man.cgi?sysctl" name="sysctl">
      <tt/net.inet.ip.forwarding/ a <tt/1/.

      <p>En muchos casos tambi&eacute;n necesitar&aacute;s ejecutar un proceso 
      de rutado para indicar la existencia en la red de tu router; FreeBSD 
      incluye el daemon estandard de rutado BSD
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?routed" name="routed">
      , aunque en situaciones m&aacute;s complejas quiz&aacute;s quieras usar 
      <em/GaTeD/ disponible por ftp en <tt/ftp.gated.Merit.EDU/.

      <p>Es nuestro deber advertirte que estando FreeBSD configurado de esta
      manera, no cumple completamente con todos los estandares de routers
      de Internet, pero es suficiente para uso ordinario.

    <sect1>
      <heading>&iquest;Puedo conectar mi Win95 con Internet a trav&eacute;s de FreeBSD?</heading>

      <p>T&iacute;picamente, la gente que pregunta esto tiene dos pc's en casa,
      uno con FreeBSD y otro con Win95; la idea es usar FreeBSD para conectar
      a Internet y luego ser capaz de acceder a Internet desde el
      ordenador con Windows 95. Este es realmente un caso especial de la
      pregunta anterior.

      <p>Hay un &uacute;til documento disponible que explica como configurar
      FreeBSD como un
      <url url="http://www.ssimicro.com/~jeremyc/ppp.html"
      name="Router PPP">

      <p><bf/NOTA:/ Esto requiere, al menos, tener dos direcciones IP
      fijas disponibles, y posiblemente tres o m&aacute;s, dependiendo del
      n&uacute;mero de m&aacute;quinas que quieras conectar. Como alternativa, 
      si no tienes una direcci&oacute;n IP fija, puedes usar una de las subredes
      privadas e instalar un proxy como
      <url url="http://squid.nlanr.net/Squid/" name="SQUID">
      y <url url="http://www.tis.com/" name="The TIS firewall toolkit">
      en tu FreeBSD.

      <p>Mira tambi&eacute;n la secci&oacute;n <ref id="direct-at" name="natd">.

    <sect1>
      <heading>
        &iquest;Por que falla la compilaci&oacute;n del &uacute;ltimo BIND del ISC?
      </heading>

      <p>Hay un conflicto entre el fichero <tt/cdefs.h/ incluido en la
      distribuci&oacute;n de BIND y el distribuido con FreeBSD. Solo tienes que
      borrar <tt>compat/include/sys/cdefs.h</tt>.

    <sect1>
      <heading>&iquest;Soporta FreeBSD SLIP y PPP?</heading>

      <p>S&iacute;. Mira las paginas man de
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?slattach"
      name="slattach">, <htmlurl
      url="http://www.FreeBSD.org/cgi/man.cgi?sliplogin" name="sliplogin">,
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?pppd" name="pppd"> y 
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="ppp">.
      <tt/pppd/ y <tt/ppp/ soportan conexiones entrantes y salientes.
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?sliplogin"
      name="Sliplogin"> trabaja exclusivamente con conexiones entrantes y
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?slattach"
      name="slattach"> con conexiones salientes.

      <p>Estos programas son descritos en las siguientes secciones del
      <url url="../../handbook/index.html" name="manual">:

      <itemize>
        <item><url url="../../handbook/slips.html"
        name="Handbook entry on SLIP (server side)">

        <item><url url="../../handbook/slipc.html"
        name="Handbook entry on SLIP (client side)">

        <item><url url="../../handbook/ppp.html"
        name="Handbook entry on PPP (kernel version)">

        <item><url url="../../handbook/ppp-and-slip.html#USERPPP"
        name="Handbook entry on PPP (user-mode version)">
      </itemize>

      <p>Si solo tienes acceso a Internet a traves de un "shell
      account", quiz&aacute;s quieras mirar el package <htmlurl
      url="http://www.FreeBSD.org/cgi/ports.cgi?^slirp" name="slirp">.
      Puede darte un (limitado) acceso a servicios como ftp y http.

    <sect1>
      <heading>
        &iquest;Soporta FreeBSD NAT o Masquerading?<label id="natd">
      </heading>

      <p>Si tienes una red local (una o m&aacute;s m&aacute;quinas), pero solo 
      se te ha asignado una &uacute;nica direcci&oacute;n IP desde tu proveedor
      de Internet (o si recibes las direcciones de manera din&aacute;mica), te 
      interesa mirar el programa
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?natd" name="natd">.
      <tt/Natd/ te permite conectar una red entera a Internet usando
      solamente una direcci&oacute;n IP.

      <p>El programa
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="ppp">
      tiene una funcionalidad similar incluida, a trav&eacute;s del 
      par&aacute;metro -alias. La <htmlurl
      url="http://www.FreeBSD.org/cgi/man.cgi?libalias" name="librer&iacute;a 
      alias"> es usada en ambos casos.


    <sect1>
      <heading>
        El ppp no funciona. &iquest;Qu&eacute; estoy haciendo mal?<label id="userppp">
      </heading>

      <p>Primero deber&iacute;as leer el <htmlurl
      url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="man de ppp"> y
      la <url url="../../handbook/ppp-and-slip.html#USERPPP"
      name="secci&oacute;n de PPP del handbook">. Activa los logs con el
      comando

      <verb>
        set log Phase Chat Connect Carrier lcp ipcp ccp command
      </verb>

      <p>Este comando deber&iacute;a ser tecleado en el prompt del <bf/ppp/ o
      incluirse en el fichero de configuraci&oacute;n <tt>/etc/ppp/ppp.conf</tt>
      (al inicio de la secci&oacute;n <bf>default</bf> es el mejor lugar).
      Asegurate que el fichero
      url="http://www.FreeBSD.org/cgi/man.cgi?syslog.conf"
      name="/etc/syslog.conf"> contiene las siguientes l&iacute;neas:

      <verb>
        !ppp
        *.*              /var/log/ppp.log
      </verb>

      <p>y que el fichero <tt>/var/log/ppp.log</tt> existe. Puedes
      encontrar mucha informaci&oacute;n sobre lo que est&aacute; pasando en las
      conexiones con el fichero de log.

      <p>Si tu versi&oacute;n de ppp no entiende el comando "set log" 
      deber&iacute;as bajarte la
      <url url="http://www.FreeBSD.org/~brian" name="&uacute;ltima 
      versi&oacute;n">. Esta compilar&aacute; sin problemas en FreeBSD 2.1.5 y 
      superiores.

      <sect2>
        <heading>PPP no quiere marcar en modo -auto</heading>

        <p>Primero, aseg&uacute;rate de tener una ruta por defecto. Ejecutando
        el comando url="http://www.FreeBSD.org/cgi/man.cgi?netstat">
        name="netstat -rn"> deber&iacute;as ver dos entradas como estas:

        <verb>
Destination        Gateway            Flags     Refs     Use     Netif Expire
default            10.0.0.2           UGSc        0        0      tun0
10.0.0.2           10.0.0.1           UH          0        0      tun0
        </verb>

        <p>Esto es asumiendo que hayas usado las direcciones del manual,
        la p&aacute;gina man o del fichero de ejemplo ppp.conf.sample. Si no
        tienes una ruta por defecto, puede ser por que est&eacute;s usando una
        versi&oacute;n antigua de <htmlurl
        url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="ppp"> que no
        entiende la palabra <tt/HISADDR/ en el fichero ppp.conf. Si
        tu versi&oacute;n de <bf/ppp/ es de antes de FreeBSD 2.2.5, cambia la
        l&iacute;nea

        <verb>
          add 0 0 HISADDR
        </verb>

        <p>por otra diciendo

        <verb>
          add 0 0 10.0.0.2
        </verb>

        <p>Otra raz&oacute;n para la inexistencia de la ruta por defecto es que
        sin darte cuenta hayas creado un default router en el fichero
        /etc/rc.conf (anteriormente llamado <tt>/etc/sysconfig</tt>) y
        hayas omitido la l&iacute;nea

        <verb>
          delete ALL
        </verb>

        <p>en el fichero <tt>ppp.conf</tt>.  Si es este el caso vuelve a la
        secci&oacute;n 
        <url url="../../handbook/ppp-and-slip.html#USERPPP-FINAL.html"
        name="configuraci&oacute;n final del sistema"> en el handbook.

      <sect2>
        <heading>&iquest;Qu&eacute; significa "No route to host"?</heading>

        <p>Este error se debe normalmente a la falta de la secci&oacute;n

        <verb>
          MYADDR:
            delete ALL
            add 0 0 HISADDR
        </verb>

        <p>en el fichero <tt>/etc/ppp/ppp.linkup</tt>. Esto es solo
        necesario si tienes una direccion IP din&aacute;mica o no sabes la
        direcci&oacute;n de tu gateway. Si est&aacute;s usando el modo 
        interactivo, puedes teclear lo siguiente despues de entrar en 
        <tt/packet mode/:

        <verb>
          delete ALL
          add 0 0 HISADDR
        </verb>

        <p>P&aacute;sate por la secci&oacute;n
        <url url="../../handbook/ppp-and-slip.html#USERPPP-DYNAMICIP"
        name="PPP y direcciones IP din&aacute;micas"> del handbook para
        m&aacute;s informaci&oacute;n.

      <sect2>
        <heading>Mi conexi&oacute;n se corta pasados 3 minutos</heading>

        <p>El timeout de ppp por defecto es de 3 minutos. Se puede ajustar
        con la l&iacute;nea:

        <verb>
          set timeout NNN
        </verb>

        <p>Donde <bf/NNN/ es el n&uacute;mero de segundos de inactividad antes 
        de cerrar la conexi&oacute;n. Si <bf/NNN/ es 0, la conexi&oacute;n no 
        se cerrar&aacute; nunca por timeout. Es posible poner este comando en 
        el fichero <tt>ppp.conf</tt>, o teclearla en el prompt del modo 
        interactivo.
        Tambi&eacute;n es posible ajustarla en cualquier momento mientras la
        conexi&oacute;n est&eacute; activa conectando al socket del servidor 
        <bf/ppp/ usando
        <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?telnet" name="telnet">
        o <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?pppctl"
        name="pppctl">. Leete el man de
        <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="ppp">
        para m&aacute;s detalles.

      <sect2>
        <heading>Mi conexi&oacute;n se corta en situaciones de carga</heading>

        <p>Si tienes la opci&oacute;n Link Quality Reporting (LQR) configurada
        es posible que demasiados paquetes LQR se pierdan entre tu
        m&aacute;quina y el remoto. PPP deduce que la l&iacute;nea es mala y 
        corta la conexi&oacute;n. En versiones anteriores a la 2.2.5 de 
        FreeBSD, LQR estaba activado por defecto. Ahora est&aacute; desactivado
        por defecto. LQR puede ser activado con la l&iacute;nea

        <verb>
          disable lqr
        </verb>

      <sect2>
        <heading>Mi conexi&oacute;n se corta en periodos aleatorios</heading>

        <p>Algunas veces, en l&iacute;neas telef&oacute;nicas de baja calidad 
        o con mucho ruido, o l&iacute;neas con la opci&oacute;n de llamada en 
        espera activada, el m&oacute;dem corta la conexi&oacute;n por que 
        piensa (err&oacute;neamente) que ha perdido la portadora.

        <p>Hay una opci&oacute;n en muchos modems para determiar la tolerancia
        a p&eacute;rdidas temporales de portadora. En un USR Sportster por
        ejemplo, esta es medida por el registro S10 en d&eacute;cimas de 
        segundo. Para hacer que tu m&oacute;dem sea m&aacute;s resistente, 
        puedes a&ntilde;adir la siguiente secuencia "send-expect" a la cadena 
        de llamada:

        <verb>
          set dial "...... ATS10=10 OK ......"
        </verb>

        <p>Mira en el manual de tu m&oacute;dem para m&aacute;s detalles.

      <sect2>
        <heading>No ocurre nada despu&eacute;s del mensaje Login OK</heading>

        <p>En versiones anteriores a FreeBSD 2.2.5, una vez estaba la
        conexi&oacute;n establecida,
        <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ppp"
        name="ppp"> espera a que el remoto inicie la negociaci&oacute;n LCP
        (Line Control Protocol). Muchos proveedores de Internet no
        iniciar&aacute;n la negociaci&oacute;n esperando que sea el cliente el
        que lo haga. Para forzar al <bf/ppp/ a iniciar el LCP, usa la
        siguiente l&iacute;nea:

        <verb>
          set openmode active
        </verb>

        <p><bf/Nota:/ Normalmente no hay problemas si las dos partes
        inician la negocioacion LCP, ya que el modo abierto (open mode)
        est&aacute; activo por defecto. De todas maneras, la siguiente 
        secci&oacute;n explica cuando pueden haber problemas.

      <sect2>
        <heading>Sigo teniendo errores sobre el par&aacute;metro magic</heading>

        <p>Ocasionalmente, justo despu&eacute;s de la conexi&oacute;n, puedes 
        ver mensajes en el log referentes a "magic number is the same".
        Algunas veces, estos mensajes son inofensivos, y otras veces
        uno de los dos extremos finaliza la conexi&oacute;n. Algunas
        implementaciones de ppp no pueden solucionar este problema, y,
        aunque parezca que la conexi&oacute;n est&aacute; establecida, 
        ver&aacute;s repetidas peticiones y aceptaciones de 
        configuraci&oacute;n en el fichero de log hasta que una de las dos 
        partes cierra la conexi&oacute;n.

        <p>Esto ocurre normalmente en servidores con disco lentos que
        tienen problemas para gestionar eficientemente los puertos
        serie. Tambi&eacute;n existen informes de problemas en conexiones
        mediante slip. La raz&oacute;n es que en el tiempo que tarda el
        servidor en salir del getty y ejecutar el ppp, el cliente
        manda los paquetes de inicio LCP. Al estar el ECHO todav&iacute;a
        activo en el puerto del servidor, el cliente ppp lo &uacute;nico que
        ve son sus propios paquetes "reflejados" por el servidor.

        <p>Una parte de la negociaci&oacute;n LCP es establecer un n&uacute;mero
        m&aacute;gico para cada una de los dos extremos de las conexiones para
        que los "reflejos" puedan ser detectados. El protocolo dice que
        cuando el remoto intenta negociar el mismo "magic number", se debe
        enviar un NAK para seleccionar un nuevo "magic number". Durante el
        periodo de tiempo que el servidor tiene el ECHO activado en el
        puerto, el cliente ppp env&iacute;a paquetes LCP, ve que el mismo 
        "magic" vuelve en el paquete reflejado y lo da como no v&aacute;lido 
        (envia NAK).
        Este todav&iacute;a ve el paquete reflajado con NAK (lo que significa 
        que el ppp debe cambiar su "magic"). Esto produce un enorme 
        n&uacute;mero de cambios de "magic number" que son introducidos en el 
        buffer tty del servidor. Tan pronto como el ppp arranca en el servidor,
        es bombardeado con cambios de "magic numbers" e inmediatamente decide
        que ya ha realizado el n&uacute;mero suficiente de negociaciones LCP y
        corta la conexi&oacute;n. Mientras tanto, el cliente, que ya no ve los
        paquetes reflejados, recibe sin problemas la desconexi&oacute;n del
        servidor y tambi&eacute;n cierra la conexi&oacute;n.

        <p>Esto puede ser resuelto permitiendo que el remoto inicie la
        negociaci&oacute;n, poniendo la siguiente l&iacute;nea en el fichero 
        ppp.conf:

        <verb>
          set openmode passive
        </verb>

        <p>Esto indica al ppp que espere a que el servidor comience la
        negociaci&oacute;n LCP. Es posible que algunos servidores nunca inicien
        la negociaci&oacute;n. Si este es el caso, puedes hacer algo como:

        <verb>
          set openmode active 3
        </verb>

        <p>Esto le indica al ppp que sea pasivo durante 3 segundos, y
        despues comience a enviar peticiones LCP. Si el remoto env&iacute;a
        peticiones durante este periodo, ppp responder&aacute; inmediatamente 
        sin esperar los 3 segundos establecidos.

      <sect2>
        <heading>
          Las negociaciones LCP continuan hasta que se cierra la conexi&oacute;n</heading>

        <p>Existe actualmente un problema de implementaci&oacute;n en <bf/ppp/ 
        en la que no asocia las respuestas LCP, CCP &amp; IPCP con sus
        peticiones originales. Como resultado, si una implementaci&oacute;n
        <bf/ppp/ es mas lenta durante 6 segundos que la remota, la remota
        enviar&aacute; dos peticiones de configuraci&oacute;n LCP adicionales.
        Esto es fatal.

        <p>Considera dos implementaciones, <bf/A/ y <bf/B/. <bf/A/ empieza
        a enviar peticiones LCP inmediatamente despu&eacute;s de conectar y 
        <bf/B/ tarda 7 segundos en arrancar. Cuando <bf/B/ arranca, <bf/A/ ha
        enviado 3 peticiones LCP. Estamos asumiendo que la l&iacute;nea tiene el
        ECHO desactivado, si no, veriamos los problemas de "magic number"
        descritos en el apartado anterior. <bf/B/ env&iacute;a un REQ, y a
        continuaci&oacute;n env&iacute;a un ACK al primer REQ de <bf/A/. Esto 
        resulta en que <bf/A/ entra en modo <bf/OPENED/ y env&iacute;a un ACK 
        (el primero) a <bf/B/. Mientras, <bf/B/ devuelve dos ACKs mas en 
        respuesta a los dos REQs adicionales enviados por <bf/A/ antes de que 
        <bf/B/ arrancase .<bf/B/ recibe el primer ACK de <bf/A/ y entra en modo
        <bf/OPENED/.
        <bf/A/ recibe el segundo ACK de <bf/B/ y vuelve al estado
        <bf/REQ-SENT/, enviando otro (el cuarto) REQ. Entonces recibe el
        tercer ACK y entra en modo <bf/OPENED/. Mientras, <bf/B/ recibe el
        cuarto REQ de <bf/A/, produciendo que vuelva de nuevo al estado
        <bf/ACK-SENT/ y enviando otro (el segundo) REQ y (cuarto) ACK. <bf/A/
        recibe el REQ, entra en modo <bf/REQ-SENT/ y env&iacute;a otro REQ.
        Inmediatamente recibe el siguiente ACK y entra en <bf/OPENED/.

        <p>Esto pasa hasta que una de las partes piensa que ya ha realizado
        suficientes reintentos y corta la conexi&oacute;n.

        <p>La mejor manera de evitar esto es configurar una de las partes
        de manera <bf/pasiva/ - que es, hacer que una de las partes espere
        a que la otra comience la negociaci&oacute;n. Esto puede realizarse 
        con el comando:

        <verb>
          set openmode passive
        </verb>

        Se debe tener cuidado con esta opci&oacute;n. Tambi&eacute;n se puede 
        usar:

        <verb>
          set stopped N
        </verb>

        para limitar el n&uacute;mero de veces que <bf/ppp/ espera a que el 
        remoto comience la negociaci&oacute;n. Alternativamente, puedes user 
        el comando:

        <verb>
          set openmode active N
        </verb>

        donde <bf/N/ es el n&uacute;mero de segundos que espera antes de empezar
        la negociaci&oacute;n. Mira en el manual para m&aacute;s detalles.

      <sect2>
        <heading>Ppp se bloquea al conectar</heading>

        <p>Antes de la versi&oacute;n 2.2.5 era posible que la conexi&oacute;n 
        se corte nada m&aacute;s iniciarse debido a un problema en la 
        negociaci&oacute;n de compresi&oacute;n Predictor1. Esto solo pasa si 
        las dos partes intentan negociar con diferentes protocolos de control 
        de compresi&oacute;n (CCP).
        Este problema ya est&aacute; corregido, pero si est&aacute;s usando 
        una versi&oacute;n antigua de <bf/ppp/, el problema puede solucionarse 
        con la l&iacute;nea

        <verb>
          disable pred1
        </verb>

      <sect2>
        <heading>Ppp se bloqua al abrir un shell de test</heading>

        <p>Cuando ejecutas el comando <tt/shell/ o <tt/!/, <bf/ppp/ ejecuta
        un shell (o si has pasado argumentos, <bf/ppp/ ejecutar&aacute; esos
        argumentos). Ppp esperar&aacute; a que se complete el comando antes de
        continuar. Si intentas usar la conexi&oacute;n ppp mientras se ejecuta 
        el comando, parecer&aacute; que la conexi&oacute;n se ha colgado. Esto 
        es por que <bf/ppp/ est&aacute; esperando a que se complete la 
        ejecuci&oacute;n del comando.

        <p>Si quieres ejecutar comandos como este, usa el comando <tt/!bg/ en
        su lugar. Esto ejecutar&aacute; el comando en background, y ppp 
        contin&uacute;a sin problemas con la conexi&oacute;n.

      <sect2>
        <heading>Ppp sobre un cable null-modem no funciona</heading>

        <p>No hay manera que <bf/ppp/ detecte autom&aacute;ticamente que una
        conexi&oacute;n directa se ha cortado. Es debido a las l&iacute;neas 
        que se usan en un cable serie null-modem. Cuando usamos este tipo de 
        conexi&oacute;n, LQR deber&iacute;a estar siempre activada con el 
        comando

        <verb>
          enable lqr
        </verb>

        <p>LQR es aceptado por defecto si es negociado por el remoto.

      <sect2>
        <heading>&iquest;Por que llama sin motivo el ppp en modo -auto?</heading>

        <p>Si <bf/ppp/ llama inesperadamente, debes determinar la causa, y
        poner filtros (dfilters) para prevenir esas llamadas.

        <p>Para determinar la causa, usa la siguiente l&iacute;nea:

        <verb>
          set log +tcp/ip
        </verb>

        <p>Esto guardara todo el tr&aacute;fico que pase a trav&eacute;s de la 
        conexi&oacute;n.
        La pr&oacute;xima vez que se realice una llamada no deseada, 
        podr&aacute;s ver la causa convenientemente guardada.

        <p>Ahora puedes desactivar las llamadas producidas por esa causa.
        Usualmente, este tipo de problemas se debe a consultas de DNS. Para
        prevenir que las consultas de DNS puedan establecer conexiones usa
        la siguiente l&iacute;nea (esto no har&aacute; que los paquetes de DNS 
        queden parados cuando la conexi&oacute;n est&aacute; establecida):

        <verb>
          set dfilter 1 deny udp src eq 53
          set dfilter 2 deny udp dst eq 53
          set dfilter 3 permit 0/0 0/0
        </verb>

        <p>Esto no siempre es aconsejable, ya que puede afectar a la
        capacidad de realizar conexiones bajo demanda - muchos programas
        necesitan hacer una consulta al DNS antes de poder realizar
        cualquier operaci&oacute;n.

        <p>En el caso del DNS, deber&iacute;as determinar que es lo que 
        est&aacute; intentando realizar esas consultas de DNS. Muchas veces,
        <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?sendmail"
        name="sendmail"> es el culpable. Debes asegurarte configurar el
        sendmail de manera que no realice ninguna consulta al DNS. Mira la
        secci&oacute;n <ref id="ispmail" name="Configuracion de correo"> para 
        tener m&aacute;s detalles acerca de como crear una fichero propio de 
        configuraci&oacute;n de sendmail. Tambi&eacute;n deber&iacute;as 
        a&ntilde;adir la siguiente l&iacute;nea en tu fichero <bf/.mc/:

        <verb>
          define(`confDELIVERY_MODE', `d')dnl
        </verb>

        <p>Esto hara que sendmail encole todo el correo hasta que no se
        procese la cola (usualmente, sendmail es invocado con
        "-bd -q30m", indicandole que procese la cola cada 30 minutos) o
        hasta que se ejecuta el comando "sendmail -q" (por ejemplo, desde
        el fichero ppp.linup).

      <sect2>
        <heading>&iquest;Qu&eacute; significan estos errores CCP?</heading>

        <p>Sigo viendo los siguientes errores en el fichero de log:

        <verb>
          CCP: CcpSendConfigReq
          CCP: Received Terminate Ack (1) state = Req-Sent (6)
        </verb>

        <p>Esto es porque ppp est&aacute; intentando negociar compresi&oacute;n
        Predictor1, y el remoto no quiere negociar ning&uacute;n tipo de
        compresi&oacute;n. Estos mensajes son sin importancia, pero si quieres
        eliminarlos, puedes desactivar la compresi&oacute;n Predictor1 
        localmente:

        <verb>
          disable pred1
        </verb>

      <sect2>
        <heading>PPP se cuelga durante transferencia de ficheros con errores I/OP</heading>

        <p>En la versi&oacute;n FreeBSD 2.2.2 y anteriores, hab&iacute;a un 
        problema en el driver tun que no permit&iacute;a paquetes entrantes con
        un tama&ntilde;o mayor que el MTU del interface. La recepci&oacute;n de
        un paquete mayor que el MTU resulta en un error IO que es logueado 
        v&iacute;a syslogd.

        <p>La especificaci&oacute;n PPP dice que un MRU de 1500 <bf>siempre</bf>
        deber&iacute;a ser aceptada como m&iacute;nimo, a pesar de lo que se 
        negocie mediante LCP, de todas maneras, es posible que hayas disminuido
        el MTU por debajo de 1500 y tu proveedor te est&eacute; enviando 
        paquetes de 1500, haciendo que tu conexi&oacute;n se bloquee.

        <p>El problema puede solucionarse haciendo que el tama&ntilde;o del
        MTU nunca sea inferior a 1500 bajo FreeBSD 2.2.2 y anteriores.

      <sect2>
        <heading>&iquest;Por que ppp no loguea la velocidad de la conexi&oacute;n?</heading>

        <p>Para loguear todas las l&iacute;neas de "conversaci&oacute;n" de tu
        m&oacute;dem, debes activar la siguiente opci&oacute;n:

        <verb>
          set log +connect
        </verb>

        <p>Esto har&aacute; que
        <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ppp" name="ppp">
        loguee todo hasta la &uacute;ltima cadena "expect" pedida.

        <p>Si quieres ver la velocidad de tu conexi&oacute;n y usas PAP o CHAP
        (y por lo tanto no tienes nada que "chatear" despu&eacute;s del CONNECT
        en el script de marcado), debes estar seguro de indicarle al ppp que
        espera la l&iacute;nea "CONNECT con algo como esto:

        <verb>
          set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
        </verb>

        <p>Aqu&iacute;, tenemos nuestro CONNECT, enviamos nada, y esperamos un
        salto de l&iacute;nea, forzando al <bf/ppp/ que lea la respuesta del
        CONNECT.

      <sect2>
        <heading>Ppp ignora el car&aacute;cter `\' en mi chat script</heading>

        <p>PPP lee cada l&iacute;nea de los ficheros de configuraci&oacute;n 
        para poder interpretar cadenas como <tt/set phone "123 456 789"/ 
        correctamente.
        Para especificar un car&aacute;cter ``"'', debes usar la contrabarra 
        (``\'').

        <p>Cuando el int&eacute;rprete lee cada argumento, reinterpreta el 
        argumento para buscar alguna secuencia especial de escape como ``\P'' 
        o ``\T''.
        Como resultado de esta doble lectura, recuerda que has de usar el
        n&uacute;mero correcto de escapes (contrabarras).

        <p>Si quieres enviar un caracter ``\'' a tu m&oacute;dem, necesitas 
        hacer algo como:

        <verb>
          set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
        </verb>

        <p>resultando en la siguiente secuencia:

        <verb>
          ATZ
          OK
          AT\X
          OK
        </verb>

        <p>o

        <verb>
          set phone 1234567
          set dial "\"\" ATZ OK ATDT\\T"
        </verb>

        <p>resultando en la siguiente secuencia:

        <verb>
          ATZ
          OK
          ATDT1234567
        </verb>

      <sect2>
        <heading>Ppp produce un seg-fault, pero no veo el fichero <tt/ppp.core/</heading>

        <p>Ppp (o cualquier otro programa de este tipo), nunca deber&iacute;an
        hacer un core dump. Por que ppp funciona con un id de usuario 0,
        el sistema operativo no escribir&aacute; la imagen del core en disco.
        Si ppp termina con errores de "segmentation violation" o cualquier
        otra se&ntilde;al que normalmente causa un core dumped, y quieres poder
        hacer un debug de ese core, aseg&uacute;rate de usar la &uacute;ltima 
        versi&oacute;n de ppp, y haz lo siguiente:

        <verb>
          $ tar xfz ppp-*.src.tar.gz
          $ cd ppp*/ppp
          $ echo STRIP= >>Makefile
          $ echo CFLAGS+=-g >>Makefile
          $ make clean all
          $ su
          # make install
          # chmod 555 /usr/sbin/ppp
        </verb>

        <p>Ahora tendr&aacute;s instalada una versi&oacute;n "debuggable" de 
        ppp. Tendr&aacute;s que ser root para poder ejecutar ppp ya que todos 
        sus privilegios han sido revocados. Cuando arranques ppp, acuerdate del
        directorio en el que te encuentras.

        <p>Ahora, cuando ppp recibe una violaci&oacute;n de segmentaci&oacute;n
        , crear&aacute; un fichero core llamado ppp.core. A continuaci&oacute;n
        , deber&iacute;as hacer lo siguiente:

        <verb>
          $ su
          # gdb /usr/sbin/ppp ppp.core
          (gdb) bt
          .....
          (gdb) f 0
          .....
          (gdb) i args
          .....
          (gdb) l
          .....
        </verb>

        <p>Toda esta informaci&oacute;n puede hacer posible diagnosticar el
        problema. Si est&aacute;s familiarizado con gdb, puedes encontrar otras
        pistas como que caus&oacute; el dump y las direcciones y valores de las
        variables m&aacute;s relevantes.

      <sect2>
        <heading>
          El proceso que fuerza una llamada en modo auto nunca funciona
        </heading>

        <p>Este es un problema conocido cuando <bf/ppp/ est&aacute; configurado
        para negociar una IP din&aacute;mica local con el remoto. Este 
        problema ha sido solucionado en la &uacute;ltima versi&oacute;n - 
        busca en el man la palabra <bf/iface/.


        <p>El problema era que cuando el programa inicial llama a
        <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?connect"
        name="connect(2)">, el IP del interface tun es asignado al punto
        final del socket. El kernel crea el primer paquete saliente y
        establece la conexi&oacute;n. Si, como resultado de la 
        asignaci&oacute;n din&aacute;mica de IP, la direcci&oacute;n del 
        interface es cambiada, el punto final del socket original ser&aacute; 
        invalido. Los siguientes paquetes enviados al remoto normalmente 
        ser&aacute;n descartados. Aun si no lo son, cualquier respuesta no 
        ser&aacute; enrutada hacia la m&aacute;quina de origen por que la
        direcci&oacute;n IP de la m&aacute;quina de origen ha cambiado.

        <p>Hay varias maneras te&oacute;ricas de solucionar este problema. Lo
        mejor ser&iacute;a que el remoto reasignase la misma IP si fuese 
        posible <tt/:-)/ La versi&oacute;n actual de <bf/ppp/ hace esto,
        pero otras muchas implementaciones no.

        <p>El m&eacute;todo m&aacute;s sencillo desde nuestra parte, 
        ser&iacute;a no cambiar nunca la IP del interface tun, pero por el 
        contrario, cambiar todos los paquetes salientes de manera que la ip de 
        origen es cambiada del IP del interface a la IP negociada, 
        instantaneamente.
        Esto es, esencialmente, lo que hacen
        <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?libalias"
        name="libalias(3)"> y el par&aacute;metro <bf/-alias/ de ppp.

        <p>Otra alternativa (y probablemente la mas eficaz) es implementar
        una llamada al sistema que cambie todos los sockets de una IP a
        otra. <bf/Ppp/ deber&iacute;a usar esta llamada para modificar los
        sockets de todos los programas existentes cuando una nueva 
        direcci&oacute;n IP es negociada. La misma llamada de sistema
        podr&iacute;a ser usada para clientes dhcp cuando son forzados
        a rehacer sus sockets.

        <p>Una tercera opci&oacute;n es permitir que un interface se active sin
        IP. Los paquetes salientes tendr&iacute;an un IP de 255.255.255.255 
        hasta que el primer SIOCAIFADDR ioctl este hecho. Esto 
        permitir&iacute;a que ppp cambiase el IP de origen, pero solo si el 
        socket es 255.255.255.255 y solo el IP y el checksum necesitan cambiar.         Esto, de todas maneras, requiere tocar el kernel para que puede enviar 
        paquetes incorrectos a un interface mal configurado.

      <sect2>
        <heading>&iquest;Porqu&eacute; muchos juegos no funcionan con el 
        par&aacute;metro -alias?</heading>

        <p>La raz&oacute;n por la que muchos de los juegos no funcionan es 
        por que la m&aacute;quina externa intentar&aacute; abrir una 
        conexi&oacute;n o enviar paquetes UDP (no solicitados) a la 
        m&aacute;quina interna. El software "alias" no sabe que esos paquetes
        debr&iacute;n enviarse a la m&aacute;quina interna.

        <p>Para que las cosas funcionen, aseg&uacute;rate que la &uacute;nica
        cosa que est&aacute; funcionando es el software con el que tienes
        problemas, entonces ejecuta tcpdump en el interface tun del 
        gateway o ejecuta el log tcp/ip del ppp ("set log +tcp/ip" en el
        gateway.

        <p>Cuando arrancas el software que no funciona, deber&iacute;s ver
        paquetes que pasan a trav&eacute;s del gateway. Cuando algo
        vuelve del exterior, ser&aacute; rechazado (ese es el problema).
        Apunta el n&uacute;mero de puerto de esos paquetes y cierra el
        software que no funciona. Haz esto varias veces para comprobar si
        el n&uacute;mero de puerto se repite. Si es as&iacute;, la siguiente
        l&iacute;nea en el fichero de configuraci&oacute;n del ppp
        /etc/ppp/ppp.conf har&aacute; que las cosas funcionen:

       <verb>
         alias port proto internalmachine:port port
       </verb>

       <p>donde "proto" puede ser "tcp" o "udp", "internalmachine" es la
       m&aacute;quina a la que quieres que los paquetes sean enviados y
       "port" es el n&uacute;mero de puerto de destino de los paquetes.

       <p>No podr&aacute;s usar ese software en otras m&aacute;quinas sin
       modificar el comando anterior, y ejecutar el software 
       simultaneamente en dos m&aacute;quinas internas no ser&aacute;
       posible - despu&eacute;s de todo, el mundo exterior est&aacute;
       viendo a toda tu red como una sola m&aacute;quina.

       <p>Si los n&uacute;meros de puertos no se repiten, hay tres opciones
       m&aacute;s:

       <p><bf>1)</bf> Desarrollar el soporte en libalias. Ejemplos de estos
       "casos especiales" los puedes encontrar en
       /usr/src/lib/libalias/alias_*.c (alias_ftp.c es un bu&eacute;n
       prototipo). Esto usualmente supone leer ciertos paquetes salientes
       conocidos, identificando la instrucci&oacute;n que le indica a la 
       m&aacute;quina exterior que inicie una conexi&oacute;n con la 
       m&aacute;quina interna en un puerto espec&iacute;fico (aleatorio)
       y configurar un "ruta" en la tabla de alias para que los paquetes
       siguientes sepan donde ir.

       <p>Esta es la soluci&oacute;n m&aacute;s dif&iacute;cil, pero es la
       mejor y har&aacute; que el software funcione con m&uacute;ltiples
       m&aacute;quinas.

       <p><bf>2)</bf> Usar un proxy. La aplicaci&oacute;n debe soportar
       socks5 por ejemplo, o (como en el caso del "cvsup") deber&iacute;a
       tener una opci&oacute;n "pasiva" que evita que el remoto intente abrir
       conexiones con la maquina local.

       <p><bf>3)</bf> Redireccionar todo el tr&aacute;fico a la m&aacute;quina
       interna usando "alias addr". Esta es la soluci&oacute;n m&aacute;s
       sencilla.

       <sect3>
         <heading>&iquest;Ha hecho alguien una lista de puertos &uacute;tiles?</heading>

         <p>Todav&iacute;a no, pero se podr&iacute;a hacer, si hay 
         inter&eacute;s. En cada ejemplo, <tt>internal</tt> debe ser
         reemplazado por la direcci&oacute;n IP de la m&aacute;quina que
         va a estar jugando.

         <itemize>
           <item><bf>Quake</bf>
           <p><tt>alias port udp internal:6112 6112</tt>
           <p>Alternativamente, quiz&aacute;s est&eacute;s interesado en 
           mirar en el 
           <htmlurl url="http://www.battle.net/support/proxy/" 
           name="www.battle.net">soporte de Quake a trav&eacute;s de proxy">.
         </itemize>

         <itemize>
           <item><bf>Quake 2</bf>
           <p><tt>alias port udp internal:27901 27910</tt>
         </itemize>

         <itemize>
           <item><bf>Red Alert</bf>
           <p><tt>alias port udp internal:8675 8675</tt>
           <p><tt>alias port udp internal:5009 5009</tt>
         </itemize>

         <itemize>
           <item><bf>Half Life</bf>
           <p><tt>alias port udp internal:27005 27015</tt>
         </itemize> 

         <itemize>
           <item><bf>PCAnywhere 8.0</bf>
           <p><tt>alias port udp internal:5632 5632</tt>
           <p><tt>alias port tcp internal:5631 5631</tt>
         </itemize>


      <sect2>
        <heading>&iquest;Qu&eacute; son los errores FCS?</heading>

        <p>FCS significa <bf/F/rame <bf/C/heck <bf/S/equence. Cada paquete
        ppp tiene un checksum a&ntilde;adido para asegurar que los datos
        que se reciben son los datos que han sido enviados. Si el FCS de un
        paquete entrante es incorrecto, el paquete es rechazado y se
        incremente el contador HDLC FCS. Los valores de error HDLC se
        pueden visualizar usando el comando <tt>show hdlc</tt>.

       <p>Si tu conexi&oacute;n es mala (o si tu driver serie est&aacute;
       rechazando paquetes), ver&aacute;s errores FCS ocasionales. En general
       no tienes porque preocuparte de ellos. Si tienes un m&oacute;dem 
       externo, aseg&uacute;rate que el cable est&aacute; correctamente
       aislado de interferencias - esto deber&iacute;a erradicar el problema.

       <p>Si tu conexi&oacute;n se corta tan pronto como has conectado y ves
       gran cantidad de errores FCS, puede ser por que ti conexi&oacute;n no
       es de 8 bits. Aseg&uacute;rate de que tu m&oacute;dem no est&aacute;
       usando control de flujo (XON/XOFF) por software. Si tu conexi&oacute;n
       de datos <bf>debe</bf> usar control de flujo por software, usa el 
       comando <tt>set accmap 0x000a0000</tt> para indicar al <bf>ppp</bf>
       que "escape" los car&aacute;cteres ^Q y ^S.

       <p>Otra raz&oacute;n para ver muchos errores FCS puede ser que el 
       remoto haya dejado de "hablar" <bf/PPP/. Deber&iacute;s activar el
       log as&iacute;ncrono para determinar si los datos entrantes son de
       un login o un prompt de shell. Si tienes un prompt de shell en el
       extremo de la conexi&oacute;n, es posible terminar el ppp sin 
       cortar la conexi&oacute;n usando el comando <tt>close clp</tt> (usando
       el comando <tt>term</tt> podr&aacute;s conectar de nuevo con el shell
       de la m&aacute;quina remota.

       <p>Si no hay nada en el log que indique por que se ha terminado la 
       conexi&oacute;n, deber&iacute;s preguntar al administrador del 
       sistema remoto porqu&eacute; ha terminado la sesi&oacute;n.

      <sect2>
        <heading>Nada de esto me ayuda - Estoy desesperado !</heading>

        <p>Si todo falla, env&iacute;a toda la informaci&oacute;n que puedas, 
        incluyendo los ficheros de configuraci&oacute;n, como arrancas el ppp, 
        las partes relevantes del fichero de log y la salida del comando
        <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?netstat"
        name="netstat -rn"> (antes y despues de la conexi&oacute;n) a la lista 
        de distribuci&oacute;n <url url="mailto:FreeBSD-questions@FreeBSD.org"
        name="FreeBSD-questions@FreeBSD.org">, a la lista de
        <url url="mailto:FreeBSD@es.FreeBSD.org" name="FreeBSD en 
        castellano"> o al grupo de news 
        <url url="news:comp.unix.bsd.FreeBSD.misc"
        name="comp.unix.bsd.FreeBSD.misc"> y alguien te ayudar&aacute; a
        solucionar los problemas.

    <sect1>
      <heading>No puedo crear el dispositivo <tt>/dev/ed0</tt>!</heading>

      <p>En el sistema de trabajo de red de Berkeley, los interfaces de
      red solo son directamente accesibles por el c&oacute;digo del kernel. Por
      favor, mira el fichero <tt>/etc/rc.network</tt> y los man de los
      programas de red all&iacute; mencionados. Si esto te deja totalmente
      confundido, entonces tendr&iacute;as que conseguir algun libro de
      administraci&oacute;n de red de cualquier sistema operativo basado en BSD;
      con algunas excepciones significativas, administrar el sistema de red
      en FreeBSD es b&aacute;sicamente igual que en SunOS 4.0 o Ultrix.

    <sect1>
      <heading>&iquest;C&oacute;mo puedo configurar alias de ethernets?</heading>

      <p>A&ntilde;ade ``<tt/netmask 0xffffffff/'' en el comando <htmlurl 
      url="http://www.FreeBSD.org/cgi/man.cgi?ifconfig" name="ifconfig">
      como el siguiente:

      <verb>
        ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff
      </verb>

    <sect1>
      <heading>&iquest;C&oacute;mo hago para usar el otro puerto de una 3C503?</heading>

      <p>Si quieres usar los otros puertos, tendr&aacute;s que especificar
      par&aacute;metros adicionales en el comando
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?ifconfig"
      name="ifconfig">. El puerto por defecto es <tt/link0/. Para usar el
      puerto AUI en lugar del BSN, usa <tt/link2/. Estos flags tendr&iacute;an 
      que ser especificados usando las variable ifconfig_* en el fichero
      <htmlurl url="http://www.FreeBSD.org/cgi/man.cgi?rc.conf"
      name="/etc/rc.conf">.

    <sect1>
      <heading>Tengo problemas con NFS desde/hacia FreeBSD.</heading>

      <p>Algunas tarjetas de red son mejores que otras y algunas veces
      pueden causar problemas con aplicaciones de uso intensivo de red
      como NFS

      <p>Mira la <url url="../../handbook/nfs.html" name="entrada en el manual
      de NFS"> para mas informaci&oacute;n sobre este tema.

    <sect1>
      <heading>&iquest;Porqu&eacute; no puedo hacer NFS-mount desde Linux?</heading>

      <p>Algunas versiones de NFS para Linux solo aceptan peticiones
      para montar unidades hechas desde un puerto privilegiado; intenta:

      <verb>
        mount -o -P linuxbox:/blah /mnt
      </verb>

    <sect1>
      <heading>&iquest;Porqu&eacute; no puedo hacer NFS-mount desde una Sun?</heading>

      <p>Las estaciones de trabajo Sun con SunOS 4.x solo aceptan peticiones
      de montar unidades hechas desde puertos privilegiados; intenta

      <verb>
        mount -o -P sunbox:/blah /mnt
      </verb>

    <sect1>
      <heading>Tengo problemas usando ppp contra m&aacute;quinas NeXTStep.</heading>

      <p>Intenta desactivar las extensiones TCP en
      url="http://www.FreeBSD.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf">
      cambiando la siguiente variable a NO:

      <verb>
        tcp_extensions=NO
      </verb>

      <p>Las m&aacute;quinas Xylogic's Annex tambi&eacute;n tienen este 
      problema, por lo que tienes que hacer el mismo cambio para conectar con 
      ellas.

    <sect1>
      <heading>&iquest;C&oacute;mo activo soporte de IP multicast?</heading>

      <p>Las operaciones multicast est&aacute;n totalmente soportadas en FreeBSD
      2.0 y superiores. Si quieres usar tu m&aacute;quina como router multicast,
      necesitar&aacute;s cargar el m&oacute;dulo de kernel <tt/ip_mrouted_mod/ y
      ejecutar el programa <tt/mrouted/.

      <p>Para mas informaci&oacute;n:

      <verb>
Producto        Descripcion             Donde
--------------- ----------------------- ---------------------------------------
faq.txt		Mbone FAQ		ftp.isi.edu:/mbone/faq.txt
imm/immserv	IMage Multicast 	ftp.hawaii.edu:/paccom/imm.src.tar.Z
        	for jpg/gif images.
nv		Network Video.		ftp.parc.xerox.com:
        				/pub/net-reseach/exp/nv3.3alpha.tar.Z
vat		LBL Visual Audio Tool.	ftp.ee.lbl.gov:
        				/conferencing/vat/i386-vat.tar.Z
wb		LBL White Board.	ftp.ee.lbl.gov:
        				/conferencing/wb/i386-wb.tar.Z
mmcc		MultiMedia Conference	ftp.isi.edu:
        	Control program		/confctrl/mmcc/mmcc-intel.tar.Z
rtpqual		Tools for testing the	ftp.psc.edu:/pub/net_tools/rtpqual.c
        	quality of RTP packets.
vat_nv_record	Recording tools for vat ftp.sics.se:archive/vat_nv_record.tar.Z
        	and nv.
      </verb>

    <sect1>
      <heading>&iquest;Qu&eacute; tarjetas de red est&aacute;n basadas en el chipset DEC PCI?</heading>

      <p>Aqu&iacute; tienes una lista hecha por <url url="mailto:gfoster@driver.nsta.org"
      name="Glen Foster">:

      <verb>
        Fabricante      Modelo
        ----------------------------------------------
        ASUS            PCI-L101-TB
        Accton          ENI1203
        Cogent          EM960PCI
        Compex          ENET32-PCI
        D-Link          DE-530
        Dayna           DP1203, DP2100
        DEC             DE435, DE450
        Danpex          EN-9400P3
        JCIS            Condor JC1260
        Linksys         EtherPCI
        Mylex           LNP101
        SMC             EtherPower 10/100 (Model 9332)
        SMC             EtherPower (Model 8432)
        TopWare         TE-3500P
        Zynx            ZX342
      </verb>

    <sect1>
      <heading>&iquest;Porqu&eacute; tengo que usar el FQDN para hosts en mi servidor?</heading>

      <p>Probablemente el host estar&aacute; en un dominio diferente; por 
      ejemplo, si est&aacute;s en el dominio foo.bar.edu y quieres encontrar 
      un host llamado "mumble" en el dominio bar.edu, tendr&aacute;s que 
      llamarlo por su nombre de dominio, "mumble.bar.edu", en vez de solo 
      "mumble".

      <p>Tradicionalmente, esto era permitido por los resolvers BIND BSD.
      La versi&oacute;n actual de <htmlurl
      url="http://www.FreeBSD.org/cgi/man.cgi?named" name="bind"> que
      se incluye en FreeBSD no resuelve abreviaciones de nombres para
      hosts fuera de nuestro dominio.

    <sect1>
      <heading>``Permission denied'' para todas las operaciones de red.
      </heading>

      <p>Si tienes el kernel compilado con la opci&oacute;n <tt/IPFIREWALL/
      . debes tener en cuenta que la pol&iacute;tica por defecto es denegar
      expl&iacute;citamente todos los paquetes que no est&aacute;n 
      expl&iacute;citamente permitidos.

      <p>Si involuntariamente has desconfigurado el firewall de tu sistema,
      puedes restaurar la operatibilidad de la red tecleando el siguiente
      comando como usuario root:

      <verb>
        ipfw add 65534 allow all from any to any
      </verb>

      <p>Para mas informaci&oacute;n en la configuraci&oacute;n del firewall 
      de FreeBSD, mira la secci&oacute;n 
      <url url="../../handbook/firewalls.html" name="del manual">.

    <sect1>
      <heading>&iquest;Cuanto tiempo retrasa IPFW el tr&aacute;fico?</heading>

      <p>Esta respuesta depende mucho en las reglas definidas y en la
      versi&oacute;n del procesador. Para la mayor&iacute;a de aplicaciones 
      que tienen que ver con la ethernet y peque&ntilde;as reglas, la 
      respuesta es, pr&aacute;cticamente nada.

      Aqu&iacute; tienes una lista de cosas a tener en cuenta para crear reglas
      de filtrado eficientes:

      <itemize>

        <item>Poner una regla "established" al inicio para manejar la
        mayor&iacute;a de trafico TCP. No pongas ninguna regla
        <tt>allow tcp</tt> antes de esta.

        <item>Pon las reglas m&aacute;s usadas antes de las menos usadas 
        (<bf>sin modificar la permisividad del firewall</bf>). Puedes ver cuales
        son las reglas m&aacute;s usadas examinando los contadores de paquetes 
        con la orden <tt>ipfw -a l</tt>.

      </itemize>

    <sect1>
       <heading>&iquest;C&oacute;mo puedo redirigir peticiones de una m&aacute;quina 
       a otra?<(/heading>

       <p>Puedes redirigir peticiones FTP (y otros servicios) con el package
       "socket", disponible en la colecci&oacute;n de ports categor&iacute;a 
       "sysutils".
       Simplemente tienes que reemplazar la l&iacute;nea del servicio 
       correspondiente en el fichero /etc/services de la siguiente manera:

<verb>
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
</verb>

       <p>donde "ftp.foo.com" y "ftp" son la m&aacute;quina y puerto 
       de destino.

  <sect1>
    <heading>&iquest;D&oacute;nde puedo conseguir una herramienta de control de ancho de banda?.</heading>

    <p>Existen dos herramientas de control de ancho de banda para FreeBSD.
    <url url="http://www.csl.sony.co.jp/person/kjc/programs.html"
    name="ALTQ"> es gratis; Bandwidth Manager de
    <url url="http://www.etinc.com" name="Emerging Technologies"> es un
    producto comercial.

  <sect1>
    <heading>&iquest;Porqu&eacute; aparece "/dev/bpf0: device not configured"?
    </heading>

    <p>El driver Berkeley Packet Filter <htmlurl
    url="http://www.FreeBSD.org/cgi/man.cgi?bpf" name="(bpf)"> necesita ser
    activado para ejecutar programas que lo utilizan. A&ntilde;ade esto al
    fichero de configuraci&oacute;n de tu kernel y crea uno nuevo:

       <verb>
         pseudo-device bpfilter         # Berkeley Packet Filter
       </verb>

    <p>A continuaci&oacute;n, despu&eacute;s de rebotar tendr&aacute;s el 
    dispositivo. Esto puede hacerse entrando en el directorio <tt>/dev</tt>
    y ejecutando el siguiente comando:

       <tscreen><verb>
       # sh MAKEDEV bpf0
       </verb></tscreen>

    <p>Por favor, mira la <htmlurl url="../../handbook/kernelconfig-nodes.html"
    name="entrada correspondiente en el handbook"> para m&aacute;s 
    informaci&oacute;n sobre la creaci&oacute;n de dispositivos.