Redes Linux Con Tcpip

Redes Linux conTCP/IP
Pat Eyler

Prentice Hall

----

" .' . - . - .

Guia Avanzada Redes Linux con TCP/IP

Pat Eyler

Traducci6n:

Traducciones Vox Populi, S.L.

Prentice Hall

----

Madrid - Mexico - Santale de Bogota - Buenos Aires - Caracas - Lima Montevideo - San Juan - San Jose - Santiago

Sao Paulo - White Plains

/ Datos de catalogaci6n bibliografica

Formato 170 X 240

Paginas: 432

PAT EVUR

GUtA AVANZADA REDES LlNUX CON TCP/IP PEARSON EDUCACI6N, S.A., Madrid, 2001

ISBN: 84-205-3156-1 Materia: Informatica 681.3

Pat Eyler

GUIA AVANZADA REDES LINUX CON TCP/IP

No esta pennitida la reproducci6n total 0 parcial de esta obra ni su tratarniento 0 transmisi6n por cualquier medio 0 rnetodo sin autorizaci6n escrita de la Editorial.

Traducido de: Networking Linux A Practical Guide to TCP/IP Copyright © 2001 by New Riders Publishing

ISBN 0-7357-1031-7

DERECHOS RESERVADOS

© 2001 respecto a la primera edici6n en espafiol por:

PEARSON EDUCACI6N, S.A. Nunez de Balboa, 120

28006 Madrid

ISBN: 84-205-3156-1

Dep6sito legal: M. 28.419-2001

PRENTICE HALL es un sello editorial autorizado de PEARSON EDUCACI6N

Editores de la edici6n en espafiol: Alejandro Dominguez, Felix Fuentes y Eva Marfa L6pez Cubierta: Mario Guindel y Yann Boix

Equipo de producci6n: Jose Antonio Clares y Tini Cardoso Composici6n: Claroscuro Servicio Grafico, S. L.

Impreso por: Imprenta Fareso, S. A.

IMPRESO EN ESPANA - PRINTED IN SPAIN

Este libro ha sido impreso con papel y tintas ecol6gicos

indice de contenido

Introduccion

xv

Profogo a una guia practica .

Protocolos en capas: dcscripcion e historia TCP/Ip

TCp/lp en accion: una narrativa . RFC.

TCp/lp Y l.inux

Problemas de la capa fisica .

2 i "i H <)

II

2 Protocolos de la capa de enlace .

PPP. Ethernet. PPPoE

ARI' y RARp YlTl) .

I~ 1-:' 1<) 22 2H 52

3 Protocolos de la capa de red .

Dirccciones II' .

Subrcdcs y superredes . Encaminamiento

liltrado de paquercs .

Traduccion de direcciones de red ..

II"., .

