NAE-TCP-A01-v1.0.07

NAE-TCP-A01 Network Administration Engineer

Arquitectura TCP/IP Introducción V1.0.07 Libro de Estudio

ABC Xperts ® Network Xperts ® Academy Xperts ®

Derechos de autor y marcas registradas Todos los derechos de autor y marcas registradas son propiedad del titular de los derechos de autor respectivo

Derechos de autor © por Academy Xperts Todos los derechos reservados. Ninguna parte de este libro puede ser reproducido, alm acenado, o transmitido por cualquier medio ya sea este un auditorio, medio gráfico, mecánico, o electrónico s in el permiso escrito del autor, excepto en los casos en que se utilicen breves extractos para usarlos en artículos o revisiones. La reproducción no autorizada de cualquier parte de este libro es ilegal y sujeta a sanciones legales.

NAE NAE-TC TCPP-A0 A01 1 v1.0.0 v1.0.07 7 – Arqu Arquit itec ectu tura ra TCP/ TCP/IP IP,, Intr Introdu oducc cció ión n

Tabla de Contenido Prólogo ..................................................................................................................................................... ............ ii Resumen .......................................................................................................................................................................... iii Audiencia ......................................................................................................................................... .......................................................................................................................................................................... ................................. iii Convenciones usadas en este libro...................................................................................................................... .................................................................................................................................. ............ iii Comentarios y preguntas ................................................................................................................................................. ................................................................................................................................................. iii

Partners de Academy Xperts X perts en Latinoamérica L atinoamérica .............................................................................................. iv Empresas Asociadas ........................................................................................................................................................ ........................................................................................................................................................ iv Universidades e Institutos Superiores ............................................................................................................................... ...............................................................................................................................v Deseas convertirte en Academia o ser Partner de A cademy Xperts? ..............................................................................v Un poco de Historia (Costa Rica) ..................................................................................................................................... ..................................................................................................................................... vi Cubriendo un País con MikroTik. ............................................................................................................................. vi

Capítulo 1: Principios de la Arquitectura Arquitectur a .............................................................................................. ............ 1 Introducción ................................................................................................................ ....................................................................................................................................................................... .......................................................1 Principios de la arquitectura .............................................................................................................................................. ..............................................................................................................................................4 Paquetes, Conexiones y Datagramas ....................................................................................................................... .......................................................................................................................5 El Argumento Extremo a Extremo y el Destino compartido ..............................................................................................6 Control de Errores y Control de Flujo ........................................................................................................................ ........................................................................................................................7

Capítulo 2: Diseño e Implementación .................................................................................................. .............. 9 Capas ......................................................................................................................... ................................................................................................................................................................................ ....................................................... 9 Relación entre los campos de la aplicación WIRESHAR K con las capas del protocolo TCP/IP ....................................10 Multiplexación, Demultiplexación y Encapsulamiento en implementaciones de capas ..................................................16

Capítulo 3: Arquitectura y protocolos de la Suite TCP/IP ............................................................................. 18 El modelo de referencia ARPANET ...................................................................................................................... ................................................................................................................................. ...........18 Multiplexación, Demulti plexación, y Encapsulamiento en TCP/IP ..................................................................................20 Numero de puertos ............................................................................................................................................... .......................................................................................................................................................... ...........20 Nombres, Direcciones, y el DNS ..................................................................................................................................... .....................................................................................................................................21 Internet, Intranet, y Extranet ............................................................................................................................................ ............................................................................................................................................21

Capítulo 4: Diseñando Aplicaciones ............................................................................................................... 23 Cliente/Servidor ............................................................................................................................... ............................................................................................................................................................... ................................23 Peer-To-Peer ............................................................................................................. ................................................................................................................................................................... ......................................................23 Interfaz de programación de aplicaciones (APIs) ............................................................................................................24 Proceso de Estandarización ............................................................................................................................................ ............................................................................................................................................24 Solicitud de comentarios (RFC)............................................................................................................................. ....................................................................................................................................... ..........25 Otros estándares ............................................................................................................................................................. .............................................................................................................................................................26 Implementaciones y distribuciones de software .............................................................................................................. ..............................................................................................................26 Ataques con la arquitectura de internet ................................................................................................................ ........................................................................................................................... ...........27 Resumen .................................................................................................................... ......................................................................................................................................................................... ..................................................... 29

Academy Xperts

i

NAE-TCP-A01 v1.0.07 – Arquitectura TCP/IP, Introducción

Prólogo MikroTik es una empresa que nace en Latvia (Letonia) en 1996 con el claro objetivo de proveer un sistema operativo de red altamente robusto y eficiente al cual llamó RouterOS en 1997. La evolución del mismo llevó a la creación y lanzamiento al mercado en el 2002 de un hardware que aprovechara al máximo sus grandes capacidades de multiprocesamiento simétrico y multi-núcleo, este hardware es el RouterBOARD. A lo largo de los años a partir del nacimiento del Internet, los administradores de red hemos visto desfilar varios fabricantes por nuestros racks, habiendo estado siempre Cisco como referente, sin em bargo, siempre había representado un costo más o menos importante a la hora de implementar una solución de red ruteada en especial si se trataba de un ISP/WISP. No es sino hasta hace una década aproximadamente en que MikroTik se empiez a a hacer conocer en Latinoamérica y varios emprendedores y por sobre entusiastas, se vuelcan a la implementación de soluciones basadas en RouterOS y RouterBOARD. Claros ejemplos de ello son nuestros grandes amigos de Index México (Ezequiel García) y REICO Costa Rica (Miguel Solís) quienes se volcaron a confiar en los productos ofrecidos por MikroTik. Es muy interesante y gratificante conversar con ellos y escuchar los relatos sobre los primeros pasos del fabricante letón en tierras americanas. Estoy convencido de que MikroTik llegó no solo para quedarse sino para formar una parte muy importante en la historia del networking y de las telecomunicaciones. De hecho, cientos de miles (quizá millones a esta fecha, Mayo 2015) obtienen su internet de banda ancha a un bajo costo a través de una red ruteada gracias a que los proveedores de Internet, pequeños y medianos, pueden estructurar e implementar redes sumamente complejas y completas usando equipos MikroTik. Las soluciones en RouterOS y RouterBOARD no se han quedado estancadas en las empresas de Telecom pequeñas, sino que han ido escalando en credibilidad en las empresa medianas y grandes en Latinoamérica, rompiendo paradigmas de fabricantes y costos de implementación. Este libro nace como un aporte a la comunidad tecnológica de habla hispana y latinoamericana que ha decidido incursionar en MikroTik y desea obtener un conocimiento formal. De igual manera queremos que esta guía constituya una fuente importante de aprendizaje para quienes empiezan a realizar sus primeras configuraciones en RouterOS.

Mauro Escalante CEO Academy Xperts CEO Network Xperts

Academy Xperts

ii


Resumen Este libro realiza una revisión más profunda a los parámetros de configuración wireless de RouterOS. Los laboratorios han sido desarrollados de tal manera que arrojen resultados que serán lo más cercanos a los ambientes reales y típicos en producción. Para la ejecución de los mismos se deben trabajar con estadísticas obtenidas de las prácticas anotando dichos resultados en tablas que podrán ser evaluadas a lo largo de los demás laboratorios. Los ejercicios de cargas y estrés para diferentes escenarios como 802.11b/g, 802.11n1x1, 802.11n2x2, Nstreme, y NV2 permitirán al lector constatar con sus propios medios el throughput real que fluye a través de una red inalámbrica. Las prácticas además permitirán obtener un expertise para hacer troubleshooting ya que el lector deberá ir aplicando los conocimientos adquiridos en los capítulos previos, a fin de obtener los resultados esperados. Finalmente, las pruebas y comparaciones realizadas con los protocolos Nstreme y Nstreme V2 (NV2) despejarán las dudas de los lectores respecto a la eficiencia y throughput de cada uno. De la mano con las pruebas y resultados en los laboratorios de 802.11n se dispondrá de una fuente amplia de resultados a valorar, y poder decidir la tecnología a emplear.

Audiencia Las personas que leen este libro deben estar familiarizados con: • •

Operaciones de red en Capa 2 Conjunto de protocolos IP, incluyendo TCP. UDP e ICMP

Este libro está dirigido a: •

Ingenieros y Técnicos en Redes, Telecomunicaciones y afines, que desea implementar y dar soporte a: Redes Corporativas Clientes WISP e ISP Ingenieros de Redes involucrados en actividades de pre-venta y post-venta en soporte e instalación de redes corporativa y PYMES Ingenieros de Redes, Administradores de Red, Técnicos en Soporte de Redes, y Técnicos de Soporte a Usuario (Help Desk) ! !

•

•

Convenciones usadas en este libro En este libro se utilizarán las siguientes convenciones tipográficas: Itálicas Indica comandos, direcciones de correo, claves, mensajes de error, nombres de archivos, énfasis, y el primer uso de términos técnicos Courier new

Indica direcciones IP y ejemplos de línea de comando Courier new en itálica

Indica texto que puede ser reemplazado Courier new en negrita

Indica datos de entrada del usuario Este icono significa un consejo, sugerencia, o una nota general. Este icono indica una advertencia o precaución.

Comentarios y preguntas Puede enviar sus comentarios y preguntas sobre este libro por correo tradicional a la siguiente dirección:

Network Xperts S.A. Av. Juan T. Marengo y J. Orrantia Edificio Professional Center, Piso 5, Ofic. 507 Guayaquil, ECUADOR +593-4-600-8590 +593-9-9535-2132 A través del sitio web y por medio de su usuario y contraseña, tendrá acceso a las actualizaciones, ejemplos, e información adicional: http://cursos.abcxperts.com Puede enviarnos sus comentarios o preguntas técnicas sobre este libro enviándonos un email a: [email protected] Para más información sobre libros, conferencias, centros de recursos, y la red educativa de Academy Xperts, visite nuestros Websites y canal de YouTube http://www.abcxperts.com http://www.academyxperts.com http://www.youtube.com/abcxperts

Academy Xperts

iii


Partners de Academy Xperts en Latinoamérica Nuestro recorrido por América Latina nos ha comprometido de una manera muy importante con nuestros alumnos, amigos y socios. Y este compromiso conlleva la enorme responsabilidad de estar siempre a la vanguardia, de presentar a nuestros estudiantes el mejor y más completo material de estudio & laboratorio, y lo que es m uy importante… que el contenido siempre esté actualizado. Nos encantaría estar presente en cada uno de los 15 países y las más de 65 ciudades que recorremos todos los años, pero el tiempo y la disponibilidad física nos es un obstáculo. Por este motivo hemos desarrollado un esquema de Partnership con empresas, universidades e institutos superiores en diferentes países que trabajan junto con nosotros en sus respetivos ambientes, y que entregan a sus estudiantes el contenido y el acceso a la suscripción de este libro (y todos sus recursos) por un cómodo valor.

Empresas Asociadas

Academy Xperts

iv


Universidades e Institutos Superiores

Deseas convertirte en Academia o ser Partner de Academy Xperts? •

•

•

Si eres Universidad o Instituto Superior que cuenta con el respectivo acuerdo ministerial de tu país, puedes optar por convertirte en una Academia MikroTik. Escríbenos a [email protected] para darte más información. Si eres Trainer Partner y quieres explotar junto a tus alumnos nuestro material y portal de capacitación, te invitamos escribirnos a [email protected] para proporcionarte los detalles. Si deseas que organicemos cursos en tu ciudad/país de residencia, escríbenos a [email protected]

Academy Xperts

v


