GUIA REDES DE COMPUTADORES Y SISTEMAS DISTRIBUIDOS II CONFIGURACION DE PROTOCOLOS TCP (DNS), UDP (DHCP) E IMPLEMENTACION DE SOCKET SCTP EN SISTEMA OPERATIVO LINUX

GUIA REDES DE COMPUTADORES Y SISTEMAS DISTRIBUIDOS II
CONFIGURACION DE PROTOCOLOS TCP (DNS), UDP (DHCP) E IMPLEMENTACION DE
SOCKET SCTP
EN SISTEMA OPERATIVO LINUX
Estudiantes: Luis Espinel Fuentes.
Cod: 940613600
Yesid Alexander Madrid
Cod: 057308412
Profesor: Sergio Peñaloza.
Ingenerio de Sistemas
Universidad de Pamplona – Colombia
Facultad de Ingenieria y Arquitectura
Programa de Ingenieria de Sistemas
2015

INTRODUCCION
En informática y telecomunicación, un protocolo de comunicaciones es un sistema de reglas
que permiten que dos o más entidades de un sistema de comunicación se comuniquen entre
ellas para transmitir información por medio de cualquier tipo de variación de una magnitud
física. Se trata de las reglas o el estándar que define la sintaxis, semántica y sincronización
de la comunicación, así como también los posibles métodos de recuperación de errores. Los
protocolos pueden ser implementados por hardware, por software, o por una combinación de
ambos.
Los sistemas de comunicación utilizan formatos bien definidos (protocolo) para intercambiar
mensajes. Cada mensaje tiene un significado exacto destinado a obtener una respuesta de
un rango de posibles respuestas predeterminadas para esa situación en particular.
Normalmente, el comportamiento especificado es independiente de cómo se va a
implementar. Los protocolos de comunicación tienen que estar acordados por las partes
involucradas. Para llegar a dicho acuerdo, un protocolo puede ser desarrollado dentro de
estándar técnico. Un lenguaje de programación describe el mismo para los cálculos, por lo
que existe una estrecha analogía entre los protocolos y los lenguajes de programación: los
protocolos son a las comunicaciones como los lenguajes de programación son a los
cómputos.2 Un protocolo de comunicación, también llamado en este caso protocolo de red,
define la forma en la que los distintos mensajes o tramas de bit circulan en una red de
computadoras.
Si bien los protocolos pueden variar mucho en propósito y sofisticación, la mayoría
especifican una o más de las siguientes propiedades:
• Detección de la conexión física subyacente (con cable o inalámbrica), o la existencia
de otro punto final o nodo.
• Handshaking.

• Negociación de varias características de la conexión.
• Cómo iniciar y finalizar un mensaje.
• Procedimientos en el formateo de un mensaje.
• Qué hacer con mensajes corruptos o formateados incorrectamente (corrección de
errores).
• Cómo detectar una pérdida inesperada de la conexión, y qué hacer entonces.
• Terminación de la sesión y/o conexión.
• Estrategias para mejorar la seguridad (autenticación, cifrado).
• Cómo se construye una red física.
• Cómo los computadores se conectan a la red.
Los protocolos de comunicación permiten el flujo información entre equipos que manejan
lenguajes distintos, por ejemplo, dos computadores conectados en la misma red pero con
protocolos diferentes no podrían comunicarse jamás, para ello, es necesario que ambas
"hablen" el mismo idioma. El protocolo TCP/IP fue creado para las comunicaciones en
Internet. Para que cualquier computador se conecte a Internet es necesario que tenga
instalado este protocolo de comunicación.
En esta guía describiremos como configurar 2 protocolos de internet en sistemas Linux, estos
son protocolo TCP (Transmission Control Protocol), protocolo UDP (User Datagram Protocol)
y una implementacion de Java de un socket (servidor – cliente) de protocolo SCTP (Stream
Control Transmission Protocol).

Objetivos
• Implementar la configuracion de Protocolos TCP (Transmission Control Protocol) y
UDP (User Datagram Protocol) en Sistema Operativo Linux.
• Ejecutar una implementacion de Socket de protocolo SCTP (Stream Control
Transmission Protocol).
• Mostrar de manera detallada el proceso de configuracion y las herramientas
necesarias (Librerias y servicios) que deben estar instalados para el normal
funcionamiento de estos protocolos.

