Capítulo 11. PPP

Primero deberías leer el man de ppp y la sección de PPP del handbook. Activa los logs con el comando

        
          set log Phase Chat Connect Carrier lcp ipcp ccp command
        

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

        !ppp
        *.*              /var/log/ppp.log
        

y que el archivo /var/log/ppp.log existe. Puedes encontrar mucha información sobre lo que está pasando en las conexiones con el archivo de log.

Si tu versión de ppp no entiende el comando "set log" deberías bajarte la última versión. Esta compilará sin problemas en FreeBSD 2.1.5 y superiores.

Esto ocurre normalmente por que no se puede resolver el nombre de la máquina. La mejor manera de solucionar este problema es asegurarse que el sistema use en primer lugar el archivo /etc/hosts para hacer la resolución de nombres. Para ello, basta con editar el archivo /etc/host.conf y poner la línea hosts en primer lugar. A continuación, simplemente hay que añadir una línea para la máquina local en el archivo /etc/hosts. Si no existe una red local, modificar la línea localhost:

127.0.0.1 foo.bar.com foo localhost
        

Añadir otra línea para la máquina local. Consultar las páginas man relevantes para más detalles.

Ahora se debería poder ejecutar el siguiente mandato de forma satisfactoria ping -c1 `hostname`.

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

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
        

Esto es asumiendo que hayas usado las direcciones del manual, la página man o del archivo de ejemplo ppp.conf.sample. Si no tienes una ruta por defecto, puede ser por que estés usando una versión antigua de ppp que no entiende la palabra HISADDR en el archivo ppp.conf. Si tu versión de ppp es de antes de FreeBSD 2.2.5, cambia la línea

          add 0 0 HISADDR
        

por otra diciendo

          add 0 0 10.0.0.2
        

Otra razón para la inexistencia de la ruta por defecto es que sin darte cuenta hayas creado un default router en el archivo /etc/rc.conf (anteriormente llamado /etc/sysconfig) y hayas omitido la línea

          delete ALL
        

en el archivo ppp.conf. Si es este el caso vuelve a la sección configuración final del sistema en el handbook.

Este error se debe normalmente a la falta de la sección

          
            MYADDR:
            delete ALL
            add 0 0 HISADDR
        

en el archivo /etc/ppp/ppp.linkup. Esto es solo necesario si tienes una direccion IP dinámica o no sabes la dirección de tu gateway. Si estás usando el modo interactivo, puedes teclear lo siguiente despues de entrar en packet mode:

          
          delete ALL
          add 0 0 HISADDR
        

Pásate por la sección PPP y direcciones IP dinámicas del handbook para más información.

El timeout de ppp por defecto es de 3 minutos. Se puede ajustar con la línea:

          set timeout NNN
        

Donde NNN es el número de segundos de inactividad antes de cerrar la conexión. Si NNN es 0, la conexión no se cerrará nunca por timeout. Es posible poner este comando en el archivo ppp.conf, o teclearla en el prompt del modo interactivo. También es posible ajustarla en cualquier momento mientras la conexión esté activa conectando al socket del servidor ppp usando telnet o pppctl. Leete el man de ppp para más detalles.

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

          disable lqr
        

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

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

          set dial "...... ATS10=10 OK ......"
        

Mira en el manual de tu módem para más detalles.

En versiones anteriores a FreeBSD 2.2.5, una vez estaba la conexión establecida, ppp espera a que el remoto inicie la negociación LCP (Line Control Protocol). Muchos proveedores de Internet no iniciarán la negociación esperando que sea el cliente el que lo haga. Para forzar al ppp a iniciar el LCP, usa la siguiente línea:

          set openmode active
        

Nota: Normalmente no hay problemas si las dos partes inician la negocioacion LCP, ya que el modo abierto (open mode) está activo por defecto. De todas maneras, la siguiente sección explica cuando pueden haber problemas.