Un poco de Historia (Costa Rica) Cubriendo un País con MikroTik. En el año 1998, estando en una empresa de servicios públicos en Costa Rica, el Ing. Miguel Solís en conjunto con el Ing. Paulino Solano, comenzaron a utilizar MikroTik con gran éxito en las telecomunicaciones de esta empresa. Se lograron 2 Mbps en una distancia de 8 Km, una velocidad record para aquellos tiempos en que la velocidad rondaba los 256 Kbps. En esta empresa de Servicios Públicos, se logró la interconexión de 52 sucursales mediante tecnología inalámbrica, todas bajo la misma marca MikroTik y su sistema operativo RouterOS. Dado el éxito alcanzado en este proyecto, ambos ingenieros en conjunto con uno más llamado Olman González, decidieron formar una empresa que se dedicara a solventar los problemas de telecomunicaciones en donde el cobre no fuera factible o se necesitara más velocidad. Esta empresa fue nombrada Redes Inalámbricas de Costa Rica S.A (REICO). Es así como a la fecha (Julio 2015), REICO, con solo Miguel Solís como propietario, tiene el liderato en telecomunicaciones inalámbricas en el país Centroamericano Costa Rica. REICO posee más de 3,800 Km de red troncal inalámbrica y más de 80,000 Km de red de acceso. Posee más de 100 radio bases instaladas estratégicamente para alcanzar una cobertura de más del 80% del territorio y a más del 90% de la población. La empresa se dedica 100% a proveer transporte de datos corporativos y sirve a sectores financieros, agroindustriales, turísticos, comerciales, etc. Su plataforma tiene una particularidad única en el mundo, con sus más de 1,000 clientes corporativos y empresariales y sus más de 1,500 equipos de acceso, CPE, transporte, Core secundario y Core primario: EL 100% SON MARCA MIKROTIK. REICO es un ejemplo del gran potencial que tiene MikroTik y RouterOS ya que esta empresa compite en el mercado con grandes de las telecomunicaciones y aun así mantiene una posición privilegiada, siendo el cuarto operador en Costa Rica en importancia en Transporte de Datos Corporativos, por debajo de ICE, Tigo y de RACSA pero por encima de Claro, Telefónica, Cables & Wireless, etc. Esto según el último informe de Estadísticas del Sector de Telecom unicaciones de Costa Rica 2014.

Texto desarrollado por el Ing. Miguel Solís, a quien agradezco por su aporte histórico sobre los inicios de MikroTik en Latinoamérica.

Academy Xperts

vi

NAE-TCP-A01 v1.0.07 – Arquitectura TCP/IP, Introducción – Capítulo 1: Principios de la Arquitectura

Capítulo 1: Principios de la Arquitectura Introducción Para todos los seres vivos, el uso de un lenguaje común nos ayuda a mantener una comunicación efectiva, de la misma manera las computadoras. El comportamiento común en conjunto con el lenguaje común entre dos o más personas, animales, computadores, etc., se hace uso de un protocolo, que según la definición de la NEW OXFORD AMERICAN DICTIONARY indica que es: “El procedimiento oficial o el sistema de reglas que gobiernan los asuntos de las circunstancias estatales o diplomáticas.” Todos los días hacemos uso de todo tipo de protocolos, como el de preguntar y responder, al realizar una negociación, trabajando en equipo, entre otras. Los computadores de igual manera, usan diferentes tipos de protocolos. Lo que para un conjunto de protocolos relacionados se lo llama “Suite de Protocolos”. Otro termino muy utilizado es la arquitectura que también se lo conoce como modelo de referencia, y es el diseño que especifica la variedad de protocolos o suite de protocolos, se relacionan mutuamente, dividiéndose tareas a completar. La suite de protocolos TCP/IP marcó la implementación en la arquitectura de internet, originándose del m odelo de referencia ARPANET (ARM – RFC0871), que por medio de los principios de los trabajos de la conmutación de paquetes realizado por Paul Baran y Leonard Kleinrock en los Estados Unidos, Donald Davies en Reino Unido, y Louis Pouzin en Francia, ha sido influenciado en la elaboración de dicho modelo de referencia.

Figura 1.1

A lo largo de los años otros modelos de referencia de protocolos, o arquitecturas han sido nombrados y estudiados, como ejemplo tenemos: el ISO protocol architecture, Xerox’s XNS, y IBM’s SNA, sin embargo, la suite de protocolos TCP/IP es utilizado por más personas, convirtiéndolo en popular. La historia de las comunicaciones y el desarrollo del internet en los ordenadores, pueden encontrase enfocados en libros como “A history of computer communications” y “Dream machine and the revolution that made computing personal”. Eventualmente la arquitectura TCP/IP se ha ido evolucionando para cubrir la necesidad de proporcionar interconexión de diferentes conexiones de computadoras con la ayuda de paquetes conmutados, esta necesidad se cubre con el uso de gateways, que hoy en dia los llamamos routers, estos proveen un proceso de traducción entre las redes que puedan ser incompatibles entre sí. CATENET es la red concatenada resultante que se la llega a conocer después con el nombre de inter-network, el cual se vuelve muy útil, cuando muchos más nodos ofrecen una variedad de servicios que se podrían aprovechar de este medio. Mucho antes que los trabajos en la arquitectura de protocolo fuera desarrollada completamente, se idearon los tipos de usos que una red global podría ofrecer. En el año de 1968, dos personas visualizaban posibles usos de una red global de comunicaciones interconectadas, fueron J. C. R. Licklider y Bob Taylor los que visualizaron este enfoque para soporte de supercomunidades. Existen comunidades en línea separadas entre si, de manera funcional y geográfica. Los miembros pueden hacer uso del procesamiento, almacenamiento y capacidades se software de su comunidad, Sin embargo, hoy en día se intenta interconectar estas comunidades separadas para transformarse en supercomunidades y que los miembros tengan más opciones de uso. Lo que se espera es que todos los miembros de todas l as comunidades gocen de los beneficios y los recursos de l a supercomunidad completa, sean estos programas datos e información para compartir. Por otro lado, todo lo visto se definiría como una frágil red de redes con cambios constantes en contenido y configuración. Aun así, con los conceptos de red global, el ARPANET y el internet, algunas tareas fueron designadas para soporte, pero así mismo muchos usos también se les da hoy en día. No obstante, no fue un camino fácil de recorrer. El prestar atención a los trabajos de diseño e ingeniería, de personas que les motivo en la idea de utilizar el internet como lo usamos a diario, y con la disposición de recursos que ayudo a realizar la transición del concepto al prototipo y del prototipo a productos comerciables es lo que remarco el éxito de esta implementación. Este curso muestra de manera general la arquitectura de internet y la suite de protocolos TCP/IP, proporcionando datos de contexto histórico y abriendo paso para los siguientes cursos con una base sólida. Las arquitecturas físicas y de protocolo, acogen siempre un conjunto de decisiones de diseño para saber qué características tienen más importancia para que tengan apoyo y de manera lógica también deben estar implementadas. Para diseñar una arquitectura no se necesita ciencia, pero si arte, y charlar más sobre las características de arquitecturas que no tuvieron éxito con el tiempo. El libro “Patrones en una arquitectura de red” del autor John Day, da un mayor enfoque de la arquitectura de red. La red que usaremos de referencia para este libro estará representada en las imágenes 1.2 y 1.3, mientras la evolución del curso se hablará de cómo trabaja cada aspecto de la red a través de estos gráficos.

Academy Xperts

1


Figura 1.2

__________________________________________________________________________________________________ En esta primera parte de la imagen se representa la red de un ISP y 2 tipos de clientes, un cliente residencial y otro Figura 1.2. cliente en este caso corporativo, con sus diferentes medios de comunicación, enlaces de fibra óptica (SONET las interfaces so), enlaces Gigabit Ethernet representadas como interfaces ge, enlaces DSL para conectar a usuarios residenciales, enlaces ethernet, fastethernet, gigabit ethernet para la red local del cliente corporativo, enlaces con el backbone, es decir un enlace que tenga con un proveedor de servicios de internet de tier superior, y dispositivos varios de red que se explicara su existencia en más adelante.

Academy Xperts

2


Figura 1.3

__________________________________________________________________________________________________ Figura 1.3. En la presente imagen particularmente se muestra la segunda parte de la red que se usara de ejemplo durante el curso, teniendo en cuenta que es otro proveedor de servicios de internet que entre sus clientes tiene un corporativo, así como podremos visualizar los medios físicos de conexión para explicaciones posteriores de cómo funciona el protocolo TCP / IP.

Por muchas razones la tendencia de las redes es incrementar el ancho de banda y la movilidad para comunicarnos, con tecnologías inalámbricas que nos permitan alcanzar el nivel de “Internet en todas partes”. Ya no existe restricción de velocidades a causa de los módems de red telefonica, ya que gracias a las nuevas tecnologías que fueron evolucionando a través del tiempo, mejoraron en gran medida los dispositivos finales y tecnologías de ultimma milla, entre aquellas están las mejoras de cableado, en los enlaces inalámbricos, incluso y mas aun los enlaces Backbone. Estas tecnologías en constante evolución de mejora, también logro captar la atención de los clientes mejorando el mercado cada ves creciente cada año, incluso en el ámbito de seguridad, y por sobre todo la seguridad, siendo este uno de los rubros importantes en la industria. Computacion en la nuve, virtualización, los centros de datos, se agregan a este mercado que como no es de extrañar, capto el total interés de sus clientes. Anfitrion.- Un host o anfitrión es cualquier dispositivo o sistema final que se ejecuta TCP/IP en la mayoría de los casos estos dispositivos son ordenadores de mesa y portátiles comunes, pero también en algunos casos los host pueden ser teléfonos

Academy Xperts

3


móviles, portátiles, tablets, asistentes personales, asi sucesivamente, en el pasado TCP/IP fue pensado e implementado para funcionar en dispositivos muy antiguos para tratar de convencer a los clientes sobre un punto. Sistema intermedio. - Sin embargo estos hosts necesitan comunicarse y no lo hacen de manera directa, para ello existen los sistemas intermedios que son considerados a menudo nodos de red o simplemente nodos. Estos nodos pueden ser routers, switches y bridges, dependiendo de sus funciones precisas en la red, en la red que utilizaremos para las referencias (Fig. 1.2, fig. 1.3) los nodos de red son routers algunos con características y capacidades de conmutación. Sistema.- Es solo la manera de decir que el dispositivo puede ser un anfitrión, router, switch, nodo o ccasi cualquier otra cosa en una red, donde la claridad es importante, siempre especificaremos un sistema fin o sistema intermedio. La red se compone de tres sistemas que ejecutan sistemas operativos diferentes que se conectan a redes de área local LAN ethernet. El despliegue se realiza en pares ya sean como: Clientes: el sistema más cercano al usuario final que realizan un trabajo delante de ellos. Servidores: el sistema de administración y por lo general utilizado remotamente. Enlaces físicos: GE, o GigabitEthernet es la tecnología ethernet que trabaja en 1000BASE-T, donde las tasas de transferencia de datos alcanzan hasta 1 gigabit por segundo. Es considerada como una mejora del estándar ethernet, específicamente referenciado como la versión 802.3ab (Cobre) y 802.3z (Fibra) del IEEE, con una notable diferencia del estándar 802.3 (FastEthernet) que alcanza velocidades hasta 100 megabits por segundo. ATM, por las siglas de Asynchronous Transfer Mode, como tecnología de comunicación, se elige por petición popular a la capacidad de transmisión de servicios y aplicaciones. A diferencia de las tecnologías ethernet, redes con implementación anillo, y FDDI permite una comunicación simultanea de datos y voz sobre un mismo canal físico. SONET, la red óptica síncrona, es un estándar de transporte para redes de fibra óptica, generada en los Estados Unidos hace posible la conexión normalizada entre los sistemas de fibra óptica, conjunto formado por 810 bytes distribuidos en 9 filas de 90 bytes que se transmiten cada 125 microsegundos, velocidad del canal telefónico básico de 64kbits por segundo, con lo que la velocidad binaria es de 51,84 megabits por segundo. DSL, línea de subscriptor digital, es un conjunto de tecnologías para el acceso a internet mediante la transmisión de datos digitales a travez de línea telefónica local. Entre las diferentes tecnologías de este conjunto tenemos ADSL, A DSL2, ADSL2+, IDSL, HDSL entre otros, la tasa de transferencia en bits varia los 256kbits por segundo con una conexión máxima de 50megabits por segundo en el flujo de descarga de datos. Todas estas tecnologías de redes diferentes generan principalmente el internet tomando en cuenta que son miles de millones de nodos que conforman el internet alrededor del mundo. Desde esta perspectiva se mostrarán los diferentes protocolos TCP/IP que se ejecutan en los ordenadores y redes enrutadas para formar el INTERNET, explicando de este modo los protocolos desde la perspectiva del usuario final (red LAN) o borde del usuario local, y también desde la perspectiva del proveedor de servicios de internet (red WAN) en el borde de la red global.