Marco Teórico
Un protocolo de red, designa el conjunto de reglas que rigen el intercambio de información a
través de una red de ordenadores. El modelo OSI de capas establece una pila de protocolos
especializados que debe ser idéntica en emisor y receptor. La mencionada pila OSI está
ordenada desde el modelo físico de la red hasta niveles abstractos como el de aplicación o
de presentación. Los protocolos de cada capa tienen una interfaz bien definida.
Generalmente, una capa se comunica con la capa inmediata inferior, la inmediata superior, y
la capa del mismo nivel en otros computadores de la red. Esta división de los protocolos
ofrece abstracción en la comunicación.
Una aplicación (capa nivel 7) por ejemplo, solo necesita conocer cómo comunicarse con la
capa 6 que le sigue, y con otra aplicación en otro computador (capa 7). No necesita conocer
nada entre las capas de la 1 a la 5. Así, un navegador web (HTTP, capa 7) puede utilizar una
conexión Ethernet o PPP (capa 2) para acceder a la Internet, sin que sea necesario cualquier
tratamiento para los protocolos de este nivel más bajo. De la misma forma, un router sólo
necesita de las informaciones del nivel de red para enrutar paquetes, sin que importe si los
datos en tránsito pertenecen a una imagen para un navegador web, un archivo transferido
vía FTP o un mensaje de correo electrónico.
Transmission Control Protocol (TCP) o Protocolo de Control de Transmisión, es uno de los
protocolos fundamentales en Internet. Fue creado entre los años 1973 y 1974 por Vint Cerf y
Robert Kahn. Muchos programas dentro de una red de datos compuesta por redes de
computadoras, pueden usar TCP para crear “conexiones” entre sí a través de las cuales
puede enviarse un flujo de datos. El protocolo garantiza que los datos serán entregados en
su destino sin errores y en el mismo orden en que se transmitieron. También proporciona un
mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a través del
concepto de puerto. TCP da soporte a muchas de las aplicaciones más populares de Internet
(navegadores, intercambio de ficheros, clientes FTP, etc.) y protocolos de aplicación HTTP,
SMTP, SSH y FTP.

Objetivos de TCP : Con el uso de protocolo TCP, las aplicaciones pueden comunicarse en
forma segura (gracias al de acuse de recibo -ACK- del protocolo TCP) independientemente
de las capas inferiores. Esto significa que los routers (que funcionan en la capa de Internet)
sólo tiene que enviar los datos en forma de datagrama, sin preocuparse con el monitoreo de
datos porque esta función la cumple la capa de transporte (o más específicamente el
protocolo TCP).
TCP es usado en gran parte de las comunicaciones de datos. Por ejemplo, gran parte de las
comunicaciones que tienen lugar en Internet emplean TCP.
Funciones de TCP: En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el
protocolo de internet (IP) y la aplicación. Muchas veces las aplicaciones necesitan que la
comunicación a través de la red sea confiable. Para ello se implementa el protocolo TCP que
asegura que los datos que emite el cliente sean recibidos por el servidor sin errores y en el
mismo orden que fueron emitidos, a pesar de trabajar con los servicios de la capa IP, la cual
no es confiable. Es un protocolo orientado a la conexión, ya que el cliente y el servidor deben
de anunciarse y aceptar la conexión antes de comenzar a transmitir los datos a ese usuario
que debe recibirlos.
Características de TCP:
• Permite colocar los datagramas nuevamente en orden cuando vienen del protocolo IP.
• Permite el monitoreo del flujo de los datos y así evita la saturación de la red.
• Permite que los datos se formen en segmentos de longitud variada para "entregarlos"
al protocolo IP.
• Permite multiplexar los datos, es decir, que la información que viene de diferentes
fuentes (por ejemplo, aplicaciones) en la misma línea pueda circular simultáneamente.
• Por último, permite comenzar y finalizar la comunicación amablemente.

Negociación en tres pasos o Three-way handshake
Las conexiones TCP se componen de tres etapas:
• establecimiento de conexión,
• transferencia de datos, y
• fin de la conexión.
Para establecer la conexión se usa el procedimiento llamado “negociación en tres pasos” (3-
way handshake). Para la desconexión se usa una “negociación en cuatro pasos” (4-way
handshake). Durante el establecimiento de la conexión, se configuran algunos parámetros
tales como el número de secuencia con el fin de asegurar la entrega ordenada de los datos y
la robustez de la comunicación.

