PDF de programación - 1. Aplicaciones y servicios de red

1. Aplicaciones y servicios de red

Para hacer su trabajo, los clientes se conectan a los servidores de red correspondientes.
Los servidores de red Unix tienen varias formas. Un programa servidor puede escuchar

un puerto por sí mismo o a través de un servidor secundario. Además, los servidores no
tienen una base de datos de configuración común y una amplia variedad de caracterís-

ticas. La mayoría de los servidores tienen un fichero de configuración para controlar su
comportamiento (aunque sin un formato comun), y la mayoría usa el servicio syslog del
sistema para registrar los mensajes. Veremos algunos servidores comunes y herramientas

que ayudarán a entender la operación del servidor.

Los clientes de red usan las interfaces y protocolos de la capa de transporte del sistema
operativo, así que entender los fundamentos de las capas de transporte TCP y UDP es

importante. Empecemos viendo aplicaciones de red y experimentando con un cliente de
red que usa TCP.

1.1. Fundamentos de los servicios

Los servicios TCP son fáciles de entender porque estan construidos sobre un flujo de datos
simple e ininterrumpido de dos sentidos. Quizás la mejor forma de ver cómo funciona

es hablar directamente a un servidor web en el puerto TCP 80 para tener una idea de
cómo se mueven los datos a través de la conexión. Por ejemplo, ejecutando el siguiente
comando para conectar a un servidor web:

$ telnet www.wikipedia.org 80

Se debe obtener una respuesta como esta:

Trying some address...

Connected to www.wikipedia.org.

Escape character is ’^I’.

Ahora ingrese

GET / HTTP/1.0

1

Presione ENTER de nuevo. El servidor debe enviar una cantidad de texto HTML como

respuesta y después terminar la conexión.

Este ejercicio muestra que

el host remoto tiene un proceso de servidor web escuchando en el puerto TCP 80;
y

telnet era el cliente que inició la conexión.

1.1.1. Un acercamiento

En el ejemplo de arriba, se interactuó manualmente con un servidor web en la red
con telnet, usando el protocolo de transferencia de hipertexto (HTTP) en la capa de
aplicación. Aunque normalmente se usa un servidor web para hacer este tipo de conexión,

demos un paso adelante y usemos un programa de línea de comandos que conoce como
hablar a la capa de aplicación HTTP. Usaremos la utilidad curl con una opción especial

para registrar detalles sobre esta comunicación:

$ curl --trace-ascii trace_file http://www.wikipedia.org/

Obtendras mucho código HTML como resultado. Ignóralo (o redirígelo a /dev/null) y
mira el nuevo fichero creado trace_file. Asumiendo que la conexión ha sido exitosa, la

primera parte del fichero debe mostrar algo como lo siguiente, en el punto donde curl
intenta establecer la conexión TCP al servidor:

== Info: About to connect() to www.wikipedia.org port 80 (#0)

== Info: Trying 10.80.154.224... == Info: connected

Puedes ver todo lo que ocurre en la capa de transporte o debajo. No obstante, si esta
conexión se da, curl intenta enviar la petición (la cabecera); aquí es donde empieza la
capa de aplicación:

=> Send header, 167 bytes (0xa7)

0000: GET / HTTP/1.1

0010: User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS

0050: SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3

2

007f: Host: www.wikipedia.org

0098: Accept: */*

00a5:

La primera linea es el depurado de curl y el resultado cuenta que hará después. Las
otras lineas muestran lo que curl envia al servidor. El texto en negrita es lo que va al

servidor; los números hexadecimales al comienzo es un depurado desde curl para ayudar
a mantener el rastreo de cuanta información se ha enviado o recibido.

Se puede ver que curl empieza emitiendo un comando GET al servidor, servido de alguna

información extra para el servidor y una línea en blanco. Después, el servidor envía una
respuesta, primero con su propia cabecera, mostrado aqui en negrita:

<= Recv header, 17 bytes (0x11)

0000: HTTP/1.1 200 OK

<= Recv header, 16 bytes (0x10)

0000: Server: Apache

<= Recv header, 42 bytes (0x2a)

0000: X-Powered-By: PHP/5.3.10-1ubuntu3.9+wmf1

--snip --

En la mayoría del resultado previo, las líneas <= son resultados de depurado, y 0000:

precede a las líneas de resultado.

La cabecera en la respuesta del servidor puede ser un poco larga, pero en algún punto
las transiciones del servidor pasan de transmitir cabeceras a enviar el documento de la
petición actual, como esto:

<= Recv header, 55 bytes (0x37)

0000: X-Cache: cp1055 hit (16), cp1054 frontend hit (22384)

<= Recv header, 2 bytes (0x2)

0000:

<= Recv data, 877 bytes (0x36d)

0000: 008000

0008: <!DOCTYPE html>.<html lang=»mul» dir=»ltr»>.<head>.<!-- Sysops:

--snip --

3

Este resultado también ilustra una importante propiedad de la capa de aplicación. Que

el resultado de depurado muestre Recv header y Recv data, implica que hay dos tipos
diferentes de mensajes del servidor, no hay diferencia en el modo en que curl le dice al
sistema operativo que recupere los dos tipos de mensajes, no hay diferencia en el modo

en que el sistema operativo los maneja, ni tampoco hay diferencia en el modo en que
la red maneja los paquetes subyacentes. Toda la diferencia está en el espacio de usuario

de la aplicación curl. curl conoce que hasta este punto ha obtenido las cabeceras, pero
cuando recibe una línea en blanco significa el fin de las cabeceras en HTTP, usado para
interpretar cualquier cosa que siga como el documento de respuesta.

Los mismo es cierto para el servidor que envía estos datos. Mientras envia la respuesta,

el servidor no diferencia entre cabecera y documentos de datos enviados al sistema
operativo; las distinciones ocurren dentro del espacio de usuario del programa servidor.

1.2. Servidores de red

La mayoría de servidores de red son como otros demonios servidor en su sistema tal
como cron, excepto que ellos interactuan con puertos de red.

Hay algunos otros servidores de red comunes que pued hallar ejecutándose en su sistema:

hhpd, apache, apache2 Servidores web

sshd Demonio de shell segura

postfix, qmail, sendmail Servidores de correo

cupsd Servidor de impresora

nfsd, mountd Demonios de sistemas de ficheros en red (ficheros compartidos)

smbd, nmbd Demonios de ficheros compartidos en Windows

rpcbind Demonio de servicio de mapeo de puertos por procedimiento de de lla-
mado (RPC)

Una característica común para la mayoría de servidores de red es que ellos usualmente
operan como procesos múltiples. Al menos un proceso escucha en un puerto de red, y

4

cuando se recibe una nueva conexión, el proceso que escucha usa fork() para crear

un nuevo proceso hijo, el cual es responsable por la nueva conexión. El hijo, a menudo
llamado proceso trabajador, termina cuando la conexión se cierra. Mientras tanto, el
proceso original continua escuchando en el puerto de red. Este proceso permite que un

servidor maneje fácilmente varias conexiones sin mucho problema.

Sin embargo, hay varia excepciones a este modelo. Llamar a fork() agerga una sig-
nificativa cantidad de trabajo al sistema. En comparación, los servidores TCP de alto

desempeño como el servidor web Apache pueden crear un número de procesos de trabajo
en el arranque que estan listos para gestionar las conexiones que sean necesarias. Los

servidores que aceptan paquetes UDP simplemente reciben datos y reaccionan a ellos;
no tienen conexiones para escuchar.

1.3. Shell segura (SSH)

Cada servidor trabaja u poco diferente. Echemos un vistazo a uno—el servidor SSH au-
tónomo. Una de las aplicaciones de servicios de red más comunes es la shell segura (SSH),

el estándar de facto para acceso remoto a una máquina Unix. Cuando se configura, SSH
permite entradas seguras de shell, ejecución remota de programas, compartir ficheros, y
más—reemplazando a los sistemas antiguos e inseguros telnet y rlogin con clave crip-

tográfica pública para autenticación y cifrado simple para sesiones de datos. La mayoría
de proveedores de internet y nube requieren SSH para el acceso por shell a sus servicios,

y varios aparatos basados en Linux (como los dispositivos NAS) también permiten el
acceso vía SSH. OpenSSH (http://www.openssh.com/) es una implementación libre de
SSH para Unix, y casi todas las distribuciones Linux la traen preinstalada. El cliente

OpenSSH es ssh, y el servidor es sshd. Hay dos versiones principales de protocolo SSH:
1 y 2. OpenSSH soporta ambas, pero la versión 1 se usa raramente.

Entre las varias capacidades y características útiles, SSH hace lo siguiente:

Encryptar su contraseña y todas las otras sesiones de datos, protegiéndole de fis-
gones.

Túneles a otras conexiones de red, incluyendo aquellas de clientes del sistema X

Window.

Ofrece clientes para casi cualquier sistema operativo.

5

Usa claves para la autentitaciónd el host.

SSH también tiene desventajas. Por ejemplo, a fin de establecer una conexión SSH,
necesita al clave pública del host remoto, y no se obtiene necesariamente de un modo

seguro (aunque se puede verificar manualmente para asegurarse de que no está siendo
espiado).

1.3.1. El servidr SSHD

Ejecutar sshd requiere un fichero de configuración y claves de host. La mayoría de las

distribuciones mantienen su configuración en el directorio de configuración /etc/ssh
e intentar configurar todo apropiadamente para ti si instalas el paquete sshd. (Sea
cuidadoso, pues es fácil confundir el paquete sshd_config con el fichero de arranque

ssh_config)

No deberías necesitar cambiar nada en sshd_config, pero no hace daño verificar. El

fichero consiste en pares clave-valor, como se muestra en este fragmento:

Port 22

# Protocol 2,1

# ListenAddress 0.0.0.0

# ListenAdrress ::

HostKey /etc/ssh/ssh_host_key

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

Las líneas que comienzan con # son comentarios, y varios comentarios en sshd_config

pueden indicar valores por defecto. la página de manual sshd_config(5) contiene des-
cripciones de todos los posibles valores, pero estos son los más importantes:

HostKey file Usa file como una clave host.