Ocasionalmente, justo después de la conexió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ón. Algunas implementaciones de ppp no pueden solucionar este problema, y, aunque parezca que la conexión está establecida, verás repetidas peticiones y aceptaciones de configuración en el archivo de log hasta que una de las dos partes cierra la conexión.

Esto ocurre normalmente en servidores con disco lentos que tienen problemas para gestionar eficientemente los puertos serie. También existen informes de problemas en conexiones mediante slip. La razó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ía activo en el puerto del servidor, el cliente ppp lo único que ve son sus propios paquetes "reflejados" por el servidor.

Una parte de la negociación LCP es establecer un número má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ía paquetes LCP, ve que el mismo "magic" vuelve en el paquete reflejado y lo da como no válido (envia NAK). Este todavía ve el paquete reflajado con NAK (lo que significa que el ppp debe cambiar su "magic"). Esto produce un enorme nú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úmero suficiente de negociaciones LCP y corta la conexión. Mientras tanto, el cliente, que ya no ve los paquetes reflejados, recibe sin problemas la desconexión del servidor y también cierra la conexión.

Esto puede ser resuelto permitiendo que el remoto inicie la negociación, poniendo la siguiente línea en el archivo ppp.conf:

          set openmode passive
        

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

          set openmode active 3
        

Esto le indica al ppp que sea pasivo durante 3 segundos, y despues comience a enviar peticiones LCP. Si el remoto envía peticiones durante este periodo, ppp responderá inmediatamente sin esperar los 3 segundos establecidos.

Existe actualmente un problema de implementación en ppp en la que no asocia las respuestas LCP, CCP & IPCP con sus peticiones originales. Como resultado, si una implementación ppp es más lenta durante 6 segundos que la remota, la remota enviará dos peticiones de configuración LCP adicionales. Esto es fatal.

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

Esto pasa hasta que una de las partes piensa que ya ha realizado suficientes reintentos y corta la conexión.

La mejor manera de evitar esto es configurar una de las partes de manera pasiva - que es, hacer que una de las partes espere a que la otra comience la negociación. Esto puede realizarse con el comando:

          
          set openmode passive
        

Se debe tener cuidado con esta opción. También se puede usar:

          
        set stopped N
        

para limitar el número de veces que ppp espera a que el remoto comience la negociación. Alternativamente, puedes user el comando:

          
          set openmode active N
        

donde N es el número de segundos que espera antes de empezar la negociación. Mira en el manual para más detalles.

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

          
          disable pred1
        

Cuando ejecutas el comando shell o !, ppp ejecuta un shell (o si has pasado argumentos, ppp ejecutará esos argumentos). Ppp esperará a que se complete el comando antes de continuar. Si intentas usar la conexión ppp mientras se ejecuta el comando, parecerá que la conexión se ha colgado. Esto es por que ppp está esperando a que se complete la ejecución del comando.

Si quieres ejecutar comandos como este, usa el comando !bg en su lugar. Esto ejecutará el comando en background, y ppp continúa sin problemas con la conexión.

No hay manera que ppp detecte automáticamente que una conexión directa se ha cortado. Es debido a las líneas que se usan en un cable serie null-modem. Cuando usamos este tipo de conexión, LQR debería estar siempre activada con el comando

          enable lqr
        

LQR es aceptado por defecto si es negociado por el remoto.

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

Para determinar la causa, usa la siguiente línea:

          set log +tcp/ip
        

Esto guardara todo el tráfico que pase a través de la conexión. La próxima vez que se realice una llamada no deseada, podrás ver la causa convenientemente guardada.

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ínea (esto no hará que los paquetes de DNS queden parados cuando la conexión está establecida):

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

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ón.