User Datagram Protocol (UDP) es un protocolo del nivel de transporte basado en el
intercambio de datagramas (Encapsulado de capa 4 Modelo OSI). Permite el envío de
datagramas a través de la red sin que se haya establecido previamente una conexión, ya que
el propio datagrama incorpora suficiente información de direccionamiento en su cabecera.
Tampoco tiene confirmación ni control de flujo, por lo que los paquetes pueden adelantarse
unos a otros; y tampoco se sabe si ha llegado correctamente, ya que no hay confirmación de
entrega o recepción. Su uso principal es para protocolos como DHCP, BOOTP, DNS y demás
protocolos en los que el intercambio de paquetes de la conexión/desconexión son mayores, o
no son rentables con respecto a la información transmitida, así como para la transmisión de
audio y vídeo en real, donde no es posible realizar retransmisiones por los estrictos requisitos
de retardo que se tiene en estos casos. User Datagram Protocol (UDP) es un protocolo
mínimo de nivel de transporte orientado a mensajes documentado en el RFC 768 de la IETF.
En la familia de protocolos de Internet UDP proporciona una sencilla interfaz entre la capa de
red y la capa de aplicación. UDP no otorga garantías para la entrega de sus mensajes (por lo
que realmente no se debería encontrar en la capa 4) y el origen UDP no retiene estados de
los mensajes UDP que han sido enviados a la red. UDP sólo añade multiplexado de
aplicación y suma de verificación de la cabecera y la carga útil. Cualquier tipo de garantías
para la transmisión de la información deben ser implementadas en capas superiores.
Puertos: UDP utiliza puertos para permitir la comunicación entre aplicaciones. El campo de
puerto tiene una longitud de 16 bits, por lo que el rango de valores válidos va de 0 a 65.535.
El puerto 0 está reservado, pero es un valor permitido como puerto origen si el proceso
emisor no espera recibir mensajes como respuesta.
• Los puertos 1 a 1023 se llaman puertos "bien conocidos" y en sistemas operativos tipo
Unix enlazar con uno de estos puertos requiere acceso como superusuario.
• Los puertos 1024 a 49.151 son puertos registrados.
• Los puertos 49.152 a 65.535 son puertos efímeros y son utilizados como puertos
temporales, sobre todo por los clientes al comunicarse con los servidores.

La mayoría de las aplicaciones claves de Internet utilizan el protocolo UDP, incluyendo: el
Sistema de Nombres de Dominio (DNS), donde las consultas deben ser rápidas y solo
contaran de una sola solicitud, luego de un paquete único de respuesta, el Protocolo de
Administración de Red (SNMP), el Protocolo de Información de Enrutamiento (RIP) y el
Protocolo de Configuración dinámica de host (DHCP).
Características de UDP:
Las características principales de este protocolo son:
1. Trabaja sin conexión, es decir que no emplea ninguna sincronización entre el origen y el
destino.
2. Trabaja con paquetes o datagramas enteros, no con bytes individuales como TCP. Una
aplicación que emplea el protocolo UDP intercambia información en forma de bloques de
bytes, de forma que por cada bloque de bytes enviado de la capa de aplicación a la capa de
transporte, se envía un paquete UDP.
3. No es fiable. No emplea control del flujo ni ordena los paquetes.
4. Su gran ventaja es que provoca poca carga adicional en la red ya que es sencillo y emplea
cabeceras muy simples.
5. Un paquete UDP puede ser fragmentado por el protocolo IP para ser enviado fragmentado
en varios paquetes IP si resulta necesario.
6. Puesto que no hay conexión, un paquete UDP admite utilizar como dirección IP de destino
la dirección de broadcast o de multicast de IP. Esto permite enviar un mismo paquete a varios
destinos.
Comparación entre UDP Y TCP:
UDP: proporciona un nivel de transporte no fiable de datagramas, ya que apenas añade la
información necesaria para la comunicación extremo a extremo al paquete que envía al nivel
inferior. Lo utilizan aplicaciones como NFS (Network File System) y RCP (comando para
copiar ficheros entre ordenadores remotos), pero sobre todo se emplea en tareas de control y
en la transmisión de audio y vídeo a través de una red. No introduce retardos para establecer
una conexión, no mantiene estado de conexión alguno y no realiza seguimiento de estos
parámetros. Así, un servidor dedicado a una aplicación particular puede soportar más
clientes activos cuando la aplicación corre sobre UDP en lugar de sobre TCP.

