Redes en Linux
Durante el transcurso de este tópico, veremos todos los temas relacionados con las redes en Linux, una parte importante de nuestros servicios, que puede ayudarnos a entender que está pasando dentro de nuestra red. Recordemos que podemos ver en detalle el funcionamiento de redes en el nivel básico aquí.
Table of Contents
ToggleProtocolo TCP/IP en Linux
Como es de saber, el modelo TCP/IP en Linux está representado por 4 capas: Aplicación, Transporte, Internet y Acceso a la Red.
El kernel de Linux tiene un enrutador IP y un filtro de paquetes. Cada una de las capas del modelo TCP/IP tiene tres áreas: usuario, kernel y hardware. Características fundamentales para el desarrollo de las redes en este sistema operativo. La configuración de los protocolos de redes en Linux la encontramos en /etc/protocols.
La implementación del modelo TCP/IP en Linux está fuertemente influenciada por las RFC’s (Request For Comments), aquellos documentos que hacen referencia a los requerimientos de hosts de internet y capas de comunicación, que acompañan desde los inicios el desarrollo de Internet. A su vez, TCP en redes Linux, se basa en la RFC 2001 (Inicio lento TCP, retransmisión rápida, prevención de congestión, recuperación rápida), además de agregarle varias mejoras, tales como el algoritmo NewReno y el Reconocimiento Selectivo (SACK).
Terminología TCP
Segment | Paquete TCP, por ejemplo puede ser un documento html que el servidor web divide en varias partes discretas encapsulándolas a cada una con su correspondiente encabezado |
Send Window | La cantidad de segmentos que puede recibir el host remoto |
Sequence number | Es un número que contienen todos los segmentos TCP para indicar el inicio de una conexión, o en caso de una conexión existente, identificar los paquetes recibidos |
TCB | Estructura de datos que tiene la información de la conexión |
Receive Window | La cantidad de segmentos que puede aceptar un host |
Creando Subredes
El espacio de direcciones de una red puede ser subdividido a su vez creando subredes autónomas separadas. Un ejemplo de uso es cuando necesitamos agrupar todos los empleados pertenecientes a un departamento de una empresa (por ejemplo, área de contaduría, marketing, seguridad, etc). En este caso se crea una subred que englobará las direcciones IP de éstos. Para conseguirlo hay que reservar bits del campo de host para identificar la subred estableciendo a uno los bits de red-subred en la máscara.
Por ejemplo, la dirección 172.10.0.0 con máscara 255.255.0.0 (/16) nos indica que los dos primeros bytes identifican la red (por ser una dirección de clase B), el tercer y cuarto byte identifican al host (tiene 0 los bits correspondientes dentro de la máscara). Hay dos direcciones de cada subred que quedan reservadas: Aquella que identifica la subred (todos los bits de hosts en 0) y la dirección para realizar el broadcast en la subred (todos los bits del host en 1).
Los siguientes comandos en redes Linux que veremos, son herramientas que nos facilitan la creación de subredes para nuestro trabajo. Estas son: ipcalc, sipcalc y subnetcalc.
Comando ipcalc
Supongamos que queremos dividir la red en 512 redes con la IP: 172.15.0.0 (IP clase B).
Usando la opción –s le pedimos la cantidad de host para dicha red:
# ipcalc –s 512 172.15.0.0
Tenemos como información:
Una dirección de Host (172.15.0.0).
Que es una dirección privada (clase B).
Que la máscara es 255.255.255.0 o /24 (teniendo en cuenta que es de clase B).
Que dicha red 172.15.0.0 tiene como direcciónes mínima (HostMin) la 172.15.0.1 y máxima (HostMax) en 172.15.0.254.
La dirección de Broadcast en 172.10.0.255.
Comando sipcalc
Algunas opciones más usadas con sipcalc:
-a Mostrará toda la información posible.
-b Habilita la resolución de nombres.
-s Divide a la red en subredes de acuerdo al tamaño de máscara.
# sipcalc 192.168.0.0/24
Comando subnetcalc
Este comando se utiliza exclusivamente como calculadora para direcciones de red, tanto con IPv4 como con IPv6. Veamos un ejemplo:
# subnetcalc 10.0.0.0/24
Dirección IPv6 en Linux
Recordemos que la función de una dirección IPv6 es la misma a su predecesor IPv4, pero estructurada de forma distinta. Está compuesta por 8 segmentos de 2 bytes cada uno, que suman un total de 128 bits , el equivalente a unos 3.4×1038 hosts direccionables. La ventaja, no solo con redes en Linux, con respecto a la dirección IPv4 es obvia en cuanto a su capacidad de direccionamiento. Su representación suele ser hexadecimal y para la separación de cada par de octetos se emplea el símbolo ”:”. Un bloque abarca desde 0000 hasta FFFF.
Algunas reglas acerca de la construcción de direcciones IPv6 son:
Los ceros iniciales, como en IPv4, se pueden obviar.
Ejemplo: 2005:0678:0002:00ab:0cde:4444:0007:0058 → 2005:678:2:ab:cde:4444:7:58
Los bloques contiguos de ceros se pueden comprimir empleando «::«. Sin embargo, esta operación sólo se puede hacer una vez.
Ejemplo: 2009:0:0:0:0:0:0:7 → 2009::7. No válido: 2005:0:0:0:8:0:0:3 → 2005::8::3 (debería ser 2005::5:0:0:3 ó 2005:0:0:0:8::3).
Podemos usar alguna de las calculadoras para obtener información para obtener información de direcciones IPv6:
# ipcalc 2501:3190:1033:1200:0:0:0:1
# subnetcalc 3ffe:6a88:85a3:08d3:1319:8a2e:0370:7344
Tipos y Descripción
TIPO | DESCRIPCIÓN |
::1 | Dirección de loopback. |
:: | Dirección por defecto. |
::ffff:0000:0000 | Dirección IPv4 mapeada en los últimos 8 ceros de una dirección IPv6. |
fe80:: | Direcciones de enlace local, sin enrutamiento entre redes. |
fec0:: | Sitio de dirección local, sólo para una única dirección de red. |
ff:: | Dirección Multicast |
2000:: | Direcciones globales de multidifusión enrutables. |
Servicios de Internet
Los servicios de Internet con redes en Linux usan un puerto y un protocolo de transporte determinado. El archivo /etc/services contiene todas las definiciones de puertos y aplicaciones conocidos. Veamos la siguiente imagen:
# cat /etc/services
Como podemos ver, el contenido es muy extenso. Sin embargo, podemos simplificar la salida para ver los puertos exclusivos con el siguiente comando:
# grep -E ‘[[:blank:]](20/|21/|80/|443/|27374/|30865)’ /etc/services
Comando ss
Esta herramienta forma parte del paquete llamado iproute2 (Debian) o también iproute (CentOS) con redes en Linux. La misma nos servirá para analizar el estado de las conexiones por protocolo.
Algunas opciones de este comando son:
-u Se refiere al protocolo UDP
-t Se refiere al protocolo TCP
-a Nos muestra todas las conexiones, tanto las de servicios como las que están en escucha en un puerto
-n Nos muestra la forma numérica
-p Nos da información acerca del proceso en ejecución
Veamos un ejemplo:
ss –utanp
Descripción de Columnas
COLUMNA | DESCRIPCIÓN |
Netid | Tipo de socket |
State | Estado del soccket |
Recv-Q | Depende de dos estados: Si el estado es ESTABLISHED, hace referencia al recuento de bytes no copiados por el programa de ususario conectado a dicho socket. Si el estado es LISTENING, hará referencia a al backlog de syn actual.
|
Send-Q | Si la conexión está establecida es la cantidad de bytes que aún no recibieron su correspondiente segmento con ACK activado del host remoto. Si está en LISTENING es el número máximo de la cola de segmentos SYN |
Local Address:Port | Dirección local |
Peer Address:Port | Dirección remota |
Con respecto a la columna “State”, el protocolo TCP cuenta con los siguientes estados:
LISTEN En escucha de peticiones.
ESTABLISHED Establecida.
SYN_SENT Se intentando establecer una conexión.
SYN_RECV Se recibió una petición para establecer una conexión.
FIN_WAIT1 Socket cerrado y cerrando la conexión.
FIN_WAIT2 Socket cerrado y esperando a que el host remoto cierre la conexión.
TIME_WAIT El socket está cerrado pero espera por si hay paquetes en la red (Por ejemplo, cuando uno de los extremos cerró el socket sin solcitar la finalización de la conexión).
CLOSE No se está usando el socket..
CLOSE_WAIT El host remoto cerró la conexión y se espera a que se cierre el socket
LAST_ACK Se está esperando que el host remoto acuse recibo que se desea cerrar la conexión.
CLOSING Los dos sockets están cerrados pero no se terminó de enviar todos los datos.
UNKNOWN Desconocida.
Conexión Cliente-Servidor con TCP
Por lo general, cuando dos personas se conocen, se dan la mano. Ambas culturas entienden el acto como señal de un saludo amigable. Las conexiones en la red son similares. En las conexiones TCP, el cliente del host establece la conexión con el servidor.
Una conexión TCP se establece en tres pasos:
- El cliente de origen solicita una sesión de comunicación de cliente a servidor con el servidor. Cliente SYN Servidor
El servidor reconoce la sesión de comunicación de cliente a servidor y solicita una sesión de comunicación de servidor a cliente. Servidor ACK–SYN Cliente
El cliente de origen reconoce la sesión de comunicación de servidor a cliente. Cliente ACK Servidor
Proceso de Conexión
De ahí en adelante cliente y servidor seguirán intercambiando segmentos con el bit ACK activado hasta el fin de la conexión.
Los nombres de los bits activados durante el establecimiento de la conexión, tienen que ver con la función que realizan. Estos son:
SYN : Sincronización de los números de secuencia.
ACK : Sirve para el reconocimiento (ACKnowledge) de la conexión.
Con el comando ss se pueden aplicar filtros para ver el estado de las conexiones con respecto a redes en Linux:
Ver todas las conexiones establecidas con puertos de destino 80 o 21 con dirección IP de destino 120.115.243.167:
# ss -o state established ‘( dport = :443 or dport = :993 )’ dst 120.115.243.167
Ver todas las conexiones excepto las que están como listen o closed:
# ss -o state connected
Finalización de la Conexión
Cuando el cliente no tiene más datos para enviar en la transmisión, envía un segmento con el marcador FIN establecido, pero el proceso de finalización puede ser iniciado por dos hosts cualesquiera que tengan una sesión abierta. El host Cliente entra en estado FIN_WAIT_1.
El servidor envía un ACK para reconocer el marcador FIN y terminar la sesión de cliente a servidor. El estado del host debería ser CLOSE_WAIT.
El servidor envía un FIN al cliente para terminar la sesión de servidor a cliente. El host pasa al estado LAST_ACK y el otro extremo pasa a FIN_WAIT2.
El cliente responde con un ACK para reconocer el recibo del FIN desde el servidor. Una vez reconocidos todos los segmentos, la sesión se cierra.
Otros motivos de cierre de conexión:
Si un extremo pierde su conexión a la red (por un problema de hardware por ejemplo), entonces el otro lado esperará durante un tiempo hasta cerrar la conexión.
Si un extremo envía un segmento RST durante una conexión establecida