Dentro de los contenidos típicos de los cursos fundamentales de redes, como CCNA, siempre se debe mencionar la capa de aplicación y los protocolos que hacen parte de ella, ya que son los protocolos más cercanos al usuario y por ende son los que permiten relacionar las acciones del usuario con la red misma. En ésta publicación les voy a describir brevemente los protocolos más comunes y algunas de sus características clave para recordar en un examen de certificación como el CCNA 200-301. Disfrútenlo.
Introducción
Como he venido describiendo, éste es un resumen del módulo 15 del primer curso de CCNA para academias llamado ITN o Introduction to networks. Ya hemos discutido lo más básico de las capas 1, 2, 3 y 4 del modelo OSI, sin embargo, para hablar de la capa de aplicación nos saltamos un poco las capas 5 y 6 porque no están muy bien definidas y no hay protocolos comunes que nos hagan fácil la descripción de sus funciones. Para más detalle sobre éstas capas les recomiendo leer mis entradas anteriores sobre el modelo OSI, particularmente sobre la capa 5 y la capa 6.
Como veremos, las acciones más comunes que ejecuta un usuario y generan actividad sobre los elementos de red como switches, routers y servidores, es el acceso a páginas web, chats y accesos remotos. En el modelo de TCP/IP, la capa de aplicación cumple las funciones de las últimas tres capas del modelo OSI (5, 6 y 7), ésto se debe a que los protocolos de aplicación que tiene la suite de protocolos TCP/IP se encargan de todas esas funciones.
Capas presentación (6) y sesión (5)
Para no saltarnos del todo las capas 6 y 5 del modelo OSI, resumiremos sus funciones. La capa de presentación se encarga de homologar los formatos de datos, es decir, si, desde una tablet android, se solicita un archivo que proviene de un servidor Intel, digamos un PDF, la capa de presentación se encarga de que ambos dispositivos acuerden el formato de bajo nivel del documento para que, si hay alguna incompatibilidad entre las dos arquitecturas, se pueda tener en cuenta y corregir transparentemente para el usuario. En términos del currículo de Cisco, la capa de presentación tiene las funciones de formateo de los datos, compresión y cifrado (encriptación) en caso de ser necesarios.
La capa de sesión o capa 5 del modelo OSI, tiene la responsabilidad de controlar las sesiones de los diferentes «clientes» del sistema en particular, por ejemplo cuánto tiempo se puede dejar una sesión abierta si no hay actividad, si las peticiones y respuestas deben ser síncronas, es decir, sólo se envía una nueva petición si no hay nada más pendiente y otras cosas de alto nivel como las formas de autenticar. En términos del currículo de Cisco: se encarga de los diálogos entre aplicaciones, la dinámica de las sesiones con las aplicaciones de red.
Capa 7 del modelo OSI o capa de aplicación
Y ésta es nuestra protagonista de hoy: la capa de aplicación. Recuerden, la capa de aplicación del modelo TCP/IP ocupa las funciones de las últimas capas del modelo OSI, por eso pasamos rápido por las tres. En la capa 7 del modelo OSI se definen los mensajes que permite enviar y recibir una aplicación, no se puede entender sin comprender que cada aplicación tiene un propósito específico, por ejemplo, ftp es un protocolo de la capa de aplicación, por ende, define las acciones de conectar, bajar archivos del servidor, subir archivos del servidor, explorar un directorio, moverse entre directorios habilitados para el servicio de ftp, etc..
Los protocolos típicos de TCP/IP son protocolos que usualmente se van a poder usar (o se usan) en cualquier dispositivo que soporte TCP/IP, por ejemplo, DHCP, DNS, HTTP, FTP, TELNET o SSH. Existe una relación estrecha entre las aplicaciones y sus puertos de capa 4 o capa de transporte, por ejemplo, si decimos DHCP debemos recordar que ésta aplicación cuyos mensajes definen cómo obtener una dirección IP y los parámetros básicos de conectividad cuando un host se conecta a la red, usa UDP para enviar éstos mensajes y sus puertos destino son 67 y 68, el primero es el puerto destino para los mensajes que envían los clientes y el segundo para los que envían los servidores. Éstos puertos se conocen como BOOTP porque éste fue el protocolo antecesor de DHCP.
Antes de continuar, debemos señalar que existen dos «arquitecturas» de aplicaciones: cliente-servidor y peer-to-peer o P2P. En el primer modelo tenemos un servidor centralizado, el cual puede ser virtual o compuesto por varios servidores físicos con algún tipo de balanceo de cargas que escucha el puerto bien conocido, por ejemplo el puerto TCP 80 para un servidor web, y todos los usuarios ejecutan aplicaciones clientes que apuntan a la IP de éste servidor y bajan sus archivos, o páginas web en éste ejemplo. El «cliente» que menciono en éste ejemplo es el navegador web. Este modelo es la forma clásica de desplegar servicios y tiene la ventaja de poder controlar el tráfico, las conexiones y los contenidos. Desde el punto de vista de la red nos presenta una ventaja y un reto: la ventaja es el control estricto del tráfico y de los contenidos, el reto es que si el servicio es muy concurrido necesitaríamos una red que dé cuenta de gran capacidad y más importante aún, gran escalabilidad, es decir, que pueda crecer rápido y fácil. Lo de la escalabilidad no es trivial: si tienes un switch y un server y depronto todo tu tráfico se dispara, tendrías que agregar cables, tarjetas de red e incluso crecer la capacidad del server. Ésto no es tan fácil y seguro tendrías que tumbar el servicio justo en su apogeo. La escalabilidad es un tema crítico que las redes modernas tienen en su base: poder crecer fácil y rápidamente.
La otra arquitectura, P2P, es una forma diferente de establecer servicios en los que cada usuario ejecuta una aplicación que hace las funciones de cliente y de servidor, de tal manera que cada usuario aporta algo en el propósito del servicio. Un ejemplo es el BitTorrent, que es una red de clientes que permiten que lo que yo haya descargado por BT también esté disponible para otro usuario que también lo quiera descargar. Otro ejemplo típico de p2p es las carpetas compartidas de Windows: en ellas cada usuario publica una carpeta y los otros usuarios de la red pueden, dependiendo de los privilegios que tenga la carpeta original, copiar, guardar y hasta borrar archivos de la carpeta compartida en nuestro disco duro, para éste servicio se usa el protocolo llamado SMB o Server message block. Otros ejemplos son FreeNet, Direct Connect e eDonkey. El reto de los servicios P2P es la seguridad y que no hay mucho control sobre los patrones de tráfico.
Protocolos de aplicación notables y cómo se articulan
Como ya lo hemos visto anteriormente, los protocolos de red usualmente apoyan las funciones de otro, es el caso de los protocolos consecutivos de las capas: los protocolos de capa 3 soportan a los protocolos de capa 4 y así sucesivamente. También existen protocolos de la misma capa que ayudan a otros a llevar a cabo sus funciones. Un ejemplo claro e importantísimo de éste tipo de integración es el protocolo DNS o Domain Name Service en inglés (Servicio de nombres de dominio en español), un protocolo de capa de aplicación que permite traducir un nombre de dominio, fácil de recordar como facebook.com o cisco.com a una dirección IP como 31.13.89.35 o 72.163.4.185 respectivamente. Todas las transacciones de red se hacen con direcciones IP, sin embargo es muy raro que, como usuarios, veamos una dirección IP en nuestro navegador o en cualquier otra aplicación, verdad? pues gracias a DNS que usa tanto TCP como UDP para transportar mensajes dirigidos al puerto 53. Un nombre de dominio se puede conocer como un FQDN o Full-qualified domain-name, básicamente es un nombre de dominio como los del ejemplo y las peticiones DNS incluyen el tipo de registro que se pide, por ejemplo, un tipo A (record A) se puede interpretar como Type A: google.com, dígame que IPv4 tiene este FQDN? Si el tipo de solicitud fuera AAA sería: Type AAA: Google.com, dígame que dirección IPv6 tiene este FQDN? Otros tipos de registro son MX que significa cuál es el servidor de correo del dominio y NS que pregunta por un servidor autoritativo del dominio. DNS es un servicio jerárquico, usualmente tenemos un DNS local que tiene los mapeos de FQDN a IPv4/IPv6 de los nombres de nuestra organización o simplemente hace un «caché» o almacenamiento temporal de lo que le consultan a él y él mismo, para poder responder, escala la consulta a servidores autoritativos del dominio o servidores raíz de Internet.
Para hacer diagnósticos del DNS, que es un servicio crítico y que puede ser el origen de la típica queja de «se cayó el internet», se usan varias herramientas. Lo primero es tener claro cuál es la IP de nuestro DNS y hacer pings o tracert a esa IP, lo segundo es usar aplicaciones especiales de DNS como nslookup o dig (para Unix/Linux).
Otro protocolo de la capa de apliación que con el tiempo se ha convertido en un protagonista en espacios que no esperabamos que lo fuera es HTTP, en inglés Hypertext transfer protocol o protocolo de transferencia de hipertexto. Lo conocemos por la navegación en internet, usa TCP y el puerto conocido que usa es el 80, sin embargo, hoy en día es más común ver HTTPS que usa el puerto TCP 443 y que usa cifrado para asegurar la privacidad e integridad de los datos entre cliente y servidor. HTTP ha empezado a ocupar un lugar importante en la automatización, porque por su popularidad, muchas aplicaciones de automatización como las de IoT lo usan para simplificar sus transacciones y no tener que inventarse un protocolo de aplicación nuevo. Las operaciones típicas o básicas de HTTP son PUT, GET y POST, la idea es que si un cliente hace una petición GET a un server, el server analiza ésta petición, busca el recurso que se está solicitando y lo regresa o, en caso de que el recurso no exista, devuelve un mensaje de error. Las operaciones mencionadas se llaman métodos de HTTP y son las más comunes, existen otras y existe un catálogo de posibles respuestas del servidor para indicar qué paso con la solicitud, por ejemplo, si el server responde con el código 200, significa que todo salió bien y se está entregando exitosamente un recurso solicitado, de otro lado si se responde 404, significa que el recurso solicitado no existe en el servidor.
Otros protocolos de aplicación muy importante son los que permiten la transferencia de correos electrónicos, por ejemplo SMTP que sirve para transferencia de correos tanto de los clientes como entre los servidores (por volumen) y POP e IMAP que están diseñados especialmente para que los clientes le envíen y reciban los correos del server. SMTP usa el puerto bien conocido tcp 25.
No olvidemos que para que una computadora se conecte a la red debe tener una dirección IP. Existen dos alternativas: o se configuran manualmente los parámetros de red (IP/máscara/gateway entre otros) o se permite que la estación los busque en la red y se autoconfigure. Para éste último propósito existe DHCP, que permite a una estación recién encendida descubrir qué servidores DHCP existen en la red, luego solicitarle un conjunto de parámetros de red en «préstamo» y finalmente devolver el «préstamo» cuando se apaga o desconecta. Así mismo, el protocolo permite al servidor ofrecer los parámetros a los clientes que le soliciten conectividad de red y otras operaciones como acusar recibo del préstamo, renovar el préstamo, rechazar la petición o retirar la IP. El caso típico y curso normal de eventos sería así:
- El cliente envía un mensaje de BROADCAST llamado DHCP_DISCOVER
- El servidor que escucha responde con un UNICAST llamado DHCP_OFFER
- El cliente responde con un mensaje de BROADCAST llamado DHCP_REQUEST
- y finalmente el server acusa recibo y final de la transacción con un UNICAST llamado DHCP_ACK
Entre estas opciones pueden existir situaciones de excepción, por ejemplo que la red tenga dos servidores DHCP y ambos reciben la petición inicial, en éste caso, alguno de los dos debe rechazar la petición con un DHCP_DECLINE o si una estación se tarda en hacer el DHCP_REQUEST (que acepta los parámetros enviados en el DHCP__OFFER), puede que el servidor ya haya enviado esos mismos parámetros a otra estación y esa misma oferta ya no sea válida, en éste caso se responde con un DHCP_NACK.
Finalmente, aunque el currículo no lo describe en éste módulo, yo sí quiero mencionar los protocolos que usamos en la administración de los dispositivos de red: telnet, ssh y SNMP. Telnet es el protocolo por defecto para conectarnos remotamente a la consola de los equipos, éste es un protocolo trivial que establece una sesión tcp al puerto 23 y todo lo que escribimos se va para el servidor de vty del router/switch y éste responde a los comandos escritos enviando la respuesta caracter a caracter a nuestra aplicación de emulación de terminal (Putty, SecureCRT, Hyperterminal, teraterm, minicom para Linux o el propio xterm para linux). Telnet es un protocolo inseguro porque el tráfico se envía caracter por caracter y sin cifrar, por ello se prefiere usar SSH que usa el puerto 22 y requiere una configuración especial para que funcione dado que usa certificados para autenticar y cifrar los clientes y el mismo servidor. Ssh no sólo sirve para acceder a la consola de los dispositivos, también es la base de otros protocolos seguros como sftp, que es ftp sobre ssh. SNMP es un protocolo muy simple que nos permite recolectar información de los dispositivos, fue diseñado para administrar, es decir, se pueden hacer operaciones sobre el dispositivo, pero por carencia de mecanismos confiables de seguridad, ésta opción usualmente está deshabilitada. SNMP usa el puerto 161 y 162 de UDP.
Conclusiones y próximas publicaciones
Como ven, existe una diferencia entre la pila (stack) de protocolos OSI y TCP/IP, ésta última es la que define los protocolos que mencionamos en ésta entrada. Algunos son protocolos que permiten a un usuario efectuar acciones directamente sobre la red como ftp o telnet. Otros son protocolos auxiliares que ayudan al usuario o a otros protocolos a cumplir su propósito, por ejemplo DNS o DHCP.
Ando en un dilema con las publicaciones porque el tráfico cayó estrepitosamente, después de venir cayendo regularmente y además mi trabajo me ha absorbido. Espero poder continuar con las publicaciones aunque por mi trabajo y por interés personal, me inclino a seguir publicando sobre DevNet o programación de redes. La próxima publicación en ésta serie sobre ITN o el curso de inciación de CCNA sería sobre Seguridad de red. Si les gustó el contenido, por favor compartan y síganme en facebook, Twiter y Youtube.