El IPCP se utiliza para negociar varios parámetros IP a la hora de configurar la conexión. Normalmente, cada extremo de comunicación puede enviar un Paquete de Petición de Configuración IPCP, indicando qué valores quiere cambiar de los que vienen predeterminados, y a qué valor. Tras la recepción, el extremo remoto inspecciona cada opción sucesivamente, y responde que la acepta, o la rechaza.
pppd le da gran control sobre qué opciones intentará negociar el IPCP. Puede ajustar esto a través de varias opciones en la línea de órdenes de las que hablamos a continuación.
Todos los interfaces IP requieren de direcciones IP asignadas a ellos; Un dispositivo PPP siempre tiene una dirección IP. El conjunto de protocolos PPP provee un mecanismo que permite la asignación automática de direcciones IP a interfaces PPP. Es posible para el programa PPP en un extremo del enlace punto a punto asignar una dirección IP al extremo opuesto para que la use, o que cada uno use la suya.
Algunos servidores PPP que sirven a muchos clientes asignan direcciones dinámicamente: las direcciones son asignadas a los sistemas sólo cuando llaman, y son reclamadas de nuevo una vez que se desconecta. Esto permite que el número de direcciones IP requeridas esté limitado al número de líneas conectadas. Mientras la limitación es conveniente para quienes gestionan los servidoresde marcado PPP, es a menudo menos conveniente para los usuarios que están intentando conectar. Ya discutimos la forma en la que los nombres de nodo son transformados en direccionnes IP mediante una base de datos en
. Para permitir que la gente se conecte a su nodo, ellos deben saber su dirección IP o el nombre del nodo asociado a ella. Si usted es usuario de un servicio PPP que le asigna una dirección IP de forma dinámica, este conocimiento es difícil sin permitir de alguna manera a la base de datos DNS que se actualice después de que le es asignada la dirección IP. Este tipo de sistemas existen, pero nosotros no los cubriremos en detalle aquí; en cambio, miraremos hacia una situación más preferible, la cual implica que sea capaz de utilizar la misma dirección IP cada vez que se establece su conexión de red. [1]
En el ejemplo anterior, hacíamos que
pppd llamase a c3po y estableciera una conexión IP. No nos preocupábamos de elegir una dirección IP particular en ninguno de los extremos de la conexión. En vez de ello, tomábamos la dirección de vlager como la dirección IP local, y dejábamos a c3po darse su propia dirección. El pppd soporta diferentes alternativas a esta aproximación.
Para pedir direcciones particulares, normalmente dé a
pppd la siguiente opción:
||
local_addr:
remote_addr ||
local_addr y
remote_addr pueden ser especificados tanto en notación de cuaternas numéricas o como nombres de nodo.[2] Esta opción hace a
pppd intentar usar la primera dirección como su propia dirección IP, y la segunda como la de su compañero. Si el compañero rechaza alguna de ellas durante la negociación IPCP, no se establecerá ninguna conexión IP.[3]
Si usted está llamando a un servidor y espera que éste le asigne una dirección IP, debe asegurarse de que
pppd no intenta negociar una por sí mismo. Para hacer esto, use la opción
noipdefault y deje la opción
local_addr en blanco. La opción
noipdefault evitará que
pppd intente usar la dirección IP asociada al nombre de ordenador como la dirección local.
Si sólo quiere establecer la dirección local, y aceptar cualquier dirección que utilice el compañero, simplemente deseche la parte
remote_addr. Por ejemplo, para hacer a vlager usar la dirección IP 130.83.4.27 en vez de la suya propia, le escribiría
130.83.4.27: en la línea de orden. De forma similar, para establecer la dirección remota únicamente, dejaría el campo de la
dir_local en blanco. Por omisión,
pppd utilizará entonces la dirección asociada al nombre de su ordenador.
Tras configurar el interfaz de red,
pppd preparará un encaminamiento que solamente le sirve para comunicarse con el otro extremo. Si el ordenador remoto está en una red de área local, seguramente usted deseará conectar también con los ordenadores que están "detrás" de él; para eso, se ha de configurar un encaminamiento de red adecuado.
Ya hemos visto antes que se puede pedir a
pppd que configure el encaminamiento predeterminado utilizando la opción
defaultroute. Esta opción es muy útil si el servidor PPP al que llama va a actuar como su pasarela a Internet.
El caso contrario, cuando su sistema actúa como una pasarela para un sólo ordenador, es también relativamente fácil de llevar a cabo. Por ejemplo, imagine a algún empleado de la Cervecera Virtual cuyo ordenador de casa se llama oneshot. Cuando esté conectando a vlager a través de PPP, él utiliza una dirección de la subred de la Cervecera. Podremos dar a
pppd del ordenador vlager la opción
proxyarp, que instalará una entrada proxy-ARP para el ordenador oneshot. Esto hará que oneshot sea automáticamente accesible desde todos los ordenadores de la Cervecera y la Vinatera.
De cualquier manera, las cosas no son siempre tan fáciles como esto, por ejemplo cuando intentamos unir dos redes de área local. Esto requiere normalmente el añadir una ruta de red especifica, porque estas redes tendrán ya sus propios encaminamientos por defecto. Por otra parte, el tener los dos extremos de comunicación utilizando la conexión PPP como encaminamiento por defecto generaría un ciclo sin fin, donde los paquetes con destinos desconocidos rebotarían entre los dos ordenadores hasta que su tiempo de vida (TTL) expirase.
Pongamos un ejemplo: suponga que la Cervecera Virtual abre una sucursal en alguna otra ciudad. La sucursal utiliza su propia red Ethernet utilizando el número de red IP 172.16.3.0, que es la subred 3 de la red de clase B de la Cervecera. Quieren conectarse a la red Ethernet principal de la Cervecera a través de PPP para actualizar las bases de datos de clientes, etc. De nuevo, vlager actuará como pasarela; la otra máquina se llama vbourbon y tiene una dirección IP de 172.16.3.1. Esta red está ilustrada en
Figura A-2 en
.
Cuando vbourbon conecta a vlager, hará que el punto de encaminamiento predeterminado sea vlager, como es habitual. En vlager, de todas formas, tendremos que instalar un encaminamiento de red para la subred 3 que vaya a través de vbourbon. Podriamos hacer esto manualmente usando la orden
route después de que el enlace PPP sea establecido, pero esta no es una solución muy práctica. Afortunadamente, podemos configurar la ruta automáticamente utilizando una característica de
pppd de la que no hemos hablado hasta ahora - la orden
ip-up. Es un script de shell situado en
/etc/ppp que se ejecuta después de que el interfaz PPP ha sido configurado. Cuando está presente, se le llama con los siguientes parámetros:
|| ip-up
interface dispositivo velocidad dir_local dir_remota ||
La tabla siguiente resume el significado de cada uno de los argumentos (en la primera columna, se muestra el número usado por el script de shell para referirse a cada argumento):
|| Argumento || Nombre || Propósito ||
|| $1 ||
interfaz || Interfaz de red usado, e.g.,
ppp0 ||
|| $2 ||
dispositivo || dispositivo es la ruta al dispositivo serie utilizado,( 
/dev/tty si se utiliza la salida y entrada estándar) ||
|| $3 ||
velocidad || La velocidad del dispositivo en bits por segundo. ||
|| $4 ||
dir_local || La dirección IP del extremo local del enlace en notación de cuarteto. ||
|| $5 ||
dir_remota || La dirección IP del extremo remoto de la conexión ||
En nuestro caso, el script
ip-up puede contener el siguiente fragmento de código:[4]
|| #!/bin/sh
case $5 in
172.16.3.1) # este es vbourbon
route add -net 172.16.3.0 gw 172.16.3.1;;
...
esac
exit 0 ||
De una forma análoga,
/etc/ppp/ip-down se utiliza para deshacer todas las acciones de
ip-up después de que la conexión PPP ha sido cortada. Asi en nuestro script
/etc/ppp/ip-down tendremos una orden
route que elimine la ruta que creamos con el script
/etc/ppp/ip-up.
A pesar de todo, la tabla de encaminamiento aún no está completa. Hemos configurado las entradas de la tabla de encaminamiento para los dos ordenadores con PPP, pero hasta ahora, todos los demás ordenadores de las dos redes no saben nada sobre la conexión PPP. Esto no es un gran problema si todos los ordenadores de la sucursal tienen su encaminamiento predeterminado encaminado a vbourbon, y todos los ordenadores de la Cervecera encaminan hacia vlager por omisión. Si éste no fuera el caso, su única posibilidad normalmente será usar un demonio de encaminamiento como
gated. Tras crear el encaminamiento de la red en vlager, el demonio de encaminamiento pasará el nuevo encaminamiento a todos los ordenadores de las redes dependientes de ésta.
Notas
|| [1] || Más información sobre mecanismos de asignación dinámica a nodos puede encontrarse aquí: http://www.dynip.com/ y http://www.justlinux.com/dynamic_dns.html. ||
|| [2] || Usar nombres de dominio en esta opción tiene consecuencias en la autentificación CHAP. Por favor, consulte la sección
” más adelante en este mismo capítulo. ||
|| [3] || Las opciones
ipcp-accept-local y
ipcp-accept-remote indican a
pppd aceptar la dirección local y remota ofrecidas por el PPP remoto, incluso si usted a provisto de alguna en su configuración. Si estas opciones no son configuradas, su
pppd rechazará cualquier intento de negociación de las direcciones IP usadas. ||
|| [4] || Si quisieramos tener rutas creadas para otros sitios cuando se conecten, tendriamos que añadir entradas apropiadas para permitir a aquellos
... que aparecieran en el ejemplo. ||