33 55 5(, iO i"i 17 ·j7

4

Protocolos de la capa de transporte Pucrtos y sockets

Pucrtos utilizados normalmente

l~:p .

lIDP 1<::\1P .

5 Protocolos de la capa de aplicaci6n .

RIP.

77

TITP 11'1'1'1'

HI H()

VI indice de contenido

II UnUZACI6N EFICIENTE DE LOS PROTOCOLOS

6 Un patron de solucion de problemas 99

Paso 1: describir los sintomas claramente 100

Paso 2: comprender el entorno 103

Paso 3: enumerar hipotesis 105

Paso 4: priorizar las hipotesis y reducir el enfoque 106

Paso 5: crear un plan de ataque 108

Paso 6: seguir el plan................................................................................... 109

Paso 7: comprobar los resultados................................................................ 110

Paso 8: aplicar los resultados de las pruebas a las hipotesis 111

Paso 9: repetir 10 que sea necesario 111

Dos historias de solucion de problemas..................................................... 113

7 Antes de que las cosas se estropeen, construccion de una base 117

Por que son importantes las bases 117

lQue es una base? 119

lComo crear una base? 122

Como mantener la base actualizada 128

Donde encaja la revision en todo esto 129

8 En el momento, estudios de casos .. 131

La red 131

La gente 131

Los estudios de casos 132

III HERRAMIENTAS PARA NUESTRO EQUIPO DE HERRAMIENTAS

9 Herramientas de resoluclon de problemas 145

ping 145

traceroute 150

arp............................................................................................................... 151

ngrep........................................................................................................... 153

10 Herramientas de revision 159

Ethereal 159

mon............................................................................................................ 171

11 Herramientas de seguridad '" 177

nmap 177

Nessus 182

iptables 191

Xinetd 199

tcp wrappers 205

OPIE 207

A RFC-1122.................................................................................................... 211

Requisitos de los hosts de Internet: capas de comunicacion 211

Tabla de contenidos 212

1. Introduccion 215

2. Capa de enlace 227

3. Protocolos de la capa de Internet 233

4. Protocolos de transporte...................................................................... 276

5. Referencias 306

B Requisitos para los hosts de Internet, aplicacion y soporte........................ 311

Estado de esta memoria 311

indice de contenido VII

Resumen .

Tabla de contcnidos . I. Introduccion .

2. Tcmas generales.

5. lngrcso remote, protocolo de Telnet . ·l. Transferencia de archives ..

'i. Correo ck-crronico, SMTP y RFC-H22 ..

c

Licericia de publicaci6n abierta .

399

indice alfabetico

Sobre el autor

Pat l.vk-r llcva trahajando con '1'<:1'/11' \' con l :\iIX desdt' I <)HH v (on I.inux dt'stlt' 1<)<)5, Iia trab.ijado como analista. adrninist rador c ingcnitTO de rcdt,s para Bocing ) Amcriu-ch Tamhicn ha cst.ido un ticmpo como adminixt rador de sistemas en Philips v Fidl'lity. Ita ofn-cido cursox sohn- administracion de sistcmas y sohrt' rnlt's para eI Anurican Research (;roup y para l'I Ejercito de Estados lnidos. ,\Ias recielltt'lllt'lltc sc ha vixro cnvuclto en cl soportc del corucrcio ck-ctronico y l'I dcvarrollo web para comp.uuas "punto.corn" y "clicks and I//()/'/(//'''

Pat ha escrito uunbicn material sobrc Linu x-Lni x. guioncs shell y redt's para cmpn-sas. grupos de usuaries y para cl publico en general. Algunos de sus mcjorcs trabajos han aparccido en la l.inux Gazcuc. Pat ha diseIlado \' adrninivtrado LAN) \VAN COil soportc para todo, desdr pcqucnas oficinas hasta rcdc-, de campus multiplc Su red favorita est;i en casa, donck: esta muv ocupado cnscuando a sus hijos pcqUeI10S a utilizar l.inux en lugar de cualquier otro sistema opcrauvo.

Pat utiliza l'I ticrnpo en que no csta trabajando en aspectos tccnicos en cstar con su familia. Le gusta viajar, leer y cocinar. EI y su familia son micmbros activos de la Iglesia de jcsucristo de los Santos de los l'Itimos Dras.

Sobre los revisores tecnicos

Estos n-visorc-, hall cont rrb uido COil xu considcrabh- cxpcricnci« pr.utica en todo vl proccso dc desarrollo de Guia avanzada Redes Linux con Tep/IP. Micnt ra» sc CSlTihla eI lihro, cstos ck-dicados protcsion.rlc« rcvisah.m todo d m.ucrtal CIl 10 quc rl'spccta al conu-nido tvcnico. la org.uuzacion \ cl tlujo. Su Informacion Iu« crrt ica a la horn de ascgurar quc Guia avanzada Rcdes Linux con Tep/IP Sl' ajust.rha a las Ilcccsidadcs del lector rcl(:rl'lltl's a intormacion tccllica de la maxima calidad,

Ivan ,\IcDollagh llcva prograrnando mas dc 2() ;1I10S \ l'S cntc-r.uucntc autodid.ura.

Sl' cn.uuoro dc las compuradora-, en d colcgio v aprcndio a programar en BASI(: ui ilizalldo tarjctas pcrtoradas. Subsccucntcmcntc. hall tU\O much.i-, oportunidadcs para t rabujar en t icrnpo real ut ilizando micro computadoras PDP \ \AX \ xu inu-re-s en los sistemas opcrauvos l'slilo ":'\IIX ha permanccldo dcsde cruoncc-.

101 irucrc« de Ivan en la programacion. part icularrncntc ell Ia prograrnacion d« sistcmas. Ie llcvo incvitahlcuu-ntc a (;:\T-Linux haec unos cu.uro ailos v ha ut iliz.ido. program ado v prornovido avidamcnu- (;:--';1 -Linu x ell todas las oportunidadcs que ha tcuido Actualmcntc trabaja a ticmpo cornplcto como vcndcdor en la industria del tabaco y a ticmpo parcial como n-visor u-cnu-o de lihros de Linu x

Actualmcntc ut iliza la distribucion l.inux I)l'biall-(;:--';' vha ut ilivado tarnhicn Red l l.u v Caldera. adcrnas de otras. Rccicntc-mcutc. la idca de Linux clcsdv un Borrador (www.liuu xfromscratch.org ) capto la au ncion de Ivan y Sl' dcdicar» a ella tall pronto como Ie sea posihl«.

Brad Harris cst uvo ell la Lriivcrxidud de Stuntord micnt ra-, era rnicmhro del prcst i gioso Programa dc Erurcnarnu-nto para no (;raduados de la Agcncia dc Seguridad ~acional. Continuo hajo los auspicio-, dc la AS:\ en cl desarrollo dc tccnicas hiomctriCIS a\an;adas alltcs dc unirsc a la division dc comprob.nkin \ Allalisis ck: Scguridad dc Sistcmas como comprobador dc pcnctrucion. Ahora trahaja como director dc illgcnicrra dc software para Sistcmas dc Comput.rdoras Afili.rck». lnc dondc: lkva a caho tareas de cornprob.uion dc pcnctr.nion \ dcsarrol!o dc xoft war«.

Reconocimientos

;\;0 podrra haber escrito este lihro sin cl gran sacrificio \ apoyo de mi esposa e hijos. Me han ayudado mucho mas de 10 que imaginamos al coruic-nzo de este provcc to .. Polly. Eliza. Mich.u-l .. jLo conscuuimos!

Tarnhicu me gustana dar las gracias a los muchos rcvixorcs de PASA (los Administ radorcs de sistemas del area de Portland). a Seth Arnold. Lucas Sheehan. Doug Munsinger. Allen Supvnuk. Philip Jacob v a los rniernbros de las lista-. de corrco de apovo de mon, ipchains y Ethereal. A todos vosotros: gracias por las ideas. cl animo y d acoso ocasional.

Esto) segufO de que me he olvidado de alguicn. A todos ellos ks dcbo tambicn mi agradccirntcnto. Si pcnsais que vucstro norubrc dchcna cstar aqui. por favor cnviadme Lin e-mail apate@gnu.org. y me ascgurarc de que aparczca en cl sitio web.

btl' lihro trata de cstandan-s abicrtos y software gratuito. lIa habido dcmasiada gente que ha escrito codigo. RFC 0 documcntacion para mi como para empezar a agradcccrselo a todos cllos. Espero habcr puesto bien los nornbrcs dondc los he utilizado y no huber olvidado mcncionar ninguno que dehlera cstar en cstas paginas.

Me gustaria tarnbien agradeccr a mis cditorcs de New Riders Puhlishing. Si cstc lihro mcrccc la pena leerse es. en gran parte. gracias a ellos. Brad. Ivan. Stephanie. John y Lisa. gracias por aguantarme.

Para terrninar, no pucdo presentar estc libro al mundo sin dark las gracias al Senor. "Con Dios, todo es posible'. Sin El. cstc libro no 10 hubiera sido.

Aunque rnuchas personas han ayudado a mejorar cstc lihro. cualquier error que haya es cxclusivarucntc mio.

Introducci6n

Introducci6n

Hicnvcnidos a Guia avanzada Redes Lirrux con TCP/IP. Espcro que aprcnda tanto levcndo cste libro como aprcndi yo cscribicndol«. Dcscuhri much as cosas, sobrc cl trabajo ell red, sobre escrihtr y sobre mi mismo. Para avudarlc a obiencr todo 10 posiblc de cstc libro, me gustaria com partir las siguicrucs ideas sohre 10 que cncontrara entre las cubicrtas y sobre como utilizarlo mcjor.

iDisfrute'

Organizaci6n de este libro

Estc libro est.i dividido ell trcs partes, COil un capitulo inicial (Capitulo I) que no csta incluido en csas partes. EI Capitulo L "Prologo a una guia practica" nos ofrece una perspectiva general de la terminologia y tccnologia utilizada en cl resto del libro. En los apcndiccs sc incluycn algunos RFC importantes. Aunque estos documcntos est.in dispontbk-s ell la Red, tcncrlos incluidos ell este libro. y con indicc, dcbcria scr una grail venra]a.

La Parte I de cstc libro. "Los protocolos", nos ofrccc una aproxirnacion a los protocolos capa a capa. Rcvisa Ia ur ilizacion de cstos protocolos, detalla la cstructura de los paquctcs que los conforrnan y cxplica como irueropcran para haccr que las rcdcs funci. men.

La Parte II, "lltilizaci(lll cficicntc de los prorocolos". cubrc la adrninistracion de redes desd« un punto de vista practico. La mayor parte del t'n!;,sis se pOlle ell la rcsoIucion de problemas, COil Ull capitulo que dctalla Ull patron de rcsolucion de problemas y otro que 1l0S ofrcc« cst udios de casos de problemas de red. Esta parte tarnbicn incluvc Ull capitulo que cubre la base fundamental de la red.

La Parte Ill, "Hcrrarnicntas para nuestro cquipo de hcrramicntas". nos proporciona una iru roduccion a un cu-rto ruuncro de herr.unicnt.rs gratuitas que hara que nucstra vida en la red sea mas f.icil. Estas introduccioncs cuhren la instalacion y la utilizacion de herramicntas para la rcsolucion de problemas. revision y seguridad de rcdcs.

XVI Introducci6n

La Parte III queda cubierta por la OPL (Open Publication License, Licencia de publicacion abierta), [por 10 que es software gratuito! La version mas reciente de esta seccion esta en linea en el sitio web dellibro original (en Ingles) http://www.networkinglinuxbook.com. La fuente de Doc Book esta disponible y queda invitado a ayudar a que sea la mejor guia de software de red gratuito.

Si es nuevo en el trabajo en red, comience con el Capitulo 1, despues lea la Parte I.

Cuando tenga una idea de como funcionan las redes, puede leer las Partes II y III a trozos. El orden en el que las lea esta mas basado en el interes que en otra cosa.

Si ya ha trabajado con redes, lea por encima el Capitulo 1. Si encuentra algo nuevo, siga por el capitulo apropiado de la Parte I. Probablemente quiera volver a la Parte I de vez en cuando a medida que vaya leyendo el resto dellibro. Las Partes II y III estan dirigidas a usted. Lea la Parte II y agregue las ideas que contiene a su bolsa de trucos de red. A continuacion, lea la Parte II en el orden que mas le interese. Las aplicaciones que se enumeran son un gran conjunto de herramientas para cualquier profesional de redes. Con suerte, encontraci un nuevo juguete para mantenerse ocupado.

Otros recursos

Hay tres clases de recursos que haran que este libro sea mas util:

El sitio web dellibro (en Ingles), Las listas de correo.

Su red.

Como ya mencionamos en la seccion anterior, e:xiste un sitio web de este libro (en Ingles). Contiene informacion sobre las listas de correo relacionadas con ellibro (preguntas, erratas y anuncios sobre nuevas ediciones). Tiene todas las erratas conocidas en linea y un sistema para presentar erratas. He intentado crear una buena seccion de enlaces a herramientas y otra informacion tarnbien incluidas.

Adernas de las listas de correo que mantenemos para este libro, existen muchas otras de TCP/lP, redes y Linux. Algunas de ellas tienen enlace desde la pagina web del libro. Invohicrese, aprendeci mucho.

Probablemente, el mejor recurso sea su propia red. Tome Ethereal (Vease el Capitulo 10, "Herramientas de revision") y comience a observar el tcifico. Lea un capitulo dellibro, despues inicie Ethereal y observe el tcifico en la vida real. No hay mejor profesor que la experiencia.

Como se escribio este libro

Este libro se escribio en DocBook y se compile en pdf para los revisores tecnicos yen rtf para la editorial. Utilice emacs (con modo psgml) para componer el DocBook. El codigo fuente se guardo en cvs. Toda la escritura se realize en una IBM Thinkpad 240 con Red Hat Linux 6.2 (con unos cuantos extras). Este libro no habria sido posible sin las ricas herramientas que pone a nuestra disposicion el maravilloso mundo del software gratuito.

1

Pr61ogo a una guia practica

EI conjunto de Protocolo de control de transmision/Protocolo Internet (Transmission Control Protocol/Internet Protocol, TCP/IP), a veces llamado TCP 0 IP, con frecuencia se ve como un laberinto de acronimos y de jergao Aunque no tenernos una varita magica para hacer que desaparezca la terrninologia, esperarnos poder proporcionarie las herrarnientas que necesite para comprender 10 que ocurre tras las cortinas. Para ayudar a minimizar la confusion, pondrernos en cursiva la primera aparici6n de los terrninos nuevos.

Antes de sumergirnos en una explicacion detallada de los protocolos, herramientas y aplicaciones que conform an TCP liP, veremos alguna informaci6n de fondo que ayude a proporcionar un contexto para los capitulos posteriores. EI resto de este capitulo introduce los protocolos en capas, describe brevemente TCPIIP, ofrece un ejernplo de TCPIIP en funcionamiento, explica las organizaciones y metodos implicados en la especificaci6n de TCP/IP, ofrece informaci6n sobre el desarrollo del protocolo TCPIIP en Linux y habla de los problemas de capas fisicas.

NOTA DEL AurOR

Si ya tiene una idea de todo esto, quiza s610 quiera leer por encima este capitulo camino del Capitulo 2, "Protocolos de la capa de enlace". Si quiere atajar, pero no est a realmente muy familiarizado con el funcionamiento de los protocolo en capas, probablemente Ie vendria bien leer la secci6n "TCP/IP en acci6n: una narrativa", mas adelante en este capitulo, antes de continuar. De hecho, si alguna vez se picrde en la pita de protocolos, volver a esa secci6n puede ayudarle a poner las cosas en perspectiva.

2 Capitulo 1 Pr61ogo a una guia practice

Protocolos en capas: deseripcion e historla

En un principio, los programas de comunicaciones escritos personalizados permltian que una computadora hablara con otra 1. Si queriamos hablar con una computadora diferente, teniamos que escribir un programa nuevo.

Este metodo no podia ampliarse mas que a unas cuantas computadoras.

Una situacion parecida se produ]o en los primeros tiempos de los trenes europeos. Regiones individuales construian sus propios sistemas de railes sin intentar adecuar el tamafio de las vias (llamados entrevias) a los sistemas vecinos. Si querias enviar mercancias 0 viajar entre dos regiones, tenias que detenerte en uno 0 mas limites regionales y cambiar de tren, porque aquel en el que estabas viajando no podia utilizar las vias de la regi6n nueva.

Los primeros intentos de solucionar este problema fueron protocolos patentados que permitian a las computadoras del mismo fabricante hablar unas con otras. Ninguno de estos protocolos se utiliza mucho hoy en dia, pero el UUCP (Unix-to-Unix Copy Program, Programa de copia de Unix a Unix) es parecido en su concepto: un protocolo monolitico que puede utilizarse solo con otra computadora que comprenda UUCP. Afortunadamente, UUCP esta ampliamente disponible, en lugar de estar bloqueado como un protocolo especifico de distribuidor. (Alin mas afortunado es el hecho de que UUCP ya no se utiliza casi, y en la mayoria de los casos en los que se hace, se implementa detras de TCP.)

La siguiente etapa en la evolucion de los protocolos fue el protocolo en capas. En este modelo, el protocolo esta dividido en capas dispuestas en una pila (como los platos en un armario). Cada una de estas capas esta compuesta de uno 0 mas protocolos, una desafortunada duplicacion de terminologia. Cada capa pasa informacion verticalmente dentro de la pila. Ejemplos de protocolos en capas que no son TCP/IP incluyen el XNS (eXtensible Name Service, Servicio de nombres extensible; el ancestro de la pila de protocolos Novell) y la SNA (System Network Architecture, Arquitectura de redes de sistemas; el protocolo de comunicaciones de IBM).

Normalmente, se habla de los protocolos en capas en terminos del modelo de siete capas OSI. Cada capa es responsable de ciertas funciones dentro de la red (por ejemplo, la capa de red direcciona y encamina paquetes y la capa de presentacion encripta y comprime datos).

Puede pensarse en estas capas (y potencialmente en los diferentes protocolos de cada capa) como en un conjunto de varios juegos diferentes. Algunos de los juegos utilizan las mismas clases de cosas (como cartas de juego laminadas). De todos los juegos que utilizan cartas, algunos utilizan el mismo tipo de baraja (por ejemplo, una baraja estandar de 52 cartas). Incluso aquellos que utilizan una baraja estandar realizan una amplia variedad de juegos (por ejemplo, poker, gin rummy y solitario), y no podemos mezclar las reglas entre ellos.

1 En un principio, las computadoras no hablaban unas con otras; no habia suficientes. Pero nos saltaremos esos tiempos y aterrizaremos en las primeras etapas de las cedes de computadoras.

Capitulo 1 Pr61ogo a una quia practice 3

Los datos de una capa dada estan organizados de un modo muy parecido a los de cualquier otra capa. Un paquete (terrnino generico para un conjunto de datos de cualquier capa) se compone de dos partes, un encabezamiento y una carga uti! (0 datos), como muestran las Figuras l.1 y l.2.

Encabezamiento Datos

Figura 1.1. Organizacion basica de un paquete.

Cada capa encapsula aquellas que estan por encima de ella.

Encabezamiento Encabezamiento

Figura 1.2. Un paquete cncapsulando un paquete de nivel superior.

Este proceso ariade un coste adicional a la cantidad de datos transfcridos 2, Y esta es una de las quejas sobre los protocol os en capas. Sin embargo, a la luz de las ventajas, el coste es minimo.

Las dos grandes ventajas de este modelo son que es facil de implernentar y facil de extender. Implementar el protocolo significa que cualquier distribuidor de hardware puede utilizar una pila de protocolos de manera que su equipo pueda cornunicarse con el equipo de cualquier otro distribuidor (suponiendo que los aspectos especificos del protocolo sean abiertos y que el otro distrihuidor 10 haya implementado tarnbien). Extender un protocolo significa afiadirle funcionalidad.

En el caso de TCP/IP, las especificaciones del protocolo est an bien abiertas, y los RFC (Requests for comments), que se describen mas ade[ante en este capitulo, dan detalles precisos sobre los distintos protocolos del conjunto TCP/IP. No solo estan disponihles los RFC, sino que cualquiera que quiera puede tambien utilizar varias implementaciones de referenda.

Para extender TCP/IP agregando un servicio nuevo de capa de aplicacion solo hay que implementar un protocolo en una capa del modelo mientras hacemos uso de las capas existentes para el resto del trabajo. Por ejernplo, si querernos implementar un protocolo para perrnitir que todos nuestros hosts en red intercambien actualizaciones, podriarnos confiar en IP y en el lJDP (User Datagram Protocol, Protocolo de datagrarna de usuario) para entregar los datos, y concentrarnos en como forrnatcar y uti!izar la informacion en cl protocolo de capa de aplicacion que desarrollemos.

2 En realidad, hay lin cierto numero de otros sitios en los que se anade lin coste adicional por la naturalcza de un rnetodo en capas. verernos muchos de cllos a mcdida que vamos estudiando los distintos protocolos, Tamhicn veremos maneras de mitigarlo, dondc podamos.

4 Capitulo 1 Pr61ogo a una guia practlca

TCP/IP

TCP /lP fue desarrollado para proporcionar un protocolo en capas neutral para el Departamento de defensa. El hecho de que sea ahora la lingua franca de Internet habla no solo de su propio disefio sino tambien de las ventajas de los protocolos en capas.

TCP/IP se diferencia del modele OSI en que solo tiene cuatro capas: una capa de enlace, una capa de red, una capa de trans porte y una capa de apltcaci6n. Algunos autores aiiaden una quinta capa, la capajfsica, debajo de la capa de enlace (vease la Figura 1.3). Sin embargo, nosotros creemos que esto es inapropiado, porque las especificaciones de TCP/IP no se ocupan de las diferencias entre las implementaciones de capa fisica de los protocolos de capa de enlace (por ejemplo, no hay una verdadera diferencia en el modo en que TCP/IP trata los marcos de Ethernet desde un origen lOBaseT 0 desde un origen lOOBaseTx). Ofreceremos una breve perspectiva de los problemas de la capa fisica al final de este capitulo.

Capa de aplicaci6n
Capa de transporte
Capa de Internet
J Capa de enlace '" Figura 1.3. Pila de protoco!os TCP/IP.

Hablaremos mas detalladamente de cada una de ellas en 10 que queda de esta seccion, pero veamoslas cipidamente ahora. Como es de esperar, hay un cierto rnimero de excepciones y variaciones menores de las siguientes descripciones.

Capa de enlace

La capa de enlace esta situada en la parte inferior de la pila. Es la responsable de transmitir y recibir porciones de informacion (a menudo llamados marcos 0 paquetes). Dos ejemplos de protocolos de esta capa son Ethernet y el PPP (Point-to-Point Protocol, Protocolo punto a punto).

Capade red

La capa de red se sinia encima de la capa de enlace. Es la responsable de encaminar y direccionar porciones de datos. En la capa de Internet, estas por-

Capitulo 1 Pr61ogo a una guia practica 5

ciones se Haman da tagra mas. Para nuestro proposito, el principal protocolo de este nivel es IP (Internet Protocol, Protocolo Internet).

Capa de trans porte

La capa de transporte esta situada encima de la capa de red. Es la encargada de asegurarse de que los datos vienen de y se dirigen a los procesos correctos de un host. Los datos se manipulan en unidades, a menu do llamadas segmentos (pero a veces lIamadas tarnbien datagrarnas '). TCP Y lJDP son los principaIes protocolos de esta capa.

Capa de aplicacion

La capa de aplicacion esta situada en la parte superior de la pila y con frecuencia se implementa en aplicaciones de usuario como Telnet 0 Nctscape. Los datos de la cap a de aplicacion se manipulan en unidades, generalmente Hamadas mensajes. Muchos protocolos (y programas asociados) forman parte de esta capa.

TCP lIP en acci6n: una narrativa

Para intentar poner todo esto (y todo 10 que viene a continuaci6n) en perspectiva, veamos como se envia un correo electronico a un host remoto. Le avisamos de que esto es una sirnplificacion, pero deberia servirnos por ahora. Aunque con frecuencia TCP/lP se explica partiendo de la cap a de enlace hacia arriba, para este ejemplo daremos la vuelta a las cosas e iremos desde la capa de aplicacion hacia abajo.

Para nuestro ejemplo, estoy conectado en cherry y voy a enviar un e-mail ami mujer en mango. (En la Figura l.4 se muestra un diagram a de los hosts y de la red que los conecta.)

Como estamos tratando los protocolos, no importa que programa envia el correo, siempre que implemente el SMTP (Simple Mail Transfer Protocol, Protocolo simple de transferencia de correo). Can frecuencia, multiples programas implementan el mismo protocolo; sendmail, qmail y postfix son solo unos cuantos MTA (Mail transfer Agents, Agentes de transferencia de correo) que implernentan SMTP. Un usuario no utiliza normalmente un MTA directamente; en su lugar, utiliza un MUA (Mail User Agent, Agente de usuario de correo), como pine, balsa a evolucion.

, Aunque esto parece confuso, es en realidad una manera precisa de hablar. TCP manipula sus datos en segmentos, mientras que HDP trata con datagrarnas. Pard mas dcrallcs. consulte el Capitulo 7, "Antes de que las cosas se estropeen, construcclon de una base". y el Capitulo S, "En el memento, estudios de casos".

6 Capitulo 1 Pr61ogo a una qula practice

hub I

hub 2

Figura 1.4. Dos sistemas de una red.

Cuando terminamos de escribir el mensaje en nuestro MUA, se pasa al MTA para su entrega. El MTA determina primero la direcci6n de mango y despues envia el mensaje y la direcci6n de mango a TCP en la capa de transporte (vease la Figura 1.5).

Encabezamiento TCP Mensaje e-mail

Figura 1.5. Un mensaje de correo e1ectr6nico en un segmento TCP.

TCP inicia entonces una sesi6n con mango, y despues de que se configure la sesi6n (cortesia de las capas inferiores), envia una serie de segmentos que contienen el mensaje a IP, en la capa de red. Cada segmento de la sesi6n contiene suficiente informacion para identificar el proceso iinico de cada equipo y que parte del mensaje de la capa de aplicaci6n lleva (vease la Figura 1.6).

Encabezamiento IP

Encabezamiento TCP

Figura 1.6. Un segmento TCP en un datagrama IP.

IP utiliza los segmentos iniciales (la petici6n de configurar la sesion) y determina d6nde enviar sus datagramas. Si el destino no esta en la red local, IP

Capitulo 1 Pr61ogo a una guia practice 7

debe determinar la pasarela adecuada para enviarlos. En este caso, cherry y mango estan en la misma red, por 10 que no es necesario ningun encaminamiento. IP pasa entonces sus datagramas al manejador de dispositivos Ethernet de la capa de enlace para su entrega (vease la Figura l.7).

Encabezamiento Ethernet Encabezamiento IP I Encabezamfento TCP J Mensaje e-mail Figura 1_7. Un datagrama IP en un paquete Ethernet.

El sistema Ethernet debe hacer correspondencia de la direccion IP del destino (0 pasarela) a una direcci6n de hardware utilizando el ARP (Address Resolution Protocol, Protocolo de resolucion de direcciones) 0 mirando en la memoria cache j ARP del equipo, si hay una entrada para esa direcci6n. En este caso, cherry tiene la siguiente cache ARP:

[root@cherry /root]# arp -a

? (192.168.1.1) at 00:A0:D2:1C:64:E8 [ether] on eth0 ? (192.168.1.11) at 00:C0:F0:26:B1:EC [ether] on eth0 [root@cherry /root]#

Despues de haber hecho correspondencia de la direccion, el datagrama IP (que lleva un segmento TCp, que a su vez lleva una porcion de un mensaje SMTP) se envuelve en un paquete Ethernet y se envia a su destino (vease la Figura 1.8)

cherry

Figura 1.8. Un paquete Ethernet llevando correo electr6nico entre hosts.

En mango, el paquete Ethernet se recibe e inspecciona. Si el host determina que es para entrega local, determina donde entregar su contenido '. En este caso, el paquete contiene un datagrama IP que se pasa a la pila IP 6.

I lIna cache es una tabla de datos, normalmente guardada en memoria por cl sistema operauvo para acelerar el acceso ala informaclon que contiene. En Linux, podernos ver la cache ARP misma mirando en /proc/net/arp,

, Es posible que un equipo pueda recibir un paquete Ethernet dirigido a otro host. Normalrnente, esto seria debido a que cl host local esta actuando como pasarda.

(, La implementaci6n de un protocolo como IP, UDP 0 TCP a rnenudo se llama pita, igual que el protocolo TCP/IP. Esto puede resultar en una gran confusion innecesaria.

8 Capitulo 1 Pr61ogo a una guia practlca

La pila IP inspecciona el datagrama y descubre que lleva un segmento TCP, que se pasa a la pila TCP. Es posible que la pila IP tenga que llevar a cabo alguna acci6n especial antes de pasar el segmento a la pila TCp, por ejernplo, volver a montar un segmento a partir de una serie de datagramas.

TCP inspecciona el datagrama que ha recibido y pasa el mensaje SMTP al MTA local, en la capa de aplicacion, para que 10 entregue al usuario final.

RFC

TCP/IP esta controlado por el IETF (Internet Engineering Task Force, Equipo operative de ingenieria de Internet), un cuerpo de estandares voluntario con una normativa de admision abierta. Los RFC se utilizan para desarrollar y mantener los diversos estandares relacionados con TCP /lP. El IETF distribuye estos documentos gratuitamente.

Los RFC 1122 Y 1123 son los RFC de los requisitos de los hosts. (El RFC 1009 es el RFC de los requisitos de los encaminadores.) Estos tres documentos componen la base de gran parte de los temas del resto dellibro. El pasaje que viene a continuaci6n del RFC 2400 ayuda a explicar parte de la terminologia utilizada en los RFC.

EXPUCACION DE TERMINOS

Existen dos clasificaciones independientes de protocolos. La primera es el nivel de madurez 0 estado de estandarizaci6n: estandar, estandar preliminar, estandar propuesto, experimental, informativo 0 hist6rico. La segunda es el nivel de necesidad 0 condici6n de este protocolo, necesario, recomendado, optative, uso limitado 0 no recomendado.

La condici6n 0 nivel de necesidad es dificil de describir en una etiqueta de una palabra. Estas etiquetas de estado deberian considerarse s610 una indicaci6n, y deberia consultarse una descripci6n mas extensa 0 sentencia de aplicabilidad.

Cuando un protocolo avanza a estandar propuesto 0 estandar preliminar, se etiqueta con una condici6n actual.

lQuE ES UN "SISTEMA"?

Algunos protocolos son particulares de hosts y otros de pasarelas; unos cuantos se utilizan en ambos. Las definiciones de los terminos se referiran a un "sistema" que es 0 un bost 0 una pasarela (0 ambos). Deberia quedar claro por el contexte del protoco- 10 en particular a que tipo de sistemas nos referimos.

DEFINICIONES DE ESTADO DE PROTOCOW

A cada protocolo enumerado en este documento se Ie asigna un nivel de madurez 0 estado de estandarizacion: estandar, estandar preliminar, estandar propuesto, experimental 0 hist6rico.

Protocolo estandar: el IESG 10 ha establecido como un protocolo estandar oficial de Internet. A estos protocolos se les asignan mimeros SID (vease el RFC 1311). Se dividen en dos grupos: protocolo IP y superiores, protocolos que se aplican a


todo Internet; y los protocolos especificos de red, normalmente especificaciones de como hacer IP en tipos de red particulares.

Protocolo estandar preliminar: el IESG esta considerando este protocolo como un posible protocolo estandar, Son de desear comentarios y pruebas amplias y sustanciales. Los comentarios y los resultados de las pruebas deberian some terse al IESG. Existe la posibilidad de que se realicen cambios en un protocolo estandar preliminar antes de que se convierta en un protocolo estandar,

Protocolo estandar propuesto: son proposiciones de protocolo que el IESG podria considerar pard su cstandarizacion en un futuro. Es deseable la implementaci6n y prueba por varios grupos. Es probable la revision de la especificacion del protocolo. Protocolo experimental: un sistema no deberia implementar un protocolo experimental a menos que estc participando en el experimento y haya coordinado su utilizacion del protocolo con el desarrollador del mismo.

Normalmente, los protocolos experimentales son aquellos que se desarrollan como parte de un proyecto de investigacion en marcha no relacionado con una oferta de servicio operacional. Aunque pueden ser propuestos como un protoco- 10 de servicio en una fase posterior, y de este modo convertirse en protocolos propuesto, pre1iminar y despues estandar, la designacion de un protocolo como experimental puede a veces utilizarse para sugerir que el protocolo, aunquc quiza este maduro, no esta dirigido a una utilizacion operacional.

Protocolo informativo: los protocolos desarrollados por otros distribuidores u organizaciones estandar, 0 aquellos que por otras razones estan fuera del ambito del IESG, pueden publicarse como RFC, por el bien de la comunidad de Internet, como protocolos informativos.

Protocolo historico: son protocolos que no tienen posibilidades de convertirse nunca en estandares de Internet, 0 porque han sido sustituidos por desarrollos posteriores 0 por falta de interes,

Definiciones de condlcion de protocolo

Este documento enumera un "nivel de nccesidad" 0 condicion para cada protocolo. La condicion puede ser "necesario", "recomendado", "opcional", "uso limitado" 0 "no recomendado" .

Protocolo necesario: un sistema debe implementar los protocol os necesarios. Protocolo recomendado: un sistema debe ria implementar los protocol os recomendados.

Protocolo opcional: un sistema puede 0 no implementar un protocolo opcional. La nocion general es que si vamos a hacer algo como esto, debemos hacer exactamente esto. Puede haber varios protocolos opcionales en un area general; por ejemplo, hay varios protocolos de correo electronico y varios protocolos de encaminamiento. Protocolo de uso limitado: Estos protocolos son para utilizarlos en circunstancias limitadas. Puede que sea por su estado experimental, su naturaleza especializada, su funcionalidad limitada 0 su estado historico.

Protocolo no recomendado: Estos protocolos no estan recomendados pard una utilizacion general. Esto puede ser debido a su funcionalidad limitada, su naturaleza especializada 0 experimental 0 a su estado historico.

TCP/IP Y Linux

TCP/lP, UNIX e Internet estan profundamente relacionados; con nuestro enfasis adicional en Linux, esto pod ria parecer mas como una codependen-


cia. De hecho, los protocolos TCP/IP se han implementado en muchas plataformas diferentes y funcionan como una especie de pegamento uniendolos en la red. Esto no quiere decir que algunos distribuidores no abusen del protocolo implementando extensiones patentadas (y ocasionalmente no interoperables) de los estandares. A largo plazo, este tipo de comportamiento puede ser bastante perjudicial 7.

Una breve historia de TCP/IP en Linux

La primera pila IP para Linux la desarrollo Ross Biro. Continuo trabajando en esta version, llamada NET-I, hasta que le desbordaron sus otros compromisos y las (a veces feroces) quejas de algunos usuarios de Linux. Se hizo una implementacion nueva de la pila de protocolos, porque existia una gran incertidumbre sobre de la condicion legal de la pila de la BSD (Berkeley Software Distribution, Distribucion de software de Berkeley) en ese momento 8.El codigo de NET-I era soportado por un controlador Ethernet para la tarjeta Ethernet WD-8003, tambien de Biro.

Ademas de los esfuerzos de Ross Biro, Orest Zborowski y Laurence Culhane tambien estaban haciendo un traba]o fundamental con la primera red Linux. Zborowski produjo la interfaz de socket BSD, que aportaba la API necesaria para la mayoria de las aplicaciones de red existentes. Culhane desarrollo los primeros controladores SLIP de Linux, permitiendo a los usuarios que no estaban conectados con Ethernet empezar a trabajar en red con Linux.

Fred van Kempen retorno el trabajo de Biro y comenzo a desarrollar NET-2.

Tenia grandes planes para la pila IP Y desarrollo cinco versiones (de NET-2A a NET- 2E). Un cierto rnimero de factores provocaron una ruptura en la comunidad, y Alan Cox comenzo a trabajar en NET-2Depurado. Con el tiempo, el trabajo de van Kempen fue superado por el de Cox, y NET-2Depurado se convirtio en el estandar,

El trabajo de Cox (ye1 de muchos otros) se convirtio con el tiempo en NET-3, la actual pila TCP/IP de Linux. Donald Becker (controladores Ethernet), Michael Callahan y AI Longyear (PPP) y Jonathon Naylor (mejoras de AX.25) son algunas de las personas que pusieron su sella en el codigo de red.

Los controladores de dispositivo dinamicos, IPX, IPv6, las capacidades de encaminamiento avanzado, el filtrado de paquetes y la NAT (Network Ad-

7 Un buen ejemplo (aunque no es en realidad un problema de TCP/lP) es el de las distintas extensiones patentadas del estandar HTML. Ahora es bastante dificil encontrar sitios web que no esten diseiiados para Netscape 0 Internet Explorer y que no se presenten de manera adecuada en el otro debido a una confianza en un beneficio no estandar, Es a1entador que eI proyecto Mozilla este luchando por la conformidad de estandares HTML en su navegador. Con suerte, esto sera el principio de una tendencia.

8 BSD se vio envuelto en un pleito con los USL (UNIX Systems Laboratories, Laboratorios de sistemas UNIX) sobre posibles violaciones del copyrigbt. S610 despues de una buena cantidad de trabajo se vio Iibre la pila BSD y, para entonces, Ia pila Linux estaba ya en marcha.

Capitulo 1 Pr61ogo a una guia practica 11

dress Translation, Traduccion de direcciones de red) son algunas de las caracteristicas disponibles para Linux hoy en dia, gracias a todas las personas implicadas en el desarrollo de la implernentacion de la red Linux. Gracias a estas caracteristicas, el traba]o de red en Linux es solido, rapido y facil, El futuro de la red y de Linux parece brillante, con continuas mejoras y nueva funcionalidad en cada version del nucleo.

Problemas de la capa fisica

Como Ethernet es el protocolo de capa de enlace utilizado mas com unmente para las LAN, limitaremos los comentarios de esta secci6n a los problemas relacionados con Ethernet. Cubriremos dos areas amplias: Ethernet de capa fisica y hardware de red.

Ethernet de capa fisica

Hoy en dia, las redes Ethernet se ven normalmente de dos tipos: 10BaseT y 100BaseTx. Como la mayoria de los nombres, estos tienen su significado. Como la rnayoria de las cosas del trabajo en red, hace falta un poco de contexto para entenderlo.

En los primeros tiempos de Ethernet, la gente utilizaba thicknet (red gruesa), 0 cableado de nucleo solido. Estos cables podian llevar una sefial de 10Mbps aproximadamente unos 500 metros y utilizaban una sefial de banda base. Esto se llego a conocer como lOBase5.

El cableado IOBase5 era caro y dificil de co nectar, y no podia extenderse por curvas severas. Se desarrollo un nuevo estandar fisico que ayudo a mitigar estos problemas, a costa de una longitud maxima mas corta. Thinnet (red fina), 0 cbeapernet (red mas barata), como se la llamaba a veces, llevaba una serial de banda base de 10Mbps casi 200 metros por cable coaxial, y se la denomina IOBase2.

A Ethernet a traves de un cableado de pares enlazados se le dio el nombre de 10BaseT, porque tarnbien llevaba una serial de banda base de 10Mbps. Cuando se lanzo Ethernet lOOMbps, se ejecutaba por cableado de pares enlazados y se denomino lOOBaseTx. Ambas implementaciones requieren cuatro pares de cable de pares enlazados por conexion (utilizando un conector RJ-45, que se parece a una roseta de telefono enorme). El estandar necesita conexiones hostto-hub (0 interruptor).

10BaseT y 100BaseTx utilizan solo cuatro cables de los ocho disponibles en los cuatro pares. Estos cuatro cables se utilizan en dos pares, uno para transmitir sefiales y el otro para recibirlas. Esto nos lleva a algunos trucos que pueden hacerse ocasionalmente.

El estandar utiliza los cables 1 y 2 como el par transmisor, y el 3 y el 6 como el receptor. Sabiendo esto, podemos hacer un cable cruzado conectando los pares como se muestra en la Figura 1.9.


Figura 1.9. Un cable cruzado.

Estos cables nos permiten conectar dos hosts sin tener un hub en medio (esto es muy parecido a un cable de modem nulo, haciendo que un co-trabajador anterior 10 llame cable de hub nulo).

Si solamente tenemos que conectar dos hosts, puede ser una manera muy facil (y con un coste razonable) de construir nuestra red. Tambien es el modo en que se conectan dos hubs; muchos hubs e interruptores vienen con un puerto que puede cambiarse entre conexiones cruzadas y directas.

Como solo se utilizan cuatro de los ocho cables disponibles, es posible ejecutar dos conexiones Ethernet en una unica conexion de cableado estandar, Esto da como resultado algo de degradacion de sefial, pero, normalmente, es utilizable en una configuracion de oficina normal. Si tenemos otto modo de ejecutar un segundo conjunto de cableado, es preferible hacerlo asi, Si no podemos ejecutar un segundo cable, este truco puede ayudamos.

Otros estandares de Ethernet disponibles incluyen Gigabit Ethernet, Ethernet sin cable y lOBroad36 (un estandar de Ethernet de banda ancha). Estos no son aun demasiado comunes, aunque Gigabir Ethernet esta camino de ser tan cormin como lOBaseT y lOOBaseTx.

Hardware de red: encaminadores, interruptores y hubs

El hardware de red se ve con demasiada frecuencia como magia negra, algo que se utiliza pero nunca se entiende. En realidad, no es tan dificil. Diferentes clases de hardware de red acnian sobre el trafico de red en diferentes niveles; esto permite que se puedan utilizar de diferentes maneras.

Los hubs, concentradores y repetidores acnian en la capa fisica. Su unico proposito es regenerar la sefial electrica (incluido cualquier error) a cada conexion saliente. Los hubs y los concentradores son dispositivos para conectar redes lOBaseT y lOOBaseTx. Los terminos son en su mayor parte intercambiables, aunque los hubs connotan dispositivos grandes (24 puertos 0 mas). Los repetidores son una vuelta a los dias de lOBase5 y lOBase2, y se utilizaban para extender la longitud de una red conectando dos segmentos de red de longitud completa.

Los hubs se utilizan con frecuencia como la estructura basica de redes pequefias, porque cuestan menos que otras soluciones (aunque esta diferencia


esta decreciendo y los hubs se estan haciendo menos populares). La Figura 1. 10 muestra una red basada en hubs.

Figura 1.10. Una red pequeria.

Un problema con las redes basadas en hubs es que cada host ve todo el trafico destinado a cualquier otro host de la red. Esto puede llevar a una congestion de la red en redes muy pobladas.

Los interruptores y los puentes operan en la capa de enlace. Restringen el trafico a conexiones salientes de las que se sabe no 10 necesitan. Por ejemplo, si tres hosts estan conectados a diferentes puertos de un interruptor y el primer host envia trafico al tercero, el interruptor mandaria el trafico s610 al puerto al que esta conectado el tercer host. Si cualquiera de los hosts fuera a enviar trafico de difusion (descrito en el siguiente capitulo), se mandaria a todos los puertos del interruptor. Esta caracteristica hace de los interruptores un buen dispositivo a utilizar como estructura basica de las redes.

Los puentes, como los repetidores, son una vuelta a una etapa anterior. Se utilizaban para conectar dos redes Ethernet mientras se aislaba el trafico en un mayor grado de 10 que 10 harian los repetidores 0 los hubs. Hoy en dia, la mayoria de las implementaciones utilizan un interrupt or en lugar de un puente. Funcionan igual y los interruptores son mas rapidos y capaces de manipular multiples conexiones (los puentes normalmente tenian s610 dos puertos Ethernet).

Los encaminadores funcionan en la capa de red. Se utilizan para pasar trafico entre multiples redes. El funcionamiento de los encaminadores se describe de manera mas completa en el Capitulo 3, "Protocolos de capa de red". Algunos interruptores (a menudo llamados interruptores de encaminamiento) acnian tambien sobre el trafico de red en la capa de red. Los encaminadores proporcionan incluso mas segregaci6n entre las redes y pueden utilizarse tambien para mover los datos de un protocolo de capa de enlace a otro (por ejernplo, de Ethernet a PPP).

Mientras que los hubs y los interruptores componen la estructura de las LAN, los encaminadores son el elemento clave de las WAN. Debido a su papel en la conexi6n de redes, los encaminadores (e interruptores de encaminamiento) son un "punto de estrangulamiento" cornun donde se lleva a cabo el control de acceso a la red. Este tema se cubre con mas detalle en la seccion "iptables" del Capitulo 10, "Herramientas de revision".

I

Los protocolos

2 Protocolos de la capa de enlace. 3 Protocolos de la capa de red.

4 Protocolos de la capa de transporte. 5 Protocolos de la capa de aplicacion,

2

Protocolos de la capa de enlace

Los protocolos de la capa de enlace proporcionan los medios para que las cornputadoras se cornuniquen unas con otras cuando haya W1 enlace fisico corruin, Ese enlace podria aportarlo un Ethernet normal, una linea de POTS (Plain Old Telephone Seruice, Antiguo servicio telefonico sencillo), un anillo de FDDI (Fiber Distributed Data Interface, Interfaz de datos distribuidos por fibra) 0 incluso un palo de palomas mensajeras (vease el RFC 1149 para mas informacion I).

Todos los protocolos de la capa superior dependen de la capa de enlace para Ia entrega real de los datos. Como existen los protocolos de la capa superior, el trafico puede cruzar un internetwork con muchos protocol os de capa de enlace diferentes, De hecho, la mayoria de los internetworks encajan con esta descripcion. Por ejernplo, dos LAN de oficina con una conexion PPP dedicada se parecerian al diagrama que se muestra en la Figura 2.1.

En las siguientes secciones, estudiaremos dos protocolos de la capa de enlace, PPP y Ethernet, y de un protocolo de la capa de enlace encapsulado, PPPoE. Tambien hablarernos sobre el dispositivo de buck de retorno local que ofrecen muchas pilas IP, del protocolo ARP y del rnetodo utilizado para dcterminar los tamafios de paquete que deberian utilizarse cuando se atravies an internetworks como la que se ve en la Figura 2.1.

ppp

El RFC 1661 define el PPP (Point-to-Point Protocol, Protocolo punto a punto), que "proporciona un metodo estandar para transportar datagram as

I EI Dia de los inoccntes en Estados Unidos y Gran Brctana es cl dia de Internet. Cada ano, cl uno de ahril, se publican una serie de RFC poco scrios. EI RFC I 14l) cs uno de ellos.

18 Capitulo 2 Protocol os de la capa de enlace

multiprotocolo por enlaces de punto a punto". PPP se utiliza para conectar muchas computadoras caseras a Internet y para ofrecer una conexion neutral en cuanto a distribuidor entre encaminadores.

Red PPP

Figura 2.1. Dos LAN con una conexi6n PPP:

PPP ha suplantado al SUP (Serial Line IP, IP de linea en serie), un protocolo anterior descrito en el RFC 1055. SUP Y SUP comprimido (Compressed SLIp) carecen de algunas de las caracteristicas que aporta PPP:

• SUP no ofrece ningun mecanismo para transferir ningun protocolo aparte de IP.

• SLIP no tiene un mecanismo de comprobacion de errores, dejando el trafico abierto a la corrupcion debido a los problemas de la linea telefonica,

• No hay ningun metodo para anunciar direcciones IP en SUP. Debemos conocer la direccion IP de cada lade de la conexion antes de comenzar 2.

Estudio sobre PPP

Los marcos PPP tienen un encabezamiento de 5 bytes, hasta 1500 bytes de datos y despues un trailer de 3 bytes. El encabezamiento contiene un indicador de inicio de 1 byte (siempre Ox7e) 3, un campo de direccion de 1 byte (siempre Oxff), un campo de control de 1 byte(siempre Ox03) y un campo de protocolo de 2 bytes (lP es Ox0021).

Todos los valores del campo de protocolo tienen que ser mimeros impares y pueden indicar datos del LCP (Link Control Protocol, Protocolo de con-

2 La gran rnayoria de las conexiones PPP modernas permiten al cliente PPP "descubrir" su direccion IP consultando al servidor PPP. 10 que hace que los servidores PPP puedan ofrecer conexion por marcacion(dtal-up) a los usuarios finales sin obligarles a configurar su direccion IP cada vez que se conecten.

3 Siempre que veamos un ruimero precedido del prefijo Ox, es un numero hexadecimal. La mayor parte de los mirneros con los que trataremos en las descodificaciones TCP/IP son hexadecimales.

Capitulo 2 Protocol os de la capa de enlace 19

trol de enlace), datos del NCP (Network Control Protocol, Proto colo de control de red) 0 datagram as encapsulados de un protocolo de nivel superior.

LCP proporciona un canal para la comprobaci6n, configuracion y estahlecimiento de enlace. Este es el mecanismo utilizado para negociar las direcciones IP y otras opciones.

Los NCP son especificos de los protoeolos de capa de red. Estos protocolos permiten que se negocien opciones adicionales.

PPP descodificado

La Figura 2.2 nos muestra un marco PPP tipico'. EI indieador de inicio no se muestra, porque en realidad es solo un marcador para indicar trafico significativo en lugar de ruido de linea. EI primer byte (Oxft) es el campo de Direccion, El segundo byte (Ox03) representa al campo de Control. Los siguientes 2 bytes (Oxc021) representan una peticion eco LCP. EI resto del paquete es carga util especiflca de LCP.

rn Fram€ 1 (16 on I'll reo 15 c aptur ed) El comt-to-comr Protocol

Addr-ess: ff

Cnntrol: 03

Protocol: LlnkControl Protocol (0)((021)

BLink contro l or ot oco t

Code: Echo Request (0)(09) tcent: f i e r : 0)(/7

Length: 8

Magi.:: number: [lxlb9a,:(55

0000 OJ cO 21 09 77 00 08 tb 9a C( 55 rc 7841 49 .. !.w ..... UlxAI

Figura 2.2. Un marco PPP

Ethernet

Aunqe normalmente hablamos de Ethernet como de un unico protocolo, en realidad dos protocolos distintos implementan Ethernet en la capa de enlace. EI mas utilizado es Ethernet II, deserito en el RFC 894. Menos utilizado es el Ethernet estilo 802.3 IEEE, definido por el IETF en el RFC 1042. Son necesarios los hosts de Internet para comprender Ethernet II y pueden implemen tar 802.3. Si ofrecen 802.3, debe ofrecerse Ethernet II, y deberia ser el

• Vease la seccion "Ethereal" del capitulo 10. "Herramientas de revision", pard mas inforrnacion sobre como leer estas pantallas Ethereal.

20 Capitulo 2 Protocolos de la capa de enlace

elemento predeterminado 5. Explicaremos Ethernet en terminos de Ethernet II y sefialaremos las areas en las que 802.3 difiere.

La especificaci6n de Ethernet original fue publicada conjuntamente por DEC, Intel y Xerox en 1982. Utiliza un bus compartido (logico 0 fisico) para la comunicaci6n y controla el acceso mediante acceso multiple con sentido portador con deteccion de colisi6n (CSMA/CD). Esto significa qe todos los hosts de una LAN comparten un dispositivo de comunicaciones cormin (acceso multiple). Cuando un dispositivo tiene trafico que enviar, escucha a la espera de una apertura (sentido portador) y despues intenta enviar su mensaje. Si mas de un host intenta enviar datos a la vez, se produce una colisi6n, y ambos hosts esperan un periodo corto de tiempo y 10 vuelven a intentar.El periodo de espera es aleatorio para evitar que los equipos vuelvan a colisionar. Esto es muy parecido al mecanismo que utilizamos cuando intentamos mantener una conversacion en una habitaci6n llena de gente. Esperamos a que haya una pausa y entonces comenzamos a hablar. Si otra persona habla al mismo tiempo, se produce una pausa corta y alguien empezara a hablar mientras que los demas miembros de la conversacion esperan.

Estudio sobre Ethernet

Los paquetes de Ethernet estan compuestos de un encabezarniento de 14 bytes, un campo de datos de 46 a 1500 bytes y una CRC (Cyclic Redundancy Check, Comprobaci6n de redundancia ciclica) de 4 bytes. Los primeros 6 bytes del encabezarniento forman la direcci6n Ethernet (tambien llamada direccion MAC 0 direcci6n de maquina) del sistema de destino. Los segundos 6 bytes representan la direccion MAC del sistema de origen. Los ultimos 2 bytes del encabezarniento son el campo de Tipo 6. La Tabla 2.1 muestra algunos de los c6digos de tipo mas utilizados.

Tabla 2.1.

C6digos de tipo de Ethernet de interes.

C6digo de tipo

Tipo de carga iitil

Ox0800 Ox86DD Ox0806 Ox8035 Ox809B

IPv4

IPv6

ARP RARP AppleTalk

, Los RFC ofrecen una definicion bastante estricta de 10 que los hosts deberian hacer y de 10 que deben hacer. Intentamos seguir la utilizacion que hacen de estos terminos. Si un host "debe" hacer algo, no se considera que tenga una lmplementaclon de acuerdo con los estandares si Calla al hacerlo, Si un host "deberia" hacer algo, aun puede estar de acuerdo a los estandares inc1uso sin ese comportamiento. Estos terminos se definen en el RFC 2119.

6 En Ethernet 802.3, los bytes 13 y 14 son un campo de Longitud. Esto exige que los paquetes 802.3 Ueven informacion de c6digo de tipo en otro encabezamiento dentro de su campo de Datos.


Como hay una longitud minima de 46 bytes para el campo de datos de Ethernet, puede que los datos necesiten relleno , bytes adicionales que suban la cuenta de bytes del campo de datos hasta el tamafio minima.

Los paquetes de menos de 64 bytes (14 bytes de encabezarniento, 46 bytes de datos y un trailer de 4 bytes) se Haman alfefiiques y se ignoran 7 Los paquetes de mas de 1518 bytes (14 bytes de cncabezarniento, 1500 bytes de datos y 4 bytes de CRC) se Haman gigantes y tambien se ignoran,

Las direcciones MAC estan compuestas de dos secciones. Los primeros 3 bytes son un campo de identificacion de distribuidor, Los segundos 3 bytes representan un ID unico para cada tarjeta H.Hay posibilidades de direcciones adicionales en la direccion de destino. Activar el bit de valor mas bajo en el primer byte representa una direccion de multiconversion, un mensaje cnviado a multiples hosts de la red. Activar todos los bits de la direccion de destino representa una forma especial de multiconvcrsion Hamada difusion.

Es importante recordar que solo porque un paquete este dirigido a un host especifico (0 una direccion de multiconversion escuchada por multiples hosts), no es privado. Todos los hosts de un segmento de Ethernet recibcn todos los paquetes enviados en ese segmento. (Esto es 10 que permite trabajar a los analizadores de red.) Norrnalrnente, cada host procesa solo aquellos paquetes que vienen dirigidos a el, incluidas multiconversiones y difusiones, e ignora los que estan dirigidos a otros hosts. La direccion de destino se coloca al principio para permitir que los hosts que siguen este comportamiento puedan manipular el trafico Ethernet de manera mas eficiente.

Esto indica claramente una gran diferencia entre PPP y Ethernet. PPP es un protocolo punto a punta; el trafico solo 10 pueden ver los dos puntas finales del circuito (y cualquier equipo especial introducido en este). Ethernet es un media de difusion; todo elemento de la LAN oira cada porcion de trafico enviada 9.

Ethernet descodificado

EI diagrama de la Figura 2.3 muestra un marco de Ethernet II. En este marco, la direccion de destino esta establecida en ff:ff:ff:ff:ff:ff (la direccion de difusion), la direccion de origen es 00:eO:98:7c:95:21 yel campo de Tipo es Ox0806 (ARP).

7 Toman ancho de banda y presentan una condici6n de problema que deberia corregirse.

H Aunque, en teoria, estes 3 bytes son unicos, cxistcn algunas circunstancias que rornpen est a regia. Algunas tarjetas Ethernet y algunos sistemas operatives (incluido Linux) nos permit iran establecer una direcci6n MAC diferente; la asignacion de una direccion duplicada puede provocarnos serios problemas. Adernas, algunos distribuidores han tenido problemas de control de calidad dando como resultado la asignacion de dtrecciones duplicadas. Afortunadamcntc, estc ultimo caso es bastante raro.

<) En las redes conmutadas de hoy en dia, csre no es necesarlamente eI caso. Veasc la breve expltcacion sobre los interruptores al final del Capitulo I, "Prologo a una guia practica".


Ell Fr"", 6 (42 on wi reo 42 captured) 13 Ethernet II

Oesti nat; on: ff: ff: ff: ff: ff: ff (ff: ff: ff: ff: ff: ff) Source: 00:eO:9B:7c:95:21 (00:eO:9B:7c:95:21) Type: AAP (0.0906)

IE Address Resolution Protocol (request)

Figura 2.3. Un marco Ethernet capturado.

PPPoE

EL RFC 2516 describe PPPoE (PPP over Ethernet, PPP en Ethernet), un metodo de encapsular paquetes PPP en Ethernet. Este protocolo se utiliza normalmente para ofrecer servicio de DSL (Digital Subscriber Line, Linea de suscriptor digital) a los suscriptores.

Estudio de PPPoE

El protocolo PPoE separa el trafico en dos clases, cada una de ellas enviada durante una etapa diferente de la sesion de red. La sesion comienza con una etapa de descubrimiento y despues pasa a una etapa de sesi6n PPP.EI ID de tipo de Ethernet es diferente para las dos etapas. En la etapa de descubrirniento, es Ox8863; en la etapa de sesion PPp, es Ox8864. El encabezamiento PPPoE es el mismo durante ambas fases del protocolo.

EI encabezamiento PPoE es de 6 bytes y contiene cinco campos. Los primeros 4 bits componen el campo de Version y se establecen en Oxl. Los segundos 4 bits denotan el campo de Tipo y se establecen en Oxl. EI siguiente campo es de 1 byte de largo y representa el campo de Codigo; este campo se define de manera separada para las etapas de descubrimiento y de sesion PPP (veanse las dos siguientes secciones para mas informacion). El siguiente campo es el campo de ID de sesion, que tiene 2 bytes de longitud (vease la seccion "Etapa de descubrimiento" para la descripcion de este campo). EI ultimo campo, el campo de Longitud, tiene 2 bytes e indica la longitud de la carga util del PPPoE (excluyendo los encabezamientos PPPoE y Ethernet).


En una sesion PPPoE resultan implicados dos hosts. EI host de inicio se llama cliente; es nuestro equipo. EI servidor (tambien llamado concentrador de acceso) es el host con el que nos estamos conectando en el ISP

Etapa de descubrimiento

Durante la etapa de descubrirniento, la carga uti! del paquete PPPoE lleva una serie de tags bien definidos. Cada tag esta compuesto de tres campos. El primero tiene 2 bytes de longitud y representa el tipo de tag. EI segundo campo representa la longitud de tag y tiene tambien 2 bytes de largo. EI tercero es el campo de Valor del tag, que tiene una longitud variable. La Tabla 2.2 muestra algunos tipos y valores de tag con su significado.

Tabla 2.2. Valores y tags de la etapa de descubrimiento de PPoE.

Tag Nombre de tag

Significado y valor

Este tag indica que no hay mas indicadores en el paquete. Su longitud de tag es de OxOOOO; no hay valor de tag. Este tag es opcionaL

Este tag se uti!iza para so!icitar 0 aprobar un servicio dentro de la sesi6n PPPoE (por ejernplo, ca!idad de servicio). EI valor del tag lleva el nombre del servicio.

Este tag da el nornbre del concentrador de acceso (el servidor PPPoE). EI nombre es un identificador unico. EI valor del tag es con frecuencia una representacion de la dtreccion MAC del servidor,

Ox0105 Especifico del distribuidor Este tag puede utilizarse pard pasar informacion patentada del distribuidor. EI contenido del campo de Valor de tag comienza con un ID de distribuidor de 4 bytes, que es OxOO, seguido de la porcion del distribuidor de 3 bytes de la direccion MAC de Ethernet. No se recornien-

OxOOOO Fin de !ista

OxO 101 Nombre de servicio

Ox0102 Nornbre del concentrador

de acceso

da la uttlizacion de este tag y puede ser ignorado legalmente por cualquier implementacion.

Ox0201 Error de nombre de servicio Este tag tiene normalmente una longitud de

OxOO e indica que el servicio so!icitado no puede ser concederse. Si hay datos en el campo de Valor de tag, deben contener una explicacion que se pueda imprimir de la ncgacion de la petieton de servicio.

Iniciaci6n del descubrimiento activo de PPPoE

La etapa de descubrimiento comienza cuando el cliente envia un paquete de PADI, (PPPoE Active Discovery Initiation, Iniciacion del descubrimiento activo de PPPoE) a la direccion de difusion de Ethernet. EI campo de Codigo


se establece en OX09. El ID de sesi6n se establece en OxOOOO. El paquete PADI debe llevar un tag de nombre de servicio y puede no llevar otros tags.

Oferta de descubrimiento activo de PPPoE

Cualquier concentrador de acceso de la red local puede responder con un paquete de PADO (PPPoE Active Discovery Offer, Oferta de descubrimiento activo de PPPoE) si es capaz de servir la solicitud. En un paquete PADO, el campo de C6digo se establece en Ox09 y el ID de sesion se establece en OxOOOO.

El paquete PADO debe llevar un tag de nombre de servicio que se corresponda con el del paquete PADI y un tag de nombre AC que contenga su propio nombre unico. Puede contener tambien cualquier cantidad de tags de nombre de servicio que indiquen los servicios que ofrece el concentrador de acceso.

Solicitud de descubrimiento activo de PPPoE

Habiendo recibido uno 0 mas paquetes PADO, el cliente selecciona uno y responde con un paquete de PADR (PPPoE Active Discovery Request, Solicitud de descubrimiento activo de PPPoE). El campo de Codigo se establece en Ox19 y el ID de sesi6n se establece en OxOOOO. El paquete PADR debe contener un tag de nombre de servicio que indique el servicio que solicita el cliente. Tambien puede contener otros tags.

Confirmaci6n de sesi6n de descubrimiento activo de PPPoE

El servidor responde a un paquete PADR con un paquete de PADS (PPPoE Active Discovery Session Confirmation, Confirmacion de sesi6n de descubrimiento activo de PPPoE). El campo de C6digo se establece en Ox65 y el ID de sesi6n se establece en un valor de 2 bytes que identifica de manera unica

. esta sesion,

El paquete PADS debe contener un tag de nombre de servicio y puede contener otros tags. Si no puede aceptar el nombre de servicio del PADR, debe responder con un PADS que contenga un tag de error de nombre de servicio. El ID de sesi6n se establece en OxOOOO.

Cuando se ha enviado el paquete PADS, se ha iniciado la sesi6n PPPoE y comienza la etapa de sesi6n PPP.

Terminaci6n de descubrimiento activo de PPPoE

Cualquier host implicado en la sesion PPPoE puede cerrar la sesi6n enviando un paquete de PADT (PPPoE Active Discovery Terminate, Terminacion de descubrimiento activo de PPPoE). El paquete PADT tiene un campo de C6digo de Oxa7 y un ID de sesion que se corresponde con el identificador unico de las sesiones. En un paquete PADT no se necesitan tags.

Despues de que se haya recibido un paquete PADT no se puede enviar mas trafico por una sesion PPPoE.

Capitulo 2 Protocolos de la capa de enlace 25

Etapa de sesi6n PPP

Cuando se ha completado la etapa de descubrimiento, puede dirigirse trafico PPP normal dentro de la scsi on PPPoE. Todo el trafico Ethernet es de uniconversion a 10 largo de la sesion. EI campo de Codigo de PPPoE se establcce en OxOO para todo el trafico de la sesion y la carga util de PPPoE es un paquete PPP.

PPPoE descodificado

La Figura 2.4 muestra un marco PAD!. EI campo de Version es Oxl EI campo de Tipo es Ox 1. EI campo de Codigo es Ox09 (PADI). EI II) de sesion es OxOOOO. EI campo de Longitud de carga util es Ox0004. EI paquete ticne s610 un tag, un tag de nornbre de servicio. EI tipo de tag es OxO 1 01. La longitud del tag es OxOOOO.

0000 ff ff ff ff ff ff 00 aD d2 tc 64 e8 88 63 11 09 0010 00 00 00 04 01 01 00 00 00 10 55 73 6S 72 20 72 0020 6571 756573 74 27 ee E.9 9d 11 Oa 60 80 cO aa 0030 01 01 00 8a 00 cf 00 00 20 46 43 45

.... d .. c ..

~Q~~~t~: 1:~s~r.r

......... FeE

lB Frame 1 (60 on wi reo 60 captured) m r ther net II

El PPPoE Discovery

Version: 1 Type: 1

Code: Active n+scoverv Initiation (PADI) ses sion 10: 0000

Payload length: 4

B PPPoE Tags

Tag: servtce-Nere

Figura 2.4. lin marco PADI de PPPoE.

La Figura 2.5 muestra un marco PADO. El campo de Version se establece en Oxl, igual que el campo de Tipo. EI campo de Codigo es Ox07 (PADO). EI ID de sesion es OxOOOO. EI campo de Longitud de carga util es Ox002a. Estc marco tiene tres tags: un tag de nombre de concentrador de acceso, un tag de nombre de servicio y un tag de cookie. EI tag de nornbre de concentrador de acceso tiene un tipo de tag de OxOl02. Su longitud de tag es d OxOOOe. Contiene la cadena de 15 bytes "crashtestdummy" como su valor de tag.

En la Figura 2.6 podemos ver un marco PADR. En estc paquete los campos de Version y de Tipo se establecen en Ox l . Su campo de Codigo es Ox19 (PADR). EI II) de sesion aun es OxOOOO. El campo de Longitud de carga util es OxOOI8. Este paquetc lleva dos tags: un tag de nombre de servicio y un tag de cookie.

La Figura 2.7 muestra un marco PADS. Sus campos de Version y de Tipo son Ox I. EI campo de Codigo se establece en Ox65 (PADS). Se ha asignado el ID de sesion y es OxOOO!. La Longitud de carga util es Ox0004. Este paquete s610 tiene un tag, el tag de nombre de servicio.


0000 00 aD d2 1< &4 88 00 so d2 tc 64 db 88 63 11 01 0010 00 00 00 2a 01 02 00 De 63?2 61 73 68 74 65 73 0020 74 64 75 6d 6d 79 01 01 00 00 01 04 00 10 8b ab 0030 fa dd 41 cc fd 67 ac Of 3b 88 <1 78 61 d3

•••• d ..... d •• c ..

.......... crashtas

tdlJllllY ••••••••••

• • C •• g •• ; •• X8.

ED Frame 2 (62 on w1 re, 62 caQtured) ED Ethernet II

B PPPoE Discoyery version: 1 Type: 1

Code: Acti ve 01 sccverv Offer (PADO) Sassi on 10: 0000

payload length: 42

B PPPoE Tags

Tag: AC-Name

String Data: crashtestdlllTl'l'l Tag: Service-Mame

Tag: AC-Cookie

Binary Data: (16 bytes)

Figura 2.5. Un marco PADO de PPPoE.

0000 00 aD d2 1< &4 db 00 aD d2 1< 64 e8 88 63 11 19 0010 00 00 00 " 01 01 00 00 01 04 00 10 II> ab fa dd 0020 47 ec fd 67 ac Of 3b eI ct 78 61 d3 00 67 f6 d6 0030 3< bf ad ed ad 79 4d fa dd 5b 13 ea

•••• d ••.•• d •• c ..

m frame 3 (60 on wi reI 60 captured) II Ethernet II

Version: 1 Type: 1

Code: Actt\l8 Discovery Request (PAOR) Sassi on 10: 0000

Payload Length: 24

9 PPPoE Tags

Tag: Serv1ce-ftame Tag: AC-Cook1 e

81 nary Data: (16 bytes)

............. "".

C •• 9 •• ; •• xa .. g ••

c .••• '1'1'4 •• [ ••

Figura 2.6. Un marco PADR de PPPoE.

DODO 00 aD el2 tc &4 e8 00 aD el2 1c 64 db 88 63 11 65 0010 00 01 DO 04 01 01 0000 el2 tc 64 db cO as 01 14 0020 00 aD d2 tc &4 ea cO a8 01 01 00 04 00 64 00 00 0030 00 00 00 00 00 00 00 00 DO 00 00 00

.... d ..... d .. c.e

: :::d::: : :d: :d::

fB Frame 4 (60 on wi reo 60 captured) Hi Ethernet II

B PPPoE 0; sccverv Version: 1 Type: 1

Code: Active Discovery Session-confi rmatf on (PADS) Sessi on 10: OD01

Payload length: 4

9 PPPoE Tags

Tag: Serv1 ce-ftame

Figura 2.7. Un marco PADS de PPPoE.

En la Figura 2.8 se muestra un tipico marco de sesion PPPoE. Tiene unos campos de Version y de Tipo de Oxl. El campo de Codigo es OxOO (Sesion), El ID de sesion es OxOOOl. La Longitud de carga util es OxOOl6. La carga iitil de este paquete es un paquete LCP de PPP.


. >~~.: ~~'~:;'.~>

F'"E

[±] r r ene '] (bO on wi r e • 50 c aotur edj

[±)Ethern8t II

verst cn: I Type: 1

P3yl'J3d L8ngth:::_::_

8 Point-to-Point Protocol ttl L -in}

Figura 2.S. lin marco de scsion de !'!'!'oE.

La interfaz de bucle de retorno

La iruerfaz de bucle de retorno es un dispositive logico que ofrece la mayoria de las pilas de protocolos IP. lJtiliza la red de clase A 127 Y normalmente se le asigna la direccion 127.0.0.1 y el nornbre localbost. En un host Linux, la interfaz 10 se utiliza para hacer un bucle de retorno, como mostramos aqui:

[root@cherry /rootj# ifconfig 10

10 Link encap:Loca1 Loopback

inet addr: 127.0.0.1 Mask: 255.0.0.0

UP LOOPBACK RUNNING MTU:3924 Metric:1

RX packets:18 errors:0 dropped:0 overruns:0 frame:0 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 co11isions:0 txqueue1en:0

[root@cherry /rootj#

EI trafico enviado a la direccion de bucle de retorno no aparece nunca en ninguna red adjunta. Un aspecto especial de esta interfaz es que el trafico enviado desde un host a si mismo se redireccionara a la dircccion de buck de retorno.

La interfaz de bucle de retorno se utiliza norrnalmente para cstablecer conexiones de red entre aplicaciones basadas en cltente-serutdor hospedadas en la misma maquina, (como el sistema de ventanas XII). Esto ayuda a evitar el trafico de la red local e incluso permite que dichas aplicaciones funcionen en auscncia de una red fisica.

La Figura 2.9 muestra una interfaz de bucle de retorno con un PPP y una interfaz Ethernet. EI flujo Iogico de trafico a y desde la capa II' 10 mucstran las flechas del diagrama.


Transmisi6n IP

Recepci6n de IP

Bude de retorno local

Transmisi6n de ppp

Recepci6n de ppp

Transmisi6n Recepci6n

de de

Ethernet Ethernet

Figura 2.9. Diagrama de la interfaz de bucle de retorno.

ARPyRARP

Si el protocolo de la capa de enlace soporta multiples hosts (como Ethernet II), IP debe tener un medio de relacionar una direccion IP con la direccion de la capa de enlace. Esto se consigue mediante ARP (Address Resolution Protocol, Protocolo de resolucion de direcciones). El ARP de IP en Ethernet esta definido en el RFC 826. RARP (Reverse ARP, ARP inverso) es un protocolo muy relacionado que se define en el RFC 903.

Si volvemos a pensar en la analogia de la habitacion llena de gente hablando que utilizamos para representar una LAN Ethernet, ARP seria como preguntar: "lquien es Tom?" Cuando alguien conteste, podemos empezar a hablar con el. En realidad, ARP pregunta: "lquien tiene la direccion IP X.X.X.X?" Cuando obtiene respuesta, comienza una conversacion de nivel IP con ese host.

ARP NO ES ENCAMINABLE

Como ARP va directamente con los protocolos de la capa de enlace, no con un protocolo de la capa de red, no es encaminable 10.

10 Como algunos hosts no pueden determinar adecuadamente su propia red y ARP para direcciones de redes remotas, existe un metodo altemativo. Proxy ARP permite que un encaminador conteste a peticlones ARP de hosts de cualquier red remota a la que sepa Uegar. Vease el Capitulo 3 para mas informacion sobre el encaminamiento.


ARP

ARP necesita dos tipos de paquetes: peticiones ARP (que piden la direccion MAC que se corresponde con una direccion IP) y respuestas ARP (que dan la correspondencia entre dos direcciones). En la mayoria de los casos, la respuesta la envia la maquina que tiene asignada la direccion IP que se solicita. Algunos hosts mas antiguos no pueden deterrninar adecuadamente si un host cs local de su red. En este caso, ARP proporciona un mecanisme para contestar a los ARP inapropiados de csos sistemas, proxy ARP. Linux nos permite configurar un bost para dar respuestas de proxy ARP configurando una entrada de cache ARP tal y como se edita con el indicador. Cuando esta establecido este marcador, tam bien puede estarlo el indicador y las entradas de cache AIU) pueden hacerse a un unico host 0 a toda una subrcd.

Los paquetes de peticiones ARP estan compuestos de 10 siguicntc: un tipo de hardware de 2 bytes, un tipo de protocolo de 2 bytes, una longitud de dircccion de hardware de 1 byte, una longitud de direccion de protocolo de I byte, un opcode de 2 bytes con un valor de 000 I, una direccion de hardware de remitente de longitud variable, una direccion de protocolo de rernitente de longitud variable, una direccion de hardware de objetivo de longitud variable y una direccion de protocolo de objetivo de longitud variable. La direccion de hardware de objetivo normalmente se rellena con ceros.

Los paquetes de respuesta ARP son parecidos a los de peticiones descritos anteriormente, excepto en que el valor de opcode es 0002 y que el campo de Direccion de hardware de objetivo se rellena con la dircccion MAC apropiada.

Aunque ARP se utiliza generalmente para determinar la direccion de hardware de otro sistema, algunas rnaquinas estan configuradas para llevar a cabo un "ARP gratuito". Cuando el bost saca su tarjeta de interfaz de red, utiliza ARP como su propia direccion IP Este mecanismo puede ayudar a reducir los conflictos de direcciones IP

EI sistema operativo mantiene la informacion ARP en un bost en una tabla ARP

En una plataforma Linux, puede verse esta informacion con el comando ARP, como en este ejemplo:

[root@cherry /rootj# arp -a

? (192.168.1.1) at 00:A0:D2:1C:64:E8 [ether] on eth0 ? (192.168.1.11) at 00:C0:F0:26:B1:EC [ether] on eth0 [root@cherry /root]#

Las entradas de Ia tabla ARP (mas apropiadamente, la cache ARP) pueden ser perrnanentes (creadas con las opciones 0) 0 dinarnicas (descubiertas autornaticamente). Normalmente, las entradas dinarnicas tienen un ticmpo muerto de 1') minutos; es decir, a un host que no sc haya comunicado en I') minutos 0 mas se le volvera a pasar por ARP Este proceso anticuado de las entradas de cache ARP minimiza el peligro de que una tarjeta de red sea re-


emplazada en un host remoto, cambiando as! la relaci6n direcci6n MAC-direcci6n IP.

HARP

RARP se utiliza para permitir que un host consiga su propia direcci6n IP dinamicamente 11. Una gran diferencia es que en ARP, cada host es responsable de hacer la correspondencia de su propia direccion IP con su direcci6n MAC, mientras que en RARP, se configuran uno 0 mas servidores para proporcionar la correspondencia de los hosts que esten haciendo RARP.

Los paquetes RARP estan identificados con el tipo de Ethernet II de 0800.

Las peticiones tienen un opcode RARP de 3 y las respuestas tienen un opcode de 4. No hay opcodes de "error" 0 "no encontrado", porque otro host de la red puede responder a la respuesta, pero, por 10 dernas, los paquetes RARP son parecidos a la estructura de los paquetes ARP.

Uno de los principales falIos de RARP es que es no encaminable. Como es un protocolo de capa de enlace, esta confinado a una unica LAN. Esto significa que cada LAN que tenga hosts haciendo RARP debe tener al menos un residente servidor RARP configurado.

ARP descodificado

En la petici6n ARP que mostramos en la Figura 2.10, mango esta solicitando una direcci6n de hardware a cherry. El tipo de hardware esta establecido en OxOOOI (Ethernet) y el tipo de protocolo en Ox0800 (lPv4). La longitud de direcci6n de hardware es Ox06 y la longitud de direcci6n de protocolo es Ox04, 6 y 4 bytes respectivamente. El opcode ARP esta establecido en OxOOOI (petici6n). La direcci6n de hardware del remitente esta establecida en OO:aO:d2:1c:64:a8 y la direccion de protocolo del remitente es 192.168.1.1. La direcci6n de hardware del objetivo es desconocida y se establece en 00:00:00:00:00:00, mientras que la direcci6n de protocolo del objetivo se establece en 192.168.1.10.

Cuando cherry responde a la peticion de mango, la mayor parte de los datos siguen siendo los mismos. El opcode ARP se cambia a Ox0002 (respuesta) y las direcciones del remitente y del objetivo se han intercambiado. Como cherry le esta dando a mango su direcci6n de hardware, la direcci6n de hardware del remitente se ha cambiado de todo 0 a 00:eO:98:7c:95:21 (vease la Figura 2.11).

La Figura 2.12 muestra un paquete RARP enviado por un servidor Sun que se esta cargando de la red. Igual que en los paquetes ARP que vimos anteriormente, el tipo de hardware es OxOOOI (Ethernet), el tipo de protocolo es Ox0800 (lPv4), la longitud de hardware es Ox06 (6 bytes) y la longitud de pro-

11 RARP ha sido en su mayor parte superado por los protoco!os BOOTP y DHCP.


toeolo es Ox04 (4 bytes). EI opcode es Ox0003, representando una petici6n RARP. Las direeciones de hardware de remitente y de objetivo estan am bas establecidas en 08:00:20:7e:40:af, la direcci6n MAC de la maquina que esta solicitando una direcci6n IP Las direceiones IP de remitente y de objetivo estan am bas estableeidas en 255.255.255.255.

ffi Frame 5 (60 on wi reo So captured) BEthernet II

Destination: 00:eO;98:7c:95:21 (OO:eO:98:7c:95:21) Source: OO:aO:d2:1c:64:e8 (OO:aO:d2:1c:64:e8)

Type: ARP (0)<0806)

El Address Resolution Protocol (request) Hardware tvoe: Ethernet (0.0001) Protocol type: IP (Ox0800)

Hardware size: E.

Protocol size: 4

oocode: request (0)<0001)

Sender harct.-vare address: OO:aO:d2: 10::&4:e8 Sender protocol address: 192.168.1.1

Target hardware address: 00:00:00:00:00:00 Target protocol address: 192.1[,8.1.10

14

0000 00 eo 98 7c 95 21 00 an d2 1e b4 £18 08 06 00 01 ... I.!.. .d ...

0010 08 00 06 04 00 01 00 en d2 t c 64 88 cO a8 [11 01 .d ..

0020 DO 00 00 00 00 00 co a8 01 Oa 00 00 11 00 00 00

0030 48 49 53 54 43 4d 44 00 00 00 00 00 HIST01).

t:1

Figura 2.10. un paquete de peticion ARP.

1II Frame 6 (42 on wi r e , 42 captured) B Ethernet II

Destination; OO:aO:d2: 1c:64:e8 (00:aO:d2:1c:64:e8) Source: 00:eO:98:7c:95:21 (00;eO:98:7c:95:21)

Type: ARP (0;.:0806)

B Address Resolution Protocol (reply) Hardware type: Ethernet (0:-:0001) Protocol type: IP (0;.:0800)

Hardware size: 6

Protocol size: 4 ooccde: reply (0)<0002)

Sender hardware address: 00:eO:'38: zc: 95:21 Sender protocol address: 192.168.1.10 Target hardware address: 00:aO:d2:1c:64:e8 Target protocol address: 192.168.1.1

0000 00 aO d2 t c 64 e8 00 eO 98 7c 95 21 08 06 CO 01 0010 08 CO 06 04 00 02 00 eO 98 7c 95 21 en aa 01 Oa 0020 00 aO d2 t c 64 e8 cu aa 01 01

. I.!. .1. ..

.. d .. .... d ..

Figura 2.11. Un paquete de respuesta ARP

!±l Frame 1 (64 on wi reo 64 captured) 1II Ethernet II

EI Address Resol ut ton Protocol (reverse request) Hardware type: Ethernet (0:-:0001)

Protocol IP (Ox0800)

Hardware

Protocol size: 4

encode: reverse request (0,,0003)

Sender hardware address; 08:00:20: 7e:40:at' Sender or otocot address: 255.255.255.255 Target hardware adl1ress: 08:00:20: 7e:40:af Target protocol address: 255.255.255.255

0000 ff ff ff ff ff ff 08 00 20 7e 40 af 80 :.5 00 01 0010 08 00 06 04 00 03 08 00 20 ie 40 af ff ff ff ff 0020 08 00 ..'0 h: 4U af ff ff ff ff 00 00 00 00 00 00 0030 0000000001] 00 00 00000000000000 DO 00

. -iI .. 5 ..

. -iI ..

.~.

Figura 2.12. Un paquete RARP.


MID

Cada uno de los protocolos de la capa de enlace impone diferentes limites a los paquetes que lleva. Entre estas restricciones esta el tamafio maximo del paquete, llamado MTU (Maximum Transmission Unit, Unidad de transmiston mixima).Normalmente, PPP utiliza una MTU de 296, Ethernet una de 1500 y FDDI Y Token Ring de 4Mbps una de 4464.

Como cada capa de enlace puede definir una MTU diferente y un paquete podria atravesar multiples redes camino de su destino final, se define una MTU de ruta. En el Capitulo 3. "Protocolos de la capa de red", veremos la fragmentacion IP (un posible resultado de tener MTU diferentes) y como evitarla utilizando el descubrimiento de la MTU de rota. En la Figura 2.13 se muestra un ejemplo de MTU de rota.

ppp

Anillo FDDI

Figura 2.13. Una internet con varios protocolos de capa de enlace representados.

En este ejemplo, la MTU de rota es 296 porque el enlace PPP que se encuentra entre la LAN Ethernet por un lado y el anillo FDDI por el otro ha negociado un indice mas bajo del que se utiliza normalmente.

3

Protocolos de la capa de red

La cap a de red (0 capa de internetu-orkv marca el punto en que el trafico escapa de los confines de una red (mica. Tambien seriala el punto don de las direcciones dan con su primera capa de abstraccion (como mostramos en la seccion HARP" del Capitulo 2, "Protocolos de la capa de enlace"). En nuestro debate sobre la capa de red, cubrirernos las direcciones II~ las subredes y superrcdes, el encarninamiento Ip, el filtrado de paquetes, la NAT (Network Address Translation, Traducci6n de direcciones de red) y la version 4 de 11' (la version que mas se utiliza actualmente).

Debido a que las direcciones Ip, las subredes y el encaminamiento estan ligados de forma muy intrincada, es dificil hablar de uno de ellos sin hacer referencia a los otros. Si esto le provoca algo de confusi6n cuando 10 lea, por favor, satisfaga su curiosidad rccurriendo a la seccion apropiada en busca de una aclaracion.

Direcciones IP

Antes de hablar del protocolo Ip, nos tomaremos algo de tiempo para repasar las direcciones IP. Se asignan una gran variedad de direcciones IP a las organizaciones. En la mayoria de los cases son asignadas por el ISP de las empresas, aunque una compafiia puede solicitar sus propias direcciones IP en algunas circunstancias excepcionales. Cualquiera de estas direcciones IP asignadas puede encaminarse por Internet a rnenos que sea bloqueada por un firewall I.

I Mas concretamentc, podrian bloquearse por un filtro de paquetes. Los filtros de paquctes con trccuencia son parte de un fireuall, Esto es una diferencia pequena, pero irnportante.

34 Capitulo 3 Protocol os de la capa de red

Las direcciones IP indican el tamaiio de la red IP local y (en algunos casos) para que se utiliza. Esto se consigue dividiendo las redes en clases, como muestra la Tabla 3.1.

Tabla 3.1. Clases de direcciones de red.

Tipo de red Primer byte Patron

de dlrecclon de identificacion

Notas

Clase A 0-127 El primer bit es un cero Las redes de clase A pro-
porcionan 16.777.214 hosts
por red. La direcci6n de red
es de 1 byte de longitud.
Clase B 128-191 Los primeros 2 bytes Las redes de clase B pro-
son 10 porcionan 65.534 hosts por
red. La direcci6n de red es
de 2 bytes de longitud.
Clase C 192-223 Los primeros 3 bytes Las redes de c1ase C pro-
son 110 porcionan 254 hosts por
red. La direcci6n de red es
de 3 bytes de longitud.
Clase D 224-239 Los primeros 4 bytes La direcciones de c1ase D
son 1110 se utilizan para tcifico de
multiconversi6n.
Clase E 240-247 Los primeros 5 bytes Las direcciones de c1ase D
son 11110 estan reservadas para uso
experimental. Ademas de estas divisiones de las direcciones IP, se hace otra distincion.

Algunas de estas direcciones se apartan para direcciones privadas. El RFC 1918 aparta las siguientes direcciones para hosts internos de una compafiia:

10.0.0.0 172.16-31.0.0 192.168.0-255.0

Estas direcciones pueden utilizarse como veamos que encajan, siempre que no sean encaminadas por Internet. Permite que todo el mundo utilice el mismo conjunto de direcciones para sus redes internas. La amplia utilizaci6n de las direcciones del RFC 1918 es posible por el uso de NAT, que explicaremos mas adelante en este capitulo y tambien en el Capitulo 11, "Herramientas de seguridad". Por favor, ayudemos a conservar las direcciones IP disponibles utilizando direcciones privadas. Tambien es mejor para la seguridad de esas redes la utilizacion del espacio de direcci6n del RFC 1918 para nuestras redes internas. Utilizaremos las direcciones del RFC 1918 en los ejemplos tanto como nos sea posible. (Vease la secci6n "Traducci6n de direcciones de red", en este mismo capitulo, para mas informaci6n.)

Capitulo 3 Protocol os de la capa de red 35

Debido a que las redes de cIase A y B son demasiado grandes para una LAN normal, y como a veces tam poco encaja una red de cIase C, existe un rnetodo para dividir una red en porciones mas pequerias. Este rnctodo se llama subred, Las subredes se forman con la mascara de subred o mascara de red, otro numero de 4 bytes. Hablaremos de las subredes en la siguiente seccion, por 10 que dcjarernos la explicacion para mas adelante.

Cuando un equipo transmite trafico IP, debe tomar una decision sobre si el host objctivo es local 0 remote. Los hosts locales se direccionan directamente, 10 que significa que sc enviara el trafico a la dircccion MAC que se corresponda con la direccion IP objetivo. El trafico de los hosts remotos se cnvlara a la pasarela local de esa red remota (veremos el encaminamicnto en una scccion posterior; por ahora, s610 diremos que se produce). Esta dccision de encaminamiento se toma basandose en la direccion II' local (0 de origen) con su mascara de red y la direccion II' de destino. La dircccion II' de origen sufre una operacion AND 2 bit a bit con la mascara de red, igual que la direccion de destine. Despues, se comparan los dos numeros resultantcs (como muestra la Figura :'.1).

110000001010100000000001 0001000 192.168.1.16 Dlrecci6n

11111111 11111111 11111111 0000000 255.255.255.0 Mascara de red

1100000010101000000000010001000 192.168.1.16 Red

Figura 3.1. Dircccion IP y mascara de red con AND.

Si los resultados de estas dos operaciones AND bit a bit son iguales. los dos equipos son locales. En el caso contrario, los dos equipos son remotos.

Ejemplo 3.1. Decision de direccion local.

Origen Destino

Direccion: 192.168.1.100 Direccton: 192.168.1.2';

Mascara de red: 2'5';.25';.2'5'5.0 Mascara de red: 2'5'5.2';';.2'5';.0

Resulrado: 192.16H.1.0 Resultado: 192.168.1.0

Como los resultados del Ejemplo I concuerdan (la direccion de red de los dos hosts sufricron AND con la mascara de subred local), cstos hosts son locales cl uno con respecto al otro; se utilizara la direccion dirccta.

2 EI AND hit a hit significa que se cornprueba cada bit de las cosas. Si ambas son vcrd.ulcras ( I). cntonces cl resultado cs verdadcro. Si una 0 ambas son t'llsas (0). entO!1CCS cl rcsultado es falso. 5i sc ha hecho AND bit a bit a 10 «)OOOIOIO) v a 12 (00001100). cl rcsultado scria H (00001000).


Ejemplo 3.2. Decision de direccion remota.

Origen Destino

Direccion: 192.168.1.100 Direccion: 192.168.10.25

Mascara de red; 255.255.255.0 Mascara de red; 255.255.255.0

Resultado; 192.168.1.0 Resultado; 192.168.10.0

Como los resultados del Ejemplo 2 no concuerdan, estos hosts no son locales el uno respecto a1 otro; sera necesario encaminar el trafico entre eUos.

Subredes y superredes

Las subredes y las superredes proporcionan un medio para utilizar las direcciones IP de manera mas eficiente. Las subredes llevan en funcionamiento casi tanto como las direcciones IP, pero las superredes son mucho mas modernas (y, por tanto, no se conocen tan bien). En esta seccion, cubriremos la mecanica de las subredes, daremos algunos ejemplos practices y hablaremos de la mecanica de las superredes.

Estudio de las subredes

La mayoria de las empresas se encuentran con que una direccion de clase A es 0 demasiado grande 0 demasiado pequefia para sus necesidades. Tomemos por ejemplo una pequefia compafiia de software. Digamos que tiene cuatro redes en la oficina: una LAN para los departamentos de contabilidad y recursos humanos, asi como para los ejecutivos; una LAN para que los desarrolladores prueben las versiones inestables de su producto; la LAN que utilizan todos los demas; y la red segura en la que se encuentran los hosts accesibles a Internet de la empresa. Ninguna de las LAN tiene mas de 14 equipos (incluido el encaminador que conecta las cuatro LAN). Esta empresa no necesita cuatro redes de clase C; puede arreglarselas con solo una dividiendola en porciones del tamafio adecuado.

Las subredes nos ofrecen un rnetodo de fraccionar las redes. Nos dan un mecanismo para dividir la porcion de host de la direccion IP 3 en dos secciones: una porcion de subred y una porcion de host. El diagrama de la Figura 3.2 nos muestra esta division.

Red

Subred

192.168.1.16/28

Host

Figura 3.2. Una direccion IP mostrando los campos de subred y de host.

3 La porci6n de bost puede ser de 1, 2 0 3 bytes, dependiendo de la c1ase de la direcci6n.


Para dividir una red en subredes, debemos tener una mascara de subred 4. Las mascaras se especifican indicando que bits se utili zan para direcciones de red 0 de subred. Seria hastante tedioso decir que para la direccion de red 192.168.1.0, la mascara era cl siguiente patron de hits: 11111111111111111111111100000000. En su lugar, indicamos la mascara en decimales con puntos (como una direccion IP), 255.255.255.0, 0 mostrando el numero de hits utiJizado en la mascara como sufijo de la direccion II~ asi: 192.168.1.0/24.

EI numero de hits del campo de la subred nos dice cuantas subredes y hosts hay disponihles utiJizando esta mascara. En el campo de host, la direccion de todo unos representa la direccion de difusion y la direccion de todo ceros representa la direccion de red, igual que una direccion IP estandar. EI campo de subred s610 necesita que la direccion de todo unos se reserve para una direccion de todo subredes, aunque algunas de las primer as implcmentaciones utilizahan las direccioncs de todo ceros para este proposito 'i. Por ejcmplo, la direccion y red 192.168.1.:':'/27 se dividen en la Tahla :'.2.

Tabla 3.2. Una direccion IP dividida en subrcdes.
IY Byte 2.° Byte 3Y Byte 4.9 Byte Decimal Nota .. con
puntos
11000000 10010100 00000001 00100001 192.168.I.:B La direccion
II'
11111111 1I111111 11I1I1I1 11100000 2SS.2S';ZS522·i I~I mascara
de suhrcd.
11000000 10010100 00000001 XXXXXXXX 192.1(,8.1.0 Red,:1 bytes
de una dire-
ccion de cla-
sec.
XXXXXXXX XXXXXXXX XXXXXXXX 00 1 XXXXX Subred.
XXXXXXXX XXXXXXXX XXXXXXXX XXXOOOOI EI host. La Tabla 3.2 nos muestra que eI host 192.168.1.33/27 es el host 1 de la red 192.168.1.0, subred 1. tUn poco confuso? No se preocupe, resulta mas facil despues de unas cuantas repeticiones, Veamos algunos ejernplos mas (Dejaremos la representacion binaria de cada ejemplo como ejercicio):

192.168.1.10/24 es el host 10 de la red 192.168.1.0; esta red no esta dividida en subredes.

• En reahdad, cada direccion II' utiliza una mascara de subred. Alii donde no se da la mascara, se torna la mascara predetcrminada de esa clase de red (24 bits pard una dircccion de clase (:. 16 pam una dircccion de clase H y 8 pard una direccion de clase A).

, Si nos encontramos en una red que incluye sistemas basados en BSu4.2 (como los equipos Sun 0 liltrix vicjos), deberiarnos cvitar la utilizacion de la subred de todo ceros. Si no tencmos tal cosa en nuestro cntorno, no tcnemos por que preocuparnos.


192.168.1.26/28 es el host 10 de la red 192.168.1.0, subred 1. 192.168.1.128/28 es la direcci6n de red (host 0) de la red 192.168.1.0, subred 8.

192.168.1.127/28 es la direcci6n de difusi6n (host 16) de la red 192.168.1.0, subred 7.

192.168.1.26/30 es el host 2 de la red 192.168.1.0, subred 6.

Las subredes funcionan igual de bien en redes que no sean de la clase C:

• 172.16.1.10/24 es el host 10 de la red 172.16.0.0, subred 1.

• 172.16.1.129/25 es el host 1 de la red 172.16.0.0, subred 3.

La mascara de red se define con el comando /sbin/ifconfig, como sigue:

/sbin/ifconfig eth0 192.168.1.10 netmask 255.255.255.0

Este ejemplo es un poco artificioso, 24 bits es la mascara predeterminada para una direccion de clase C. Sin embargo, si vamos a tomarnos el trabajo de definir una mascara de subred, probable mente deseemos otro valor que no sea el predeterminado. Si queremos asignar una mascara de 28 bits, deberiamos hacer esto:

/sbin/ifconfig eth0 192.168.1.10 netmask 255.255.255.~24

Representa el host 10 de la red 192.168.1.0, subred O.

Probablemente sea util tener una pequefia tabla de mascaras de subred y el mimero de subredes y hosts que proporcionan 6 (vease la Tabla 3.3).

Tabla 3.3. Redes divididas en subredes de varios tamafios.

Dlreccjon de red

Mascara desubred

Redes disponibles

Hosts porsubred

Nfunero total

de hosts por red

192.168.1.0 192.168.1.0 172.16.0.0 172.16.0.0

255.255.255.240 255.255.255.192 255.255.255.128 255.255.255.254

15 3 511 127

14 62 126 510

210 186 64386 64770

EJEMPLO REAL

Hace varios afios, trabaje para un empresa de puesta a punto de sistemas y era el unico del equipo que conocia realmente las mascaras de subred. Un dia, se present6 un cliente con la necesidad urgente de reconfigurar un esquema de redes. La compafiia acababa de abrir otra ofieina y necesitaba unirla con las dos ya existentes. Aunque habiamos

6 Como solo se Uega a comprender de verdad las subredes utilizandolas repetidamente, dejaremos la finalizacion de esta hoja como ejercicio. Tambien hay herramientas disponibles para calcular mascaras de subred. Ahorran mucho tiempo, pero deberiamos saber como funciona todo esto antes de empezar a confiar en elias.

Capitulo 3 Protocolos de la capa de red 39

planeado eI crecimiento, la nueva oficina tenia mas hosts de 10 que se habia proyectado. S610 habia que rehacer las mascaras y asignar intervalos de direcciones nuevos. Podran imaginarse a quien lIamaron para que 10 hiciera. EI unico inconveniente era que mi mujer y yo estabarnos en eI hospital, donde se estaba preparando para tener un bebe: afortunadamente, no se enfado demasiado cuando recibi la lIamada. No tenia hcrrarnientas para hacer subredes, asi que tcrrnine haciendo los calculos mental mente y disefiando un mapa en eI envoltorio de unos guantcs para pasarselo a nuestro c1iente.

Un host solo conoce su propia mascara de subred. Cualquier cornparacion que haga esta basada solamente en su propia mascara. Esto puede causar problemas a veces. Si dos hosts de una red local tienen mascaras de subred diferentes, puede que no sean capaces de comunicarse con IP.

Estudio de las superredes

Del mismo modo en que las subredes se utilizan para crear rcdes de un tamafio adecuadamente mas pcquerio, existe un metodo para alargar redcs, proporcionando asi redes mas gran des y encaminadas mas facilmente. Las superredes ayudan a resolver dos problemas. En primer lugar, no hay redes de tamafio adecuadamente mas grande para las organizaciones que las necesitan (las redes de clase C no son lo suficientemente grandes para la mayo ria de las empresas y no hay suficientes redes de clase B para dar a las compafiias que en realidad solo necesitan 10 0 12 bits de espacio de direccion de host). En segundo lugar, las tab las de encaminamiento de los encaminadores del nuclco de Internet se hacen poco flexibles cuando se llenan de muchas redes de clase C diferentes en la periferia de Internet.

El RFC 1518 Y el RFC 1519 definen el CIDR (Classless Interdomain Routing, Encaminamiento entre domini os sin clase , pronunciado "cider"), 0 superredes. Este mecanismo permite la cornbinacion de grandes bloques de direcciones contiguas. Esta agregacion de redes ayuda a aligerar el problema de encaminamiento y tambien da a las organizaciones de tamafio medio el espacio de direccion de host que necesitan.

Para la utilizacion de las superredes es necesario que los encaminadores conozcan la mascara de red de las redes que llevan. Las implementaciones actuales de los principales protocolos de encaminamiento (RIP-2, BGP-4 Y OSPF) llevan toda la informacion necesaria.

COMO COMPRENDER LAS SUPERREDES

Para comprender las superredes y como alivian los dos problemas mencionados anteriormente, vearnos un ejernplo:

lin ISP pequerio, Small-ISP.net, tiene un bloque de CIDR de 192.16K 192.0/20 (recordemos que esto significa que controla desde la dircccion 192.16H.192.0 a la 192. 16B.207.2SS, un total de 16 redes de clase C). Como cllSP solo controla est as dirccciones, cualquier otro encaminador del nuclco de Internet nccesita solo una entrada de tabla de encaminamiento para todo el ISp, en lugar de 16 entradas separadas, Small-ISPnet ofrece servicios a tres empresas, adernas de a sus clicntes individuates. A SmaliCo y LittleCo (las mas pequerias de las tres empresas) se les asigna 192.16K206.0/23

40 Capitulo 3 Protocol 05 de la capa de red

y 192.168.204.0/23, respectivamente, dando a cada compafiia 510 posibles direcdones de host para sus redes. A MidSize, Inc. se le asigna 192.168.200.0/22, cediendo 1.022 direcdones de host. Todas estas asignaciones dejan a Small-ISP.net con 1a red 192.168.192.0/21 para su propio uso (0 una subdivision posterior, si es necesario).

Encaminamiento

EI encaminamiento es una funcion principal de la capa de red y es uno de los puntos fuertes de IP. Uno de los objetivos de diseiio del protocolo IP fue que una IP de internet fuera capaz de sobrevivir a perdidas casi catastroficas de sus conexiones de internetwork. IP encamina cada datagrama de forma separada, de modo que si la rota de datos seguida por un paquete resulta bloqueada, el siguiente paquete sera, sencillamente, encaminado por una rota diferente. Esto funciona muy bien en una red combinada.

REDES SENCILLAS Y COMBINADAS

Normalmente, las redes se clasifican como sencillas 0 combinadas (a veces incluso "profundamente combinadas"). Una red sencilla es aquella en la que hay pocas conexiones entre redes. Con frecuencia, el trafico tiene solamente una unica ruta posible a traves de una red sencilla. Una red combinada es aquella en la que existen muchas conexiones entre redes. El trafico puede pasar a menudo por multiples rutas entre puntos de una red combinada.

Una de las claves de esta capacidad es que cualquier equipo tiene que conocer solo su siguiente conexion para llegar a cualquier otro punto de la internet. En realidad, para muchos equipos, solo es necesaria una unica conexion; Hamada pasarela predeterminada. Este conjunto de informacion se llama tabla de encaminamiento.

Una red sencilla

Comencemos con un ejemplo bastante sencillo de encaminamiento. Utilizaremos la internet que mostramos en la Figura 3.3.

fedex

usps

patton

cuke

Figura 3.3. Una internet pequeiia.


Cada uno de estos hosts (incluidos los encaminadores) tiene una tabla de cncaminamiento; las mostramos aqui:

cuke:

[pate@cuke -]$ netstat -rn

Tabla de encaminamiento IP

Destination Gateway Genmask

192.168.2.51 0.0.0.0 255.255.255.255

192.168.2.0 0.0.0.0 255.255.255.0

127.0.0.0 0.0.0.0 255.0.0.0

0.0.0.0 192.168.2.1 0.0.0.0

de nucleo Flags LJ1

U

U LG

fedex:

[pate@fedex -]$ netstat -rn



192.168.1.2 0.0.0.0 255.255.255.255

192.168.1.0 0.0.0.0 255.255.255.0 U

192.168.2.1 0.0.0.0 255.255.255.255 LJ1

192.168.2.0 0.0.0.0 255.255.255.0

127.0.0.0 0.0.0.0 255.0.0.0

0.0.0.0 192.168.1.1 0.0.0.0

kumquat:

[pate@kumquat -]$ netstat -rn



192.168.1.12 0.0.0.0 255.255.255.255

192.168.1.0 0.0.0.0 255.255.255.0

127.0.0.0 0.0.0.0 255.0.0.0

0.0.0.0 192.168.1.1 0.0.0.0

cherry:

[pate@cherry -]$ netstat -rn



192.168.1.10 0.0.0.0 255.255.255.255

192.168.1.0 0.0.0.0 255.255.255.0

192.168.2.0 192.168.1.2 255.255.255.0

127.0.0.0 0.0.0.0 255.0.0.0

0.0.0.0 192.168.1.1 0.0.0.0

de nucleo Flags LJ1

U U LG

de nucleo Flags LJ1

U

U LG

de nucleo Flags LJ1

U

U

U LG

MSS WindON 00

00

00

00

MSS WindON 00

00

00

00

00

00

MSS WindON 00

00

00

00

MSS WindON 00

00

00

00

00

irtt Iface

o eth0

o eth0

o 10

o eth0

irtt Iface

o eth0

o eth0

o eth1

o eth1

o 10

o eth0

irtt Iface

o eth0

o eth0

o 10

o eth0

irtt Iface

o eth0

o eth0

o eth0

o 10

o eth0

[pate@cherry -]$ /sbin/ifconfig

eth0 Link encap:Ethernet HWaddr 00:E0:98:7C:95:21

inet addr:192.168.1 .10 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100

Interrupt:3 Base address:0x200

usps:

[pate@usps -]$ netstat -rn
Tabla de encaminamiento IP de nucleo
Destination Gateway Genmask Flags MSS WindON irtt Iface
192.168.0.2 0.0.0.0 255 . 255 . 255 . 255 LJ1 00 o eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 00 o eth0
192.168.1.1 0.0.0.0 255.255.255.255 LJ1 00 o eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 00 o eth1
192.168.2.0 192.168.1.2 255.255.255.0 U 00 o eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 00 o 10
0.0.0.0 192.168.0.1 0.0.0.0 LG 00 o eth0 42 Capitulo 3 Protocol os de la capa de red

patton:

[pate@patton -]$ netstat -rn



192.168.0.12 0.0.0.0 255.255.255.255

192.168.0.0 0.0.0.0 255.255.255.0

192.168.1.0 192.168.0.2 255.255.255.0

192.168.2.0 192.168.0.2 255.255.255.0

127.0.0.0 0.0.0.0 255.0.0.0

0.0.0.0 192.168.0.1 0.0.0.0

de nucleo Flags LH

U

U

U

MSS W:i.ndoN irtt Iface
00 o eth0
00 o eth0
00 o eth0
00 o eth0
00 010
00 o eth0 U LG

Dada esta informacion, trabajemos con algunos ejemplos.

Ejemplo de encaminamiento local

Si cherry quiere enviar tcifico a kumquat, primero compara su propia direcci6n IP con la direcci6n IP de kumquat en vista de su propia mascara de subred. 192.168.1.10 y 192.168.1.12 estan en la misma red de clase C, y con una mascara de /24, tambien estan en la misma subred. Como la direcci6n IP de kumquat es local, el datagrama IP se dirige a kumquat y se pone en un marco Ethernet con la direccion MAC de kumquat.

Cuando kumquat recibe el marco, lee la direcci6n IP y ve que el datagrarna esta dirigido a si mismo. Cualquier trafico de retorno pasaria por los mismos pasos.

Ejemplo de encaminamiento de salta Unico

Cuando cherry envia trafico a patton, de nuevo compara las direcciones IP. En este caso, 192.168.1.10 esta en una red distinta a 192.168.0.12. por 10 que cherry tendril que enviar su trafico mediante un encaminador. Despues, cherry consulta su tabla de encaminamiento. No hay rutas explicitas para la red 192.168.0.0, pero hay una entrada de pasarela predeterminada, usps, por 10 que cherry encaminara a traves de ella. El datagrama IP se dirige a patton y se pone en un marco Ethernet con la direccion MAC de usps.

Cuando usps recibe el marco Ethernet, ve que la direcci6n IP no es local.

Como usps esta configurado para enviar (0 encaminar) paquetes, comprueba su tabla de encaminamiento IP para determinar el siguiente saIto del datagrarna IP. Aqui, patton se encuentra en una red conectada localmente, por 10 que el datagrama se pone en un marco Ethernet con la direccion MAC de patton y se envia a traves de la interfaz de red adecuada.

Cuando patton recibe el marco, comprueba la direcccion IP del datagrarna IP y determina que este es para entrega local.

Despues de que la pila IP haya terminado con el datagrama y la aplicaci6n haya devuelto una respuesta, patton comprueba su propia direccion IP con la de cherry. Descubre que cherry no es local, por 10 que patton tendril que utilizar un encaminador para entregar el datagrama que lleva la respuesta.

A continuaci6n, patton comprueba su tabla de encaminamiento y descubre que usps es el encaminador adecuado para la red 192.168.1.0/24. El datagrama se dirige entonces a cherry y se pone en un marco Ethernet dirigido a usps.


Por ultimo, usps comprueba la direccion del datagrama II' y ve que es para cherry. Al comprobar su tabla de encaminamiento. usps descubrc que cherry esta conectado localrnente. EI datagrama se pone en un marco Ethernet nuevo dirigido a cherry y se envia a traves de la interfaz de red adecuada.

Ejemplo de encaminamiento de dos saltos

Cuando cuke quiere enviar un datagrama II' a patton, primero cornpara su dircccion II' con la de patton en vista de su propia mascara de subred. 192. 16H.2. ') 1 Y 192. 16H.O.12 estan en diferentes redes, por 10 que cuke comprueba su tabla de encaminamiento en busca de una entrada apropiada. No hay una entrada de ruta explicita para la red 192.16H.O.O, asi que cuke utiliza su pasarela predeterminada. EI datagram a II' dirigido a patton se pone en un marco Ethernet dirigido a fedex.

Despues de recibir el marco Ethernet, fdex comprueba el datagram a II' adjunto y ve que esta dirigido a 192.168.0.12. La red 192.I6H.O.O no esta unida directamente a fedex, por 10 que mira en su tabla de encaminamiento para ver donde tiene que enviar el datagrama. No hay una entrada de ruta explicita, asi que fedex utiliza su pasarela predeterrninada, usps. EI datagrama IPse pone en un marco Ethernet dirigido a usps y se envia a travcs de la interfaz de red apropiada.

Cuando usps recibe el marco Etchrnet, comprueba el datagrama IP y descubre que esta dirigido a 192.168.0.12. La red 192.16H.O.O esta unida dircctamente, por 10 que usps incluye el datagrama IP en un marco Ethernet dirigido a patton y 10 envia a traves de la interfaz de red apropiada.

Despues patton recibe el marco Ethernet y descubre que el datagrama IP adjunto esta dirigido a si mismo. Despues de rnanipular el datagram a IP, si hay que enviar una respuesta, patton sigue la misma serie de pasos para enviarla.

Dejamos el trazado de la rut a de retorno del datagram a IP como ejercicio.

Encaminamiento por grados

Todo encaminamiento en un host se lleva a cabo de acuerdo con la tabla de encaminamiento de ese host. En esta tabla cxisten tres tipos basicos de entrada, correspondiendose con tres clases de encaminamiento: redes unidas localmente (encaminamiento directo), rut as asignadas estaticamente (encamin ami en to estatico) y rutas asignadas dinamicamente (encaminamiento dinarnico). En las siguientes secciones los estudiarernos por separado.

Encaminamiento directo

Cuando dos hosts estan en la misma red y subrcd, no es necesario ningun encaminador para pasar trafico entre ellos. Los datagrarnas IP se envian entre ellos utilizando marcos de capa de enlace dirigidos directamente.

Esta es la forma de encaminamiento mas sencilla disponible. Las entradas se afiaden automaticamente a una tabla de encaminamiento de hosts cuando se agrega una red nueva can el comando Isbin/ifconfig.

44 Capitulo 3 Protocolos de la capa de red

Eneaminamiento estiitieo

En redes seneillas, 0 porciones sencillas de redes combinadas, las entradas de encaminamiento pueden introducirse a mano en una tabla de encaminamiento de bost con el comando Isbin/ifconfig. Normalmente, esto se haee solo cuando no es probable que la ruta cambie, porque cualquier cambio debe introducirse tarnbien a mano. La entrada de pasarela predeterminada en una tabla de encaminamiento es casi siempre una entrada de encaminamiento estatico.

Eneaminamiento din3.mieo

Cuando es probable que las rutas entre redes cambien, es mas apropiado el eneaminamiento dinamico, Se basa en un protocolo de encaminamiento subyacente como RIP-2, OSPF 0 BGP para pasar informacion sobre las rutas a las redes entre encaminadores. En el Capitulo 5, "Protocolos de la capa de aplicacion", veremos con mas detalle RIP-2.

EI encaminamiento dinamico es la clave de una capacidad de internet combinada para sobrevivir perdiendo conexiones entre redes.. En la Figura 3.4 podemos ver un ejemplo sencillo.

Figura 3.4. Una internet combinada pequefia.

En esta internet, la red 192.168.0.0/24 puede enviar trafico a la red 192.168.5.0/24 a traves de la red 192.168.2.0/240 de la red 192.168.3.0/24 (sin embargo, todo el trafico fluira a traves de la red 192.168.1.0/24). EI traflco fluira normalmente por esta ruta:

192.168.0.0/24 a 192.168.1.0/24 a 192.168.2.0/24 a 192.168.5.0/24

EI trafico encaminado a traves de la red 192.168.3.0/24 necesitara un salto adicional ya que pasa a traves de la red 192.168.4.0/24. Este salta adicional


se refleja en las entradas de la tabla de encaminamiento pasadas entre los encaminadores.

Si la conexion entre 192.168.1.0/24 y 192.168.2.0/24 cayera por alguna razon, las tablas de encaminamiento se actualizarian para mostrar que la mejor ruta nueva era como sigue:

192.168.0.0/24 a 192.168.1.0/24 a 192.168.:Ul/24 a 192.168.4.0/24 a 192.168.<;.0/24

Aunque es mas larga que la ruta antigua, aun funciona y pasa a ser la mejor ruta. Cuando se recupera el enlace entre 192.168.1.0/24 y 192.168.2.0/24, la tabla de encaminamiento volvera a la ruta mas corta a traves de la red 192.168.2.0/24.

Como convertir nuestro equipo Ilnux en un encaminador

Todos los equipos Linux son capaces de encaminar trafico IP Esta capacidad esta desactivada por omision en la mayoria de las distribuciones Linux. Un parametro de nuclco llamado ip_forward control a esta funcionalidad. EI siguiente comando perrnitira el encaminarniento en nuestro sistema:

echo 1 > /proc/sys/net/ipv4/ip_forward

Si nuestro equipo esta conectado a una 0 mas redes IP, cornenzara a encaminar el trafico entre cllas. Desde luego, encaminara s610 el trafico que sc Ie envie como encarninador, por 10 que debcriarnos informar a los hosts de las redes conectadas de que este encaminador esta ahora activo. Para una red sencilla, esto probablemente signifique la adicion de nuestro encaminador como la pasarela predeterrninada de nuestros hosts individuales. Para una red mas implicada, iniciaremos los demonios routed, gated 0 zebra y dejaremos que anuncien nuestro nuevo encaminador. Para mas informacion sobre estos programas, veanse los Capitulos 5 y 7.

Trucos mas avanzados

EI nucleo Linux 2.4 incluye la capacidad de ir mas alla de este encaminamiento sencillo. Algunas de las capacidades de encarninamiento avanzadas con el nuevo nucleo incluyen encarninamiento basado en el tipo de servicio, reencaminamiento de trafico basandose en el protocolo de la capa de aplicacion, filtrado de paquetes, traduccion de direcciones de red, forrnacion de trafico y otros trucos.

Filtrado de paquetes

EI filtrado de paquetes es el proceso de deterrninar si encaminar, aceptar o denegar un paquete basandose en la informacion del encabezamiento de

46 Capitulo 3 Protocolos de la capa de red

paquete. La forma mas sencilla de filtrado de paquetes se basa en una comparacion de las direcciones IP de origen y de destino (vease la Figura 3.5).

Encaminador con filtro de paquetes

Figura 3.5. Una red pequeiia.

Dada una red como la que mostramos en la Figura 3.5, el filtro de paquetes podria configurar normas para bloquear trafico como este (utilizando un sencillo pseudo codigo de configuracion explicado aqui).

deny 10.0.0.0/24201.13.25.0/8 deny 172.16.0.0/20 201.13.25.0/8 deny 192.168.0.0/16201.13.25.0/8 deny 127.0.0.1/24201.13.25.0/8 deny 201.13.25.0/8 201.13.25.0/8 allow 0.0.0.0/32 201.13.25.100/0 deny all

Cada norma es de esta forma:

action source/mask destination/mask

Las mascaras de estas normas no son mascaras de subred; cada bit representa un bit cambiable, comenzando por el bit menos significativo de la direccion, Por ejemplo, la combinacion destine-mascara 201.13.25.0/8 representa a todas las direcciones desde 201.13.25.0 a 201.13.25.255 (cualquier bit del ultimo octeto puede establecerse en cualquier valor).

Las cinco primeras normas niegan las conexiones de tres clases de tcifi.co: las direcciones privadas del RFC 1918 (explicadas anteriormente), las direcciones de bucle de retorno locales y la red interna (para evitar trafico falseado). La sexta norma permite el trafico desde cualquier host (que no este ya denegado) que este dirigido a 201.13.25.100. La Ultima norma niega todo 10 demas '.

Netfilter e iptables proporcionan las capacidades de filtrado de paquetes de Linux. Explicaremos estas herramientas en su propia seccion en el Capitulo 11.

7 Estas nonnas no son adecuadas para asegurar una red. Las damos solo como ejemplos.


Traduccion de direcciones de red

La NAT (Network Address translation,Traducci6n de direcciones de red) es el metodo para hacer correspondencia de un espacio de direcciones privadas intern as (normalmente compuesto de direcciones del RFC 1918) con una 0 mas direcciones IP encaminables. Esta funcionalidad puede ayudar a ofrecer seguridad (ocultando nuestra estructura de direccion interna y evitando la conexion con nuestros hosts internos) y a minimizar el coste adicional de direcciones IP (utilizando un espacio de direcciones privadas en lugar de tener que adquirir direcciones IP encaminables de nuestro ISP).

EI enmascaramiento es una forma cornun de NAT. EI enmascaramiento IP hace correspondencia entre cualquier espacio de direcciones internas con una direccion IP (mica. Esto se utiliza norrnalmente para permitir que varios PC de una casa u oficina pequeiia compartan una (mica conexion a Internet por marcaci6n, DSL 0 modem-cable.

IPv4

EI IP (Internet Protocol, Protocolo Internet) se define en el RFC 791. IP proporciona direcciones encaminables, fragmentaci6n y reagrupaci6n y opciones de entrega basadas en el tipo de servicio (TOS).

Estudio de IPv4

Normalmente, el encabezamiento IPv4 tiene 20 bytes de longitud. Contiene un campo de Version de 4 bits (siempre sera 4), un campo de Longitud de encabezamiento de 4 bits (normalmente sera 5, indicando cinco palabras de 4 bytes cada una, con un total de 20 bytes), un campo de TOS de 1 byte, un campo de TTL (Total Length, Longitud total) de 2 bytes, un campo de Identificacion de 2 bytes, un campo de Indicadores de 3 bits, un campo de Desplazarniento de fragmentos de 13 bits, un campo de TTL (Time to Live, Tiempo de vida) de 1 byte, un campo de Protocolo de 1 byte, un campo de Suma de verificaci6n de encabezamiento de 2 bytes, un campo de Direccion de origen de 4 bytes y un campo de Direccion de destino de 4 bytes.

TOS

EI byte de TOS esta dividido en tres secciones. En la primera seccion, se utilizan 3 bits para un campo de precedencia, que se utiliza poco hoy en dia. En la segunda seccion, se utilizan 4 bits para indicar TOS y s610 puede esta-


blecerse uno de eUos. Los cuatro indicadores de TOS posibles son delay, throughput, reliability y cost. Si no se activa ninguno de estos bits se producira un encaminamiento normal. La tercera seccion es un espacio reservado de 1 bit; este bit esta reservado y debe establecerse en O.

Los bits de TOS permiten un mejor control sobre como se encaminaci un paquete. Una aplicaci6n interactiva como ssh deberia establecer el bit de retraso (delay), indicando que los paquetes deberian encaminarse para minimizar el retraso. Una aplicaci6n que este transfiriendo datos deberia establecer el bit de rendimiento (throughput) para obtener un encaminamiento dirigido hacia la maximizaci6n del rendimiento. Estas opciones se explican mas exhaustivamente en el RFC 1349. Ademas de encaminamiento TOS, el micleo Linux 2.4 aporta herramientas potentes para dar forma al trafico de red basandose en un cierto mimero de posibles claves; estas herramientas se explicaran en el Capitulo 11.

Longitud total

El campo de Longitud total indica la longitud total del datagrama IP (incluido el encabezamiento) en bytes. IP esta limitado a 65535 bytes, 65515 de los cuales pueden cargarse. Si el datagrama IP se fragmenta (vease la seccion "Indicadores de fragmentaci6n", un poco mas adelante), el campo de Longitud total indica el tamafio del fragmento. En la practica, TCP y UDP limitan el tamafio de sus datos para evitar enviar paquetes extremadamente grandes (8192 bytes es un tope normal).

Identificaci6n

Cada datagrama de un host esta identificado de manera unica por el campo de Identificaci6n de 2 bytes. Esta identificacion no cambia entre fragmentos de un unico datagrama, 10 que permite que este se reagrupe en el destino.

Indicadores de fragmentaci6n

El campo de Indicadores de 3 bits contiene dos indicadores que tratan de la fragmentaci6n y un bit reservado. El primer bit esta reservado y debe ser o. El segundo bit es el indicador de No fragmentar. Si esta establecido este bit, indica que no se deberia fragmentar este bit; en su lugar, deberia generarse un mensaje de error de ICMP (Internet Control Message Protocol, Protocolo de mensajes de control de Internet) 8. El tercer bit es el indicador de Ultimo fragmento. Este bit se establece cuando no hay mas fragmentos de este datagrama.

8 Esto hace que e1 bit de No fragmentar sea uti! para las herramientas de diagnostico.


Campo de Desplazamiento de fragmentaci6n

Si el datagrama no se ha fragmentado, el campo de Desplazamiento de fragmentacion se establecera en todo ceros. Si se ha fragmentado, el campo indicant el numero de palabras de 8 bytes que separan a este fragmento del inicio del datagrama. En la seccion "Fragrnentacion IP" aparece un ejernplo de fragrnentacion.

TTL

El campo TTL indica el numero de saltos que puede hacer el paquete antes de descartarse. Cuando se crea un paquete, se Ie da un TTL de 64. Despues, cada vez que pasa por un encarninador, el TTL disminuye en 1. Esto evita que los paquetes que no se pueden entregar vaguen para siempre por la red.

Protocolo

El campo Protocolo indica que protocolo va en la carga util del datagrama IP Nos ocuparernos de tres posibles valores: Ox06 (TCP), Oxil (HDP) y OxOI (ICMP). Tratarernos estos protocolos en el siguiente capitulo.

Suma de comprobaci6n IP

La suma de comprobacion se ca1cula s610 con los datos del encabezamiento; nada de la carga util se utiliza en el calculo. EI campo de Suma de comprobaci6n se llena inicialmente con ceros.

Direcciones de origen y de destino

Los campos de Direcciones de origen y de destino contienen las direcciones IP de los hosts remitente y objetivo. Estos campos no se cambian en el flujo de datos IP a traves de una red, excepto en el caso de datagramas encaminados de origen (vease la Tabla 3.4). Por seguridad, el encaminamiento de origen normalmente ya no se utiliza.

Opciones IP

Los encabezamientos IP excederan de 20 bytes cuando se inc1uyan opciones IP En este caso, el campo de Longitud de encabezamiento se volvera a poner en el valor Oxf y se haran disponibles los siguientes campos adiciona- 1es: Copiar a traves de puerta (1 bit), Clase de operon (2 bits) y Numero de opcion (5 bits). El campo de Copiar a traves de puerta indica si estas opciones IP deberian afiadirse a cada fragmento de un paquete IP (cuando se establece en 1) 0 no (cuando se establece en 0). El campo Clase de opcion tiene dos val ores no reservados, 00 indica codigos de control de trafico y 10 indica codigos de depuracion y de medida. Algunas de las opciones se muestran (con breves explicaciones) en la Tabla 3.4.

Tabla 3.4. Opciones IP.
Cwe C6digo Nombre Longitud Descripci6n
deopci6n deopci6n
00 00000 Fin de lista Indica que no hay mas opdo-
deopciones nes en el campo de opdones.
00 00010 Manipulacion 11 Define como hay que mani-
de seguridad pular un paquete (en un en-
torno militar). Vease RFC
11 08 para mas detalles.
00 00011 encaminamiento Variable Indica que un paquete debe-
de origen flexible ria atravesar un conjunto de
encaminadores especifica-
do. Tamblen pueden atrave-
sarse otros encaminadores.
10 00100 Recoger marcas de Variable Indica que un paquete de-
tiempo de Internet beria ser marcado con la
hora actual de cada host
que atraviese.
00 00111 Ruta de registro Variable Indica que un paquete de-
beria marcarse con la dire-
ccion IP de cada host que
atraviese.
00 01001 Encaminamiento Variable Indica que un paquete de-
de origen estricto beria atravesar un conjunto
de encaminadores especifi-
cado. 5610 pueden atravesar-
se los encaminadores enu-
merados. Pragmentaclon IF

Los datagramas IP pueden ser mucho mas grandes que la MTU de la ruta que sigue el datagrama cuando se entrega, La Figura 3.6 muestra un ejemplo de una red pequeii.a en la que podria ocurrir esto.

La red Token Ring tiene una MTU de 4096, la Ethernet tiene una MTU de 1500 y la conexi6n PPP tiene una MTU de 576.

Si se envia un datagrama IP de 4096 por Token Ring desde Dexter a Wally en la Ethernet remota, se fragmentara en tres datagramas nuevos (cada uno de enos con el mismo mimero de ID) cuando pase por el encaminador 1 en la Ehernet local. Los dos primeros datagramas tienen 1500 bytes de largo y el tercero 1156. Recordemos que cada uno neva un encabezamiento IP, as. que hemos aii.adido 40 bytes (para los dos encabezamientos IP nuevos), mas el relleno para alcanzar la longitud de palabra de 8 bytes necesaria aii.adido al coste adicional del datagrama inicial.

Cuando se trasladan desde la Ethernet local al enlace PPP a traves del encaminador 2, cada datagrama IP se vuelve a fragmentar, Los dos primeros datagramas se fragmentan en tres nuevos datagramas cada uno: 576, 576 y 388 bytes. El tercer datagrama se ha fragmentado ahora en tres datagramas


tambien: 576, 576 Y 44 bytes. Estos nueve datagramas representan 160 bytes adicionales de encabezamiento IP y cierta cantidad de relleno.

router 2

Token Ring

IJ

~ Wally

Figura 3.6. Fragmentacion IP en una red pequena.

Cuando los nueve datagram as pasan a traves del encaminador 3 en la Ethernet remota, no se reagrupan. La reagrupacion del datagrama inicial se produce solamente en el punto final de la transmision.

EI ancho de banda adicional utilizado por los datagram as fragmentados, asi como la utilizacion de CPU necesaria pard fragmentar y reagrupar los paquetes, hacen que el descubrimiento de la MTU de ruta inicial sea una opcion deseable.

IPv4 descodificado

En el datagrama IP que se muestra en la Figura 3.7, la version IP se establece en 4. La longitud de encabezamiento se establece en 5, 10 que indica que no hay encabezamientos. Los indicadores Precedencia y TOS se establecen en OxOO, 10 que significa que no se establece ningun indicador de rnanipulacion especial. (Esto se etiqueta como "Servicios diferenciados" en la captura de pantalla Ethereal.) La longitud total se establece en Ox003c (0 64 bytes). EI ID de datagrama se establece en Ox0054. EI campo de Indicadores se establece en 010, indicando que esta establecido el indicador de No fragmentar. Como no hay fragmentacion, el desplazamiento de fragmentos es cero. EI TIL es Ox40 (64), rnostrando que este datagrama no ha pasado a traves de ningun encaminador. EI Protocolo se establece en Oxo6 (TCP). La Suma de verificacion es Ox3c66, 10 que es correcto pard este datagrama. La Direccion de origen es 127.0.0.1 y la Direccion de destino es 127.0.0.1. Este


paquete era parte de una conexi6n TCP de la interfaz de bude de retorno de un bost.

EB Frame 1 (74 on w1 re, 74 captured)
m Ethe rnet II
Version: 4
Header length: 20 bytes
8 Differentiated Services field: 0)(00 (DSCP OxOO: Defau1t)
0000 00 .. - Differentiated Services Codepotnt: Defaul t (OxOO)
•• 00 - Currently Unused: 0
Total length: SO
Identi f1 catt on: 0)(0054
8 Flags: 0)(04
.1 .. - Don't fra~nt: Set
•. 0. - fIIore fra(J'n8nts: Not set
Fra~nt offset: 0
Time to 11 ve: &4
Protoco 1: TCP (OxOS)
Header checkslll'l: O)l(3c66 (correct)
Source: cherry (127.0.0.1)
Destination: cherry (127.0.0.1)
III Transmission Control Protocol. Src Port: 1063 (1063L Dst Port: tel net (23L Seq: 583579226, Ack: 0
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ...... [.
0010 0031:0054400040116 3I:1iIl7fOOOOO17fOO :<:~:!: <f ......
0020 00 01 04 27 00 17 22 c8 es 5. 00 00 00 00 ao 02 .Z ......
0030 79 60 22 1. 00 00 02 04 Of 2c 04 02 08 Oa 00 00 ~" ..... ........
0040 c7 bt 00 00 00 00 01 03 03 00 ........ .. Figura 3.7. Datagrama IP.

4

Protocolos de la capa de transporte

La capa de transporte traslada datos entre hosts para la aplicacion que tiene por encima e informacion de diagnostico sobre las conexi ones entre los hosts de la red. Esta informacion se traslada a traves de TCP (y el T7TCP relacionado), UDP 0 ICMP. Estos protocolos son bastante diferentes en funciones y apariencia (como veremos en sus secciones respectivas). TCP garantiza un flujo de datos fiable, permitiendo que la implementacion de la aplicacion ignore dichos detalles. UDP no garantiza la entrega, 10 que fuerza a la aplicacion a garantizar la fiabilidad. ICMP no traslada los datos segun el sentido tradicional, pero los traslada por la red 0 por otras conexi ones de la red. En este capitulo explicaremos los puertos y los sockets, TCp, UDP e ICMP.

Puertos y sockets

En la capa de transporte hacemos referencia a los protocolos de la cap a superior mediante sus nurneros de puerto. Son mimeros de 2 bytes que se corresponden con una aplicacion 0 proceso en particular. Algunos nurneros de puerto estan reservados 0 registrados y estan recogidos en el RFC 1700. EI acceso a dichos puertos esta controlado frecuentemente por un demonio como inetd (http en el puerto 80 es una excepcion cormin a esta norma). Otros puertos se asignan a una aplicacion "al vuelo" (los servidores 0 clientes se pueden adherir a un puerto de esta forma).

intetd (y otros demonios similares) acnian como la "caja de conrnutadores" de un host. Este proceso esta configurado para escuchar en multiples puertos y despues captar un proceso servidor del tipo apropiado para cada conexi on entrante. inetd es susceptible a varios tipos de ataques y normalmente es reern-

54 Capitulo 4 Protocol os de la capa de transporte

plazado 0 suplementado por otras herramientas. xinetd y los TCP wrappers son ejemplos de servidores de reemplazo y suplemento, respectivamente, y los explicamos en el Capitulo 11, "Herramientas de seguridad".

Los puertos reservados son aquellos que tienen un valor del 1 al 1023 (ambos incluidos). La utilizacion de estos puertos esta restringida a los procesos iniciados por la raiz, Estos puertos se asignan a las aplicaciones a trayes de la lANA (Internet Assigned Numbers Authority, Autoridad de Niimeros Asignados de Internet). Como la utilizacion de estos puertos esta controlada por un micleo de estandares, a veces se les llama "puertos bien conocidos" .

Los puertos del intervalo de 1024 a 65535 (inclusive) se Haman puertos registrados si estan enumerados en el RFC 1700. Aunque estan enumerados por la lANA, no estan estandarizados. Un proceso servidor puede adjuntarse a cualquiera de los puertos de este intervalo, pero consideramos una buena practica intentar evitar la utilizacion de numeros reservados utilizados con frecuencia.

Tambien los procesos clientes utilizan este Intervale de puertos. Por ejemplo, cuando un usuario hace una conexion Telnet con un host remoto, el cliente Telnet local se une a un puerto del intervalo no restringido, por ejemplo, el 1027. El cliente Telnet intenta entonces hacer una conexion con el servidor en el puerto 23. Como el acceso Telnet se manipula normalmente con inetd, recibe la peticion entrante e inicia un proceso in. telnetd para tratar con la sesion Telnet.

Puertos utilizados normalmente

Las Tablas 4.1, 4.2 y 4.3 (extraidas del archivo /etc/services) representan servicios utilizados de forma muy frecuente. Algunos se ofrecen a traves de TCP y UDp, otros no.

Tabla 4.1. Servicios proporcionados internamente en la pila IP.

Puerto/Protocolo

Nombre de serviclo

7/tcp 7/udp 9/tcp 9/udp ll/tcp 13/tcp 13/udp 15/tcp 17/tcp 19/tcp 19/udp 37/tcp 37/udp

echo echo discard discard systat daytime daytime netstat qotd chargen chargen time time

Capitulo 4 Protocolos de la capa de transporte 55

Tabla 4.2. Servicios proporcionados por demonios externos en los puertos restringidos.

Puerto/Protocolo Nombre de servicio
20/tep ftp-data
21/tep ftp
22/tep ssh
22/udp ssh
23/tep telnet
2S/tep srntp
S3/tep domain
53/udp domain
67/tep bootps
67/udp bootps
68/tep bootpe
6S/udp bootpe
69/udp tftp
79/tep finger
80/tep www
80/udp www
S8/tep kerberos
88/udp kerberos
98/tep linuxeonf
t lu/tcp pop3
l Ifl/udp pop3
lil/tep sunrpe
lll/udp sunrpe
113/tep auth
137/tep netbios-ns
I 37/udp netbios-ns
I 38/tep netbios-dgm
I 38/udp netbios-dgrn
I 39/tep netbios-ssn
139/udp netbios-ssn
161/udp snmp
162/udp snmp-trap
220/tep imap3
220/udp imap3
389/tep ldap
389/udp ldap
443/tep https
443/udp https
512/tep exee
513/tep login
513/udp who
514/tep shell
S14/udp syslog
520/udp route
S43/tep klogin
S44/tep kshell
636/tep ssl-klap
873/tep rsyne
873/udp rsyne 56 Capitulo 4 Protocolos de la capa de transporte

Tabla 4.3. Servicios proporcionados por demonios extemos en los puertos registrados.

Puerto/Protocolo

Nombre de servicio

2401/tcp 240l/udp 3306/tcp 3306/udp 4559/tcp 5308/tcp 5308/udp 5432/tcp 5432/udp 6667/tcp 6667/udp l0080/udp 1 008 l/tcp l0081/udp l0082/tcp l0083/tcp

cvspserver cvspserver mysql mysql hylafax cfengine cfengine postgres postgres ired

ircd amanda kamanda kamanda amandaidx amidxtape

lQue es un socket?

Como un mimero de puerto no es de mucha ayuda de forma aislada, normalmente se les pone en contexto como sockets, que son una direccion IP con un mimero de puerto. Asi, una conexi6n Telnet de cherry a mango podria tener los siguientes sockets:

Lado del cllente Socket cherry 192.168.1.1 0: 1 027

Lado del servidor Socket mango 192.168.1.1:23

TCP

TCP (Transmission Control Protocol, Protocolo de Control de Transmision), definido en el RFC 793 Y clarificado en el RFC 1123, esta mas implicado que UDp, pero con el coste afiadido de la ejecucion de TCP obtenemos un conjunto de caracteristicas y una fiabilidad mayores. Las sesiones dadas por TCP son la causa de gran parte de la sobrecarga del protocolo, pero ofrecen muchos de los beneficios de TCP.

Las sesiones suministran una conexi6n continua entre dos procesos, un mecanismo para el seguimiento de la cantidad de datos presentes en una conexi6n, un metodo para la difusion de los datos perdidos y una forma de acusar recibo de los paquetes que se han recibido. Proporcionan un sistema de control de congestion sin necesidad de que la aplicaci6n 10 manipule.

Capitulo 4 Protocol os de la capa de transporte 57

Tambien controla el tamaiio de los paquetes que se envian y mantiene un flujo ordenado de paquetes que vuelven a la aplicaci6n, incluso pudiendo recibir paquetes fuera de orden (0 duplicados) de la capa IP.

Un estudio de TCP

En nuestra explicacion de Tep, cubriremos la estructura del encabezamiento Tep, el inicio y finalizaci6n de la sesi6n y T (rep. Cada una de estas secciones se construye a partir de la informaci6n contenida en las anteriores, asi que tenemos que leerlas en orden.

EI encabezamiento

Un encabezamiento TCP se compone de los siguientes campos: un mimero de Puerto de origen de 2 bytes, un mirnero de Puerto de destino de 2 bytes, un numero de Secuencia de 4 bytes, un nurnero de Acuse de recibo de 4 bytes, un Tamafio de encabezarniento de 4 bits, un campo Reservado de 6 bits, una secci6n Indicador de 6 bits, un Tamafio de ventana de 2 bytes, una Suma de comprobaci6n de 2 bytes, un Puntero de datos urgentes de 2 bytes y opciones.

En todos los segmentos Tep se llevan los numeros de puerto de los procesos de origen y de destino y se define el socket de cada lado de la conexion, como describimos en la sec cion anterior, "Puertos y sockets".

EI numero de Secuencia identifica el primer byte de datos incluido en este segmento. Los bytes de una corriente Tep no se cuentan desde cero; en lugar de ello, se cuentan desde un punta casi aleatorio sobre el que se ha llegada a un acuerdo al comienzo de la sesi6n TCP. (Definimos este proceso en la siguiente seccion, "Comienzo y finalizacion de sesiones".)

EI rnimero de Acuse de recibo esta unido a la secuencia del otro extrema de la conexion, Representa el siguiente byte que este equipo esta esperando que llegue del otro.

EI Tamaiio de encabezamiento es el numero de palabras de 4 bytes utilizado por el encabezamiento Tep. Normalmente, el encabezamiento es de 20 bytes, dando un valor de 4 bits de 5. Frecuentemente se utilizan las opciones en el comienzo de la sesion TCP. Cuando estan presentes, el Tamario de encabezamiento esta establecido como 6 (24 bytes) y se establece una Opcion de Ox0204xXXXX. EI XXXX es el mimero de 2 bytes correspondiente al MSS (maximum segment size, Tamafio de segmento maximo) permitido por el host remitente. Si no se utiliza esta opcion, el MSS se establece como 536 (para un total de 576 bytes, despues de afiadir 20 para cada uno de los encabezamientos IP y TCl' estandar). Se hace algun uso de las opciones para mejorar el rendimiento en redes muy cargadas (LFN). Otras opciones son Noop OxOl y la Lista de final de opcion (end-of-option List) OxOO; cada una de ell as es de solo 1 byte.

58 Capitulo 4 Protocolos de la capa de transporte

TCPENLFN

La capacidad de conexi6n es el producto del ancho de banda (en bits por segundo) y del tiempo de viaje (en segundos). Como este mimero es muy grande en las WAN modemas (mas de 320.000.000 bits, 0 40.000.000 bytes, para una OC3 entre Nueva York y California), el tamafio de ventana no es capaz de manipular de forma efectiva el control de flujo. Hay dos opciones para ayudar a evitar este problema.

La primera, llamada escalado de ventana, cambia el tamafio de la ventana TCP de 2 a 4 bytes. Esto se hace ensanchando la ventana hasta 14 bits. La opcion de escalado de ventana es Ox03030X, donde X es el tarnafio del ensanchamiento que vamos a hacer). Solo podemos llevar a cabo el escalado de ventana en los paquetes SYN y SYN-ACK del comienzo de la sesi6n TCP.

La segunda opcion recae en el sella temporal (Ox080aSSSSSSSSRRRRRRRR, donde SSSSSSSS es el sello temporal y RRRRRRRR es la respuesta al sella temporal), que ayuda a evitar que se coloquen datos duplicados en la secci6n incorrecta del buffer. Podemos utilizar el sello temporal durante una sesi6n TCP.

A continuacion de los bits reservados hay una serie de indicadores de 1 bit utilizados por TCP:

• URG. Este segmento contiene datos urgentes,

ACK. El mimero de acuse de recibo contiene un valor valido. PUSH. Solicita una manipulacion mas cipida del paquete.

• RST. Solicita una finalizaci6n expedita del proceso remoto porque el proceso local se esta cerrando 0 se ha cerrado,

• SYN. Establece el mimero de secuencia inicial del host. Este bit se establece solo durante el comienzo inicial de la sesi6n TCP.

FIN. Este indicador solicita que se cierre la conexi6n de forma normal.

Explicamos los bits ACK, SYN Y FIN en la siguiente seccion, "Comienzo y finalizaci6n de sesiones".

Utilizamos el campo Tamafto de ventana en conjunci6n con el mimero de Acuse de recibo para proporcionar un control de flujo. Muestra la cantidad de espacio de buffer disponible en el host rernitente para los paquetes entrantes de esta sesion, comenzando por el rnimero de Acuse de recibo, Funciona asi:

Despues de configurada la sesi6n (como describimos en la siguiente seccion), cherry tiene un mimero de Acuse de recibo de Ox00000020 y un Tamafto de ventana de Oxo040 (64 bytes). Es un mimero anormalmente pequefio, pero 10 utilizamos por razones de claridad en el ejemplo. mango envia un paquete de 17 bytes de datos y un segundo paquete de 20 bytes. De alguna forma, el primer paquete se pierde en el camino hacia cherry. Cuando cherry envia el siguiente paquete, todavia tiene un rnimero de Acuse de recibo de OxOOOOOO20 (porque no ha visto los primeros 17 bytes de mango), pero disminuye su Tamafio de ventana a Ox0020c.

Entonces, mango envia un paquete de 10 bytes a cherry, que responde con un numero de Acuse de recibo de Ox00000020 y un Tamafio de ventana de Ox0022. mango vuelve a enviar su primer paquete y cherry responde con un rnimero de Acuse de recibo de Ox00000046 (que refleja todos los datos


que ha recibido) y un Tamafio de ventana de Ox000040 (vuelve a estar disponible todo su buffer).

Este metodo de control de flujo que utiliza un cambio en el tamafio de ventana se llama ventana deslizante.

La Suma de cornprobacion TCP cs una suma de cornprobacion obligatoria que se computa sobre un pseudoencabezamiento, cl encabezamiento TCI~ y en los datos transportados por el paquete. EI pseudoencabezamiento contienc campos del cncabczamicnto II' para verificar que el paquete ha sido recibido por cl host correcto. Los campos utilizados son la dircccion IP de origen de 4 bytes, la direccion de destine de 4 bytes, un rclleno de 4 bytes (todos 0), el protocolo de trans porte de 1 byte y el tarnano de transporte de 2 bytes. Mostramos un diagrarna de este pseudocncabczarnicnto en la Figura 4.1.

Dir. IP fuente de 4 bytes
Dir. IP destino de 4 bytes
OxOO I Ox06 I Long. de 2 Bytes Figura 4.1. lin pseudocncabczarnicnto TCP

I Itilizamos el Puntero de datos urgentes para indicar el ultimo byte de datos urgcntes transportados en los datos Tep. Se utiliza para permitir la transmision en banda de datos de emergencia. Si el datagrama contiene datos urgcntes, tarnbien debe tener establecido un indicador UR(~. Estos datos urgentes representan frecuentemcnte una interrupcion en el trafico interactive como el de Telnet, rlogin 0 FTP. Por ejernplo, la introduccion de una interrupcion par.! cambiar nucstras opciones de Telnet se haria con datos urgentes.

Comienzo y finalizaci6n de sesiones

Tanto el comienzo como la finalizacion de las sesiones imponen sobrecarga sobre la misma sesion, Esta sobrecarga perrnite que la sesion se adrninistre de forma apropiada cuando haya comenzado y que se cierre apropiadamente cuando haya finalizado.

El protocolo de intercambio en tres pasos

EI comienzo de una sesion TCl" se llama protocolo de intcrcambio en tres pasos (0 protocolo de intercambio). Se cornpone de los trcs primcros segmentes TCP transmitidos, Durante este protocolo se intcrcarnbian y se acusa recibo de los numeros de secuencia iniciales y despues las opcioncs de inicio.

Comienza cuando el cliente envia un datagrama al servidor, Este datagrarna tiene cstablecido el indicador SYN y el valor inicial del numero de secuencia del clicnte. Si sc van a utilizar una opcion de escalade de venturia 0 MSS, cstas opciones tam bien deben establecerse en estc datagrama. Normalmente a cste datagrama se le llama datagrama 0 paquete SYN.


En el segundo paso del protocolo, el servidor envia un datagrama al clienteo Bstan establecidos tanto el indicador SYN como el ACK, se acusa recibo del rnimero de secuencia del cliente (con un valor de mimero de secuencia incrementado en 1) y se establece el mimero de secuencia del servidor.

De nuevo, si se van a utilizar en esta sesion una opcion de escalado de ventana 0 MSS, estas opciones se deben establecer en este datagrama. A este datagrama se Ie llama datagrama 0 paquete SYN-ACK.

EI paso final del protocolo se dirige del cliente al servidor. En este datagrama, el cliente envia un indicador ACK, acusando recibo del mimero de secuencia del servidor (nuevamente con la cuenta incrementada en 1). Se Ie llama datagrama 0 paquete ACK.

Las herramientas netstat, nmap y ethereal (explicadas en los Capitulos 9, "Herramientas de resolucion de problemas", y 10, "Herramientas de revision") describen las sesiones TCP como si pasaran por varios estados. El protocolo de intercambio hace que la sesion TCP se traslade por varios de ellos. La siguiente seccion revisa los pasos normales de un cliente y de un servidor. La Figura 4.2 muestra todos estos estados.

El cliente comienza en un estado CLOSED (cerrado) y pasa directamente al estado SYN_SENT (SYN enviado) cuando envia un paquete SYN. Cuando recibe el paquete SYN-ACK del servidor, pasa al estado ESTABLISHED (establecido), donde se mantiene hasta el cierre de la sesion.

El servidor comienza tamblen en un estado CLOSED. Normalmente se une a un puerto y espera paquetes entrantes; a esto se Ie llama estado de LISTEN (escucha). Despues de recibido el paquete SYN y enviado el paquete SYN-ACK, pasa al estado SYN_RCVD 1. Cuando el servidor recibe el paquete ACK del cliente, pasa al estado ESTABLISHED, donde se mantiene hasta el cierre de la sesion,

Cierre normal de la sesi6n

Para que una sesion se cierre normalmente se precisan cuatro paquetes.

Cualquiera de los extremos de la conexion pueden solicitar el cierre de la sesion.

El cierre de la sesion comienza cuando uno de los equipos implicados en la misma envia una datagrama con los indicadores ACK y FIN establecidos. Normalmente se Ie llama paquete ACK-FIN. El segundo equipo responde con un datagrama en el que solo esta establecido el indicador ACK; se Ie llama paquete ACK. Como las sesiones TCP son en ambas direcciones, el segundo equipo podria continuar enviando paquetes, pero no es normal.

1 Durante el estado SYN·RCVD, el servidor debe asignar un bloque de control de transmlsi6n. solo un pequefio mirnero de estas estructuras se envian aparte de la memoria, as! que esto presenta una vulnerabilidad para eI servidor. Los piratas que intentan desactivar un servidor atacan esta debilidad cuando intentan ejecutar un ataque de inundaci6n SYN.


FIN_WAIT_2

Figura 4.2. Diagrama de cstado de una sesion TCl!

EI cierre de la sesi6n queda complete cuando el segundo equipo en via un datagrama con los indicadores ACK y FIN establecidos y recibe la respuesta del primer equipo con el indicador ACK establecido. En este memento, ambas partes de la sesion estan cerradas. Durante un cierre de sesi6n normal, la sesi6n TCP pasa por varios estados. Sigue una de dos rutas posibles por dichos estados, como describimos a continuaci6n.

La primera nita (y la mas normal) de un cierre de sesion es la siguiente: en el equipo que cierra primero su parte de la sesion TCp, la sesion cornienza en el estado ESTABLISHED. Cuando se envia el paquete ACK-F1N, pasa al estado FIN_ WAIT_1. Cuando se recibe el paquete ACK, pas a al estado F1N_ WAIT_2. Cuando recibe el ACK-F1N del equipo rernoto, envia un paquete ACK y se introduce en el estado TIME_ WAIT, donde permanece por el tiempo especificado por la implernentacion (el RFC 793 especifica 2 minutos, pero frecuentemente se utilizan otros valores).

Si el equipo rernoto inicia el cierre normal de la sesion TCl~ el equipo local pas a a un estado de CLOSE_ WAIT despues de recibir el paquete ACKFIN Y enviar su propio paquete ACK. Cuando el equipo local cnvia el paquete ACK-FIN, se introduce en el estado LAST_ACK y espera cl paquete ACK del host remoto.

Es posible hacer algunas simplificaciones cerrando arnbas partes de la sesion TCP al mismo tiempo. A esto se le llama cierre simultanco. En cste


caso, el primer host envia un paquete ACK-FIN, el segundo equipo responde con un paquete ACK-FIN y el primero envia un paquete ACK final. Esto reduce el rnimero de datagramas necesarios para el cierre de la sesi6n de cuatro a tres y elimina el estado FlN_ WAIT_2 de la serie de estados del primer equipo.

La Figura 4.2 muestra un diagrama de los estados por los que pasa una sesi6n TCP.

Interrupcion de una seston

Normalmente, las sesiones TCP se interrumpen (0 abortan) por dos razones. 0 el cliente ha intentado conectar con un puerto inexistente 0 uno de los host implicados aborta manualmente la sesi6n.

Cuando el servidor recibe el paquete SYN del cliente que solicita una conexi6n con un puerto sin un proceso adjunto, el servidor responde con un datagrama que tiene establecido el indicador RST. EI cliente deberia entonces abandonar la sesion como si hubiera intentado crear una conexi6n con un puerto no dispooible.

Cuando una de las dos partes de una conexi6n aborta una sesion, envia un datagrama con el indicador RST establecido. EI otro equipo no envia respuesta; sencillamente aborta la sesi6n y notifica a la capa de aplicaci6n que ha interrumpido la sesi6n.

Expiracion del tiempo

Los temporizadores de sostenimiento no son parte de la especificaci6n TCp, pero esto no hace que ciertas pilas de protocolo TCP/IP no los implementen. Generalmente, estos paquetes de sostenimiento se envian despues de una espera de unas dos horas. Cuando se envia el paquete, pueden pasar tres cosas:

El host remoto es inaccesible.

• El host remoto es accesible, pero la conexi6n esta muerta.

EI host remoto es accesible y la conexi6n esta todavia viva.

En el primer caso, el host local intentara paquetes de sostenimiento otras nueve veces, en intervalos de 75 segundos. Si no hay respuesta se cerrara la conexi6n. Observemos que el host remoto podria ser inaccesible porque se haya estropeado, se haya apagado, etc.; son causas razonables para cerrar una conexi6n. Tambien podria ser inaccesible por un error transitorio de la red; esta no es una raz6n demasiado buena para cerrar una conexion, El host local no tiene forma de determinar por que no ha respondido el host remoto, asi que a veces cierra paquetes que hubiera sido mejor dejar abiertos ',

En el segundo caso, el host remoto responders con un paquete RST y el local cerrara la conexi6n. Bste es un caso especial de puertos no dispooibles (descritos anteriormente).

2 Esta es una de las razones por las que eI exceso de tiempo no es parte de la espccificacion TCP.


En el tercer caso, el host remoto responders con un paquete ACK y la conexion se mantendra viva.

T/TCP

Como TCP impone una sobrecarga de siete paquetes para la configuracion y el cierre de una sesion (y frecuentemente paquetes adicionales que llevan acuses de recibo), no esta muy bien preparado para trafico repetido y pequefio. En el RFC 1379 se define una solucion que permite el trafico transaccional. TrrCp (Transactional TCP, TCP Transaccional) perrnite que una (mica sesion TCP traslade multiples transacciones. Lo hace afiadiendo un campo CC (Connection Count, Cuenta de conexion) de 4 bytes al encabezamiento TCP Cada transaccion dentro de la sesion TCP utiliza una unica CC, asi que cada host debe hacer un seguimiento de la CC valida y actual del host rernoto de la sesi6n.

TCP descodificado

EI paquete capturado en la Figura 4.3 muestra un Puerto de origen Ox0413 (1043) y un Puerto de destino Ox1770 (6000). Los puertos de origen y de destino estan en el intervalo disponible para los clientes, pero el de destina esta en el puerto bien conocido (0 registrado) del sistema X-II y seguramente sera el servidor de este intercambio. EI equipo de origen tiene un numero de Secuencia actual de 330802776 y esta enviando un Acuse de recibo para el byte 327043426 (el siguiente byte que espera encontrar). EI Tamano de encabezamiento esta establecido como Ox8, 10 que representa 32 bytes de encabezamiento. A continuacion esta e1 relleno necesario y los indicadores como Ox18 (00011000 en binario), que representan ACK y PUSH. EI Tamafio de ventana esta establecido como Ox7900 (30976 bytes). La Suma de cornprobacion es Ox5e75.

Como el Tarnafio de encabezamiento es de 32 bytes, sabemos que hay 12 bytes de opciones, 32 (tamafio del encabezamiento) - 20 (tamario normal del encabezamiento) = 12 (bytes de encabezamiento). En este caso, las opciones son OxOO (una NOP), OxOO (otra NOP) y OxOl0108a007b5cdb007b5cda (un sella temporal con un valor de 8084699 y una respuesta de sello temporal equiva1ente) .

En la Figura 4.4 podemos ver el protocolo de intercambio en accion. Un usuario en cherry comienza la sesion Telnet con mango, mango replica y cherry responde a la replica. Se intercambian estos tres paquetes antes de pasar cualquier dato Telnet (datos vivos 0 configurados).


Destination port: 6000 Sequence nLl'l'lber: 330802776 Acknow1edqement m.l'liler: 32704:;426


8 Flags: Ox0018 (PSH. ACK)

.• 0 •.••• - Urgent: Not set

••• 1 •••• - AcknowledlJl'IElnt: Set .••. 1 ••• - Push: Set

•.••• 0 •• - Reset: Nnt set

•••• " O. - Syn: Not set ••••••• 0 - Fin: Not set

Window size: 30976 Checks"": OX5875

8 Options: (12 bytes) HOP

HOP

Time stMl1l: tsval 8084699, tsecr 8084698

Data (202<' bytes)

Figura 4.3. Un encabezamiento TCP.

mango

mango 192.168.1.10 mango 192.168.1.10 mango 192.168.1.10

1122 > tel net [ACK] SeQ-2588306917 Telnet Data ... tel net > 1122 [ACK] Teln.t Data ... 1122 > tel net [ACK] Seq-2588306944

Telnet Data .

Telnet Data .

Telnet Data .

Telnet Data .

tel net ) 1122 rACK] Telnet Data ...

2588306916. Ack: 0

Figura 4.4. E1 protocolo de intercambio.

EI primer paquete del protocolo de intercambio muestra a cherry estableciendo el bit SYN en el campo Opciones, con un mimero de Secuencia de 2588306916. En este momenta no hay valor para el mimero de Acuse de reciboo Lo mostramos en la Figura 4.5.

EI segundo paquete es de mango. Tiene establecidos tanto el bit ACK como el SYN. Tiene un mimero de Secuencia de 3483702130 y un mimero de Acuse de recibo de 2588306917. Observemos que el numero de secuencia no tiene conexi6n con el mimero de secuencia utilizado por cherry; en


lugar de eso, es el numero de acuse de recibo que refleja el numero de secuencia del host remoto. mango utiliza un numero de acuse de recibo 1 byte mayor que el numero de secuencia de cherry, porque es el siguiente byte que espera recibir. Lo mostramos en la Figura 4.6.

En el paquete final del protocolo de intercambio (mostrado en la Figura 4.7), cherry ya no tiene establecido el bit SYN, pero tiene el ACK. Ahora ha incrementado su numero de secuencia en 1, indicando que es el siguiente byte de datos que enviara. cherry establece su numero de Acuse de recibo

,

- ------~ --- ----- -----~-----

!±l Frame 3 (74 on wi reo 74 captured) I!l Ethernet II

ffiInternet Protocol

E1Transmission Control Protocol, Src Port: 1122 !_1122), [1St Port: tel net (:'3), Seq: 2588305'316, A(~: 0

Source port: 1122 (1122) Destination port: te1net (23) Sequence number: 2'588306'315 Header length: 40 bytes

ElFlags: Qx0002 (S'iN)

.. 0. - Urgent: Not set

... 0. a Acknowledgment: Not set

0.. ~ Push: riot set

.0 .. ~ Reset: Not set

.. 1. ~ Set

" ,0 ~ Not set

WindOl" si:e: 32120 checksum: Oxb9b4

EI Options: (20 bytes)

Maximum segment size: 1450 bvtes SACK pe rmi t tec

Time stamp: tsva l 4948111. tS8U I) NOP

Wlndow scale: 0 bytes

0000 00 aD d2 1c 64 88 00 eO 98 7c 9S 21 08 00 45 00 0010 00 3c 41 2c 40 00 40 06 76 34 co a8 01 Oa co a8 0020 01 01 04 62 00 17 '3a 46 6d e4 00 00 00 00 an 02 0030 7d 78 bs b4 00 00 02 04 as b4 04 02 08 Oa 00 4b 0040 80 8f 00 00 00 00 01 03 OJ 00

.... d .... I.!..E.

• ,A,@.@. 'J4. b ••• F m •..

}x.. . ... 1'

Figura 4.5. EI paquete SYN del protocolo de intcrcambio .

. .

~ - ~ -- - -- ~- - -- - - - - - - -- - -- --

I±l Frame 4 (74 on wi r e , 74 captured) I±l Ethernet II

Hl Inter net Protocol

B Lr ansmt sst on Control Protocol, Src Port: tel net (23), uat Port: 1122 (1122), Seq: 3483702130, Ad,: 2588305'317 Source port: tel net (23)

Destination port: 1122 (1122)

Sequence number: 3483702130

Acknowledgement number: 2588305917


G Flags: Ox0012 (SYN, ACK)

.. 0 ..... = Urgent: Not set

... 1 . -= Acknowledgment: Set

0.. = Push: Not set

.0 .. = Reset: Not set

.. 1 "Syn: Set

... 0'" Fin: Not set Window size: 32120 Checksim: Oxcld8

B Options: (20 bytes)

Maximum segment si Z8: 1460 bytes SACK permitted

Time s terc: t sval 26153764, t sec r 4948111 NO!'

Window scale: 0 bytes

0000 00 eO 98 7c 95 21 00 au d2 t c 64 e8 08 0045 00 ... 1.1.. .. d .. .E .
0010 OD3c 34 09 40 00 40 06 83 57 cO aa 01 01 cO a8 · <4.@.@. .w ..
0020 01 Oa 00 17 04 62 cf as 13 ?2 9a 46 6d e5 aD 12 .. b. . r. Fm ..
0030 7d 78 cl d8 00 00 02 04 05 b4 Cl4 02 08 Oa 01 Sf }~: ..
0040 13 24 00 4b 80 8f 01 03 0300 · $.K .. Figura 4.6. EI paqucte SYN-ACK del protocolo de intercambio.


como 3483702131, uno mas que el mimero de secuencia de mango, mostrando el siguiente byte que espera encontrar.

Con el protocolo de intercambio apartado, los datos de la capa de aplicacion pueden cornenzar a pasar en los siguientes segmentos TCP. Esto continua a 10 largo de la captura de datos hasta que se termina la conexion,

Ell Ethernet II

EEl Internet Protocol

8 Transm1ssion Control Protocol. SfC Port: 1122 (1122). Ost Port: tel net (23). Seq: 2588306917. Ack: 34837021 Source port: 1122 (1122)

Destination port: tel net (23)

Sequence mJl"ber: 2588306917

Acknowledganent nt.ft'ber: 3483702131

Header 1.n9th: 32 bytes

8 Flags: 0)(0010 (KK)

•• 0 •• ,., .. Urgent: Not set

... 1 AcknowledlJl1lnt: Set

.... 0 Push: Not set

..... 0 Reset: Not set

. ••• .• O Syn: Not set

.•••.•• 0" Fin: Not set

Wi ndow s1 ze: 32120 Checksllll: Oxf09d

8 Opt1 ons: (12 bytes) OOP

OOP

Time stem: tsval 4948111, tsecr 26153764

Figura 4.7. E1 paquete ACK del protocolo de intercambio.

En la Figura 4.8, que muestra una corriente TCp, podemos ver el comienzo de la finalizacion con el paquete resaltado. El cierre comienza cuando mango envia un paquete con los bits ACK y FIN establecidos. cherry responde con un paquete que tiene establecido el bit ACK. Despues envia un paquete con los bits ACK y FIN establecidos.

La Figura 4.9 muestra la respuesta de mango, el paquete final con solo el bit ACK establecido. Muestra tambien el primer paquete de cierre. Hemos resaltado los bits indicadores en esta captura de pantalla y podemos ver los bits ACK y FIN activados (el valor Oxll corresponde a 0100001).

UDP

UDP (User Datagram Protocol, Protocolo de Datagrama de Usuario) esta definido en el RFC 768. UDP proporciona un protocolo de transporte senci- 110 que utiliza datagramas para llevar los datos del origen al destino.

UDP ofrece una ventaja de velocidad frente a TCP al coste de algo de robustez. No hay sesion UDp, asi que no hay comienzo de sesion y no hay sobrecarga de seguimiento de una ventana de datos. El encabezamiento tiene la mitad de tamafio que el encabezamiento de TCP. Como UDP no esta orientado a la corriente como TCp, cada datagrama lleva un grupo de datos discreto para la aplicacion de nivel superior (0 la mayor parte de un grupo de datos discreto permitida por la ruta MTU).


mango 192.158.1.10

TElNET Tel net nete
TEU'lET Tel net uat a
TELNET T",l net [1001:.3
TElNET Te1ne1: uet a ..
TElNET relnet r.ate
TELNET Tel net [lata
Tep tetnet [A(V] Seq=2",:,88 30704 ~i P
HLN[T [lata
T(p 1122 t ... lnet [Ar~,l 510'11=::'588307043 p
TELNET t elnet [JOlta
T':P 11 2~' r el net
T(P 11 ~':' 1:10'1 -ct
To:P \12.:: telnet
T(P tetne t 11 2~' &1 10.1 '30631 192. \ 58.1. 10 52 10.191550 mango

53 10.,'j551g 192.1Ei8.1.10 5410.137616

6510.206734 .10

t.b 10.207747 mango

£7 10.218489 19::-.158.1.10

1.10

1.10

.10

I.IU

1.10

@ r r ame 72 (5& on wi r e , t.t. caotured) [±)Ethernet II

00 eO 98 t.. 95 21 au so d2 1,~ b4 e8 08 00 45 00

1)1) 34 54 27 4CI elo 40 05 8341 ,:0 a8 IJI 01 cu aB

01 ue 001704 &2 ,_f .3~, H 1)0 '~a 41; 5>:' &3 :3CI 11

7d 78 ea b. 01) 00 Ul 01 08 1],3 01 sf 1:' 24 00 4b

83 CI4

Figura 4.8. Un cierre de scsion de cuatro pasos.

" ...

-_ - -~~---- ------~- - -- - - - - - -- - - - - - ---

l±l Frame 72 (56 on wi r e , 55 captured) l±l Ethernet II

m tnte rner Protocol

E1Transmission Control Protocol. Sr c Port: tel net (23), Dst Port: 1122 (1122), Seq: )483702358. A(~; 2588307043

Source port: tel net (23) Destination POI-t: 1122 (1122) Sequence number: 3483702358

Acknowl edqament number: 2588307043 Header length: 32 bytes

MMF .••••• " ..

. 0. = Urgent: Not set

•.• 1 " "" Acknowledgment: Set

0.. "" Push: Hot set

.0 .. "" Reset: Not set

.. 0. Not set

•.• 1 = Set

Window size: 32120 Checksum: oxeabc

EI Options: (12 bytes) NOP

NOP

Time s tano : t sval 251'i4?R8. t ve.t r 43487411

90 eO ~.8 H"3S 21 00. alJ

UIJ ]4 H 40 OD 40 05

D 1 o;~ uo 04 52 .~ t dS

i'd i8 e8 00000101

83 04

d2 1.~ 54 1:8 08 OD 4S DO 83 41 ·:D .,,8 D1 01 ·:D a8 14 50 9.3 4t; t;e 133 8CI 11 08 Da 01 8f \i 24 00 4b

Figura 4.9. El primer paquctc ACK-FIN.

Un estudio de UDP

El cncabezamiento UDP esta cornpuesto de cuatro campos, cada uno de 2 bytes: el Puerto de origen lJDI~ el Puerto objetivo lJDI~ el Tarnano del mensaje y la Suma de comprobacion. Los puestos de Origen y Objetivo se utilizan para indicar cl proceso utilizado en cada extremo de la conexion, como describimos antcriorrncnte. El Tamafio del mcnsaje indica el numero de bytes


del encabezamiento UDP y los datos trasladados por el datagrama: el valor minimo es de 8 bytes.

La Suma de comprobacion de UDP es opcional. Si no la calcula el remitente, se envia como un campo de todo ceros (OxOOOO). Cuando la utilizamos, se computa para los datos y para el pseudoencabezamiento construido como el pseudoencabezamiento TCP explicado en la seccion anterior. Mostramos el pseudoencabezamiento en la Figura 4.10.

Dir. IP fuente de 4 bytes

Dir. IP destino de 4 bytes

OxOO I Ox I I I Long. de 2 bytes

Figura 4.10. Pseudoencabezamiento UDP para la computaci6n de la suma de comprobaci6n.

Se precisa un relleno en al menos un lugar (y posiblemente dos) de los datos de la suma de comprobacion. Hay un relleno de 1 byte entre la direccion IP de destino y el campo de Protocolo. Si hay un numero extraiio de bytes en la porcion de datos del datagrama UDP, se necesita otro relleno de 1 byte para hacer que los datos de la suma de comprobacion se ajusten a unos limites de 2 bytes.

UDP descodiflcado

El paquete UDP de la Figura 4.11 es una peticion DNS. EI Puerto de origen es Ox0402 (1042) y el Puerto de destino es Ox0035 (53 0 DNS) EI Tamafio es Ox0032 (50 bytes). La Suma de comprobacion esta en uso y tiene un valor de Ox590b.

Figura 4.11. Un encabezamiento UDP.

Aunque UDP no tiene sesiones como TCp, es posible que aplicaciones basadas en UDP lleven a cabo transacciones. La red de la Figura 4.12 muestra un buen ejemplo. Observemos que el primer paquete es una peticion generica y que recibe una respuesta vada. Las dos peticiones siguientes son para nombres de host distintos y reciben respuestas distintas.


ICMP

Mientras que TCP y lJDP trasladan datos, el ICMP (Internet Control Message Protocol, Protocolo de mensajes de control de Internet) ofrecc capacidades de informe de errores y diagnostico, Debido a csta funcionalidad, ICMP es una importante herramienta para la cornprension de nucstras rcdes.

Revision del protocolo

Los paquetes ICMP pueden generarse a partir de hosts IP cuando sc cncucntran cicrtos errorcs 0 por una aplicacion. Estas dos causas de generacion de un paquete ICMP nos ayudan a dividir dichos paquetcs en dos clascs: errorcs ICMP y peticiones-respuestas ICMP.

Figura 4.12. lin rastro de transacciones J)NS en UDP

Los errores ICMP generalmente se debcn a un fallo en la entrega de un datagrama IP. Como los datagramas IP no siguen una ruta fijada a traves de la red, los mensajes de error ICMP se devuelven s610 al host de origen, no a los encaminadores interrnedios, (Esto nos perrnite construir herramientas de diagnostico como traceroute, que explicaremos en el Capitulo 9.)

Todos los paquetes ICMP siguen la misma estructura basica: un campo de Tipo de 1 byte, un campo de Codigo de I byte y un campo de Suma de comprobacion de 2 bytes, seguidos de una cierta variedad de campos, dependiendo del tipo de paquete. Como la suma de comprobacion del encabezamiento II~ la de ICMP utiliza un valor de OxOOOO para su calculo. A difcrencia de ella, que utiliza s610 cl encabezamicnto, para el calculo se utiliza todo el paquete ICMP


Veremos la estructura de varios tipos de paquetes ICMP paso a paso. La Tabla 4.4 muestra los diferentes tipos de paquetes ICMP resumidos.

Tabla 4.4. Paquetes ICMP con Tipo y C6digo

Tipo COdigo Punclon
0/8 0 Petici6n-respuesta eco.
3 0-15 Destino inaccesible.
4 0 Apagado de origen.
5 0-3 Redireccionamiento.
9/10 0 Solicitud-aviso de encaminador (no mostrado).
11 0-1 TIL excedido.
12 0-1 Error de pararnetro.
13/14 0 Petici6n-respuesta de marca de tiempo.
15/16 0 Obsoleto (no mostrado).
17/18 0 Petici6n-respuesta de mascara de subred (no mostrado). Nota: no vamos a describir en el texto todos los mensajes ICMP enumerados en esta tabla. Hemos intentado describir 5010 los mas comunes e importantes.

Hay cinco tipos de errores que no producen mensajes ICMP:

Un fallo que implique a un mensaje de error ICMP.

Un datagrama IP con una direcci6n de destino de difusi6n.

Un marco de capa de enlace con una direcci6n de destino de difusi6n.

• Cualquier fragmento de un datagrama IP distinto del primero.

Cualquier datagrama cuya direcci6n de origen no sea una direccion uniconversi6n.

Si se enviaran mensajes de error ICMP para estos tipos de errores, el resultado podria ser un gran periodo de trafico llamado tormenta de difusi6n 3.

Petici6n-respuesta eco

Los mensajes de petici6n y respuesta eco ICMP son la base del comando Ibinlping explicado en el Capitulo 9. El host origen lleva a cabo una petici6n eco ICMP (fipo 8) y el host destino devuelve una respuesta eco ICMP (fipo 0).

EI mensaje de peticion/respuesta eco ICMP esta organizado asi: un campo Tipo de 1 byte, un campo C6digo de 1 byte (siempre OxOO), un campo Suma de comprobaci6n de 2 bytes, un campo Numero ID de 2 bytes, un campo Niimero de secuencia de 2 bytes y un campo Datos de tamafio variable. EI Numero ID es unico para comando ping que se lleve a cabo. EI Numero de secuencia se incrementa de forma separada en cada comando ping. Si ejecu-

3 Una tormenta de difusi6n es un periodo de trafico muy pesado (que a veces consume todo el ancho de banda disponible), caracterizada por el trafico enviado a direcciones que no son uniconversi6n.


tamos un guion como el siguiente, observaremos que cada ping tiene un Numero ID diferente pero el mismo Numero de secuencia:

for count in 1 2 3; do /bin/ping -c1 192.168.1.1

done

Si ejecutarnos este cornando, veremos que cada ping tiene el mismo Numero ID pero que se incrernentan los Nurneros de secuencia:

/bin/ping -c3 192.168.1.1

Destino inaccesible

Los mensajes de Destino inaccesible de ICMP se envian cuando no se puede entregar un paquete en el destino. Estos mensajes estan organizados asi: un campo Tipo de 1 byte (Ox03), un campo Codigo de 1 byte (vcase la Tabla 4.6), un campo Suma de comprobacion de 2 bytes, un campo Reservado de 4 bytes (estc campo debe ser OxOOOOOOOO), un campo Encabezamiento IP fallido de 20 bytes y un campo Datagrama IP fallido de H bytes. Los 20 bytes del campo Encabezamiento IP fallido ofrecen todos los datos necesarios para identificar el paquete IP de origen de la condicion de error. Los 8 bytes del campo Datos IP fallidos muestran los primeros 8 bytes del encabezamiento de la capa de transporte; esto ofrece suficiente informacion para identificar la aplicacion que ha causado la condicion de error. Mostramos la organizacion de este tipo de paquete ICMP en la Tabla 4.5.

Tabla 4.5_ Campos del mensaje Destino inaccesihle de ICMP

Tamaiio Contenido Datos de ejemplo
1 byte Tipo 03
1 byte C6digo 00
2 bytes Suma de comprobacion Oa7b
4 bytes Reservado 00000000
20 bytes Encabezamiento IP fallido 45 ...
R bytes Datos IP fallidos 05 b3. La Tabla 4.6 muestra varios valores de Codigo que se pueden enviar en los rnensajes Destine inaccesible de ICMP.

Tabla 4_6. C6digos de Destino inaccesible de ICMP

C6digo

Significado

() 1

La red es inaccesible EllJost es inaccesible

(continuu )


Tabla 4.6. C6digos de Destino inaccesible de ICMP. (Continuaci6n)

COOlgo Significado

2 El protocolo es inaccesible.

3 El puerto es inaccesible.

4 Se necesita fragmentaci6n pero esta desactivada.

5 Ruta de origen fallida.

6 La red de destino es desconocida.

7 El host de destino es desconocido.

8 Obsoleto.

9 La red de destino esta prohibida.

10 El host de destino esta prohibido.

11 La red es inaccesible para TOS.

12 El host es inaccesible para TOS.

13 La comunicaci6n esta prohibida por un filtro.

14 Ha tenido lugar una violacion de precedencia de host.

15 El corte de precedencia esta en efecto.

Los c6digos del 0 al 3 son los valores mas normales, aunque el 4 se utiliza al determinar la rota MTIJ de una cone:xi6n de red.

Apagado de origen

Los mensajes de Apagado de origen ICMP se utilizan cuando un encaminador esta cercano allimite de su capacidad de buffer. El encaminador envia su mensaje al host de origen del datagrama que dispar6 el evento. Se supone que el sistema que recibe el mensaje de apagado de origen reduce su indlce de transmisi6n hasta que deja de recibir este tipo de mensajes.

EI mensaje de apagado de origen contiene los siguientes campos: un campo Tipo de 1 byte (siempre Ox04), un campo C6digo de 1 byte, un campo Suma de comprobaci6n de 2 bytes, un campo Reservado de 4 bytes (este campo deberia ser OxOOOOOOOO), un campo Encabezamiento IP fallido de 20 bytes y un campo Datos IP fallidos de 8 bytes. La Tabla 4.7 muestra una comparaci6n de los campos de los mensajes de apagado de origen.

Tabla 4.7. Campos del mensaje Apagado de origen de ICMP

Tamafto

Contenido

Datos de ejemplo

1 byte

1 byte

2 bytes 4 bytes 20 bytes 8 bytes

Tipo Codigo

Suma de comprobaci6n Reservado Encabezarniento IP fallido Datos IP fallidos

04

00

Oa7b 00000000 45 ...

05 b3 ...


Redireccionamiento

Los mensajes de redireccionamiento de ICMP se envian cuando un host intenta utilizar un encaminador inapropiado. La Figura 4.13 muestra una red en la que podria ocurrir.

sherman

; - -- I

1(Jlcherry

1,:;1"!'III?'

Figura 4.13. Una red con dos cncarninadores.

cherry utiliza a mango como su encarninador predeterminado, para la siguiente tabla de enrutamiento:

Destination Gateway Genmask Flags M3S WindON irtt Iface
192.168.1.10 0.0.0.0 255 . 255 . 255.255 lJ-l 00 o eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 00 o eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 00 o 10
0.0.0.0 192.168.1.1 0.0.0.0 LG 00 o eth0 mango necesita enviar trafico a sherman (que reside en una red tras papaya). cherry envia el primer paquete a mango, que se 10 pas a a papaya y envia un mensaje de redireccionamiento ICMP (mensaje ICMP Tipo 5 Codigo 0) a cherry. Entonces cherry debe ria actualizar su tabla de encaminamiento para que tuviera la siguiente apariencia:

Destination Gateway Genmask Flags M3S WindON irtt Iface
192.168.1.10 0.0.0.0 255.255.255.255 lJ-l 00 o eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 00 o eth0
192.168.2.0 192.168.1.11 255.255.255.0 in 00 o eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 00 o 10
0.0.0.0 192.168.1.1 0.0.0.0 LG 00 o eth0 'Iodo el trafico posterior a la red 192.168.2.0/24 deberia ir ahora a traves de papaya.

Un mensaje de redireccionamiento ICMP esta organizado de la misma forma que el mensa]e de apagado de origen descrito anteriormente. Los campos son un campo Tipo de 1 byte, un campo Codigo de 1 byte, un campo Suma de cornprobacion de 2 bytes, un campo Reservado de 4 bytes (este campo


deberia ser OxOOOOOOOO), un campo Encabezamiento IP fallido de 20 bytes y un campo Datos IP fallidos de 8 bytes. Mostramos la organizaci6n del mensaje y los posibles valores del campo C6digo en las Tablas 4.8 y 4.9.

Tabla 4.8. Campos del mensaje Redireccionamiento de ICMP

Tamaiio Contenido Datos de ejemplo
1 byte Tipo 05
1 byte C6digo 00
2 bytes Suma de comprobaci6n Oa7b
4 bytes Reservado 00000000
20 bytes Encabezamiento IP fallido 45 ...
8 bytes Datos IP fallidos 05 b3 ... Tabla 4.9. C6digos de Redireccionamiento de ICMP

C6digo Significado

o Redireccionamiento para red

1 Redireccionamiento para host

2 Redireccionamiento para red y TOS

3 Redireccionamiento para host y TOS

1TL excedido

El mensaje TI'L excedido de ICMP es la base del comando lusrlsbin/traceroute. Se genera cuando la cuenta de saltos de un paquete excede su TTL. (por favor, observemos que tambien hay un c6digo que representa un exceso de tiempo mientras esperamos la desfragmentacion.) Los mensajes TTL contienen los siguientes campos: un campo Tipo de 1 byte (siempre OxOll), un campo C6digo de 1 byte, un campo Suma de comprobaci6n de 2 bytes, un campo Reservado de 4 bytes (este campo deberia ser OxOOOOOOOO), un campo Encabezamiento IP fallido de 20 bytes y un campo Datos IP fallidos de 8 bytes. Mostramos este mensaje y los Codigos validos en las Tablas 4.10 y 4.11.

Tabla 4.10. Mensaje TTL excedido de ICMP

Tamaiio

Contenido

Datos de ejemplo

1 byte

1 byte

2 bytes 4 bytes 20 bytes 8 bytes

Tipo Codigo

Suma de comprobaci6n Reservado Encabezamiento IP fallido Datos IP fallidos

Ob

00

Oa7b 00000000 45 ...

05 b3 ...


Tabla 4.11. Codigos de TrL exccdido de ICMP

C6digo Significado

() TTL igual a () durante cl transit o,

I TTL igual a () durante la reconstrucc-ton.

Error de pararnetro

Cuando se detccta un error en el encabezamiento IP de un paquete, se cnvia un mcnsaje error de pararnetro de ICMP al host que 10 origina. Este mensaje indica que uno de los campos se ha perdido 0 es incorrccto. La organizacion del mensaje de error de pararnetro es similar a la de los otros mcnsajes de error de ICMP: un campo Tipo de 1 byte (sicmpre OxOc), un campo Codigo de 1 byte, un campo Suma de cornprobacion de 2 bytes, un campo Puntero a los datos erroneos de 1 byte, un campo Reservado de 3 bytes (este campo deberia ser OxOOOOOOOO), un campo Encabezamiento II' fallido de 20 bytes y un campo Datos IP fallidos de 8 bytes. Podernos ver dicha organizacion en 1a Tabla 4.12. Observernos que el campo Puntero a los datos erroneos cs 0 (10 que indica que cl error esta en el primer byte).

La Tabla 4.13 muestra los campos C6digo validos para el mensaje de parametro de ICMP

Tabla 4.12. Mensaje Error de pararnetro de IeMP

Tamaiio

Contenido

Datos de ejemplo

I byte

I byte

2 bytes I byte

3 bytes 20 bytes 8 bytes

Tipo Codigo

Suma de comprobaci6n Puntero a los datos erroneos Reservado

Encabezamiento IP fallido Datos IP fallidos

Ob 00 Oa7b 00

0000 00 00 40 ..

OS b3.

Tabla 4.13. C6digos de Error de parametro de ICMP

C6digo Significado

o El encabezamiento IP es erroneo.

I Se ha perdido una operon necesaria.

5

Protocolos de la capa de aplicacion

Desde que comenzamos con la capa de enlace en el Capitulo 2, "Protocolos de la capa de enlace", hemos recorrido la pila de protocolos. Ahora hemos llegado a la cima. Ahora, en las cumbres de la capa de aplicaci6n, vamos aver mucha mas variedad que en cualquier otra capa que hayamos explicado. En este capitulo, explicaremos tres protocolos: RIP, TFfP Y HTTP Los dos primeros estan construidos sobre UDP; el tercero utiliza TCP

RIP

Utilizamos el RIP (Routing Information Protocol, Protocolo de informacion de encaminamiento) para enviar informacion de encaminamiento entre hosts en red I. RIP se especifico formalmente en el RFC 1058, que fue escrito varios afios despues de la implernentacion del protocolo en Berkeley UNIX. Actualmente, la version mas cornun de RIP con mas uso es la version 2, 0 RIP-2, especificada en el RFC 1388. Los equipos mas antiguos que ejecuten RIP pueden en tender los paquetes RIP-2 porque utiliza campos reservados de RIP para enviar informacion adicional y RIP ignora dichos paquetes. En el resto de esta seccion, vamos a hablar de la version 2 de RIP; cuando utilicemos el termino RIP, nos referiremos a RIP-2.

I Para obtcner mas informacion sobre encaminarniento, vease la scccion "Encaminarniento" del Capitulo 3, "Protocolos de la cap a de red".

78 Capitulo 5 Protocolos de la capa de aplicaci6n

RIP solo proporciona un esquema de encaminamiento muy sencillo: confia en la cuenta de saltos como unica metric a para la determinacion de la rota a escoger. Cada host participante retransrnite un mensaje que contiene su lista de redes conocidas con la correspondiente cuenta de saltos. Como las actualizaciones se retransmiten solo de forma periodica (generalmente cada 30 0 90 segundos), a los encaminadores les puede llevar mucho tiempo propagar una red. RIP tiene una forma de ayudar a reducir esto al minimo, cualquier cosa que requiera mas de 15 saltos se considera inaccesible.

La Figura 5.1 muestra los encaminadores utilizados para conectar varias redes pequefias. La Tabla 5.1 muestra las interfaces y direcciones IP de dichos encaminadores (damos el nombre en el formato nombre.interfaz). Utilizaremos esta red para mostrar el funcionamiento normal de RIP y para ilustrar un inconveniente de RIP junto con su solucion.

Tabla 5.1.

Encaminadores, interfaces y direcciones

Nombre e interfaz

Direcci6n IP Y mascara de subred

aaron.O aaron. 1 aaron.2 alan.O alan. 1 alan. 2 bob.O bill.O

bill. 1

bill. 2 bruce.O bruce. 1 brandon.O brandon. 1 chuck.O chuck. 1 caleb.O caleb. 1 caleb. 2 carLO carLl

carL 2 doug.O doug. 1 don.O don. 1

192.168.1.1/24 192.168.2.1/24 192.168.3.1/24 192.168.4.1/24 192.168.5.1/24 192.168.6.1/24 192.168.6.2/24 192.168.5.2/24 192.168.12.1/24 192.168.13.1/24 192.168.3.2/24 192.168.14.1 192.168.2.2/24 192.168.15.1/24 192.168.13.2/24 192.168.21.1/24 192.168.12.2/24 192.168.22.1/24 192.168.23.1/24 192.168.14.2/24 192.168.15.2/24 192.168.24.1/24 192.168.22.2/24 192.168.24.2/24 192.168.21.2/24 192.168.23/24

Capitulo 5 Protocol os de la capa de aplicaci6n 79

aaron

brandon

Figura 5.1. Los encarninadores de una pequefia interred.

Cada encaminador de la Tabla 5.1 tiene una vision distinta de la red. alan y aaron tienen una conexion directa a Internet y pueden actuar como pasarelas predeterminadas para las redes que hay tras ellas. doug y don estan en la parte de arras de la red y ambas tienen una cierta variedad de rutas para llegar a la parte de delante. Comencemos observando el punto de vista del mundo de alan, bill, caleb y doug, adernas de la informacion de encaminamiento que enviaran,

alan tiene una entrada predeterminada de 0.0.0.0/0 a traves de la interfaz O.

No estara configurada para enviar informacion de encaminamiento fuera de la interfaz, para evitar direcciones de difusion internas (RFC 1918). Tambien tiene caminos de un salto hacia las redes 192.168.4.0/24, 192.168.5.0/24 Y 192.168.6.0/242. Como bill ya tiene un camino de un saIto hacia la red 192.168.5.0/24, ignora esta entrada. Las dernas se anaden a su tabla de encaminamiento. En su siguiente difusion, bill envia informacion sobre todas las entradas de uno y dos saltos de su tabla de encaminamiento. (Ahora, tambien alan conoce la red 192.168.13.0/24.)

BUCLES DE ENCAMINAMIENTO Y HORIZONTE DIVIDIDO

Aqui es donde nos encontrarnos nuestro problema mas importantc con RIP iQue ocurriria si alan.3 fallara? bill enviaria una difusion RIP que rnostraria una entrada de dos saltos hacia la red 192.168.6.0/24. Normalmente, alan las ignoraria, porque tienen una cuenta de saltos mayor que sus propias entradas, pero, sin la interfaz eth3, los caminos de bill pasan a ser los mejores disponibles, excepto en que implican un saito hacia atras hasta alan.

RIP no lIeva suficiente informacion para detener estc tipo de bucks de encaminamiento. En lugar de ello, confia en un metodo llamado horizonte dividido. Ningun participante RIP retransmitira fuera de la interfaz un camino que haya recibido en ella.

Si bill sigue esta norma, alan nunca recibe los caminos erroneos de bob y evitarnos el bucle de encaminamiento.

1 Estos son todos caminos de dos saltos porque hill ha aiiadido uno a la cuenta de sail os para cada camino, indicando que debe pasar por alan.

80 Capitulo 5 Protocolos de la capa de aplicaci6n

Continuando con nuestro ejemplo, caleb tiene caminos de un salto a las redes 192.168.12.0/24, 192.168.22.0/24 Y 192.168.23.0/24. Cuando recibe la difusion de bill, caleb aprende caminos de dos saltos a las redes 192.168.13.0/24 y 192.168.5.0/24 Y de tres a las redes 192.168.4.0/24 y 192.168.6.0/24. Retransmitira su propia tabla de encaminamiento y bill y alan conoceran las redes 192.168.22.0/24 y 192.168.23.0/24 (con dos y tres saltos respectivamente).

doug comienza con caminos de un salta a las redes 192.168.22.0/24 y 192.168.24.0/24. Tras recibir las actualizaciones de caleb, doug tambien tendra caminos de saltos a las redes 192.168.23.0/24 y 192.168.12.0/24, de tres a las 192.168.13.0/24 y 192.168.5.0/24 Y de cuatro a las 192.168.4.0/24 y 192.168.6.0/24.

En las descripciones anteriores hemos visto el flujo de los datos RIP en una sola direccion. En realidad, fluye en ambas direcciones. Despues de que la red lleve conectada un rato, los caminos se propagan a traves de ella. En este momento, alan tendra una tabla de encaminamiento como la mostrada en la Tabla 5.2.

Tabla 5.2. Tabla de encaminamiento de alan

192.168.4.0/24 192.168.5.0/24 192.168.6.0/24 192.168.12.0/24 192.168.13.0/24 192.168.21.0/24 192.168.22.0/24 192.168.23.0;24 192.168.24.0/24 192.168.14.0/24 192.168.15.0/24 192.168.3.0/24 192.168.2.0/24 192.168.1.0/24

Saito siguiente Cuenta de saItos
192.168.4.1 1
192.168.5.1
192.168.6.1 1
192.168.6.2 2
192.168.5.2 2
192.168.5.2 3
192.168.5.2 3
192.168.5.2 3
192.168.5.2 4
192.168.5.2 5
192.168.5.2 5
192.168.5.2 6
192.168.5.2 6
192.168.5.2 7 Red

Rastro del protocolo RIP-2

La Figura 5.2 muestra una peticion RIP-2. El paquete esta dirigido a la direccion de difusion IP. Tanto el puerto de origen como el de destino se envian a 520. Dentro del datagrama RIP, el campo Comando esta establecido como 1 (Peticion), El campo Version de RIP esta establecido como 2.

Capitulo 5 Protocolos de la capa de aplicaci6n 81

TFTP

EI TFTP (Trivial File Transfer Protocol, Protocolo de transferencia de archivos trivial) es un protocolo basado en el UDP (User Datagram Protocol, Protocolo de datagram a de usuario) para el intercambio de archivos entre sistemas. Fue disefiado para acelerar y facilitar la implernentacion de un host con recursos limitados. TFTP esta definido en el RFC 13';0.

[!] Frame I (52 on wi r e , S2 captured) ffi Raw packet data

ffiInternet Protocol

El User Dat aqr am Protocol

Sour-.e port: route (')20) Destination port: route (520) t enqtb: 32

Checksum: Ox11 fl

B Routinq Inf o rmati on Protoco l Corrrnand: 1 (Request) Version: ::

Routing nornatn: 0 unknown address f ami ly 0

4Sbo,,1 lheJ3rl>fRIPv.:' Rf''1t1E'~! '

-- ----

DODO 45 00 00 ]4 00 7b 00 00 01 11 co a3 dB 29 27 -tb E .• 4. (.. . .. ) ',",

DOlO d t f7 17 2f 02 08 02 08002011 fl 01 020000 .. ,1.

0020 000000 00 00 00 00 00 00 00 00 00 00 00 00 00

0lJ30 DO 00 00 10

Figura 5.2. lin aviso de camino RIP.

Revision del protocolo

TFTP esta implementado con cinco tipos de paquetes:

Peticiones de lectura. Peticiones de escritura. Datos de archivo.

Acuses de recibo. Manipulaci6n de errores.

Cada uno de estos tipos de paquetes (excepto las peticiones de lectura y de escritura) tiene una estructura de paquete ligeramente diferente. Echaremos un vistazo a cada una de elias por orden.

Las peticiones de lectura y escritura de paquetes tienen cinco campos. EI primero es de 2 bytes y es el campo C6digo Op; las peticiones de lectura son Ox0001 y las de escritura Ox0002. EI siguiente campo es de tamano variable y es el nombre del archivo a leer. A continuaci6n hay un separador de 1 byte, que siempre es OxOO. EI cuarto campo es el Modo de datos y puede tener uno de estos tres valores:

Netascii. Binario.

La direcci6n de e-mail del rernitente (s610 en las peticiones de escritura).

EI cuarto campo es de tamafio variable. EI quinto es de 1 byte y es un marcador de EOF (End of File, Final de archive); siempre es OxOO.

Los paquetes de datos solo tienen tres campos. EI primero cs el campo Codigo Op y tiene 2 bytes; siernpre es Ox0003. EI segundo es el Numero de

82 Capitulo 5 Protocol os de la capa de aplicaci6n

bloque y tiene 2 bytes. EI resto del paquete (con una longitud maxima de 512 bytes) son los datos. Cuando TFrP transfiere datos, utiliza un mecanismo sencillo para ver donde esta dentro de los datos a ser transferidos. Los datos estan divididos en bloques de 512 bytes y cada uno se envia y se acusa recibo de forma individual 3 . El Ultimo paquete de una transferencia es un paquete de datos con un campo de datos menor de 512 bytes. Si los datos se dividen exactamente en bloques de 512 bytes, se enviara un paquete vacio en Ultimo lugar (con 0 bytes, que es menor que 512).

Cada bloque de datos se responde con un paquete de acuse de recibo.

Este paquete tiene 4 bytes y dos campos. El primer campo es el C6digo Op de 2 bytes (OX0004). EI segundo es el mimero de bloque de 2 bytes del bloque al que se esta dando acuse de recibo.

Como nada es perfecto, TFfP tiene un sistema de manipulaci6n de errores sencillo construido en un paquete de manipulacion de errores. Estos paquetes tienen cuatro campos y son de tamafio variable. El primer campo es el Codigo Op; tiene 2 bytes y es siempre Ox0005. El segundo es de 2 bytes y lleva el c6digo de error. El tercero es el texto del error, de tamafio variable. En la Tabla 5.3 mostramos los c6digos de error validos y sus correspondientes textos de error.

Tabla 5.3.

C6digos de error TFfP.

COdigo de error

Texto de error

OXOOOO OxOOOI OxOOO2 OxOOO3 OxOOO4 OxOOO5 OxOOO6 OxOOO7

Error indefmido.

Archivo no encontrado. Violaci6n de acceso. Espacio de disco excedido. Operacion ilegal.

ID de transferencia desconocida. El archivo existe.

No existe dicho usuario.

Rastro del protocolo TFfP

La Figura 5.3 muestra una petici6n de lectura TFfP; el campo C6digo Op es OxOOOl. EI siguiente campo es el nombre del archivo a leer, testout. A continuaci6n hay un marcador EOF, OxOO. El siguiente campo es el modo de datos, netascii. EI ultimo es otro marcador EOF, OxOO.

3 Nos puede llevar a una complicaci6n poco afortunada. EI remitente guarda un temporizador en los datos que envia, Si el receptor no acusa recibo de un bloque de datos antes de que el temporizador expire, el remitente enviaci otra copia. Si el receptor ha tardado, envtara un acuse de recibo del bloque y despues otro cuando reciba la segunda copia. Si continua ocurriendo, crea un efecto de bola de nieve que congestiona la red. A esto frecuentemente se Ie llama el fallo del Aprendiz de brujo, debido a la escena de Fantasia en la que Mickey Mouse conjura un ejercito de gamuzas para limpiar la tocre del brujo (las gamuzas se Ie van r:ipidamente de las manos, como el proceso TFTP que sufre este error).


DODO 00 aD d2 1.: 64 db 00 an d2 1 ( 64 88 08 00 4S 00 0010 00 2e 18 20 00 00 4Lll1 df 33 cO a8 0101,=0 ea 0020 01 14 04 IJ1 00 45 00 1 a 93 04 00 02 74 65 73 74 0030 69 61' 00 lie 65 74 61 73 63 69 69 00

.... d:@: ,d.. .E.

E test

tn.netes cii.

[3 Frame 70 (60 on wi reo 60 captured) I±I Ethernet II

@ Internet Protocol @User Datagram Protocol

Write Request Destination File: testin Type: net esc i i

I~

Figura 5.3. Una peticion de lectura TITP

La Figura 5.4 rnuestra una peticion de escritura TFTP; el campo Codigo Op es Ox0002. EI nombre del archivo a escrihir es testin, seguido de un OxOO (cl marcador EOF). EI modo de datos es netascii y tarnbien esta seguido por un marcador EOE

0000 00 aD d2 1C 64 db 00 aD d2 1( 64 e8 DB 0045 00 0010 00 2e 18 20 00 00 40 11 df 39 cO a8 01 01 cO aa 0020 01 14 04 01 00 45 00 1a 93 04 00 02 74 65 73 74 0030 69 6e 00 6e 65 74 61 73 63 69 69 00

.... d ..... d ... E. •••• @. •• 9.

in.~~~~s ~ii. test

[3 Frame 70 (60 on wi reo 60 captured) [±l Ethernet II

m tnter net Protocol

[±] User net aqr en Protocol

B Trivial file Transfer orotcco:

Write Request Destination File: testin Type: net asc i i

Figura 5.4. Una peticion de escritura TFTP.

En la Figura 5.5 mostramos eI paquete de datos TFTP. EI campo Codigo Op es Ox0003; eI numero de bloque es OxOOOl. EI resto del paquete es un gran campo Datos. Tiene 512 bytes, as! que sabemos que quedan mas paquetes por Uegar.

0020 01 01 04 01 04 01 02 OC &1 &7 00 03 00 01 74 G8 0030 69 73 20 69 73 zn 61 20 74 65 73 74 Ze 20 20 74 0040 68 69 73 20 69 73 20 61 zo 74 65 73 74 2e 20 20 0050 od Oa 74 68 69 73 20 69 73 20 61 ZO 74 65 73 74 0060 2e ZO 74 68 69 73 20 69 73 20 61 20 74 65 73 74 0070 ze 20 74 68 69 73 20 69 73 20 61 20 74 65 73 74 0080 2e 20 74 68 69 73 20 69 73 ZO 61 20 74 65 73 74 00'30 2e 20 74 68 69 73 20 69 73 20 61 20 74 65 73 74 OOaO 2e 20 74 G8 69 73 ZO 69 73 ZO 61 ZO 74 65 73 74

OObO ~e ~~ !~ ~ ~~ !~ ~ ~~ !~ ~ ~! ~ !~ ~~ !~ !~

is·.is.a. ~~i:::~~

his.h.a .test ...

· .this.i s.a.test

· .this.; a.a.rest

· .this.i s.a.test

· .this.i s.a.resr

· .this.i s.a.test .this.f sca.resr .. !~~s.! ~.a.test

[±] Frame 2 (558 on wi reo 558 captured) [±] Ethernet II

[±]Internet Protocol

El User Datagram Protocol

Data Packet Block ... 1

Data (512 bytes)

Figura 5.5. Un paquete de datos TFTP.

84 Capitulo 5 Protocol os de la capa de aplicaci6n

La Figura 5.6 muestra un paquete de Acuse de recibo TFfP. Su campo C6digo Op es Ox0004 y su rnimero de bloque es OxOOO I. El resto del paquete esta relleno para a1canzar el limite minimo de tamaiio de datos de un paquete de Ethernet II.

0000 00 aD d2 tc 64 db 00 aD ~~ tc G4 8S'08 00 <tS 00 0010 002017 ff 00 00 40 11 ~~ 68 cO a8 01 01 cO a8

0020 01 14 04 01 04 01 00 Oc 69 00 04 00 01 73 74

0030 sf 7S 74 00 6e 65 74 61 63 69 69

.... d .•••• d ••• E. •.•.•••.• h •....• ........ t t •.•. st

out. neta sci 1

IE Frame 3 (60 on wi reo 60 captured) IB Ethernet II

III Internet Protocol

III User Datagran Protocol 8Trivial File Transfer Protocol

Acknowl edgement Block - 1

Figura 5.6. Un paquete de acuse de recibo TFfP.

En Ia Figura 5.7 mostramos el ultimo tipo de paquete TFfP, un paquete de error TFfP. EI campo C6digo Op es OXOOO5. El c6digo de error es OxOOOI y el texto de error es "File not foundr (Archivo no encontrado).

0000 00 aD d2 tc 64 e8 00 au ~~ tc 64 db 08 00 45 00 0010 00 2f 00 58 00 0040 11 ~? 00 cO as 01 14 cO a8

0020 01 01 04 02 04 01 00 1b 58 00 05 00 01 46 69

0030 Be 65 20 6e sf 74 20 66 7S 6e 64 00

Ii .. d .•. E. ........ jx::: :F1

le.not. found.

(f] Frame 75 (61 on wi reo 61 captured) IE Ethernet II

III Internet Protocol

HI User Datagram Protocol STri'll1al File Transfer Protocol

Error Code

Code - Fll e not found

Error Message: File not found

Figura 5.7. Un paquete de error TFfP.

Conflguraclon de un servidor para TFfP

La configuraci6n de un equipo Linux para servir a TFfp es una tarea bastante sencilla. TFfp es un hueco de seguridad notorio, pero tambien puede ser una parte importante de nuestra red. Los sistemas sin disco y otros tipos de hardware utilizan frecuentemente TFfp para recuperar archivos de configuracion de un servidor especifico.

Hay dos problemas importantes de seguridad en TFTP: el primero, permite el acceso de escritura y lectura anonimo en un puerto bien conocido. EI segundo, es una aplicaci6n basada en UDp, as! que es dificil de manipular con un cortafuegos (casi el bloqueo de todo).

Como ocurre en Ia mayoria de los protocolos, si no necesitamos TFfP, mejor no ejecutarlo. Si necesitamos un servidor TFfP, 10 ejecutamos en un solo equipo y hacemos todo 10 posible por mantenerlo tan segura como podamos. Los siguientes parrafos explican como hacerlo.


La configuraci6n de un servidor TFTP es tan sen cilia como modificar nuestro archivo /etc/inetd.conf y enviar a inetd la serial HlJP" La seccion que queremos cambiar tiene la apariencia de la que mostramos en el Ejemplo 5.1 (al menos en sistemas basados en Red Hat 6.2).

Ejemplo 5.1. Un inetd.conf sin TFrp activado.

# El servicio TFTP se proporciona principalmente para el arranque. # La mayo ria de los sitios

# ejecutan esto s610 en equipos que act~an como 'servidores de # arranque.' No deje de comentar

# esto a menos que 10 *necesite*.

#

#tftp dgram #bootps dgram #

udp udp

wait wait

root root

/usr/sbin/tcpd /usr/sbin/tcpd

in.tftpd bootpd

Tenemos que cambiarla hasta que tenga la apariencia del Ejemplo 5.2.

Ejemplo 5.2. Un inctd.conf con Tf<TP activado.

# El servicio TFTP se proporciona principalmente para el arranque. # La mayoria de los sitios

# e j ecutan esto s610 en equipos que ac tuan como 'serv idores de # arranque.' No deje de comentar

# esto a menos que 10 *necesite*.

#

#tftp dgram #bootps dgram #

udp udp

wait wait

root root

/usr/sbin/tcpd /usr/sbin/tcpd

in. tftpd bootpd

Despues de hecho este cambio, podemos suprimir el servidor inetd. Mostramos el proceso en el Ejemplo 5.3.

Ejemplo 5.3. HUP de inetd.

[root@cherry /root)# ps ·aux I grep inetd
root 482 0.0 0.0 1148 0 ? fNV Aug08 0:00 [inetd)
root 2791 0.0 0.8 1360 508 pts/1 R 04:31 0:00 grep inetd
[root@cherry /root)# ps ·ef I grep inetd
root 482 1 0 Aug08 ? 00:00:00 [inetd)
[root@cherry /root)# kill ·1 482
[root@cherry /root)# ps ·aux I grep inetd
root 482 0.0 0.3 1148 240 ? S Aug08 0:00 inetd
root 2795 0.0 0.8 1364 524 pts/1 S 04:32 0:00 grep inetd
[root@cherry /root)# , lin HlIP 0 Colgado (Hang UP) se envia con el coman do kill-I [pid].

Redes Linux Con Tcpip

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Redes Linux Con Tcpip

Uploaded by

Copyright:

Available Formats

Redes Linux conTCP/IP

You might also like

Redes Linux Con Tcpip

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Redes Linux Con Tcpip

Uploaded by

Copyright:

Available Formats

﻿Redes Linux conTCP/IP

You might also like

Redes Linux conTCP/IP