TCP: es el protocolo que proporciona un transporte fiable de flujo de bits entre aplicaciones.
Está pensado para poder enviar grandes cantidades de información de forma fiable,
liberando al programador de la dificultad de gestionar la fiabilidad de la conexión
(retransmisiones, pérdida de paquetes, orden en el que llegan los paquetes, duplicados de
paquetes...) que gestiona el propio protocolo. Pero la complejidad de la gestión de la
fiabilidad tiene un coste en eficiencia, ya que para llevar a cabo las gestiones anteriores se
tiene que añadir bastante información a los paquetes que enviar. Debido a que los paquetes
para enviar tienen un tamaño máximo, cuanta más información añada el protocolo para su
gestión, menos información que proviene de la aplicación podrá contener ese paquete (el
segmento TCP tiene una sobrecarga de 20 bytes en cada segmento, mientras que UDP solo
añade 8 bytes). Por eso, cuando es más importante la velocidad que la fiabilidad, se utiliza
UDP. En cambio, TCP asegura la recepción en destino de la información para transmitir.
Stream Control Transmission Protocol (SCTP) es un protocolo de comunicación de capa
de transporte que fue definido por el grupo SIGTRAN de IETF en el año 2000. El protocolo
está especificado en la RFC 2960, y la RFC 3286 brinda una introducción al mismo. SCTP es
una alternativa a los protocolos de transporte TCP y UDP pues provee confiabilidad, control
de flujo y secuenciación como TCP. Sin embargo, SCTP opcionalmente permite el envío de
mensajes fuera de orden y a diferencia de TCP, SCTP es un protocolo orientado al mensaje
(similar al envío de datagramas UDP).
Las ventajas de SCTP son:
• Capacidad de Multihoming, en la cual uno (o dos) de los extremos de una asociación
(conexión) pueden tener más de una dirección IP. Esto permite reaccionar en forma
transparente ante fallos en la red.
• Entrega de los datos en trozos que forman parte de flujos independientes y paralelos
eliminando así el problema de head of the line blocking que sufre TCP.
• Es capaz de seleccionar y monitorizar caminos, seleccionando un camino "primario" y
verificando constantemente la conectividad de cada uno de los caminos alternativos.
• Mecanismos de validación y asentimiento como protección ante ataques por
inundación, proveyendo notificación de trozos de datos duplicados o perdidos.

SCTP fue diseñado inicialmente por el grupo Sigtran para transportar señalización telefónica
SS7 sobre IP. La intención fue la de proveer en IP de algunas de las características de
confiabilidad de SS7. Por su versatilidad luego se ha propuesto utilizarlo en otras áreas,
como por ejemplo para transportar mensajes de los protocolos DIAMETER o SIP. Al igual que
TCP, SCTP tiene un mecanismo de Fast Retransmit el cual consiste en optimizar el
rendimiento ante pérdidas aisladas.
Características:
SCTP es una alternativa a los protocolos de transporte TCP y UDP pues provee
confiabilidad, control de flujo y secuenciación como TCP. Sin embargo, SCTP opcionalmente
permite el envío de mensajes fuera de orden y a diferencia de TCP, SCTP es un protocolo
orientado al mensaje (similar al envío de datagramas UDP).
Soporte de multihoming Soporte de multistreaming Orientado a la coneccion Delimitadores
de mensajes Provee servicio de mensaje no ordenados y confiables (Ordering) Mecanismos
de validación y asentimiento como protección ante ataques por inundación, proveyendo
notificación de trozos de datos duplicados o perdidos. Entrega de los datos en trozos que
forman parte de flujos independientes y paralelos —eliminando así el problema de head of
the line blocking que sufre TCP.
Estructura del Paquete:
Los paquetes SCTP tienen una estructura básica más simple que los paquetes TCP. Cada
uno consiste en dos secciones básicas: La cabecera común, que ocupa los primeros 12
bytes y está resaltado en azul, y Los fragmentos de datos, que ocupan la parte restante del
paquete. El primer fragmento se resalta en verde, y el último de N trozos se resalta en rojo.
Cada fragmento tiene un identificador de tipo que es un byte de largo rendimiento, como
máximo, 255 tipos diferentes trozo. RFC 4960 define una lista de tipos de trozo y
actualmente hay 15 tipos definidos. El resto de la porción es de una longitud de dos bytes y
los datos. Si el trozo no forma un múltiplo de 4 bytes a continuación, se rellena con ceros
implícitamente que no están incluidos en la longitud trozo.establece una conexión desde un
punto de entrada hacia el dispositivo de entrega.

Diferencia entre SCTP Y TCP:
• SCTP utiliza cookies durante el four-way handshake evitando ataques SYN flooding.
• SCTP permite la transferencia multihoming y multistream.
• SCTP permite el envío de datos fuera de orden.
• SCTP no permite el cierre en un solo sentido.
SCTP está implementado en los siguientes sistemas operativos:
• Linux 2.4 y 2.6
• Sun Solaris 10
• FreeBSD de forma nativa desde 7.0 RELEASE
• QNX Neutrino Realtime OS