Principios de la arquitectura La suite de protocolos TCP/IP permite a los dispositivos finales, sean estos computadores, sm artphones, placas con sistemas embebidos de todos los tamaños, diferentes marcas, con diferentes sistemas operativos, comunicarse todos ellos entre sí. A comienzos del siglo 21, se volvió necesidad para el comercio, entretenimiento, y las comunicaciones de la actualidad. Ciertamente se lo define como un si stema abierto donde la suite de protocolos y sus implementaciones están disponibles de manera pública con poco o ningún costo. Esto es la base del internet global, o simplemente internet, también conocida com o una red de área extensa (WAN) de más de 3500 millones de usuarios en la actualidad. Considerado el 50% de la población mundial. Mucha gente considera al internet como el amplio mundo de la red (www) para términos de intercambio de información, otras personas ven al internet por su capacidad para proporcionar comunicación entre computadoras. WWW es una aplicación que hace uso del internet para comunicarse, quizás la más importante ya que llevo la tecnología del internet a la atención del mundo a partir de la década de los 90’s. La arquitectura de internet fue creada bajo la guía de algunos objetivos. David D. Clark, científico de computación y pionero del internet, expresa como objetivo principal el desarrollar una técnica efectiva para la utilización multiplexada de las redes interconectadas existentes. Con esto el científico Clark dio a entender que la arquitectura de internet debe ser capaz de conectar varias redes sin importar lo que se esté conectando, para aprovechar la red en múltiples actividades que deben ejecutarse de manera simultánea en dicha red resultante. Sobre este objetivo el científico también expreso algunos secundarios: -Incluso con la perdida de red o gateways, debe continuar la comunicación de internet. -El internet debe interpretar y tolerar múltiples tipos de servicios de comunicación. -Sabemos que existen redes variadas, la arquitectura de internet tiene que acoplarse a ellas. -Debe también permitir la administración distribuida de sus recursos. -En el costo debe incluir las cargas adicionales como los intereses, los impuestos, etc. -El host debe acoplarse a la arquitectura de internet con el menor esfuerzo. -Los recursos de la arquitectura de internet deben estar auditados. Entre los objetivos expresados anteriormente, deberían tomarse en cuenta para algunas diferentes decisiones de diseño de aquellas tomadas últimamente. Sin embargo, existen opciones de diseño que fueron ganando impulso, en el momento que

Academy Xperts

4


los principios de la arquitectura estaban siendo formulados, influyendo a los diseñadores en las decisiones que han tomado. A lo largo de este curso se mencionarán los más importantes y sus consecuencias.

Paquetes, Conexiones y Datagramas Entre los años 1960 y 1970, las redes que conocemos hoy en día, en concepto se basa en la red telefónica. En la red telefónica, se fue desarrollando la idea de conectar teléfonos por una duración específica, establecida por los extremos, al finalizar la llamada. Para establecer la conexión, un circuito eléctrico establece una trayectoria única y dura hasta que los interlocutores cierren la llamada, entonces la trayectoria se liberaba permitiendo a otro usuario poder realizar otra llamada. Para las conexiones de red telefónica, la duración de la llamada y la identificación de las conexiones, o números telefónicos, representaban un costo para los usuarios. Cuando la red telefónica se estableció, la conexión brindaba una cantidad de ancho de banda para enviar la voz como información. Luego, la red telefónica fue evolucionando y de sus raíces analógicas paso a lo digital, mejorando la confiabilidad y el rendimiento. La conexión de la trayectoria única que se establecía en el circuito proporcionaba un servicio predecible, y como pasaban entre conmutadores de red la suma de los retardos se dio a conocer el concepto de latencia. Los circuitos que forman la trayectoria a través de la red, aunque dure hasta finalizar la llamada, no era siempre utilizado, como ejemplo, si uno de los extremos se ausenta, pero mantiene la llamada activa, ese tiempo mal utilizado lo podría utilizar otro usuario que desee comunicarse. Sin embargo, así no lo estemos utilizando, la empresa de teléfonos nos cobra por el tiempo que mantenemos activa la llamada.

Figura 1.2

La idea de la conmutación de paquetes, fue desarrollado a partir de los años desde 1960 y fue una de las más importantes desde esa década hasta la actualidad, la información se maneja por trozos de información digital, tam bién llamados paquetes, con una cantidad de bytes que viajan a través de la red. Estos paquetes vienen de diferentes remitentes, de las cuales pueden viajar por diferentes trayectorias para luego mezclarse, este proceso se lo conoce como multiplexación. Los paquetes que viajan hacia su destino, pasan a través de varios conmutadores, en otras palabras, no sigue un único camino para llegar a su destino. La conmutación de paquetes consta de dos ventajas potenciales, una de ellas es que la red es más resistente, y la otra ventaja es el mejor uso de los enlaces de red y conmutadores gracias al multiplexado estadístico. Los conmutadores de paquetes, reciben y guardan los paquetes a un buffer de memoria, o cola y procesado de tal manera de que el primero que llega el primero en ser atendido (first-come-first-served FCFS). Este método es el que actualmente se lo utiliza para agendar de manera simple la forma en que los paquetes son procesados y lo conocemos com o first-in-first-out (FIFO). La administración de buffer en memoria FIFO y la programación bajo demanda se combinan para implementar el multiplexado estadístico, que es el primer método para entremezclar tráfico de diferentes fuentes en el internet. En este tipo de multiplexado, el tráfico se mezcla basándose en la información estadística que se recolecta al llegar un paquete al buffer de memoria, o también se basa en un patrón de tiempo del tráfico. Esta multiplexación trabaja de manera simple y eficiente, porque en el caso que haya una red a ocupar y tráfico en dicha red, en otras palabras, que este ocupada la red, formándose cuellos de botella. Una de las desventajas que nos da este enfoque, es se limita la predictibilidad – el rendimiento de una aplicación se mide por medio de las estadísticas de otra aplicación que está compartiendo la red. Este tipo de multiplexación, es como una carretera donde los autos pueden cambiarse de carril y tomar rutas alternas cuando encuentre un cuello de botella. Las técnicas, multiplexación de división de tiempo (TDM) y multiplexación estática, reservan un tiempo u otro recurso para realizar el proceso de multiplexación. Aunque estas técnicas pueden apuntar a mas predictibilidad, lo que es una característica útil para soportar llamadas de bit rates constantes, no pueden utilizar toda la red porque reserva ancho de banda que puede que no esté siendo usado. No hay que pasar desapercibido que los circuitos que son directamente implementados usando TDM, los circuitos virtuales por otro lado no dependen de conmutadores físicos y pueden ser implementados sobre una conexión orientado por paquetes. El protocolo X.25 tomo estas técnicas como base hasta inicios de la década de 1990, a partir de aquí fue reemplazado por FRAME RELAY y DIGITAL SUBSCRIBER LINE (DSL) y dispositivos que soportan la conectividad de internet. Los circuitos virtuales y las redes de conexión orientado por paquetes tal como X.25 requiere un dato adicional para saber a qué conmutador se dirigirá. Por eso un paquete contiene una pequeña sección de información en la cabecera que es como un índice para la tabla de estado. En X.25 los 12 bit para el identificador de canal lógico (logical channel identifier - LCI) o número de canal lógico (logical channel number - LCN) sirve para i dentificar a que conmutador o dispositivo de red se dirigirá el paquete. Para cada Switch, el LCI o LCN se usa con los estados per-flow (por flujo) en cada conmutador para determinar el siguiente conmutador a lo largo del camino para el paquete. El estado per-flow está establecido para intercambiar datos en un circuito virtual usando un protocolo de señalización que soporta los establecimientos de conexión, limpieza, y estado de información. Estas redes son conocidas como conexión orientada, que pueden ser por circuitos o paquetes, y por muchos años fueron las redes más frecuentes. A finales de la década de 1960, otro concepto se ha estado hablando conocido como datagrama. Originado por el sistema CYCLADES, un datagrama es un paquete en el que toda la información que identifica

Academy Xperts

5


a la fuente y el destino final, reside dentro del paquete mismo, lo contrario a un conmutador de paquetes, a pesar de que esto signifique requerir paquetes más largos, el estado per-connection (por conexión) en el conmutador de paquetes, ya no se requiere y las redes sin conexión deberían ser levantado, eliminando la necesidad para un protocolo de señalización (el cual es complicado). Los datagramas fueron acogidos por los diseñadores de los inicios de internet, con lo que tuvo una profunda implicación para el resto del conjunto de protocolos.

Figura 1.3

En la imagen anterior (Figura 1.3) las aplicaciones escriben mensajes que se transmiten en protocolos. Un límite de mensaje es el desplazamiento de posición o byte entre una escritura y otra. Los protocolos que preservan los límites del mensaje devuelven el mismo mensaje del emisor en el receptor con los mismos tamaños en bytes. Los protocolos que no preservan los límites del mensaje (por ejemplo, TCP) ignoran esta información y no le dejan igual el mensaje al receptor, sino que las aplicaciones pueden necesitar una función para indicar los límites del mensaje del remitente en el caso de necesitar de esta capacidad. Otro concepto relacionado es de los límites de mensaje (messages boundary) o marcadores de registro (record markers). Como muestran en la figura 1.3, cuando una aplicación envía paquetes de información a la red, el protocolo receptor de dicho paquete puede preservar o no los m ensajes. Un datagrama, por ejemplo, preserva la información en la mayoría de los protocolos porque contienen en si información del inicio y del final. Sin embargo, en una red de circuito o circuito virtual, una aplicación puede escribir varios trozos de datos, mientras que la aplicación que l o recibe puede leerlo en uno o varios trozos de diferentes tamaños. Estos tipos de protocolos no conservan los límites de mensajes. En casos donde un protocolo subyacente falle de preservar los límites de mensaje, pero son necesarios para una aplicación, la aplicación debe proporcionar su propio sistema interpretador de límites de mensajes.

El Argumento Extremo a Extremo y el Destino compartido Cuando los sistemas operativos o suites de protocolos están siendo diseñados, existe una duda sobre donde una particular características o las funciones deben ser colocadas. Uno de los más importantes principios que influyeron en el diseño de la suite TCP/IP es llamado argumento extremo a extremo.

El argumento de extremo a extremo solo puede ser implementada con el conocimiento y la ayuda de la aplicación en los puntos finales del sistema de comunicación. Por lo tanto, siempre que el argumento sea cuestionado como una característica de la comunicación no es posible. (A veces una versión incompleta de la función proporcionada por el sistema de comunicación puede ser útil como una mejora de rendimiento). Este argumento ha inspirado a muchos diseñadores e investigadores del internet para tener profundas implicaciones para el diseño de sistemas de comunicación y sostiene que la corrección y la integridad sólo pueden alcanzarse mediante la participación de la aplicación o del usuario final del sistema de comunicación. Los esfuerzos para implementar correctamente lo que la aplicación puede necesitar están condenados a estar incompletos. En resumen, este principio argumenta que las funciones importantes para asegurar los datos, por ejemplo, Control de errores, cifrado, reconocimiento de entrega, normalmente no deberían implementarse en las capas de bajo nivel de los sistemas grandes. Por otro lado, estas capas pueden facilitar el trabajo de los puntos finales mejorando el rendimiento. Un estudio adicional de este argumento sugiere que las funciones de bajo nivel no deben ser perfectas porque para que una aplicación pueda requerirla es poco probable que sea posible. El argumento de extremo a extremo opta por un diseño donde se dice que la red es "tonta" y los sistemas son "inteligentes" conectados a la red. En el diseño de TCP/IP vemos muchas funciones, por ejemplo, métodos para asegurar que los datos no se pierden, controlando la velocidad a la que envía un remitente, entre otros, que se implementan en los hosts finales con las aplicaciones que usen. El concepto que indica cuales funciones comparten la misma com putadora o red o pila de software se basa en un principio relacionado conocido como “Destino Compartido”.

Academy Xperts

6


El destino compartido sugiere con el fin de mantener una comunicación activa, ubicar todos los estados necesarios en los puntos finales del sistema de comunicación. Siendo así que la única manera de que se destruya la comunicación como tipo de fallo, es destruyendo uno o más puntos finales, que cambien destruye la comunicación global. Compartir el destino es una de las filosofías del diseño en la que las conexiones virtuales se mantengan activas aun si existe algún fallo en la conectividad por un lapso prudente de tiempo. Destino compartido de igual forma que el argumento de extremo a extremo, siguen un diseño de una “red tonta con los anfitriones finales inteligentes", y lo que causa más tensión en temas de internet de hoy es que funciones residen en la red y qué funciones no.

Figura 1.4