En el caso del DNS, deberías determinar que es lo que está intentando realizar esas consultas de DNS. Muchas veces, sendmail es el culpable. Debes asegurarte configurar el sendmail de manera que no realice ninguna consulta al DNS. Mira la sección Configuracion de correo para tener más detalles acerca de como crear una archivo propio de configuración de sendmail. También deberías añadir la siguiente línea en tu archivo .mc:

          define(`confDELIVERY_MODE', `d')dnl
        

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 archivo ppp.linup).

Sigo viendo los siguientes errores en el archivo de log:

          CCP: CcpSendConfigReq
          CCP: Received Terminate Ack (1) state = Req-Sent (6)
        

Esto es porque ppp está intentando negociar compresión Predictor1, y el remoto no quiere negociar ningún tipo de compresión. Estos mensajes son sin importancia, pero si quieres eliminarlos, puedes desactivar la compresión Predictor1 localmente:

          disable pred1
        

En la versión FreeBSD 2.2.2 y anteriores, había un problema en el driver tun que no permitía paquetes entrantes con un tamaño mayor que el MTU del interface. La recepción de un paquete mayor que el MTU resulta en un error IO que es logueado vía syslogd.

La especificación PPP dice que un MRU de 1500 siempre debería ser aceptada como mí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é enviando paquetes de 1500, haciendo que tu conexión se bloquee.

El problema puede solucionarse haciendo que el tamaño del MTU nunca sea inferior a 1500 bajo FreeBSD 2.2.2 y anteriores.

Para loguear todas las líneas de "conversación" de tu módem, debes activar la siguiente opción:

          set log +connect
        

Esto hará que ppp loguee todo hasta la última cadena "expect" pedida.

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

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

Aquí, tenemos nuestro CONNECT, enviamos nada, y esperamos un salto de línea, forzando al ppp que lea la respuesta del CONNECT.

PPP lee cada línea de los archivos de configuración para poder interpretar cadenas como set phone "123 456 789" correctamente. Para especificar un carácter ``"'', debes usar la contrabarra (``\'').

Cuando el inté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úmero correcto de escapes (contrabarras).

Si quieres enviar un caracter ``\'' a tu módem, necesitas hacer algo como:

          set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
        

resultando en la siguiente secuencia:

          ATZ
          OK
          AT\X
          OK
        

o

          set phone 1234567
          set dial "\"\" ATZ OK ATDT\\T"
        

resultando en la siguiente secuencia:

          ATZ
          OK
          ATDT1234567
        

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

          $ 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
        

Ahora tendrás instalada una versión "debuggable" de ppp. Tendrá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.

Ahora, cuando ppp recibe una violación de segmentación , creará un archivo core llamado ppp.core. A continuación , deberías hacer lo siguiente:

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

Toda esta información puede hacer posible diagnosticar el problema. Si estás familiarizado con gdb, puedes encontrar otras pistas como que causó el dump y las direcciones y valores de las variables más relevantes.

Este es un problema conocido cuando ppp está configurado para negociar una IP dinámica local con el remoto. Este problema ha sido solucionado en la última versión - busca en el man la palabra iface.

El problema era que cuando el programa inicial llama a 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ón. Si, como resultado de la asignación dinámica de IP, la dirección del interface es cambiada, el punto final del socket original será invalido. Los siguientes paquetes enviados al remoto normalmente serán descartados. Aun si no lo son, cualquier respuesta no será enrutada hacia la máquina de origen por que la dirección IP de la máquina de origen ha cambiado.

Hay varias maneras teóricas de solucionar este problema. Lo mejor sería que el remoto reasignase la misma IP si fuese posible :-) La versión actual de ppp hace esto, pero otras muchas implementaciones no.

El método más sencillo desde nuestra parte, serí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 libalias(3) y el parámetro -alias de ppp.

Otra alternativa (y probablemente la más eficaz) es implementar una llamada al sistema que cambie todos los sockets de una IP a otra. Ppp debería usar esta llamada para modificar los sockets de todos los programas existentes cuando una nueva dirección IP es negociada. La misma llamada de sistema podría ser usada para clientes dhcp cuando son forzados a rehacer sus sockets.

