| Depto. Automática y computación Universidad Pública de Navarra |
Daniel Morató daniel.morato@unavarra.es |
Para probar las configuraciones de redes empleando routers CISCO necesitaremos PCs que colocaremos en las diferentes redes. Por ello en esta práctica repasaremos los comandos y ficheros básicos para configurar un interfaz de red Ethernet con IP en Linux y conectarlo a una LAN con un router de acceso. Emplearemos en esta LAN diferentes elementos típicos de redes Ethernet. También veremos cómo hacer que un PC con Linux actúe como un router y juntaremos el uso de modems de la práctica anterior con la configuración IP para ser capaces de hacer que un usuario que se conecta por módem a un PC que está en una LAN pueda comunicarse con otros PCs de esa LAN e incluso aprovechar su acceso a Internet (funcionamiento análogo al de un proveedor de servicio de Internet).
En los ordenadores dispuestos para la realización de estas prácticas se han creado dos usuarios para el empleo por los grupos de prácticas: el usuario guest (password invitado) y el usuario root (password telemat). El primero de ellos es un usuario normal que se deberá emplear en todas aquellas tareas que no requieran privilegios de superusuario. El segundo (root) es el superusuario de la máquina, cuando se esté trabajando como superusuario se debe tener mucho cuidado para no borrar o estropear ficheros accidentalmente. Si va a editar un fichero del sistema haga antes una copia de seguridad (por ejemplo con el mismo nombre añadiendo .bak).
Para mayor comodidad empleando las X edite el contenido del fichero wm_style que hay en el HOME de la cuenta con la que vaya a lanzar las X y ponga en ese fichero AfterStep (borre lo que hubiera antes).
Cree un directorio dentro del HOME del usuario guest (/home/guest) y otro dentro del HOME del usaurio root con nombre grupoXY donde XY es su número de grupo de prácticas. No cree o edite ningún fichero fuera de esos directorios salvo que sea necesario. Al finalizar la sesión de prácticas borre todos los ficheros nuevos que haya creado. Tenga en cuenta que los discos duros de los ordenadores están casi llenos.
Cree un fichero de texto en el directorio /home/guest con nombre dia-mes-grupoXY y dentro del fichero los nombres de las personas que han estado trabajando en ese PC ese día.
Si quiere conservar cualquier fichero entre sesiones guárdelo en un disquete.
Conecte su ordenador a su concentrador utilizando un cable recto (no cruzado). Lea la página del manual del comando ifconfig. Este comando permite configurar el interfaz de red de la máquina. Configure el mismo para que su dirección IP sea 10.0.0.grupo donde debe substituir grupo por el número de su grupo de prácticas. Emplee como máscara de red 255.255.255.0 (Nota: el nombre de su interfaz de red es eth0). Compruebe que puede hacer ping a su propia dirección IP. Averigüe la dirección MAC de su tarjeta.
Recuerde el funcionamiento del protocolo ARP: cuando un ordenador desea mandar un paquete IP a otra máquina que se encuentre en la misma red Ethernet necesita saber la dirección MAC de la tarjeta de esa máquina para poder enviarle una trama Ethernet con ese paquete IP. Para averiguar esta dirección el ordenador envía una trama Ethernet del protocolo ARP a esa red, dirigida a la MAC de broadcast (ff:ff:ff:ff:ff:ff) en cuyos datos está preguntando por la MAC del interfaz que tiene esa IP. Todas las máquinas de la red leerán esa trama y la que tenga esa dirección IP contestará, indicando así su dirección física. Vamos a ver estos paquetes empleando tcpdump.
El programa tcpdump nos permite observar los paquetes de red que son recibidos o transmitidos por un interfaz de red. Para ello lee del interfaz de red y muestra de una forma sencilla de entender el contenido principal de las cabeceras del paquete. Además, si el interfaz está en modo promiscuo (vea ifconfig) permite ver también todos aquellos paquetes que circulen por el dominio de colisión al que se esté conectado. Tiene bastantes opciones, entre ellas se pueden especificar filtros para que solo muestre los paquetes que cumplan ciertas condiciones (por ejemplo ser paquetes TCP dirigidos al puerto 80) o indicar el interfaz por el que leer. Opciones útiles son por ejemplo la combinación -nl, la opción l hace que los paquetes aparezcan por pantalla nada más recibirse y n que las direcciones (o los puertos) no se conviertan en nombres DNS (o en nombres del servicio).
Conéctese al mismo concentrador que sus compañeros de mesa. Antes de intentar ninguna comunicación con el ordenador de sus compañeros consulte la caché ARP de su ordenador y del de sus compañeros con el comando arp. En ella podrá ver las relaciones DirecciónIP-DirecciónMAC que su máquina conoce. Ejecute ahora el programa tcpdump en un terminal. A continuación haga ping a la máquina de sus compañeros. Estudie los paquetes que muestra tcpdump. Vea cómo han cambiado las cachés ARP de ambas máquinas.
Ahora vamos a crear una LAN más grande. Podríamos interconectar los hubs de cada grupo de prácticas empleando un cable de par trenzado pero lo que vamos a hacer es crear pequeños backbones empleando el puerto 10BASE2 que tienen estos hubs. Empleando el cable coaxial que les puede prestar el profesor de prácticas creen una LAN Ethernet en la que su hub se conecte con el de sus compañeros de mesa y con los dos grupos de prácticas de la mesa de enfrente.
Backbone 10BASE2
Pruebe que puede hacer pings a todos los PC conectados ahora en su LAN. ¿Cuáles son sus direcciones MAC?
A continuación vamos a juntar los tres segmentos Ethernet que se habrán creado en el laboratorio. Podríamos crear un gran bus Ethernet 10BASE2 pero para evitar posibles problemas (si se estropea un cable se corta todo el bus y es más complicado encontrar el punto de fallo, además no tenemos muchos cables largos :-) vamos a juntar los segmentos empleando par trenzado y puertos de algunos hubs. Realicen la disposición que ven en la figura siguiente. Para ello empleen cables rectos y el puerto de su hub que está cruzado o empleen cables cruzados y puertos normales. A continuación pruebe que puede hacer pings a PCs en todos los segmentos.
Finalmente empleamos un repetidor para unir uno de los buses con el conmutador Ethernet al cual está conectado el router de salida. Este repetidor tiene un puerto 10BASE2 y otro 10BASE-T. Con uno lo conectamos a uno de los buses y con el otro a uno de los puntos de las mesas que van a un conmutador Ethernet dispuesto para estas prácticas. Los puntos activados en las mesas para ir al conmutador son los siguientes (uno para cada grupo de prácticas): 8-1, 8-4, 8-6, 8-8, 8-9, 8-11, 9-1, 9-4, 9-5, 9-8, 9-9 y 9-10
Una vez que está unida la red al conmutador prueben que pueden hacerle ping al router que está conectado al mismo. Su IP es 10.0.0.254
Backbones 10BASE2. Disposición física
Conectado al conmutador
Checkpoint general
Se les contabilizará un checkpoint cuando esta disposición esté terminada y todos puedan hacer ping al router.
Ahora mismo nuestra máquina ya puede comunicarse con cualquier otra que se encuentre en la misma LAN. Para que pueda conectarse a otras LANs hemos de indicarle cuál es el router que debe emplear para salir de ella (¡y ha de haber un router de salida en nuestra LAN!). Para ello vamos a introducir lo que se llama una ruta por defecto, es decir, una ruta o regla que indica a dónde enviar todo el tráfico IP que no se sabe hacer llegar a su destino de otra forma. En nuestro caso el único tráfico que sabemos hacer llegar a su destino es el dirigido a máquinas de nuestra misma red.
Introduzca la ruta empleando el comando route. Consulte el manual del mismo. La página del manual trae ejemplos sobre cómo añadir rutas al PC. Añada la ruta por defecto al router 10.0.0.254
Por simplicidad vamos a desmontar la red con buses de Thinnet. Conectamos ahora el puerto de la tarjeta de red de nuestro PC al punto de red que hay en la mesa (anteriormente se han mencionado los puntos activos). Todos estos puntos van al conmutador Ethernet en el cual está conectado también el router que da acceso al exterior. Elija correctamente cómo hacer la conexión (¿Cable recto o cruzado?)
PCs conectados en una LAN con un router de acceso
Compruebe ahora que puede hacer ping al interfaz del router (10.0.0.254) y a la máquina 1.1.1.254 que es una de las de la Red del laboratorio tal y como aparece en la figura.
Ahora configuraremos el servidor de DNS que usará nuestro PC. Para ello añada al fichero /etc/resolv.conf una línea que ponga nameserver 1.1.1.253 y otra que ponga nameserver 1.1.1.254
Abra un navegador (mozilla) y configure (Preferencias Avanzadas) la dirección 1.1.1.254 como Proxy de SOCKS5 por el puerto 1080. Ahora ya puede probar a navegar por la web en Internet.
Así como el funcionamiento de utilidades de configuración como ifconfig es bastante parecido entre diferentes sistemas operativos de tipo UNIX, la forma de configurar la máquina en el arranque suele variar, incluso entre diferentes versiones del mismo sistema operativo. En general todos estos sistemas operativos comienzan arrancando el programa init para el cual, en su fichero de configuración /etc/inittab se indica algún programa que ejecutar para realizar la configuración del sistema. Este programa suele ser un script que va llamando a otros hasta completar la configuración. Vamos a ver cuáles son los ficheros de configuración más típicos en un Linux RedHat que son leídos por esos scripts en el arranque para configurar el/los interfaces.
En el directorio /etc/sysconfig/network-scripts se deben colocar ficheros que contienen la configuración de cada uno de los interfaces de red. Estos ficheros son leídos por un script en el arranque el cual configura los interfaces con ifconfig empleando la configuración que se indique en el fichero.
El nombre del fichero debe ser ifcfg-device, por ejemplo ifcfg-eth0. Dentro de él debemos dar valor a unas variables como si fuera un script de sh. Algunas variables son:
En el mismo directorio hay dos scripts ifup e ifdown que nos permiten activar y desactivar un interfaz de red con la configuración indicada en el fichero anterior. Se les debe pasar el nombre del interfaz.
Parámetros de configuración que no son por interfaz suelen ir en el fichero /etc/sysconfig/network Algunas variables en él son:
Checkpoint
Muestre al responsable de prácticas que al arrancar su PC la red está configurada como se indicó en el apartado anterior (IP 10.0.0.grupo, máscara 255.255.255.0, router por defecto 10.0.0.254)
Existen protocolos para que una máquina obtenga su configuración IP de un servidor en la red. Uno de estos protocolos es DHCP. Pruebe a activar la configuración automática mediante DHCP. Hay conectado a la LAN un PC que tiene corriendo un servidor de DHCP. En el fichero de configuración del interfaz (ifcfg-eth0) ponga el valor dhcp a la variable BOOTPROTO y no configure la IP. Levante el interfaz y observe cómo obtiene la configuración (puede ver los paquetes con un tcpdump).
Nota: DHCP es una extensión de un protocolo más antiguo llamado BOOTP.
A continuación vamos a aplicar lo aprendido en la práctica anterior sobre el empleo de modems y lo que hemos visto de conexión a LANs para configurar un PC para hacer de servidor de acceso a Internet para un usuario que se conecte por módem.
Para esta práctica necesitará de nuevo la amable colaboración de sus compañeros de mesa.
Desactiven el interfaz Ethernet de uno de los PCs (ifconfig down). Este PC hará las veces del usuario que se conecta por módem y lo llamaremos el cliente. Prepare los scripts que necesite para que se conecte al servidor por módem (con o sin autentificación, no tiene mucha importancia, la que prefiera).
El otro PC hará las veces del servidor de acceso del ISP. Para ello debe estar conectado a la red del laboratorio a través de nuestro router de acceso. Digamos que nuestra pequeña red junto con la red del laboratorio y la de la propia universidad hacen las funciones de la red interna del ISP. Además del interfaz Ethernet deberemos conectarle un módem y preparalo para aceptar la llamada igual que hicimos en la práctica anterior.
Establezca un enlace PPP sobre modems entre los dos PCs. Emplee para ellos las direcciones IP 10.0.0.grupo*2+100 y 10.0.0.grupo*2+101 para cada extremo, donde el grupo es el del que pone el PC para hacer de servidor. Es decir, si ustedes son los grupos 04 y 12 y seleccionan el ordenador del grupo 04 como servidor, entonces éste deberá tener la dirección IP 10.0.0.4 en su interfaz Ethernet, el interfaz Ethernet del otro PC debe estar bajado (down) y las IPs de ambos extremos del anlace PPP por módem pueden ser 10.0.0.108:10.0.0.109 (todo esto por mantener una cierta uniformidad entre los diferentes grupos de prácticas)
Llegado este punto deberíamos ser capaces de enviar tráfico IP entre los dos PCs y desde el servidor a Internet pero seguramente no podamos llegar a la red del laboratorio directamente desde el cliente (pruebe a hacer un ping a 1.1.1.254 desde el cliente). Como buenos usuarios de UNIX lo que podríamos hacer es un telnet desde el cliente al servidor y desde ahí utilizar el acceso que éste tiene al resto de la red (pruébelo). Sin embargo, lo que queremos es que el cliente pueda comunicarse con máquinas de Internet con normalidad.
¿Qué es lo que está haciendo el cliente cuando tiene un paquete IP que se dirige a 1.1.1.254? Consulte su tabla de rutas con el comando route para contestar a la pregunta.
Añada una ruta por defecto al cliente con el servidor (la IP de su interfaz PPP) como siguiente salto. Ahora el cliente envía al servidor todos los paquetes que no pertenecen a ninguna de las redes a las que está conectado. El programa pppd permite que al crear un nuevo enlace serie se añada automáticamente una ruta por defecto por ese enlace punto-a-punto. Para ello tendríamos que lanzarlo con la opción defaultroute en el cliente.
Pruebe de nuevo el ping al laboratorio. Verá que no funciona. Mientras la aplicación ping se está ejecutando en el cliente lance un tcpdump en el mismo para que le muestre los paquetes ICMP que envía por el interfaz PPP. A continuación coloque un tcpdump en el servidor que muestre los paquetes por el interfaz PPP y otro para que muestre los paquetes por el interfaz Ethernet. Verá que el servidor recibe los paquetes ICMP del cliente pero no los reenvía. ¡Le estamos entregando los paquetes al servidor pero él no sabe qué hacer con ellos! Para que esto funcione el servidor debe reenviar los paquete por su otro interfaz, es decir, debe actuar como un router...
El servidor tiene dos interfaces IP en funcionamiento: el interfaz eth0 con el que se conecta a la red del laboratorio y a través de ella a Internet y el interfaz ppp0 con el que se conecta con el cliente.
Tal y como está, se dice que este PC está multihomed porque tiene interfaces en redes diferentes (la red en el interfaz ppp0 es un caso degenerado de red que contiene tan solo a las dos direcciones de los dos extremos). Ahora mismo, si recibe por uno de sus interfaces un paquete que se dirige a una IP destino que no es ninguna de las suyas lo descarta. Para que funcione como un router tenemos que convencerle de que cuando reciba un paquete con esas características no lo tire sino que lo reenvíe aplicando las reglas que tiene en su tabla de rutas. Esta funcionalidad es lo que se conoce como IP forwarding o reenvío de paquetes IP. Si el kernel tiene compilada esta funcionalidad (y en nuestro caso la tiene) podemos activarla sin más que escribir un 1 en el fichero /proc/sys/net/ipv4/ip_forward (recuerde que los ficheros en /proc en realidad hacen referencias a variables dentro del kernel)
[1]% echo "1" > /proc/sys/net/ipv4/ip_forward
Con solo hacer ésto el PC empezará a reenviar paquetes. También se podría activar esta funcionalidad para que reenviara paquetes solo entre ciertos interfaces, lo cual sería útil si tuviéramos más de dos y no quisiéramos que reenviará entre todos ellos (ficheros /proc/sys/net/ipv4/conf/*/forwarding).
Y ya está. El PC ya se comporta como un router. Si tuviera más interfaces (Ethernet, PPP, WLAN, etc) podría reenviar tráfico entre todos ellos. De hecho esta es una solución bastante barata para tener un router. Coloque ahora un tcpdump en el servidor y observe que sí reenvía los paquetes ICMP.
Una vez que el PC funciona como un router debemos mirar con más cuidado el contenido de su tabla de rutas dado que ahora no solo la empleará para todos los paquetes que él quiera enviar sino también para todos los que decida reenviar.
No, aún no funciona. Compruébelo haciendo ping a la IP 1.1.1.254.
Cuando el cliente envía un paquete IP a esa máquina se lo entrega al servidor, éste comprueba que no es para él, busca en la tabla de rutas y lo reenvía por su ruta por defecto que va al router de acceso. Si mirásemos el tráfico que llega al router de acceso veríamos que el paquete ICMP del ping está llegando a él. La tabla de rutas del router de acceso es algo así (el router es un CISCO y aún no hemos visto cómo muestra su tabla así que emplearemos una representación tradicional de la tabla):
Red_destino Mascara Siguiente_salto Interfaz 1.1.1.0 255.255.255.0 - interfaz_0 10.0.0.0 255.255.255.0 - interfaz_1
Donde con el interfaz_0 se conecta a la red del laboratorio y con el interfaz_1 a nuestra pequeña red. No tiene importancia que no tenga ruta por defecto, ya veremos en otra práctica que el laboratorio está conectado a Internet a través de un Proxy. El router reenvía el ICMP directamente al destino final por su interfaz_0 dado que el destino del paquete IP se encuentra precisamente en esa Red. El paquete llega correctamente al destino, el problema se encuentra en el camino inverso, es el paquete de respuesta al ICMP Echo Request el que no llega al cliente.
Si pensamos en el paquete de respuesta de nuestro ping lo enviará la máquina 1.1.1.254 con IP destino la de nuestro cliente, que será por ejemplo 10.0.0.108 Consultando su tabla de rutas (la del host 1.1.1.254) esta IP no pertenece a su red y él tiene como ruta por defecto la IP del interfaz_0 de nuestro router de acceso así que se lo entregará a él. Cuando el paquete llega al router de acceso éste consulta su tabla de rutas para ver que la máquina con esa IP se encuentra en la misma red en la que él está conectado con el interfaz_1, es decir, tal y como él lo entiende esa máquina está en la misma red que él y por lo tanto puede llegar a ella sin pasar por ningún otro router, ¡pero esto es mentira! Como la red es una Ethernet el router hará un ARP en esa red para averiguar la dirección MAC de la máquina que tiene la dirección IP 10.0.0.108 Este ARP es una trama Ethernet dirigida a la MAC de broadcast ff:ff:ff:ff:ff:ff que todos los PCs de nuestra red leerán pero como ninguno de ellos tiene configurada esa IP ninguno responderá, con lo que el router no sabrá a qué dirección MAC enviar la trama con el paquete IP y se verá obligado a descartarlo.
Falla el ARP del router
Coloque un tcpdump en el servidor que muestre los paquetes ARP en la red Ethernet mientras está haciendo ping.
¿Cómo se soluciona esto? Primero pensemos en el origen del problema. El problema se da porque el router de acceso piensa que nuestros clientes están conectados a la misma Ethernet que él cuando esto no es cierto. Llega a esta conclusión porque las direcciones IP que les hemos asignado pertenecen a esa red a la que él esta conectado. Una forma de resolver el problema sería asignar a los enlaces punto-a-punto direcciones en otras redes, diferente para cada cliente que acceda a través de un servidor diferente. Entonces, para que el router sepa llegar a ellos deberíamos añadirle rutas a su tabla de forma que sepa que para llegar a esas redes en las que están los clientes debe reenviar los paquetes a los respectivos servidores. Es decir, una ruta por cada servidor.
Diseñe en papel esta solución, en ella asigne una red diferente a su enlace PPP y decida qué ruta debería añadir al router de acceso para que le llegaran al servidor los paquetes que debe reenviar al cliente.
Aunque esta solución funciona introduce muchas rutas en el router de acceso. La forma tradicional de resolver esta situación es mediante lo que se llama Proxy ARP o el ARP Hack. Si recordamos, el problema venía porque el router de acceso hacía ARP en nuestra red y nadie contestaba porque ninguno de los servidores tenía configurada esa IP (hace ARP por la IP de un cliente). El hack está en hacer que el servidor al que está conectado ese cliente en cuestión responda a ese ARP diciéndole su propia dirección MAC. Con esto el router creerá que la máquina con la IP del cliente tiene de dirección MAC la del interfaz Ethernet del servidor. Enviará la trama y el interfaz Ethernet del servidor la recogerá. Ahora el servidor tiene un paquete IP dirigido a la IP del cliente, ¿qué hará con él? Reenviárselo dado que está actuando como un router y sabe que se llega a esa IP destino por el enlace punto-a-punto que tiene con ella.
¿Cómo se configura en el servidor que haga de Proxy ARP en favor del cliente? Introduciendo en su cache de ARP una entrada especial. Consulte en el manual del comando arp cómo introducir manualmente una entrada de este tipo en el servidor que haga que su interfaz Ethernet conteste con su MAC a ARPs que preguntan por la IP del cliente. Detenga el ping para que pueda ver los siguientes paquetes con calma e introduzca la entrada de proxy ARP. Coloque de nuevo un tcpdump en el servidor para ver los paquetes en la red Ethernet. Vuelva a lanzar el ping y verá el ARP del router y la respuesta del servidor.
Consulte de nuevo la página del manual de pppd, la opción proxyarp sirve precisamente para que automáticamente al configurar el interfaz PPP se introduzca una entrada de Proxy ARP de este tipo en favor del otro extremo del enlace PPP.
Nuestro servidor contesta al ARP del router
El paquete que el router quería entregar al cliente llega, reenviado por el servidor
Checkpoint
Muestre al responsable de prácticas que el cliente puede navegar por internet
En esta prática hemos visto cómo crear una red Ethernet, el funcionamiento de ARP y todo lo necesario para configurar IP en interfaces Ethernet en Linux, lo cual necesitaremos en prácticas posteriores. También se ha visto un ejemplo de cómo crear un ISP sencillo que da acceso por modem a usuarios.
En las próximas prácticas empezaremos a emplear routers comerciales Cisco y los PCs servirán normalmente como hosts en las redes y para configurarlos.
Intente configurar su servidor de acceso por módem para que conteste automáticamente a la llamada sin tener que lanzar nosotros el pppd en línea de comandos. Estudie para ello cómo colocar un programa que lance init (vea el manual del fichero inittab) y emplee el programa mgetty para responder a la llamada y lanzar el pppd (vea el manual del mgetty).
El pppd tiene una opción para realizar la llamada solo cuando haya tráfico IP que se deba cursar por el enlace y otra para desactivar el enlace si durante cierto tiempo no hay tráfico. Busque y pruebe estas opciones. Intente configurarlo para que llame cuando haya tráfico y que cuelgue si durante un minuto no hubo ningún paquete por el enlace. ¿Qué utilidades puede tener esto?
| Depto. Automática y computación Universidad Pública de Navarra |
Daniel Morató daniel.morato@unavarra.es |