Procedimiento:
Configuracion de Servidor DNS (TCP) en Linux Mint 17
Este proceso vamos a instalar el servidor DNS BIND9, que es un Servidor DNS, disponible
en muchas versiones y Distros de Linux como Debian, OpenSuse, etc, y que además brinda
gran flexibilidad con este servicio y que es bastante estable.
Entramos a una terminal (para abrir la terminal Ctrl + alt + t) y accedemos como
superusuario. Para instalar BIND9, debemos tener instalado el paquete dnsutils, que por lo
general se instala automaticamente en los Sistemas Operativos Linux, si no es asi lo
podemos instalar con la siguiente orden en la terminal :
sudo apt-get install dnsutils
Ya teniendo este paquete en nuestra Librería, podemos acceder a instalar BIND9 ademas
instalamos resolvconf para el caso de que nuestro equipo tambien sea un cliente dns:
sudo apt-get install bind9 resolvconf
Todos los archivos de configuración se encuentran en /etc/bind desde una terminal nos
ubicamos en /etc/bind:
cd /etc/bind
Estando en esta carpeta, vamos primero a configurar el archivo named.conf.options, lo
abrimos con cualquier editor, en nuestro caso lo editaremos con nano:
nano named.conf.options
Alli lo que vamos a hacer es configurar DNS externos por lo general se colocan los de google
que son gratuitos , en los casos que nuestro servidor no pueda encontrar a un equipo:
Esto lo hacemos en la parte de forwarders, no hay que olvidar descomentar las lineas
pertenecientes a este bloque de instrucciones.
Nos debería quedar algo como esto:

Luego de esto vamos a configurar las zonas (Directa e Inversa) de nuestro servidor DNS,
esto lo haremos desde el archivo named.conf.local, lo abrimos con algun editor y pondremos
la siguiente configuracion:

Podemos observar la zona directa tiene el nombre de “redes2.local”, el servidor lo
declaramos de tipo maestro (type master) ya que va a atender todas los equipos de la red.
En la linea fyle le ponemos la dirección entre comillas del archivo donde va a estar la
configuración de la zona directa, que aun no lo hemos declarado. Lo mismo hacemos con la
zona inversa, los nombres puestos en este ejercicio han seguido la notación general para
este tipo de archivos.
Luego procedemos a crear los archivos de zona directa, en nuestro caso el archivo
db.redes2.local y lo editamos, esto deberia quedar algo asi:
Agregamos una linea con $ORIGIN nombre_red.
Debemos tener cuidado en algunos apectos, como por ejemplo en la parte inicial del archivo
debe ir de la siguiente manera
@ IN SOA nombre_del_host.nombre_red root.nombre_red
donde el nombre del host, es el nombre del servidor, es decir nuestra PC. (Lo podemos saber
ingresando el comando hostname en una terminal), en el bloque que viene dentro de las
llaves que siguen, la configuración la podemos copiar del archivo que ofrece bind9 dentro de

su carpeta, el archivo de llama db.0
Luego de esto en el mismo archivo debemos configurar el servidor principal:
@ IN NS nombre_servidor.nombre_red.
En nuestro caso:
@ IN NS luigy-VirtualBox.redes2.local.
Ahora ponemos la dirección de nuestro servidor, es decir la ip de nuestra pc (la asignación de
ip debe estar estática en nuestro pc):
@ IN A direccion_ip
para nuestro caso:
@ IN A 10.0.2.10
y le damos el nombre como sigue :
luigy-VirtualBox IN A 10.0.2.10
Luego procedemos a asignar nombres a las posibles maquinas que se conectaran a nuestra
red según la ip. Ejemplo:
maquina1 IN A 10.0.2.11
maquina1 es el nombre que se le dara al pc que se conecte a nuestra red y tenga la ip =
10.0.2.11.
Luego de nombrar cada pc según la ip de la misma, podemos poder un alias a nuestro
servidor:
alias IN CNAME nombre_servidor.
Esa seria la configuración principal de la zona directa.

Ahora pasaremos a la zona inversa:
Recordemos que el archivo de la zona inversa en nuestro caso la llamamos:
db.2.0.10.in-addr.arpa
Esto tratando de seguir la nomenclatura de este tipo de archivos.
Para no empezar desde cero, podemos copiar el contenido del archivo db.127 que viene por
default en la carpeta bind, una vez copiado eso podemos proceder a modificarlo, En nuestro
caso quedara asi:
En este caso agregamos una linea que contenga:
$ORIGIN tres_octetos_red.in-addr.arpa.
Los tres_octetos hacen referencia a los tres primeros octetos de la dirección ip de la red,
puestos en posición inversa, en nuestro caso la ip del servidor es:
10.0.2.10 entonces los tres primeros octetos son 10.0.2 y en posición inversa quedan:

2.0.10
Lo que le sigue es, solo por cuestiones de generalidades de los archivos (in-addr.arpa.).
La linea que sigue debe ser:
@ IN SOA nombre_host.nombre_red. root.nombre_red
la configuración que esta en las llaves la dejamos como está.
Luego procedemos a configurar el servidor principal, agregamos una linea que debe
contener:
@ IN NS nombre_host.nombre_red.
En otra linea empezamos a escribir el ultimo octeto de la ip de los clientes seguido de IN PTR
y luego el nombre del cliente en nuestra red.
ultimo_octeto IN PTR nombre_pc_en_red.
Ejemplo: para nuestro servidor que la dirección es 10.0.2.10 esta linea quedaría:
10 IN PTR luigy-VirtualBox.redes2.local.
Eso mismo debemos hacer para cada uno de los pc que estarán en nuestra red, teniendo en
cuenta solo el ultimo octeto de la ip de los mismos.
Ahora solo falta editar el archivo resolv.conf
Es necesario configurar correctamente el archivo /etc/resolv.conf para poder resolver los
nombres de los servidores en Internet. Aquí se muestra un ejemplo de configuración de este
archivo:
domain redes2.local
nameserver 10.0.2.10
Luego de eso podemos reiniciar el servicio de bind9:
service bind9 restart
No nos debe arrojar ningun error.
Nota: los clientes deben tener una ip que nuestro servidor DNS reconozca, es decir que
hallamos editado en los archivos, además deben tener configurado el servidor DNS (la ip de
nuestro servidor). Esto se puede hacer de manera gráfica sin ninguna complicación.

Configuracion de DHCP en Linux mint 17:
DHCP (siglas en inglés de Dynamic Host Configuration Protocol, en español «protocolo de
configuración dinámica de host») es un protocolo de red que permite a los clientes de una
red IP obtener sus parámetros de configuración automáticamente. Se trata de un protocolo
de tipo cliente/servidor en el que generalmente un servidor posee una lista de direcciones IP
dinámicas y las va asignando a los clientes conforme éstas van quedando libres, sabiendo en
todo momento quién ha estado en posesión de esa IP, cuánto tiempo la ha tenido y a quién
se la ha asignado después.
Esquema de una sesión típica DHCP.
Para este caso vamos a instalar el servidor DHCP3, que nos ofrecera el servicio de dhcp nos
hacer mas facil la configuracion del mismo.
Lo primero sera entrar a una terminal y acceder como superusuario, con esto instalamos el
servidor dhcp3:
apt-get install dhcp3-server
esto instala todos los paquetes necesario para el servicio dhcp.
Ahora accedemos a la carpeta donde están los archivos de configuración del dhcp3-server,
esta carpeta se encuentra en /etc/dhcp, accedemos desde la terminal con:
cd /etc/dhcp/

dentro de esta carpeta se encuentra un archivo llamado dhcpd.conf, este archivo lo
editaremos, lo abrimos con un editor de texto, alli nos vamos a la parte del archivo que dice
que tiene la siguiente linea:
# A slightly different configuration for an internal subnet.
En esta parte descomentaremos el bloque que le sigue a la linea, en esta parte tendremos
que poner las características de nuestra red, y nuestro servidor.
subnet ip_nustra_red netmask mascara_nuestra_red {
range ip_minima ip_maxima; // ← rango de ip a asignar por nuestro servidor
option domain-name-servers ip_nuetro_servidor;
option domain-name "nombre_red";
option r outers ip_nuestro_servidor;
option broadcast-address broabcast;
default-lease-time 600;

max-lease-time 7200;
}
Para nuesto caso este bloque quedaria asi:
subnet 10.0.0.0 netmask 255.0.0.0 {
range 10.0.2.11 10.0.2.20; // ← el rango de ip va desde la 10.0.2.11 a la 10.0.2.20
option domain-name-servers 10.0.2.10;
option domain-name "redes2"; // ← nombre de nuestra red (el nombre que se quiera)
option routers 10.0.2.10;
option broadcast-address 10.255.255.255;
default-lease-time 600;
max-lease-time 7200;
}
Luego de esto, en el mismo archivo vamos a agregar los host (huéspedes) es decir los pc
que se pueden conectar a nuestra red, teniendo en cuenta la direccion MAC del dispositivo.
Para esto agregaremos bloques de codigo como sigue:
host nombre_maquina {
hardware ethernet direccion_mac;
fixed-address ip_a_asignar;
}
Por ejemplo en nuestro caso agregamos un host con las siguientes caracteristicas:
host maquina1 {
hardware ethernet DC:0E:A1:45:94:29;
fixed-address 10.0.2.11;
}
si deseamos agregar mas host, solo debemos agregar mas bloques de este tipo.
Nota: la dirección mac, debe corresponder a la dirección mac del dispositivo conectado a la
red.