Control de Errores y Control de Flujo En algunos casos, los datos dentro de una red, se dañan o se pierden. Esto ocurre por algunas razones, como problema de hardware, radiación en el ambiente que modifica los bits que están siendo transmitidos, en el caso de una red inalámbrica que el punto final este fuera del rango, entre otros, y tratar con estos problemas, lo llamamos control de errores, y estos se implementan dentro de la red o en los sistemas de red, o lo más recomendable es una combinación de estas implementaciones. Para el caso de los conceptos anteriormente revisados (Argumento extremo a extremo, Destino compartido) se sugiere que estas implementaciones se las realice en capas cercanas o donde residan las aplicaciones. Por lo general, si una cantidad mínima de bits puede ser preocupante, existirá una serie de códigos que puedan detectar y reparar dichos errores cuando la aplicación reciba los datos o mientras sigue en tránsito por la red. Lo que lo convierte en una tarea rutinaria dentro de la red. En el caso que ocurra un daño mayor, los paquetes suelen ser reenviados o retransmitidos. Por otro lado, en la conmutación de circuitos, la transmisión suele hacerse dentro de la red. Esto puede ser muy favorable para aplicaciones que requieren que sus datos no tengan ni un error, sin embargo, existen aplicaciones que no requieren de esta habilidad por lo que prefieren no estimar esos costos, tales como el establecimiento de la conexión y los retrasos potenciales de la retransmisión, para mantener sus datos de manera confiable. Siendo así que una aplicación confiable de transferencia de archivos, no importa cómo se entregan los paquetes de datos, siempre que los reciba todos los paquetes sin errores para luego ordenarlos en su forma original. Para llamar a la alternativa de sobrecarga de una entrega confiable y ordenada dentro de una red tenemos el llamado entrega del mejor esfuerzo (Best effort delivery), función que fue adoptada por Frame Relay y el protocolo de internet IP. Con esta nueva función, la red ya no invierte tiempo y esfuerzo en garantizar que los datos se entreguen sin errores o huecos. Algunos errores suelen detectarse por medio de un código de sumas de comprobación (CHECKSUM), así como un dato que indica a los dispositivos de comunicación identificar a que dirección se dirige un datagrama, con la diferencia que esta suma de comprobación al detectar error, descarta el datagrama para que pueda ser retransmitido. En el caso de la entrega del mejor esfuerzo, siempre que sea satisfactoria, un remitente puede producir información a velocidades que el receptor no es capaz de igualar o superar, originándose un cuello de botella donde se suelen perder muchos datos, y para estos casos se sugiere en las redes IP con la función del m ejor esfuerzo, se sugiere una nueva función que es la de control de flujo, la cual minimizara la velocidad del emisor para que el receptor pueda aprovechar toda la información que le envíen, (haciendo analogía como si fuera un semáforo). La suite de protocolos TCP suele manejar este tipo de problemas y es consistente con el argumento de extremo a extremo: en TCP, la tasa de control la maneja dentro de los puntos finales. También es coherente con el destino compartido: lo que indica que no importa si existen puntos de error en la infraestructura de red que no incluya l a capacidad de los dispositivos de red externos de comunicarse siempre y cuando exista otro camino por dónde ir.

Academy Xperts

7


Figura 1.5

Academy Xperts

8

NAE-TCP-A01 v1.0.07 – Arquitectura TCP/IP, Introducción – Capítulo 2: Diseño e Implementación

Capítulo 2: Diseño e Implementación La arquitectura de protocolo sugiere un alcance para la implementación, pero no es algo que tenga que ser realizado por una ley. Siendo así, se hace una distinción entre el protocolo e implementación, definiendo los conceptos en una arquitectura de protocolo se puedan interpretar en forma existente de software. Las personas responsables de implementar protocolos para ARPANET ya tenían bases de estructuración de software de los sistemas operativos, y un documento escrito por E. Dijkstra “La estructura del sistema de multiprogramación THE”, asocia el uso de una estructura jerárquica para llevar un orden en la implementación de un software grande. Este documento y su enfoque lambien contribuyo al diseño de la arquitectura para los protocolos de red, separándolos por múltiples capas de implementación y diseño. A este enfoque lo denominam os “estructura de capas” y es como actualmente se usa como m étodo para implementar suites de protocolos.

Capas Con este nuevo concepto, cada capa se hace responsable de una función o conjunto de funciones diferentes en el ámbito de la comunicación. Estas nos benefician porque permite a los desarrolladores evolucionar en diferentes partes del sistema por separado, así para que las personas trabajen en el área donde se sientan que su especialidad se vincule con esa parte del sistema específico. El modelo OSI es uno de los conceptos más populares de capas de protocolos, siendo solo un enfoque solo para entender el estudio de las capas. OSI viene de las siglas Open System Interconnection, modelo de interconexión de sistemas abiertos, que fue definido por la organización internacional de normalización. La Figura 2.1 muestra las capas del modelo OSI estándar, incluyendo sus nombres, números y algunos ejemplos. Las siete capas que sugiere el modelo OSI pueden ser usadas para una implementación de arquitectura de protocolo, normalmente se considera la arquitectura TCP/IP que tiene cinco capas. En los debates donde se discutía los beneficios y las deficiencias del modelo OSI y ARPANET su antecesor, a principios de la década de 1960. Sin embargo, el modelo de capas de TCP/IP gano como modelo de implem entación y el modelo OSI como referencia para estudio, las ideas han seguido surgiendo y protocolos del conjunto de protocolos estandarizados por ISO para ser usados por la suite de protocolos TCP/IP por ejemplo IS-IS [RFC3787].

Figura 2.1

En la imagen anterior (Figura 2.1) tenemos el modelo OSI de siete capas estándar especificado por la ISO. No todos los protocolos son implementados por cada dispositivo en red (al menos en teoría). La terminología OSI y los números de capa son ampliamente utilizados. Como se describe brevemente en la Figura 2.1, cada capa se hace cargo de una responsabilidad diferente en la que podremos apreciar la capa uno, o capa física define la manera de mover datos digitales en un entorno de comunicaciones como una línea telefónica, cable de cobre, cable coaxial, o fibra óptica, los estándares ethernet y wireless forman parte de esta primera capa. Sin embargo, no se profundiza mucho de esta capa. La capa dos o capa de enlace de datos ya incluye algo de información en sus datagramas que utilizan los protocolos y métodos para establecer una comunicaci ón con personas que comparten el mismo medio. Algunas redes de esta capa solo conectan dos vecinos. Una red es de acceso múltiple cuando más de un vecino puede conectarse a esa red. Wi-F i y Ethernet son ejemplos de redes de acceso m últiple de la capa

Academy Xperts

9


de enlace y protocolos específicos se utilizan para mediar qué estaciones tienen acceso al medio compartido en un momento dado. La capa tres, capa de red o internetwork es lo que más vamos a tratar en general. Para redes de paquetes como TCP/IP, ofrecen un paquete con formato interoperable, utilizado en diferentes redes de la capa de enlace para conectarse. La capa incluye un esquema de direccionamiento para los dispositivos finales y dispositivos de transmisión, así como algoritmos de enrutamiento que eligen dónde van los paquetes. Por encima de la capa tres encontramos protocolos que son implementados sólo por los usuarios finales, incluyendo la capa de transporte que proporciona un flujo de datos entre sesiones y dependiendo del tipo de servicio el concepto puede ser muy complejo (p. Ej., Entrega confiable en una red de paquetes que puede eliminar datos). La capa de sesión representa la interacción continua entre aplicaciones, por ejemplo, cuando se usan "cookies" con un navegador web durante un inicio de sesión en la Web, y los protocolos que trabajan en la capa de sesión pueden iniciar, apagar o reiniciar una sesión, además de puntos de guardado para el o los trabajos que se ha logrado hasta aquí. Sobre la capa de sesión esta la capa de presentación, que realiza las conversiones de formato y las codificaciones estándar de información. Como veremos, los protocolos de Internet no incluyen estas dos últimas capas, por lo que las funciones listadas anteriormente las trabajaría la capa de aplicación en caso de ser necesario. La capa siete, última capa del modelo OSI, es la capa de aplicación. Las aplicaciones crean e implementan sus propios protocolos para la capa de aplicación, y los usuarios finales son los que pueden receptar la información e interpretarla en su lenguaje. Hay una gran variedad de protocolos de capas de aplicación, y cada día se van inventando nuevos protocolos. Lo que significa que la capa de aplicación es donde hay más innovación y donde nuevas capacidades son desarrolladas y desplegadas.

Relación entre los campos de la aplicación WIRESHARK con las capas del protocolo TCP/IP Como observaremos en las siguientes imágenes, proporcionada por el analizador de trafico de red “WIRESHARK”, El protocolo “ TCP” pertenece a la capa cuatro del modelo OSI, es decir, la capa de transporte; que es el encargado de la transferencia libre de errores de los datos entre el emisor y el receptor, aunque no estén directamente conectados, así como de mantener el flujo de la red. Elegimos la interfaz que más uso este en ese momento pasando, en este caso la interfaz Ethernet, como se muestra en la imagen 2.2.

Figura 2.2

Una vez que se haya elegido la interfaz, para realizar la captura de paquetes transitando por esa red, se procede a dar dobleclick sobe la interfaz, de esta manera aparecerá la siguiente imagen (figura 2.3).

Figura 2.3

Como se observa en la parte inferior de la imagen 2.3 para poder llegar a la capa número cuatro del modelo OSI, se debe primero “transitar” las capas anteriores en las c uales encontramos tres capas más; l a física, el enlace y la red. De arriba para abajo tenemos que la primera línea hace referencia a la capa física donde muestra información de tiempos de llegada de la trama entre otros datos que se detallaran más adelante, luego encontram os la línea que hace referencia a la capa de enlace, Academy Xperts

10


con información de las direcciones MAC de origen y destino, continuando tenemos la línea que hace referencia a la capa de red, con la información del datagrama IP, la cuarta línea nos hace referencia de la información de la capa de transporte, en este caso TCP, y las 2 últimas líneas hacen referencia a la capa de aplicación. A continuación, vemos como se compone su encabezado.

-CAPA FISICA Figura 2.4

Como podemos ver en la información mostrada en la imagen 2.4, existen varios parámetros que identifica al c apturar los bits de la capa física, obteniendo información tal como el tamaño del conjunto de bits, como de la c aptura, entre otros parámetros. Dado de lo que conocemos hasta ahora, en la capa física los datos que transitan por esta via se las conoce por bits, pues en específico son bits que se transmiten por estos medios.

-CAPA DE ENLACE DE DATOS Figura 2.5

En la información podemos ver que la capa de enlace de datos representado por wireshark (figura 2.5), muestra las direcciones MAC del origen y destino de las interfaces de las que pertenece ese paquete, indicando desde donde viene y hacia dónde va, así como también muestra que tipo de protocolo IP está usando para la siguiente línea. A diferencia de la capa anterior, en esta capa los datos se encapsulan en Tramas.

-CAPA DE RED Figura 2.6

En wireshark se representa la capa de red, acorde a la información que proporciona el datagrama IP, mostrando la dirección IP de origen y destino, la versión, la longitud de la cabecera, entre otros diferentes parámetros, mostrados en la figura 2.6. Siguiendo con el encapsulamiento, la capa de red toma la trama y la convierte en paquete, o datagrama donde se encuentra información necesaria en la cabecera para que pueda seguir su camino a través de la red.

-CAPA DE TRANSPORTE Figura 2.7

Academy Xperts

11


En la capa de transporte representado por wireshark (Figura 2.7) muestran los puertos que están siendo utiliz ados en la red, tanto de origen como de destino, el tamaño del segmento TCP, el número de secuencia, el tamaño de la cabecera, entre otros parámetros. Llegados a este punto, la capa de transporte toma el paquete que viene de la capa de red y la transforma en segmento.

-CAPA DE APLICACIÓN Figura 2.8

Por ultimo en la capa de aplicación, representado por wireshark, podemos apreciar información de la página que está siendo visitada por la aplicación en este caso HTTP, se pueden ver datos como host, agente de usuario, referente, entre otros diferentes parámetros. Por último, la capa de aplicación ya convierte el segmento de la capa de transporte en datos entendibles por el usuario.

-EJERCICIOS BASADOS EN WIRESHARK Captura de paquetes por la interfaz ethernet de su computador:

Para la captura de paquetes se utiliza un aplicativo que le permite al usuario ver en la red y guardar los paquetes que pasan a través de una interfaz, en el presente ejercicio, el estudiante será capaz de utilizar la aplicación WIRESHARK para poder realizar la captura de paquetes. 1.