Una tercera opción es permitir que un interface se active sin IP. Los paquetes salientes tendrían un IP de 255.255.255.255 hasta que el primer SIOCAIFADDR ioctl este hecho. Esto permitirí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.

La razón por la que muchos de los juegos no funcionan es por que la máquina externa intentará abrir una conexión o enviar paquetes UDP (no solicitados) a la máquina interna. El software "alias" no sabe que esos paquetes debrín enviarse a la máquina interna.

Para que las cosas funcionen, asegúrate que la única cosa que está 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.

Cuando arrancas el software que no funciona, deberís ver paquetes que pasan a través del gateway. Cuando algo vuelve del exterior, será rechazado (ese es el problema). Apunta el número de puerto de esos paquetes y cierra el software que no funciona. Haz esto varias veces para comprobar si el número de puerto se repite. Si es así, la siguiente línea en el archivo de configuración del ppp /etc/ppp/ppp.conf hará que las cosas funcionen:

         alias port proto internalmachine:port port
       

donde "proto" puede ser "tcp" o "udp", "internalmachine" es la máquina a la que quieres que los paquetes sean enviados y "port" es el número de puerto de destino de los paquetes.

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

Si los números de puertos no se repiten, hay tres opciones más:

1) 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én prototipo). Esto usualmente supone leer ciertos paquetes salientes conocidos, identificando la instrucción que le indica a la máquina exterior que inicie una conexión con la máquina interna en un puerto específico (aleatorio) y configurar un "ruta" en la tabla de alias para que los paquetes siguientes sepan donde ir.

Esta es la solución más difícil, pero es la mejor y hará que el software funcione con múltiples máquinas.

2) Usar un proxy. La aplicación debe soportar socks5 por ejemplo, o (como en el caso del "cvsup") debería tener una opción "pasiva" que evita que el remoto intente abrir conexiones con la maquina local.

3) Redireccionar todo el tráfico a la máquina interna usando "alias addr". Esta es la solución más sencilla.

Todavía no, pero se podría hacer, si hay interés. En cada ejemplo, internal debe ser reemplazado por la dirección IP de la máquina que va a estar jugando.

• Quake

  alias port udp internal:6112 6112

  Alternativamente, quizás estés interesado en mirar en el www.battle.netsoporte de Quake a través de proxy">.

• Quake 2

  alias port udp internal:27901 27910

• Red Alert

  alias port udp internal:8675 8675

  alias port udp internal:5009 5009

• Half Life

  alias port udp internal:27005 27015

• PCAnywhere 8.0

  alias port udp internal:5632 5632

  alias port tcp internal:5631 5631

FCS significa Frame Check Sequence. Cada paquete ppp tiene un checksum añ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 show hdlc.

Si tu conexión es mala (o si tu driver serie está rechazando paquetes), verás errores FCS ocasionales. En general no tienes porque preocuparte de ellos. Si tienes un módem externo, asegúrate que el cable está correctamente aislado de interferencias - esto debería erradicar el problema.

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

Otra razón para ver muchos errores FCS puede ser que el remoto haya dejado de "hablar" PPP. Deberís activar el log así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ón, es posible terminar el ppp sin cortar la conexión usando el comando close clp (usando el comando term podrás conectar de nuevo con el shell de la máquina remota.

Si no hay nada en el log que indique por que se ha terminado la conexión, deberís preguntar al administrador del sistema remoto porqué ha terminado la sesión.

Si todo falla, envía toda la información que puedas, incluyendo los archivos de configuración, como arrancas el ppp, las partes relevantes del archivo de log y la salida del comando netstat -rn (antes y despues de la conexión) a la lista de distribución FreeBSD-questions@FreeBSD.org, a la lista de FreeBSD en castellano o al grupo de news comp.unix.bsd.FreeBSD.misc y alguien te ayudará a solucionar los problemas.