Realizado todo este proceso vamos a editar el archivo isc-dhcp-server, que se encuentra en
la carpeta /etc/default/. Aca lo que hacemos es en la linea que dice INTERFACES=” ”, donde
descomentaremos la linea y colocaremos el nombre de la interfaz de red de nuestra red, en
nuestro caso es eth0 :
Nota: para ver el nombre de su interfaz de red desde una terminal introduzca ifconfig.
Solo queda correr el servicio, desde una terminal tecleamos:
/etc/init.d/isc-dhcp-server start
Nota: los pc's o dispositivos que se conectaran a nuestra red, no deben tener ninguna
configuracion adicional.

Implementacion de socket sctp en Linux Mint 17:
Stream Control Transmission Protocol (SCTP) es un protocolo de comunicación de capa de
transporte que fue definido por el grupo SIGTRAN de IETF en el año 2000. El protocolo está
especificado en la RFC 2960, y la RFC 3286 brinda una introducción al mismo.
SCTP es una alternativa a los protocolos de transporte TCP y UDP pues provee
confiabilidad, control de flujo y secuenciación como TCP. Sin embargo, SCTP opcionalmente
permite el envío de mensajes fuera de orden y a diferencia de TCP, SCTP es un protocolo
orientado al mensaje (similar al envío de datagramas UDP).
En este ejemplo, necesitaremos dos librerías que nos ofrecen los sistema Linux:
- lksctp-tools y – libsctp1
Para instalarlo abrimos una terminal y tecleamos:
sudo apt-get install lksctp-tools
y
sudo apt-get install libsctp1
Esto nos permitirá correr sockets de protocolos sctp.
Tomamos un socket sctp (servidor,cliente), en este ejemplo lo tomamos de:
http://www.oracle.com/technetwork/articles/javase/index-139946.html
Este ejemplo demuestra la característica de transmisión múltiple de SCTP implementado en
JAVA. El servidor implementa un tipo de protocolo durante el día. Envía la fecha hora actual
en formato de EE.UU. Inglés en un arroyo y en francés en otro. El manejo de errores se
omite para hacer el código más legible.

El codigo para el Servidor:
public class DaytimeServer {
static int SERVER_PORT = 3456;
static int US_STREAM = 0;
static int FR_STREAM = 1;
static SimpleDateFormat USformatter = new SimpleDateFormat(
"h:mm:ss a EEE d MMM yy, zzzz", Locale.US);
static SimpleDateFormat FRformatter = new SimpleDateFormat(
"h:mm:ss a EEE d MMM yy, zzzz", Locale.FRENCH);
public static void main(String[] args) throws IOException {
SctpServerChannel ssc = SctpServerChannel.open();
InetSocketAddress serverAddr = new InetSocketAddress(SERVER_PORT);
ssc.bind(serverAddr);
ByteBuffer buf = ByteBuffer.allocateDirect(60);
CharBuffer cbuf = CharBuffer.allocate(60);
Charset charset = Charset.forName("ISO-8859-1");
CharsetEncoder encoder = charset.newEncoder();
while (true) {
SctpChannel sc = ssc.accept();
/* get the current date */
Date today = new Date();
cbuf.put(USformatter.format(today)).flip();
encoder.encode(cbuf, buf, true);
buf.flip();
/* send the message on the US stream */
MessageInfo messageInfo = MessageInfo.createOutgoing(null,
US_STREAM);
sc.send(buf, messageInfo);
/* update the buffer with French format */
cbuf.clear();
cbuf.put(FRformatter.format(today)).flip();
buf.clear();
encoder.encode(cbuf, buf, true);
buf.flip();
/* send the message on the French stream */
messageInfo.streamNumber(FR_STREAM);
sc.send(buf, messageInfo);

cbuf.clear();
buf.clear();
sc.close();
}
}
}
Codigo para el cliente:
public class DaytimeClient {
static int SERVER_PORT = 3456;
static int US_STREAM = 0;
static int FR_STREAM = 1;
public static void main(String[] args) throws IOException {
InetSocketAddress serverAddr = new InetSocketAddress("10.0.2.10",
SERVER_PORT);
ByteBuffer buf = ByteBuffer.allocateDirect(60);
Charset charset = Charset.forName("ISO-8859-1");
CharsetDecoder decoder = charset.newDecoder();
SctpChannel sc = SctpChannel.open(serverAddr, 0, 0);
/* handler to keep track of association setup and termination */
AssociationHandler assocHandler = new AssociationHandler();
/* expect two messages and two notifications */
MessageInfo messageInfo = null;
do {
messageInfo = sc.receive(buf, System.out, assocHandler);
buf.flip();
if (buf.remaining() > 0 &&
messageInfo.streamNumber() == US_STREAM) {
System.out.println("(US) " + decoder.decode(buf).toString());
} else if (buf.remaining() > 0 &&
messageInfo.streamNumber() == FR_STREAM) {
System.out.println("(FR) " + decoder.decode(buf).toString());
}
buf.clear();
} while (messageInfo != null);
sc.close();
}
static class AssociationHandler
extends AbstractNotificationHandler<printstream>

{
public HandlerResult handleNotification(AssociationChangeNotification not,
PrintStream stream) {
if (not.event().equals(COMM_UP)) {
int outbound = not.association().maxOutboundStreams();
int inbound = not.association().maxInboundStreams();
stream.printf("New association setup with %d outbound streams" +
", and %d inbound streams.n", outbound, inbound);
}
return HandlerResult.CONTINUE;
}
public HandlerResult handleNotification(ShutdownNotification not,
PrintStream stream) {
stream.printf("The association has been shutdown.n");
return HandlerResult.RETURN;
}
}
}
Al estar corriendo el servicio servidor, y correr el cliente se obtiene la salida:
>: java DaytimeClient
New association setup with 32 outbound streams, and 32 inbound streams.
(US) 4:00:51 PM Fri 15 May 09, British Summer Time
(FR) 4:00:51 PM ven. 15 mai 09, Heure d'ete britannique
The association has been shutdown.