Descargar el aplicativo wireshark desde: https://www.wireshark.org/

Academy Xperts

12


2.

Instale y ejecute el programa, tome en cuenta que para realizar la captura de paquetes tiene que imperativamente instalar winpcap, este aplicativo se le solicitara instalar durante la instalación de wireshark.

3.

Capture los paquetes a través de su interfaz ethernet, por un lapso de 5 minutos (hasta mientras puede navegar). Durante la captura de paquetes que se realiza a través de seleccionar la opción ethernet en Capture al hacer doble click, no solo va a captar los paquetes mientras navega en internet, sino que va a capturar todos los paquetes que forman parte de todos los protocolos que pasan a travez de esa interfaz.

Academy Xperts

13


4.

Para detener la captura de paquetes luego de 5 minutos presionar el botón ‘stop capturing packets’, ubicado en la parte superior izquierda de la ventana de wireshark.

5.

Identificar los paquetes del protocolo TCP puerto 80, para ver el trafico HTTP. Haciendo uso del comando >tcp.port == 80< se puede filtrar del trafico capturado toda la navegación http por el lapso de 5 minutos que se realizó la captura.

6.

Identificar los paquetes donde conste la dirección IP de su computador. Haciendo uso del comando >ip.addr == 10.0.0.62< se puede filtrar del trafico capturado toda la navegación http por el lapso de 5 minutos que se realizó la captura.

Academy Xperts

14


Capturar paquetes de Facebook 1.

Lo primero a realizar para comenzar una captura de alguna pagina especifica es conocer su dirección IP publica. Esta acción la podemos hacer mediante un ping hacia la pagina que se desea realizar la captura, en este caso utilizaremos la pagina de Facebook.com, para ello tenemos que abrir la interfaz de línea de comandos y especificar un ping a Facebook.com.

2.

Ya con esta información tenemos en claro que la dirección IP de la pagina de Facebook.com es 31.13.67.35, dirección por la que vamos a realizar el filtrado de paquetes por dicha dirección.

3.

Entre toda la información que se muestra en pantalla luego de realizar el filtrado de paquetes por direccion IP la dirección de Facebook 31.13.67.35, encontramos en la parte inferior izquierda una leyenda interesante.

Academy Xperts

15


Sobre la leyenda se muestra la cantidad de paquetes totales capturados en el transcurso de tiempo que hemos establecido anteriormente. Así como también se muestra la cantidad de paquetes tras el filtrado de paquetes por dirección IP, entre corchetes consta el el porcentaje que identifica la cantidad de paquetes que navego durante los 5 minutos de captura

Multiplexación, Demultiplexación y Encapsulamiento en implementaciones de capas Entre los beneficios principales de la arquitectura basado en capas, está la capacidad de realizar multiplexación de protocolos, esta permite que múltiples protocolos trabajen en la mism a infraestructura. También permite q muchas instancias se usen de manera simultánea, sin confundirse, y se puede ocurrir en diferentes capas, y cada capa la utiliza con un identificador diferente para determinar que protocolo está usando o que flujo de información es. Por ejemplo, en la capa de enlace usan un identificador para determinar si el enlace que usa es ethernet o wi-fi u otro, así identificar que protocolo está transportando dicho paquete. PDU son las siglas de unidad de datos de protocolo, esta PDU que transita entre capas de una superior a una inferior, se dice que se encapsula como datos opacos, en otras palabras, que no son legibles o interpretables para el usuario final. Los objetos en el proceso de multiplexación se encapsulan de la capa N a la capa N-1, el identificador de estos PDU, se utiliza para determinar el protocolo o programa que recibe en la capa N durante la demultiplexación. En la Figura 2.9, se explica cómo funciona la encapsulación, y como cada capa maneja su propio concepto, la responsabilidad de la creación de la PDU corresponde a cada capa en particular. Por ejemplo, en el caso de que un protocolo de la capa de transporte produce un paquete, tendría como nombre TPDU o PDU de transporte. Cuando una capa recibe un paquete de la capa superior, no revisa el contenido, sino que lo encapsula en su propia capa, produciendo su propia PDU. En esencia esto es la encapsulación, con cada capa tratando datos de las capas superiores como datos ilegibles, no interpretables. Para identificar a una PDU en que capa esta, para eso hace uso de la cabecera, y los trailers que son utilizados por algunos protocolos, pero no por todos. En el encabezado se utiliza en el proceso de Multiplexación de los datos al enviar, y para al recibir realice la demultiplexación, haciendo uso de un identificador que llamaremos DEMUX.

Figura 2.9

En la imagen anterior (Figura 2.9) la encapsulación se utiliza generalmente junto con las capas. La encapsulación pura implica tomar la PDU de una capa y tratarla como datos opacos (no interpretados) en la capa de abajo. La encapsulación tiene lugar en cada emisor, y la desencapsulación (la operación inversa) tiene lugar en cada receptor. La mayoría de los protocolos utilizan encabezados durante la encapsulación; Algunos también utilizan trailers. En redes TCP / IP, los identificadores pueden ser direcciones de hardware, direcciones ip, y numero de puertos. Algo muy práctico en el uso de encabezados es que proporciona información de estado del paquete que se considera en el proceso de comunicación. El objeto que resulta de la unión del encabezado, los datos, y el tráiler (si lo tuviere), es otra PDU. Otra característica importante del concepto de capas sugerida por la Figura 2.1 es que no todos los dispositivos en red necesitan implementar todas las capas. La Figura 2.10 podremos apreciar que no todos los dispositivos hacen uso exclusivo de todas las capas del modelo OSI o TCP/IP, esto se debe a la función que vallan a cumplir. En la Figura 2.10, se pensó en una pequeña es tructura de red en la que tenemos 2 dispositivos finales, un router y un switch. Cada número corresponde a una capa particular, dependiendo de la capa, los protocolos que use dentro de ella. Como podemos ver, algunos dispositivos no hacen uso de todas las capas de la pila. El anfitrión de la izquierda genera tres protocolos diferentes en la capa de enlace (D, E y F) con sus respectivas capas físicas y tres protocolos en la capa de transporte diferentes (A, B y C) que se trabajan en una capa de red. Los anfitriones o host finales trabajan en todas las capas, los switches hasta la capa 2 (este switch implem enta D y G) y los enrutadores hasta la capa 3. Los enrutadores son capaces de interconectar múltiples redes de capa de enlace y deben trabajar con sus protocolos para cada tipo de red que interconectan.

Academy Xperts

16


Figura 2.10

Figura 2.11

En la imagen anterior (Figura 2.10/11) diferentes dispositivos de red implementan diferentes subconjuntos de la pila de protocolos. Los anfitriones finales tienden a implementar todas las capas. Los enrutadores trabajan con las capas que están debajo de la capa de transporte y los conmutadores trabajan con protocolos de la capa de enlace y física. Esta estructura propuesta es frecuentemente alterada porque los enrutadores y conmutadores incluyen la capacidad de actuar como un host y por lo tanto necesitan trabajar en todas las capas, aunque no se usen todas. En el ejemplo se mostró dos hosts comunicándose, las capas de enlace de datos y física con las etiquetas D y G no solo sirve para comunicar dos hosts, sino múltiples host, de ser así, la comunicación es posible entre varios sistemas que trabajan con capas por encima de la capa de red. En la figura 2.10 se puede diferenciar los hosts finales y los dispositivos encargados de la comunicación. Las capas que están por encima de la capa de red, trabajan con protocolos extremo a extremo. En la imagen también se puede apreciar que las capas de extremo a extremo solo son necesarias en los hosts finales. Por otro lado, la capa de red proporciona un protocolo hop-by-hop (salto por salto) y se utiliza en todos los dispositivos mostrados en la figura. El conmutador o puente (Bridge) no se considera un sistema intermediario puesto que no utiliza un formato de direccionamiento del protocolo de interconexión, y funciona de manera transparente al protocolo de capa de red. Desde el punto de vista de los enrutadores y anfitriones finales, el conmutador o puente es invisible. Un enrutador, por definición, tiene dos o más interfaces de red. Un sistema o dispositivo con múltiples interfaces se la llama multihomed. Un host también puede ser catalogado como multihomed, pero si no envía paquetes de una interfaz a otra, no se lo puede llamar enrutador. Además, los enrutadores no solamente son cajas de hardware especiales que mueven paquetes alrededor de un Internet. La mayoría de las implementaciones de TCP / IP, permiten que un host m ultihomed actúe como un router también, si está configurado para esa labor. En este caso, podemos llamar al sistema un host cuando se utiliza una aplicación como el protocolo de transferencia de archivos (FTP), o enrutador cuando está reenviando paquetes de una red a otra. Usaremos cualquier término que tenga sentido dado el contexto. Uno de los objetivos de Internet es ocultar todos los detalles de la disposición física, que conocemos como topología, y la heterogeneidad del protocolo de capas inferiores de las aplicaciones. Aunque esto no es obvio en nuestro Internet de dos redes en la Figura 2.10, las capas de aplicación no deberían preocuparse que aunque cada host esté conectado a una red usando el protocolo de capa de enlace D (por ejemplo, Ethernet), Los hosts están separados por un enrutador y un conmutador que utilizan la capa de enlace G. Podría haber veinte enrutadores en el sistema de comunicación entre los host, con tipos adicionales de interconexiones físicas, y las aplicaciones se ejecutarían sin modificación (aunque el rendimiento podría variar). Resumen de los detalles de este enfoque es lo que hace que el concepto de Internet tan poderosa y útil.

Academy Xperts

17

NAE-TCP-A01 v1.0.07 – Arquitectura TCP/IP, Introducción – Capítulo 3: Arquitectura y protocolos de la Suite TCP/IP

Capítulo 3: Arquitectura y protocolos de la Suite TCP/IP Se ha discutido sobre la arquitectura, los protocolos, las suites de protocolos y técnicas de implementación, un resumen de ello en los primeros dos capítulos. En el presente capitulo se discutirá sobre la arquitectura y protocolos particulares que constituyen a la suite de protocolos TCP/IP. esta suite de protocolos se ha convertido hoy en día, un término establecido para los protocolos que se utilizan en internet. Primero revisaremos como estuvo conformado el concepto de capas en el modelo de referencia ARPANET, que a fin de cuentas marco la base del protocolo de internet, en si este concepto es diferente al que se revisó anteriormente en el modelo OSI.

El modelo de referencia ARPANET La Figura 3.1 muestra las capas del modelo de referencia ARPANET, que fue adoptada por la suite de protocolos TCP / IP. La estructura es más simple que el modelo OSI, pero las implementaciones reales incluyen unos pocos protocolos que no encajan en las capas convencionales. Comenzando desde la parte inferior de la Figura 3.1 y recorriendo el resto de capas, la primera capa que vemos tiene número 2.5, es una capa "no oficial" de enlace de datos donde hay varios protocolos que operan aquí. Uno de los más antiguos y más importantes se llama el Protocolo de resolución de direcciones (ARP). Es un protocolo utilizado con IPv4 y sólo con protocolos de capa de enlace de acceso múltiple para convertir entre las direcciones utilizadas por la capa IP y las direcciones MAC utilizadas por la capa de enl ace. En IPv6, se realiza este mapeo de direcciones con ICMPv6.

Figura 3.1

En la imagen anterior (Figura 3.1) las capas de protocolos basadas en el conjunto ARM o TCP / IP utilizado en Internet. No hay sesiones oficiales ni capas de presentación. Además, hay varios protocolos "auxiliares" que no encajan bien en las capas estándar pero que realizan funciones importantes para el funcionamiento de los otros protocolos. Algunos de estos protocolos no se usan con IPv6 (por ejemplo, IGMP y ARP). En la capa número 3 en la Figura 3.1 encontramos a IP, protocolo principal para la capa de red de la suite de protocolos TCP/IP. La PDU que envía IP a la capa dos se denomina datagrama IP y puede ser tan grande como 64KB y hasta 4GB para IPv6. En muchos casos usaremos el término paquete para identificar a un datagrama IP. Cuando existen paquetes grandes el ajuste de la PDU de capa de enlace que lo llamamos tramas, estos pueden ser más pequeños y se lo realiza mediante la función llamada fragmentación que puede ser implementada por hosts IP y algunos enrutadores cuando sea necesario. En la fragmentación, los datagramas grandes se envían en múltiples datagramas más pequeños llamados fragmentos y se vuelven a juntan o se re ensamblan al llegar a su destino. En general a lo largo de este curso y próximos cursos usamos el termino IP para referirnos tanto a las versiones 4 y 6. Usamos el término IPv6 para referirnos a IP versión 6 e IPv4 para referirnos a la popular IP versión 4. Cuando se habla de arquitectura, los detalles de IPv4 frente a IPv6 no tienen mucha importancia. Cuando nos enfocamos en la forma en cómo trabajan determinadas funciones de direccionamiento y configuración, estos detalles serán más importantes. Debido a que los paquetes IP son datagramas, cada uno contiene la dirección del remitente y destinatario de la capa 3. Estas direcciones se llaman direcciones IP y son 32 bits de largo para IPv4 y 128 bits para IPv6. Esta diferencia de tamaño es la característica que remarca más la diferencia entre IPv4 de IPv6. La dirección de destino de cada datagrama se utiliza para determinar dónde debe enviarse el paquete, y el proceso de realizar la comprobación y enviar el datagrama a su siguiente salto se llama reenvío. Tanto los enrutadores como los hosts realizan el reenvío, aunque los enrutadores tienden a hacerlo mucho más a menudo. Hay tres tipos de direcciones IP y el tipo que afecta cómo se realiza el reenvío: unicast, donde el paquete es destinado a un único host, broadcast, el paquete ahora es destinado a todos los hosts de una red dada y multicast, el paquete va destinado a un conjunto de hosts que pertenecen a un grupo de multidifusión.

Academy Xperts

18


El Protocolo de mensajes de control de Internet (ICMP, Internet Control Message Protocol) es un protocolo que se adjunta al IP y lo etiquetamos en la capacapa 3.5. Es utilizado para intercambiar mensajes de error y otra información vital con la capa IP en otro host o enrutador. Hay dos versiones de ICMP: ICMPv4, utilizado con IPv4, e ICMPv6, utilizado con IPv6 el cual es más complejo e incluye funciones como la autoconfiguración de direcciones y Neighbor Discovery que son administrados por otros protocolos como ARP en redes IPv4. Aunque ICMP se utiliza por IP, también es posible que las aplicaciones lo utilicen. De hecho, existen dos herramientas de diagnóstico populares, ping y traceroute aplicaciones que usan el protocolo ICMP. Los mensajes ICMP se encapsulan en los datagramas IP de la misma manera que las PDU de la capa de transporte. El protocolo de gestión de grupos de Internet (IGMP) es otro protocolo adjunto a IPv4. Se utiliza con direccionamiento y entrega multicast para gestionar qué hosts son miembros de un grupo de multidifusión, en otras palabras, un grupo de receptores interesados en recibir tráfico para una dirección de destino multicast en particular. Describimos las propiedades generales de difusión y multidifusión, junto con IGMP y el protocolo Multicast Listener Discovery (MLD, utilizado con IPv6), en un curso posterior.

Figura 3.2

En la capa 4, los dos protocolos más comunes de transporte tienen remarcables diferencias. El Protocolo de Control de Transmisión (TCP), el más utilizado, se encarga de resolver problemas como la pérdida de paquetes, la duplicación y el reordenamiento que no lo realiza la capa tres. Opera de una manera orientada a la conexión (VC) y no preserva los límites del mensaje. Por otro lado, el protocolo de datagramas de usuario (UDP) proporciona más de las características que IP. UDP permite a las aplicaciones enviar datagramas conservando los límites del mensaje, pero no impone ningún control de velocidad o control de errores. TCP proporciona un flujo confiable de datos entre dos hosts. Acciones como dividir los datos que emite la aplicación en fragmentos de tamaño conveniente para la capa de red, reconocer los paquetes recibidos y establecer tiempos de espera para asegurarse de que el otro host reconozca los paquetes enviados y el flujo confiable de datos son características que proporciona este protocolo en la capa de transporte, la capa de aplicación puede ignorar todos estos detalles. La PDU que TCP envía a IP se denomina segmento TCP. UDP, en cambio, proporciona un servicio más simple a la capa de aplicación. Permite que los datagramas se envíen de un host a otro, sin embargo, no hay garantía de que los datagramas lleguen al otro extremo, habiendo perdidas de paquetes en el camino de comunicaciones. La capa de aplicación debe añadir cualquier fiabilidad deseada. De hecho, todo lo que UDP ofrece para la “confiabilidad” es un conjunto de números de puerto para multiplexar y demultiplexar datos, más una sum a de comprobación de integridad de datos. Como podemos ver, UDP y TCP difieren mucho la una de la otra, aun estando en la misma capa. Hay un uso para cada tipo de protocolo de transporte, lo que veremos cuando nos fijamos en las diferentes aplicaciones que utilizan TCP y UDP. Existen dos protocolos de capa de transporte adicionales disponibles en algunos sistemas. Como todavía no están muy extendidos, no les dedicamos mucha discusión, sin embargo, los nombramos a continuación. El primero es el Protocolo de Control de Congestión de Datagramas (DCCP), especificado en [RFC4340]. El tipo de servicio que proporciona este protocolo es intermedio entre TCP y UDP. El intercambio orientado a la conexión de datagramas no confiables, pero con la habilidad de controlar la congestión. El control de la congestión comprende una serie de técnicas donde un remitente está limitado a una velocidad de envío para evitar sobrecargar en la red. El otro protocolo de transporte disponible en algunos sistemas se llama el Protocolo de Transmisión de Control de Flujo (SCTP), especificado en [RFC4960]. SCTP realiza una entrega confiable como TCP, pero no mantiene un orden estricto en los datos. Permite múltiples flujos transmitidos de manera lógica en la misma conexión y proporciona una abstracción de mensaje, que difiere de TCP. SCTP fue diseñado para transportar mensajes de señalización en redes IP similares a los utilizados en la red telefónica. La última capa por encima de la capa de transporte se encuentra la capa de aplicación que maneja los detalles de la aplicación en particular. Hay muchas aplicaciones que casi todas las implementaciones de TCP / IP proporciona. La capa de aplicación no se ocupa del movimiento de datos a través de la red. Las tres capas inferiores son lo opuesto: no saben nada sobre la aplicación, pero manejan todos los detalles de la comunicación.

Academy Xperts

19


Multiplexación, Demultiplexación, y Encapsulamiento en TCP/IP Ya hemos discutido los conceptos básicos de multiplexación, demultiplexación y encapsulación. En cada capa hay un identificador que permite a un sistema receptor determinar qué protocolo o flujo de datos pertenece. Por lo general, también encontramos información de direccionamiento. Esta información nos sirve para garantizar que una PDU se ha entregado en el lugar correcto. La Figura 3.3 muestra cómo funciona la demultiplexación en un host hipotético de Internet. Comenzando desde el nivel inferior al superior, mencionaremos cómo se realiza la demultiplexación en la capa de enlace. Una trama Ethernet que llega contiene una dirección de destino en la capa de enlace de 48 bits que se llama dirección MACMedia Access Control y un campo de 16 bits denominado tipo Ethernet. El valor hexadecimal “0x0800” indica que la trama contiene un datagrama IPv4. Los valores de “0x0806” y “0x86DD” indican ARP e IPv6, respectivamente. En el caso que la dirección de destino coincida con una de las direcciones del sistema receptor, la trama es recibida y se realiza una comprobación de errores y el campo Tipo Ethernet se utiliza para indicar a la siguiente capa qué protocolo de capa de red debe procesarla. Si la trama recibida contiene un datagrama IP, el encabezado y tráiler Ethernet se elimina y los bytes restantes que constituyen la carga útil de la trama se dan a IP para su procesamiento. IP comprueba una serie de elementos, incluida la dirección IP de destino en el datagrama.

Figura 3.3

En la imagen anterior (Figura 3.3) la pila TCP / IP utiliza una combinación de direccionamiento e identificadores de demultiplexación para determinar si un datagrama ha sido recibido correctam ente, en caso de que sea afirmativo decidir cuál entidad debe procesarla. Varias capas también comprueban valores numéricos como las sumas de comprobación checksum para asegurar que el contenido no se ha dañado durante el tránsito. Si la dirección de destino coincide con una de las suyas y el datagrama no contiene errores en su encabezado por que en el caso del protocolo IP, no verifica la carga útil, se verifica el campo Protocolo IPv4 de 8 bits llamado Next Header en IPv6 para determinar qué protocolo invocar a continuación. Entre los valores comunes del campo protocolo incluyen: 1 (ICMP), 2 (IGMP), 4 (IPv4), 6 (TCP) y 17 (UDP). El valor de 4 (y 41, que indica IPv6) resulta ser un caso interesante, porque habría la posibilidad de que un datagrama ipv4 o ipv6 forme parte de la carga útil, rompiendo los conceptos originales de capas y encapsulación, pero realmente es utilizada por una técnica conocida como tunelización. Una vez que la capa de red (IPv4 o IPv6) determine que el datagrama entrante es válido y el protocolo de transporte correcto, el datagrama resultante (re ensamblado en caso de que haya sido fragmentado) se pasa a la capa de transporte para su procesamiento. En la capa de transporte, la mayoría de los protocolos (incluyendo TCP y UDP) usan números de puerto para demultiplexar a la aplicación receptora apropiada.

Numero de puertos Los números de puerto son enteros no negativos de 16 bits es decir que tienen un rango de 0 a 65535. Estos números son abstractos y no cataloga nada del ámbito físico. Cada dirección IP tiene 65.536 puerto asociados para cada protocolo de transporte que utiliza números de puerto como la mayoría, y se usan para determinar la aplicación con la que va a trabajar la carga útil de la TPD U. Para las aplicaciones cliente / s ervidor, un servidor primero "se une" a un núm ero de puerto y luego los clientes se conectan al servidor con el número de puerto usando un protocolo de transporte. Mas parece ser que los números de puertos actúan como extensiones de número telefónico, con la diferencia que estos números de puerto están asignados por estándares. Los números de puerto estándar son asignados por la Internet Assigned Numbers Authority (IANA). El conjunto de números se divide en tres rangos: Numero de puertos bien conocidos (0-1023), los # de puertos registrados (1024-49151) y los dinámicos o privados (49152-65535). Tradicionalmente, los servidores que desean enlazarse un puerto bien conocido para ofrecer el servicio, requiere privilegios especiales como acceso de administrador o "root". Academy Xperts

20


El rango de puertos bien conocidos se utiliza para identificar muchos servicios, como Secure Shell Protocol (SSH, puerto 22), FTP (puertos 20 y 21), protocolo de terminal remoto Telnet (puerto 23), correo electrónico / Protocolo de transferencia de correo electrónico simple (SMTP, puerto 25), Sistema de nom bres de dominio (DNS, puerto 53), Protocolo de transferencia de hipertexto o Web (HTTP y HTTPS, puertos 80 y 443), IMAP e IMAPS, puertos 143 y 993), protocolo de gestión de red simple (SNMP, puertos 161 y 162), protocolo de acceso a directorios ligeros (LDAP, puerto 389) y varios otros. Los protocolos con puertos múltiples (por ejemplo, HTTP y HT TPS) suelen tener números de puerto diferentes dependiendo de si Transport Layer Security (TLS) se está utilizando con el protocolo de capa de aplicación base. Nota Examinando los números de puerto para estos servicios, y comparándolos con otros servicios que ofrece TCP/IP, nos percatamos que la mayoría son impares. Adentrándonos un poco en la historia, estos números de puerto se derivan de los utilizados en NCP, el protocolo de control de red, que precedió a TCP como un protocolo de capa de transporte para ARPANET. El NCP era simplex (Comunicación en una sola vía), no full duplex, siendo así que cada aplicación requiera dos conexiones y un par de números (uno par y el otro impar) de puertos reservados para cada aplicación. Cuando TCP y UDP se convirtieron en las capas de transporte estándar, sólo se necesitaba un único número de puerto por aplicación, aunque se usaron los números de puerto impares de NCP. Los números de puerto registrados están disponibles para usuarios con privilegios especiales, pero IANA mantiene un registro reservado para los tres campos, los “bien conocidos”, “registrados” y “dinámicos”, por eso, los números de puertos bien conocidos y registrados generalmente deben evitarse al desarrollar nuevas aplicaciones a menos que se haya obtenido una asignación de la IANA. Los números de puerto dinámico / privado no están regulados. Como veremos en algunos casos, el valor del número de puerto dinámico no tiene más importancia que la ubicar un paquete en un puerto para la transmisión, porque el uso es transitorio. A estos números de puerto también se los llaman, números de puertos efímeros. S on temporales porque un cliente necesita uno solo mientras el usuario conecte al cliente a su servicio requerido, enlazando al con el servidor convocándolo por medio de su número de puerto para establecer una conexión. Servidores, por el contrario, por otro lado, requieren nombres y números de puerto que no cambian con frecuencia para ser encontrados por los clientes.