Conclusiones:
• Los protocolos de red implementados en los equipos, facilitan el entendimiento entre
estos, haciendo que la comunicación entre ellos sea posible sin importar mucho el
canal de transmisión.
• El servicio de DNS asocia información variada con nombres de dominios asignado a
cada uno de los participantes. Su función más importante, es traducir (resolver)
nombres inteligibles para las personas en identificadores binarios asociados con los
equipos conectados a la red, esto con el propósito de poder localizar y direccionar
estos equipos tanto localmente como mundialmente.
• DHCP Es un protocolo que permite que un equipo conectado a una red pueda obtener
su configuración (principalmente, su configuración de red) en forma dinámica (es decir,
sin intervención particular). Sólo tiene que especificarle al equipo, mediante DHCP,
que encuentre una dirección IP de manera independiente. El objetivo principal es
simplificar la administración de la red.
• SCTP es un protocolo de capa de transporte fiable orientado a la conexión que ofrece
los mismos servicios a las aplicaciones que TCP. Además, SCTP admite conexiones
entre sistema que tienen más de una dirección, o de host múltiple. La conexión SCTP
entre el sistema transmisor y receptor se denomina asociación. Los datos de la
asociación se organizan en bloques. Dado que el protocolo SCTP admite varios hosts,
determinadas aplicaciones, en especial las que se utilizan en el sector de las
telecomunicaciones, necesitan ejecutar SCTP en lugar de TCP.

Bibliografía:
TCP
http://www.taringa.net/post/linux/10272389/Configurar-servidor-DNS-en-Linux.html
http://www.ite.educacion.es/formacion/materiales/85/cd/linux/m2/servidor_dns_bind9.html
http://www.alcancelibre.org/staticpages/index.php/como-dns
DHCP
https://www.youtube.com/watch?v=AbR3bYE5S3A
http://es.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
http://www.ite.educacion.es/formacion/materiales/85/cd/linux/m2/servidor_dhcp.html
SCTP
http://www.oracle.com/technetwork/articles/javase/index-139946.html
http://es.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
http://searchnetworking.techtarget.com/definition/SCTP

GUIA REDES DE COMPUTADORES Y SISTEMAS DISTRIBUIDOS II CONFIGURACION DE PROTOCOLOS TCP (DNS), UDP (DHCP) E IMPLEMENTACION DE SOCKET SCTP EN SISTEMA OPERATIVO LINUX

Más contenido relacionado

La actualidad más candente (20)

Similar a GUIA REDES DE COMPUTADORES Y SISTEMAS DISTRIBUIDOS II CONFIGURACION DE PROTOCOLOS TCP (DNS), UDP (DHCP) E IMPLEMENTACION DE SOCKET SCTP EN SISTEMA OPERATIVO LINUX (20)

Último (20)

GUIA REDES DE COMPUTADORES Y SISTEMAS DISTRIBUIDOS II CONFIGURACION DE PROTOCOLOS TCP (DNS), UDP (DHCP) E IMPLEMENTACION DE SOCKET SCTP EN SISTEMA OPERATIVO LINUX