Nombres, Direcciones, y el DNS Con TCP/IP, cada interfaz de capa de enlace en cada equipo tiene al menos una dirección IP, los cuales son suficientes para identificar un host, no muy convenientes para que los humanos recuerden o manipulen, especialmente usadas con IPv6. En el ámbito de TCP/IP, el DNS es una base de datos distribuida donde se guardan y se asignan los nombres de host con la dirección IP y viceversa. Los nombres se apegan a una jerarquía, terminando en dominios como .com, .org, .gov, .in, .uk y .edu. Tal vez, DNS es un protocolo de capa de aplicación y por lo tanto depende de los otros protocolos para operar. Aunque la mayoría de paquetes en TCP/IP no se preocupan de los nombres de host, los usuarios que usan navegadores web, por otro lado, lo usan con frecuencia, por lo que, si el DNS no funciona correctamente, el acceso normal a Internet se inhabilita.

Figura 3.4

Las aplicaciones que manipulan nombres hacen uso de una función API estándar para buscar la dirección o direcciones IP correspondiente al nombre de un host dado. Siendo así que utiliza una función para realizar la búsqueda inversa otorgando una dirección IP y busque el nom bre de host correspondiente. La mayoría de las aplicaciones que toman un nombre de host como entrada también tienen una dirección IP. Los navegadores web admiten esta capacidad mediante el uso de los Localizadores Uniformes de Recursos (URL), ejemplos como: http://131.243.2.201/index.html y http://[2001:400:610:102::c9]/index.html pueden escribirse en un navegador Web y son efectivamente equivalentes a http://ee.lbl.gov/index.html. En el caso del segundo ejemplo, se requiere conectividad IPv6 para que tenga éxito la conexión.

Internet, Intranet, y Extranet Como se sugirió anteriormente, el internet se ha desarrollado como una red agregada resultante de la interconexión de redes ya constituidas a lo largo del tiempo. Un corto concepto de internet seria “varias redes conectadas entre sí”, haciendo uso de un conjunto de protocolos común, Tomando un concepto mayor del internet, nos referimos a la colección de hosts alrededor del mundo que pueden comunicarse entre sí mediante TCP/IP. Una de las razones para el crecimiento de las redes durante la década de 1980 fue el comprender que trabajar con grupos aislados de computadoras stand-alone o independientes, ya no tiene sentido. Algunos sistemas autónomos se unieron a una red. Aunque esto fue solo uno de los pasos, durante la década de 1990 nos dimos cuenta que las redes separadas que no podían interoperar no eran valiosas como una red más grande. Este enfoque es la base de la llamada Ley de Metcalfe, que establece que el valor de una red informática es proporcional al cuadrado del número de host finales conectados. La idea de

Academy Xperts

21


Internet, y sus protocolos, harían que la interconexión de diferentes redes se establezca. Este concepto engañosamente simple resulta extraordinariamente poderoso. La forma más fácil de armar una estructura de Internet es conectar dos o más redes con un enrutador. Un enrutador es un dispositivo de propósito especial para conectar redes la mayoría de las veces. Lo bueno de los routers es que proporcionan conexiones a muchos tipos diferentes de redes físicas: Ethernet, Wi-Fi, enlaces punto a punto, DSL, servicio de Internet por cable, etc.

Figura 4.1

Nota Los enrutadores o routers IP, históricamente se los conocía como Gateways o puertas de enlace, y este término se utiliza en gran parte de la literatura más antigua de TCP/IP. Hoy en día, el término gateway se utiliza para una puerta de enlace de la capa de aplicación (ALG - application layer gateway), un proceso que conecta dos suites de protocolo diferentes (por ejemplo, TCP / IP e IBM SNA) para transportar datos generados por alguna aplicación (a menudo correo electrónico o transferencia de archivos). En los últimos años hay 2 nuevos términos en las configuraciones de internets utilizando la suite de protocolos TCP / IP. Una intranet es el término utilizado para describir una red privada, suelen ser administradas por un negocio u otra empresa y con las seguridades pertinentes, todos los datos que se manejen dentro de esta intranet no podría ser vista por ninguna persona en el exterior, permitiendo así, acceso a los recursos disponibles sólo para los miembros de la empresa en particular. Los usuarios pueden conectarse a su intranet desde fuera de la organización, utilizando una red privada virtual (VPN). Las VPN garantizan el acceso a los recursos potencialmente confidenciales en una intranet y que sólo esté disponible para usuarios autorizados, usualmente utilizando el concepto de túneles que se mencionó anteriormente. En muchos casos, una empresa o negocio desea una red que contenga servidores accesibles a ciertos socios y asociados con conexión a Internet. Dichas redes, que también suelen implicar el uso de una VPN y se las conocen como extranets y consisten en computadoras conectadas fuera del Firewall de la empresa de servicios. En el aspecto técnico, no hay mucha diferencia entre estos tres conceptos, pero podremos apreciar las diferencias depende del uso y las políticas adminis trativas que tenga una empresa u organización, y, por lo tanto, una serie de estos términos más específicos han evolucionado.

Academy Xperts

22

NAE-TCP-A01 v1.0.07 – Arquitectura TCP/IP, Introducción – Capítulo 4: Diseñando Aplicaciones

Capítulo 4: Diseñando Aplicaciones Los conceptos de red que hemos tocado hasta ahora proporcionan un modelo de servicio bastante simple: transmitir bytes, multiplexar, entre protocolos y programas ejecutándose en diferentes equipos y/o dispositivos intermedios. Para hacer algo útil con estos conceptos, necesitamos aplicaciones en la red que la usen para otorgar servicios o realizando cómputos. Las aplicaciones en la red se apegan a un número pequeño de patrones del diseño. El más común de estos diseños son el cliente / servidor y el peer-to-peer.

Cliente/Servidor La mayoría de las aplicaciones de red tienen como diseño un host que actúe como cliente, y otro como servidor. El servidor provee algún servicio a los clientes, por ejemplo, el acceso a archivos en el host del servidor, correo electrónico, DNS, DHC P, entre otros. En el caso estricto de los servidores, podemos apreciar dos clases: iterativa y concurrente. Un servidor iterativo trabaja de acuerdo a los siguientes pasos: I1. Espera de la solicitud del cliente. I2. Proceso de la solicitud del cliente. I3. Envío de una o las respuestas al cliente que lo solicito. I4. Regresar al paso I1. El problema con un servidor iterativo es cuando el paso I2 se toma mucho tiempo en procesar la solicitud del cliente, dejando sin servicio a ningún otro cliente hasta que termine el paso I3. Por otro lado, un servidor concurrente realiza los siguientes pasos: C1. Espera de la solicitud del cliente. C2. Se inicia una nueva instancia para procesar la solicitud de dicho cliente. Creando así un nuevo proceso, tarea o subproceso, dependiendo de los recursos de soporte del sistema operativo subyacente. Este nuevo servidor generado gestiona la solicitud completa de un cliente. Cuando finaliza la tarea, el nuevo servidor finaliza. Mientras tanto, la instancia del servidor original continúa con C3. C3. Vuelva al paso C1. La ventaja de un servidor concurrente es que se genera una nueva instancia de servidor para atender a la solicitud del cliente. Cada cliente tiene su propio servidor. Suponiendo que el sistema operativo tenga permitida la multiprogramación (todos lo hacen hoy en día), varios clientes son atendidos simultáneamente. La razón por la que clasificamos los servidores, y no los clientes, es que un cliente normalmente no puede saber si está hablando con un servidor iterativo o con un servidor concurrente. Como regla general, la mayoría de los servidores son concurrentes. Cuando hablamos de los términos de cliente y servidor es para referirnos a las aplicaciones no a sistemas informáticos donde se ejecutan. Los mismos térm inos se utilizan para referirse a las partes de hardware que hacen uso de un servicio específico que les permita utilizar con más frecuencia, por ejem plo, una solución de cámaras de video vigilancia. Aunque la terminología es así algo imprecisa, funciona bastante bien en la práctica. Como resultado, es común encontrar un servidor (en el sentido del hardware) que ejecute más de un servidor (en el sentido de la aplicación).

Figura 5.1

Peer-To-Peer Existen aplicaciones las cuales están diseñadas para trabajar de manera más distribuida, donde no existe solamente un servidor. Cada aplicación trabaja como cliente, así como también al servidor, y en ocasiones trabajan a la vez reenviando solicitudes. Entre las aplicaciones más populares que trabajan con este diseño de aplicaciones, tenemos a S kype, BitTorrent, entre otros, a este tipo de aplicaciones se los denominan Peer-to-Peer o P2P. Estas aplicaciones de forma concurrente reciben una solicitud entrante, y decide si este puede responder a dicha solicitud, caso contrario reenvía la solicitud a algún otro servidor que pertenezca a la red. Es por eso que el conjunto de aplicaciones p2p unidos, forman una red superpuesta, estas redes son hoy en día comunes y pueden ser extremadamente poderosas. Tomando el ejemplo de Skype, este ha crecido hasta convertirse en la mayor empresa de llamadas telefónicas internacionales. Y por el lado de BitTorrent, este fue responsable de más de la mitad de todo el tráfico de internet en el 2009. Sin embargo, existen problemas y uno de los principales en este tipo de redes p2p se lo denomina, problema de descubrimiento. Guiándose por la pregunta, ¿cómo uno de los peer encuentra cual peer o peers les proveerá el s ervicio que

Academy Xperts

23


requieren donde dichos peer no son constantes en la red?, el procedimiento comienza con un arranque por el cual cada cliente realiza una configuración inicial con las direcciones y números de puerto de algunos pares donde probablemente esté operando, una vez establecida la conexión, el nuevo participante aprende de sus vecinos activos, y dependiendo del protocolo usado, proporcionar archivos o servicios.

Interfaz de programación de aplicaciones (APIs) Las aplicaciones sin importar el diseño que hayan seguido, sea este P2P o cliente/servidor, las operaciones de red que realicen, por ejemplo, establecer una conexión, o leer y escribir datos, deben ser expresadas de alguna manera. Por esto, suele ser soportado por un sistema operativo anfitrión, haciendo uso de una interfaz de programación de aplicaciones de red (API por sus siglas en ingles). El más popular de los API se lo llama sockets o sockets de Berkeley, este último, indicando donde fue desarrollado originalmente.

Figura 5.2

Este curso al no ser de programación, aunque en ocasiones nos referimos de una característica de TCP/IP, pero generalmente no tocamos temas de programación, y si esa característica es proporcionada por la API sockets o no. Todos los detalles de programación con ejemplos de sockets se pueden encontrar en el libro de programación de red de UNIX de los autores Stevens, Fenner y Rudolf. Las modificaciones a los zócalos para el uso de IPv6 también se describen en una serie de documentos en línea disponibles de manera gratuita en [RFC3493][RFC3542][RFC3678][RFC4584][RFC5014].

Proceso de Estandarización Lo fundamental es idear un conjunto de reglas para cualquier o todas las fases de l a comunicación y convencer a los dem ás para hacer un nuevo hardware o software que implemente este nuevo método. Promueven y mantienen un mercado abierto y competitivo para hardware y software de red. Un estándar no garantiza la aceptación en el mercado, pero para un protocolo es difícil tener éxito sin un estándar. Estos estándares indican las directrices esenciales para los fabricantes, vendedores, proveedores de servicios, consultores, agencias gubernamentales, y usuarios para asegurar que la interconectividad necesaria está ahí. Cuando hablamos de normativas existen 2 categorías: “de jure”, por regla o regulación, “de facto”, de hecho, o convencimiento. Las normas dentro de la categoría “de jure”, han sido aprobadas por un organismo reconocido oficialmente que se encarga de estandarizar los protocolos y otros aspectos de las redes, a menudo tienen fuerza de ley, incluso si son solamente recomendaciones. Se les recomienda a los países utilizar sus propios métodos de aplicación, como multas para asegurarse que sigan estas regulaciones. Por otro lado, las normas en la categoría “de facto”, por lo general, no han sido aprobadas formalmente, sin embargo, son ampliamente aplicadas, este tipo de normas se puede utilizar para establecer rápidamente un nuevo producto de tecnología, los estándares que están en la categoría “de facto” pueden ser propuestas para aprobación “de jure”. Este tema se pone más complejo cuando los protocolos son para uso de internet, de tal manera son pocas las normas oficiales y no existen sanciones reales si no llegan a cumplirlas. Los que recién se integran a los conocimientos de la suite TCP / IP se preguntan quién es responsable de establecer y estandarizar los diversos protocolos y explicar la manera de cómo operan. Para la respuesta a esta pregunta, existen varias organizaciones que trabajan para esos fines específicos. La organización que más atención tiene en estas cuestiones es el Internet Engineering Task Force (IETF) [RFC4677]. Este grupo se reúne tres veces al año en varios lugares alrededor del mundo y la labor fundamental de estas reuniones es el de desarrollar, discutir y acordar estándares para los protocolos "básicos" de Internet. Algún protocolo que se considere como núcleo está sujeto a debate, pero los protocolos comunes como IPv4, IPv6, TCP, UDP y DNS forman parte del ámbito de IETF. La asistencia a las reuniones de la IETF está abierta a cualquiera, y las reuniones pueden ser para cualquier persona sin embargo no es gratuito. IETF es un foro que se encarga de elegir grupos de liderazgo llamados el Internet Architecture Board (IAB) y el Internet Engineering Steering Group (IESG). El IAB se encarga de proporcionar orientación arquitectónica a las actividades en IETF y realiza también otro tipo de tareas como el nombramiento de enlaces a otras Organizaciones que Definen Normas (SDO). El IESG, por otro lado, está autorizada a tomar decisiones que tienen que ver con la creación y aprobación de nuevas normas, así como también modificaciones a las normas existentes. Esto es lo que se llama "trabajo pesado" o trabajo detallado el cual es realizado por los grupos de trabajo de IETF que son coordinados por sus respectivos jefes de grupo de trabajo que se ofrecen voluntariamente para esta tarea. Además de la IETF, hay dos adicionales grupos que son importantes de mencionar y que interactúan estrechamente con el IETF. El Grupo de Trabajo sobre Investigación en Internet (Internet Research Task Force - IRTF) explora protocolos, arquitecturas y procedimientos, los que luego pasan por un proceso donde se decide si se consideran o no lo suficientemente maduros para la estandarización. El actual presidente de la IRTF es un miembro no votante de la IAB. El IAB, trabaja también con la Internet Society (ISOC) que los ayuda a influir y promover las políticas m undiales, y la educación sobre las tecnologías con el uso de Internet.

Figura 6.1

Academy Xperts

24


Solicitud de comentarios (RFC) Cada estándar que haya sido aceptada como oficial en la comunidad de Internet se publica como una solicitud de comentarios, o RFC (Request For Comments). Los RFC pueden realizarse de varias maneras, y el editor de RFC reconoce varios flujos de documentos que corresponden al formato que se ha desarrollado un RFC. A partir de 2010 hasta la actualidad se incluyen IETF, IAB, IRTF y flujos de envío independientes. Antes de ser aceptado y publicado de forma permanente como RFC, los documentos primero pasan de ser borradores temporales de Internet mientras reciben comentarios y progresos a través del proceso de edición y revisión. Todos los RFC publicados no son estándares. Sólo la categoría llamada pista-estándar en los RFCs se consideran normas oficiales. Otras categorías incluyen la mejor práctica actual (Best Current Practice - BCP), informativa, experimental e histórica. Hay que tener presente que no todos los documentos que se encuentren en RFC, han sido aceptados y endosados por IETF como un estándar. Es decir que existen RFCs donde existen desacuerdos significativos. Los RFCs pueden variar de unas pocas hojas a cientos de ellas. Cada uno es identificado por un número, por ejemplo, RFC 1122, los números más altos en RFC significa que son documentos nuevos y más recientes. Estos documentos están disponibles gratuitamente en diferentes sitios Web, incluyendo a http://www.rfc-editor.org. Por razones históricas, RFCs por lo general se entregan los documentos en texto plano, aunque algunos RFCs han sido reformateados o creados utilizando formatos de archivo más avanzados y recientes. Una serie de RFCs pueden resumir, aclarar o interpretar determinados conjuntos de otras normas. Por ejemplo, [RFC5000] define el conjunto de RFC que se consideran normas oficiales a mediados de 2008. Una lista actualizada está disponible en el sitio Web de estándares actuales. Los requerimientos [RFC 1122] y [RFC1123] definen los requisitos para implementar los protocolos en los hosts IPv4 de Internet, y los Requisitos [RFC1812] hace lo mismo para los enrutadores. Los requisitos de nodo [RFC4294] para los sistemas IPv6.

Niveles de madurez de un RFC Figura 6.2

Figura 6.2 madurez de un RFC muestran los diferentes estados por los que pasa un proyecto de internet antes de ser un RFC registrado. Podemos percatarnos que un proyecto de internet en primera instancia puede ser 3 tipos de RFC. El experimental muestra el contenido de una tecnología que no desea pasar por un proceso de estandarización o normativa, a diferencia de si desea ser propuesto para un estándar, en el cual si pasa por un proceso de 6 meses para luego llevar este proyecto de internet a proyecto de normativa, y en el proceso de 4 meses adicionales pasar a ser un estándar de internet y por supuesto, ser registrado como un RFC Historico.

Academy Xperts

25


Otros estándares Aunque el IETF es responsable de estandarizar la mayoría de los protocolos que hemos discutido y se discutirán más adelante, otras SDOs son responsables de definir protocolos que pueden sernos de mucho interés. Los más importantes de estos grupos son el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE), el W orld Wide Web Consortium (W3C) y la Unión Internacional de Telecomunicaciones (ITU). Entre sus acti vidades, el IEEE se ocupa de los estándares por debajo de la capa 3 por ejemplo, Wi-Fi y Ethernet y el W3C se ocupa de l os protocolos de capa de aplicación, específicamente los relacionados con las tecnologías Web, por ejemplo, sintaxis basada en HTML. La ITU, y más específicamente el ITU-T (anteriormente CCITT), normaliza los protocolos para las redes telefónicas y celulares, el que es un componente que se toma más importancia cada vez en el ámbito de internet.

IEEE -

La mayor sociedad de ingenieros profesionales en el mundo Entre sus labores está el supervisar el desarrollo y la adaptación de normas internacionales. La mayor parte del tiempo se enfocan en conexiones LAN 802.11 es un ejemplo de norma que representa las redes LAN inalámbricas.

-

Organización sin fines de lucro No existe afiliación al gobierno federal Entre sus labores coordinan la normalización de manera voluntaria en los Estados Unidos ASCII es un ejemplo de estándar ANSI

-

Organización sin fines de lucro Alienado a ANSI en las preocupaciones de fabricación electrónica Contribuyo en la creación de redes mediante la definición de interfaces de conexión física. RJ-45 Es un ejemplo de estándar para los conectores populares recomendados para redes LAN.

-

El objetivo de la organización es igualar y homogeneizar todas las culturas Son una organización voluntaria dedicada a las normas internacionales La principal contribución de ISO en el campo de las redes es la inclusión de un modelo de redes de datos. OSI, interconexión de sistemas abiertos, es un ejemplo de modelo de referencia para la estandarización ISO.

-

Prepara normas internacionales para la economía global no necesariamente para las redes pero si para la telefonía conmutada para el publico global. Las comunicaciones que atraviesan fronteras nacionales deben seguir las recomendaciones de esta organización los cuales tiene peso de ley. La arquitectura ATM modo de transferencia asíncrono es un ejemplo de estándar ITU

ANSI

EIA

ISO

ITU

-

Implementaciones y distribuciones de software Los hechos históricos de las implementaciones standard TCP/IP comenzaron en el Grupo de Investigación de Sistemas Informáticos (Computer Systems Research Group - CSRG) de la Universidad de Berkeley en California donde se desarrolló y distribuyó el sistema BSD (Berkeley Software Distribution) 4.x y con los BSD Networking Releases hasta mediados de los noventa. Este código fuente es el punto de partida para muchas implementaciones diferentes. Hoy en día, cada sistema

Academy Xperts

26


operativo popular tiene su propia implementación. Se tiende a dibujar ejemplos de las implementaciones de TCP / IP en Linux, Windows y a veces FreeBSD y Mac OS, ambos derivados de versiones históricas de BSD).

Figura 7.1

La Figura 7.2 muestra un esquema cronológico de las versiones de BS D, indicando las características importantes de TCP/IP que lo revisaremos en cursos posteriores. También se podrá visualizar cuando Linux y Windows comenzaron a soportar TCP/IP. Los lanzamientos de redes BSD mostrados en la segunda fila fueron versiones públicas de código fuente disponibles de manera gratuita que contenían todo el código de red, así como también los propios protocolos como muchas aplicaciones y utilidades, por ejemplo, el programa de terminal remoto Telnet y el programa de transferencia de archivos FTP. A mediados de la década de los noventa, Internet y TCP / IP estaban bien establecidos. Todos los sistemas operativos populares luego de esa fecha admiten TCP / IP de forma nativa. La investigación y el desarrollo de nuevas características de TCP / IP, antes realizadas en BSD, se encuentran ahora en las versiones de Linux. Windows ha implementado recientemente una nueva pila de TCP / IP comenzando su implementación con Windows Vista, y con muchas nuevas características y capacidad IPv6 nativa. Linux, FreeBSD y Mac OS X también admiten IPv6 sin realizar ninguna configuración especial.

Figura 7.2

En la imagen anterior (Figura 7.1) la historia de las versiones de software que soportan TCP / IP hasta mediados de los noventa. Las distintas versiones de BSD fueron pioneras en la disponibilidad de TCP / IP. Esta afirmación es en parte debido a las incertidumbres legales con respecto a los lanzamientos de BSD, Linux se desarrolló como una alternativa que fue inicialmente diseñada para usuarios de PC. Microsoft comenzó a soportar TCP / IP en Windows un par de años más tarde.

Ataques con la arquitectura de internet A través de este curso hemos hablado un poco acerca de los ataques y vulnerabilidades descubiertas en el diseño o la implementación del tema que estam os discutiendo. Pocos ataques apuntan completamente a la arquitectura de internet. Sin embargo, es importante observar que la arquitectura de Internet entrega datagramas IP basados en direcciones IP de destino. Como resultado, los usuarios malintencionados pueden tener la capacidad de insertar cualquier dirección IP que elijan en el campo de dirección IP de origen de cada datagrama IP que envíen, a esta actividad ilícita es llamada spoofing. Los datagramas resultantes se entregan a sus destinos, pero es difícil realizar la verificación. Es decir, puede ser difícil o imposible determinar el origen real de un datagrama recibido desde Internet.

Figura 7.3

Academy Xperts

27


La falsificación se puede combinar con otros ataques vistos periódicamente en Internet. Los ataques de denegación de servicio (DoS, por sus siglas en inglés) implican el uso de varios recursos importantes que son negados a los usuarios legítimos. Por ejemplo, el envío de muchos datagramas IP a un servidor, manteniendo ocupado con varias peticiones falsas y pasa todo su tiempo en procesar los paquetes entrantes sin realizar ningún otro trabajo útil es lo que se denomina ataque de tipo DoS. Otros ataques DoS pueden implicar la obstrucción de la red con mucho tráfico impidiendo que se puedan enviar otros paquetes. Esto se logra a menudo utilizando muchos equipos para el proceso de dichos paquetes falsos, formando un ataque distribuido de DoS (DDoS).

Figura 7.4

Los ataques de acceso no autorizados o también llamados de intrusión, implican el acceso a información o recursos de manera no autorizada. El acceso no autorizado puede ser realizado por medio de un conjunto de técnicas, como explotar (xploit) errores de implementación de protocolo, buscando vulnerabilidades y aprovechándose de ellas para tomar el control de un sistema (llamado 0wning y convertirlo en un zombie o bot). También puede implicar varias formas de enmascaramiento, haciendo pasar al atacante como si fuera un usuario legítimo de la red, por ejemplo, cuando se ejecuta con las credenciales del usuario. Algunos de los ataques implican tomar el control de muchos sistemas remotos utilizando malware y usarlos de una manera coordinada y distribuida, a estos dispositivos infectados se los llama botnets. Los programadores que

Academy Xperts

28

NAE-TCP-A01-v1.0.07

Recommend Documents