#4sysadmins

Inicio » LPIC-1 Capítulo 8

LPIC-1 Capítulo 8

EN ESTE CAPÍTULO SE ABARCAN LOS SIGUIENTES OBJETIVOS DEL EXAMEN:

  • 109.1: Fundamentos de los protocolos de Internet (4)
  • 109.2: Configuración básica de redes (4)
  • 109.3: Resolución de problemas básicos de red (4)
  • 109.4: Configuración DNS en el lado del cliente (2)

Configuración básica de redes TCP/IP

La mayoría de los sistemas Linux están conectados a una red, ya sea como máquinas clientes, servidores o ambos a la vez. Es por ello necesario saber como configurar las herramientas básicas de red, de manera que sea posible mantener comunicaciones con el exterior.

Una red a parte de estar formada por máquinas clientes y servidoras, consta de una serie de dispositivos que deben estar interconectados como son los routers, switch, hubs, modems, hardware, radioenlaces y/o telefonía IP, además de servicios y programas.

Un esquema de red básico donde se usan PCs clientes, servidor, switch o hub y router con conexión al exterior,  podría ser el siguiente:

EsquemaLAN

Nota: En la red de la imagen se ha utilizado un switch y no hub. Los hub redirigen todo el tráfico entre todos los ordenadores, mientras que los switch son lo bastante inteligentes como para enviar paquetes solo al destino pertinente, además los hub sólo permiten una transmisión semidúplex (como la usada por los walkie-talkies, mientras uno envía mensaje el otro extremo solo escucha), por el contrario, los switch usan conexiones dúplex, en la que ambas partes pueden enviar información al mismo tiempo. Estas características hacen superiores a los switch frente a los hubs.

Para que todos estos dispositivos, servicios y programas puedan mantener ‘conversaciones‘ inteligibles y fluidas por todos ellos, debe de existir una serie de ‘normas‘ y estándares de construcción y comunicación. Serán los protocolos las reglas que utilice la red para hacer posible las comunicaciones.

Actualmente, el estańdar de la industria en redes es un conjunto o pila de protocolos denominado TCP/IP
(Transmission Control Protocol/Internet Procotol, Protocolo de control de Transmisión/Protocolo de Internet) formado por una serie  de capas o niveles que resuelven tareas relacionadas con la transmisión de datos y proporcionan un servicio bien definido a los niveles mas altos. Los niveles mas altos son los mas cercanos al usuario y tratan con datos mas abstractos, dejando a los niveles más bajos la labor de traducir los datos de forma que sean físicamente manipulables.

Supongamos la transferencia de datos de un ordenador a otro, un archivo por ejemplo. Lo primero será disponer de una aplicación cliente con la que enviar el archivo, esta aplicación puede encontrarse en la capa superior de la pila de protocolos. Las capas consecutivas harán entre otras cosas que el archivo sea dividido en bloques de datos conocidos como paquetes a los que se le añadirá cierta información y serán encapsulados y enviados por separado permitiendo por ejemplo que si un paquete se pierde o corrompe se pueda reenviar solo el paquete específico en vez del archivo completo. El sistema receptor deberá de desemcapsular estos paquetes para recomponer el archivo de origen.

Nota: Es algo normal que en las transferencias se retrasen o pierdan paquetes, es por ello que muchos protocolos de red incluyen procedimientos para la detección de errores.

Existen varios tipos de paquetes e incluso algunos se pueden almacenar dentro de otros. Ethernet incluye su propio tipo de paquete conocido como frame, por lo que aquellos paquetes generados por protocolos de red que se ejecuten sobre Ethernet se almacenarán dentro de estos frames para ser transportados.

En las próximas secciones estudiaremos la pila TCP/IP de una forma mas detallada. De momento será indispensable que conozcamos el hardware de red así como sus funciones básicas.

 

El hardware de red

El hardware de red está diseñado para permitir que dos o mas ordenadores se comuniquen entre sí, es por ello que en cada punto de la comunicación será necesario un dispositivo que permita la entrada y salida de mensajes. La mayoría de ordenadores cuentan con interfaces de red integradas en su placa base, tarjetas de red internas (PCI o PCIe) o externas como las USB.

Linux admite varios tipos habituales de hardware de red, entre los que destacan las tarjetas Ethernet y las utilizadas para las conexiones inalámbricas (Wi-Fi).

 

Ethernet

Las conexiones vía Ethernet se realizan mediante cableado de par trenzado (lo que evita las interferencias) llamado UTP. Las conexiones Ethernet se presentan en varias velocidades de transmisión siendo las mas comunes en redes locales las 10Base-T o 100Base-T (10 Mbits/s o Mbps y 100Mbps) para las que se suelen utilizar el cableado UTP de categoría 5 o 5e (UTP Cat 5 o 5e). Otros estándares emergente de gran velocidad son los de 1000Base-T (1.000Mbps o conocido como Gigabit Ethernet) y 10 gigabits, para los que se suele utilizar cableado UTP Cat 5e o cables ópticos.

 

Wi-Fi

Para las conexiones Wi-Fi se utilizan los protocolos inalámbricos siendo los mas habituales:

  • 802.11b cuya velocidad para la cual está diseñado es de 11Mbps
  • 802.11a y 802.11g que trabajan a una velocidad de 54 Mbps teórica
  • 802.11n el cual es el más rápido con una velocidad de hasta 300Mbps

A excepción del protocolo 802.11a raramente utilizado, el resto son compatibles entre ellos, utilizándose siempre el más lento de entre los detectados en la red.

Advertencia: Si utiliza redes inalámbricas, debemos de asegurarnos de usar encriptación sobre la clave de acceso a la red mediante los protocolos WPA (Wi-Fi Protected Access, Acceso protegido a red inalámbrica) o preferiblemente WAP2. La encriptación WEP (Wired Equivalent Privacy) es mas débil  y superada con facilidad.

 

Otros tipos de hardware de red

  • Token Ring: Anteriormente usado en redes IBM
  • LocalTalk: Diseñado para la comunicación entre los primeros Macintosh
  • FDDI (Fiber Distributed Data Interface, Interfaz de datos distribuidos por fibra), HIPPI (High-Performance Parallel Interface, Interfaz en paralelo de alto rendimiento) y Fibre Channel: Interfaces de alta velocidad utilizadas en aplicaciones de alto rendimiento, por ejemplo, para interconectar edificios que están a muchos metros de distancia e incluso Kilómetros como pueden ser las centrales de telefonía y armarios de subrepartición.

 

Pilas de protocolos de red

Una pila de protocolo es un conjunto de programas que convierten y encapsulan datos entre capas de abstracción. La pila puede ir desde una capa superior que por ejemplo trabaja con un programa cliente, como podría ser Filezilla (un programa para transferencias mediante el protocolo FTP) hasta capas mas inferiores donde podríamos encontrar el controlador de la propia tarjeta de red.

Para que existan transacciones entre diferentes dispositivos se precisa de una pila de protocolos compatibles en cada uno de ellos, de manera que un dispositivo receptor pueda trabajar con los paquetes recibidos de manera homóloga pero a la inversa de como lo hizo el emisor.

Las pilas de protocolos se suelen representar gráficamente mediante diagramas.

 

La pila TCP/IP

La pila de TCP/IP es un conjunto de protocolos de red en los que se basa Internet permitiendo la comunicación y transferencia de datos entre ordenadores instalado en distintos puntos.

Podemos describir por analogía la pila TCP/IP con el modelo OSI (Open System Interconnection) propuesto como una aproximación teórica y como una primera fase en la evolución de la redes de ordenadores. El modelo OSI es mas fácil de entender pero el que se utiliza es TCP/IP sucesor de NCP (Network Control Program). El modelo OSI esta formado por un total de siete capas mientras que TCP/IP ‘absorbe’ alguna de ellas en varias capas reduciendo el número a cuatro, es por ello que OSI se entiende mejor. La siguiente imagen muestra ambas pilas de protocolos:

 

ositcpip

A continuación vamos a resumir muy brevemente lo que realiza cada capa de la pila TCP/IP

  1. La capa de Acceso a la red controla los dispositivos del hardware y los medios que forman la red, por ejemplo la tarjeta de red del usuario, asegurando que existe conexión y está OK
  2. La siguiente capa “Internet” determina la mejor ruta a seguir a través de la red.
  3.  La capa de transporte admite las comunicaciones entre distintos  dispositivos  de  distintas redes
  4.  Representa los datos para el usuario, además del control de codificación, compresión y diálogo entre usuarios

Se le denomina TCP/IP en referencia a dos de los mas importantes protocolos que la componen y que además fueron los primeros en definirse: TCP (Transmission Control Protocol, Protocolo de control de Transmisión) y IP (Internet Procotol/Protocolo de Internet). Algunos otros protocolos que formar esta pila son (clasificados por capa dentro de la pila):

Capa 4 – Aplicación:

  • DNS (Domain Name Service): Utilizado para resolver nombres de direcciones IP en Internet
  • HTTP (Hypertext Transfer Protocol): Se usa para transferir y acceder a las páginas web
  • SMTP (Simple Mail Transfer Protocol): Se utiliza para la transferencia de mensajes de correo y adjuntos
  • FTP (File Transfer Protocol): transferencia interactiva de archivos entre sistemas
  • Telnet: Un protocolo de emulación de terminal, utilizado para proporcionar acceso remoto a servidores y dispositivos de red

Capa 3 – Transporte:

  • UDP (User Datagram Protocol): Es protocolo mas sencillo de la pila TCP/IP pero rápido. No proporciona sofisticados procedimientos para corregir los paquetes desordenados, garantizar el envío ni, en general, mejorar las limitaciones de IP. Entre los protocolos de la capa de Aplicación que se construyen sobre UDP se incluyen: DNS, NFS y muchos otros protocolos de medios en streaming.
  • TCP (Transmission Control Protocol): Seguramente el protocolo de transporte mas ampliamente utilizado en la pila TCP/IP. TCP crea conexiones completas con comprobación de errores y otras funciones que simplifican la creación de protocolos de red que deben de intercambiar grandes cantidades de datos. Por ello TCP aplica una pequeña penalización de rendimiento. La mayoría de los protocolos de la capa de Aplicación se construyen bajo TCP y destacan algunos como: SMTP, HTTP y FTP.

Capa 2 – Internet:

  • IP (Internet Protocol): Protocolo central de la pila TCP/IP. Proporciona un método de mejora para transferir paquetes entre ordenadores. Esto no garantiza que los paquetes alcancen su destino. Entre otras cosas mas IP es el protocolo es encargado de asociar direcciones IP
  • ICMP (Internet Control Message Protocol): Sencillo protocolo para la comunicación de datos. Se suele utilizar para enviar mensajes de error entre ordenadores, algo que se suele hacer modificando un paquete y devolviéndoselo al emisor.

 

Otras pilas de protocolos

Otras pilas de protocolos para la transferencia de datos entre ordenadores pueden ser:

  • NetBEUI: Pila de protocolos original de Microsoft e IBM para Windows. En desuso
  • AppleTalk: Pila inicial de Apple
  • IPX/SPX (Internet Packet Exchange/Sequence Packet Exchange, Intercambio de paquetes entre redes/Intercambio de paquetes en secuencia): Pila de protocolos preferida por Novell

Nota: Cada capa de las que se compone el sistema emisor equivale a una capa del sistema receptor, pero no tienen porque ser absolutamente idénticas, por ejemplo, puede tener distintos modelos de tarjetas de red o, incluso, puede utilizar tipos de hardware de red totalmente diferentes como Ethernet y Wi-Fi. Los ordenadores pueden ejecutar distintos OS y por tanto utilizar pilas de protocolos diferentes (pero lógicamente equivalentes).

 

IPv6. Mejoras sobre IPv4

  • Mientras IPv4 alcanza un máximo teórico de “cuatro mil millones” de direcciones IP, que debido al mal reparto de estas son algunas menos, IPv6 eleva esta cifra a “seiscientos setenta mil billones” (670 mil billones) de direcciones IP por cada milímetro cuadrado de la superficie de la tierra.
  • Multicast, habilidad para enviar un único paquete a múltiples destinos. Forma parte de la especificación base de IPv6 y no como en IPv4, donde es opcional aunque usualmente implementado. IPv6 no implementa broadcast (envió de un paquete a todos los nodos conectados). El multicast IPv6 comparte protocolos y características comunes con IPv4, pero también incorpora cambios y mejoras.
  • SLAAC (Stateless Address Autoconfiguration): La primera vez que un dispositivo es conectado a una red, este envía una solicitud de router (RS: router rolicitation) usando multicast pidiendo los parámetros de configuración. Si los router están configurados para responder a esta petición, enviarán un RA: router advertisement con los datos de configuración. Si una aplicación no soporta SLAAC usará entonces DHCP.
  • IPSec (Internet Protocol Security): Protocolo para cifrado y autenticación de IP. Obligatorio en IPv6 ya que viene como base del protocolo, aunque actualmente no se está utilizando.
  • IPv6 ofrece mejoras en el rendimiento relativo al procesamiento de datos a través de los router.

 

Direcciones de red

Para que los dispositivos puedan comunicarse necesitarán algún medio al que hacer referencia a la hora de transmitir los paquetes, este medio no es otro que una dirección y un puerto. Las direcciones pueden adoptar formas diferentes dependiendo del tipo de hardware de red, pila de protocolos, etc… e igualmente podrán necesitar un puerto, usado para dirigir un programa específico a un ordenador remoto.

Para conectar ordenadores dentro de redes en las que pueden estar usándose hardware de bajo nivel diferentes, como pueden ser Ethernet, Token Ring, Wi-Fi, etc… se necesitarán diferentes direcciones, de entre las que deberemos de conocer al menos las direcciones de hardware de red, las direcciones IP numéricas y los nombres de hosts de tipo texto.

 

Direcciones de hardware

El hardware de red dedicado como las tarjetas de Ethernet llevan programadas direcciones de red únicas conocidas como direcciones MAC (Media Access Control, Control de acceso a medios). Tienen una longitud de seis bytes y se expresan como números hexadecimales separados por dos puntos. Podemos informarnos sobre las direcciones de hardware para las tarjetas Ethernet instaladas en un sistema utilizando el comando ifconfig.

Algunas utilidades y el hardware de red de bajo nivel utilizan las direcciones de hardware para dirigir paquetes de datos. Por ejemplo, el switch detecta que una dirección en particular está conectada a un cable concreto, y en consecuencia, envía los datos dirigidos a dicha dirección sólo a través del cable asociado. Otro ejemplo es el uso que hace de estas direcciones el servicio DHCP asignando direcciones IP fijas a direcciones de hardware específicas. Existen herramientas de diagnostico avanzado que permiten examinar paquetes que proceden de o están dirigidos a direcciones de hardware específicas. En la mayoría a de los casos, no tendrá que preocuparse de las direcciones de hardware de un ordenador.

 

Direcciones numéricas IPv4/IPv6

Acabamos de ver algunos motivos del porque sobre la existencia de direcciones MAC o direcciones de hardware. Estas direcciones no guardan relación matemática alguna con las direcciones IP numéricas de IPv4 y IPv6 pero si que existen protocolos de la pila TCP/IP como ARP (Address Resolution Protocol, Protocolo de resolución de direcciones) o NDP (Neighbor Discovery Protocol, Protocolo de detección de vecinos) que realizan conversiones entre direcciones IPv4 – MAC, y IPv6 – MAC, con el fin por ejemplo de permitir a un ordenador que envíe un paquete Broadcast (mensaje que se envía a todos los ordenadores de la red) en cuya respuesta se incluirá la dirección hardware del receptor del paquete y así la pila TCP/IP puede dirigir el tráfico para una IP dada a la dirección hardware obtenida.

Las direcciones IPv4 se suelen expresar con cuatro números en base decimal, donde cada uno puede llegar al máximo de 255 (192.168.10.255) separados por puntos o bien, mediante notación “dotted quad“. dotted quad viene a ser la representación de una IP mediante una secuencia de 32 bits separados por puntos (dots) en grupos de cuarto (quad) bytes cada uno. Por ejemplo podríamos representar la IP de máscara de red 255.255.128.0 de la siguiente forma:

255.255.128.0 = 11111111.11111111.10000000.00000000

Las direcciones IPv6 constan de ocho grupos de números hexadecimales de cuatro dígitos separados por dos puntos y tienen un tamaño de 16 bytes (128 bits). Si uno o varios grupos de cuatro dígitos son 0000, éste o estos se pueden omitir, indicándolo con “: :“. Una IPv4 podría ser:

fed1:odb8:85a3:08d3:1319:8a2e:3070:7334

La máscara de red como ya adelantábamos (también llamada máscara de subred o netmask) es un número que define las 2 partes de las que está formada una IP, la parte de dirección de red y la de dirección de host. Empleando el ejemplo de netmask podríamos apreciar ambas partes de la siguiente manera, donde con azul representamos la dirección de red y con rojo el número de hosts que podemos anidar en esa red. Evidentemente para esto necesitamos una dirección IP de host, pero esto se explicará mas detalladamente en las siguientes secciones:

11111111.11111111.10000000.00000000

Nota: Las direcciones TCP/IP se combinan con una máscara de red para aislar la dirección de red.

Además de las formas con las que hemos representado anteriormente una máscara de red (bien en decimal o bien en binario) podremos identificar la netmask de una red con una serie de sufijos colocados en la dirección de red. Igualmente, usando la netmask del ejemplo anterior (255.255.128.0) y la dirección de red 192.168.10.0, podremos entonces definir la red como:

192.168.10.0/17

Nota: Si contamos el número de bits 1 que forman la máscara de red en binario, deduciremos que el /17 representa entonces a la netmask para esa red. Además esta porción de la netmask (la del grupo de 1, define la porción de red, algo que veremos a continuación).

La máscara de red de IPv6 funcionan igual que las de IPv4 con la diferencia de que los números son más largos y que en IPv6 se tiende a emplear la notación hexadecimal.

 

Clases de redes

Dentro de IPv4 nos encontramos con bloques de direcciones que definen redes, estas se han dividido tradicionalmente en varias clases, cada una de ellas destinadas a un tamaño de red, de manera que podamos estructurar las subredes y dispositivos conectados de una forma mas eficiente, al menos antes de la llegada del estándar CIDR (veremos este estándar a continuación). En la actualidad sirven principalmente como medio para definir máscaras de red por defecto (sufijos /8, /16 y /24). Las clases de direcciones IPv4 son las siguientes:

subredes

Las clases A, B y C son para uso general de la red. Normalmente utilizaremos una clase de red y su rango de direcciones privadas reservado en función del tamaño que le vayamos a dar a la red. Dependerá si es para una corporación, gran empresa o campus universitario (clases A y B) o una pequeña o mediana empresa e incluso las redes de uso doméstico (clase C). Los rangos de direcciones privadas reservados en cada clase son los siguientes:

  • Clase A: 10.0.0.0 – 10.255.255.255
  • Clase B: 172.16.0.0 – 172.31.255.255
  • Clase C: 192.168.0.0 – 192.168.255.255

Estos rangos de IP reservadas se conocen como direcciones RFC1918 ya que es el documento que las define. Se usan para que cada dispositivo dentro de una red privada (LAN) pueda tener su propia dirección. No sirven para conectar directamente con el exterior. Para conectar con el exterior u otras redes privadas, se dispondrá de una puerta de enlace (normalmente un dispositivo de traducción de dirección de red o NAT, o un servidor proxy).

El cometido de NAT (Network Address Translation) es ‘ocultar’ una serie de dispositivos de una red tras un único sistema o IP. Por ejemplo, si contamos con una red privada de clase C 192.168.1.x con 5 ordenadores, NAT tendrá que traducir las conexiones de estos 5 ordenadores para que puedan tanto enviar como recibir datos a través de una sola IP pública ofrecida por nuestro ISP (Internet Service Provider, Proveedor de Servicios de Internet), mediante la cual conectamos a Internet.

Las clases D y E son especiales. La primera (clase D) es utilizada para el envío simultáneo de datos a varios ordenadores (multidifusión), mientras que la clase E es utilizada para propósitos experimentales unicamente.

Importante: Las direcciones IP deben ser asignadas a ordenadores individuales para evitar que dos sistemas utilicen la misma dirección en Internet o red local.

 

Direcciones IPv4 especiales

  • La dirección IP 0.0.0.0 es usada como red default.
  • Las direcciones IP 127.x.y.z en concreto 127.0.0.1 son utilizadas como direcciones loopback, es decir el ordenador la usa para enviarse información a él mismo.
  • Para el direccionamiento Broadcast (enviar los datos una sola vez desde un emisor a todos los destinos posibles) se usa la dirección 255.255.255.255, dirección que el protocolo IP tiene limitado a uso local ya que de lo contrario saturaríamos Internet. Podremos hacer un Broadcast directo e igualmente limitado localmente (en términos de red) a un grupo de ordenadores concretos, o mejor dicho a una subred específica, utilizando el prefijo de dirección de red y la porción de host que identifica la conexión Broadcast de dicha red (algo que veremos en la próxima sección cuando hablemos del subnetting), por ejemplo, para la red con sufijo 192.168.1 y con una máscara de red 255.255.255.0 podríamos usar la dirección 192.168.1.255 para realizar una transmisión Broadcast en esa sola red.
  • Una dirección multicast esta asociada con un grupo de receptores interesados. El emisor envía un único datagrama desde su dirección IP hacía la dirección multicast, cuyo rango es de la IP 224.0.0.0 a la 239.255.255.255 (clase D) definido por la RFC 3171, y el router será el encargado de entregar este mensaje a aquellos emisores que hayan informado sobre su interés en el contenido.

 

El estándar CIDR y la técnica VLSM

El estándar CIDR (Classless Inter-Domain Routing, Direccionamiento entre dominios sin clases) aplicado empleando la técnica VLSM (Variable Length Subnet mask, Máscara de Subred de Longitud Variable), se implantó con el fin de aportar mas flexibilidad y, en resumidas cuentas poder crear máscaras y definición de redes que no dependieran de una clase como las anteriormente estudiadas.

Originalmente las IP se dividían en las clases A,B,C,D y E, lo que daba lugar entre otras cosas a que los routers utilizaran un encaminamiento con clases (classfull routing). Las clases eran divididas según su máscara de red la cual además se definía a partir de bloques enteros de unos y ceros binarios dando lugar a poder utilizar los sufijos naturales 8, 16 y 24 para definir una red, por ejemplo:

Una red con IP 192.168.1.0 y una netmask 255.255.255.0 puede ser definida mediante 192.168.1.0/24 donde el 24 indica el número de bits 1 que componen la porción de red dentro de la máscara (255.255.255.0 = 11111111.11111111.11111111.00000000)

Lo que se pretendió con CIDR fue permitir una mayor flexibilidad al dividir rangos de direcciones IP en redes separadas lo que aportó un uso más eficiente de las cada vez más escasas direcciones IPv4 y disminuyó la sobrecarga de los routers principales de Internet para realizar el encaminamiento, utilizando ahora un encaminamiento sin clases (classless routing).

Información: El término VLSM se usa generalmente cuando se habla de redes privadas, mientras que CIDR se usa cuando se habla de Internet.

Por ejemplo, vamos a utilizar una máscara de red de longitud variable y no una con una clase predefinida como la del ejemplo anterior. Esto puede ser útil si queremos crear una red en la que solo puedan anidarse 6 dispositivos, por poner un ejemplo: Un router, un PC cliente, un Servidor y un dispositivo móvil (aun tendremos dos IP libres). Para lograr esto, tendremos que adaptar la máscara de red:

La IP de la red seguirá siendo 192.168.1.0 pero en cambio la máscara pasará a ser 255.255.255.248 (11111111.11111111.11111111.11111000) o 192.168.1.0/29. Para conocer el número de host basta con ver la porción de host de la netmask (aquella que solo contiene ceros) que está en base dos por lo que en nuestro caso será 2^3-2=6

Nota: Restamos 2 debido a que no podemos usar la primera IP la cual es para la red y ni la última que se utiliza para Broadcast. Si hubiésemos elegido una máscara mas elevada como por ejemplo /30 solo podríamos anidar 2 hosts, así que nos hubiésemos quedado cortos.

 

Subnetting

Las direcciones IP están divididas en dos bloques, definidos por su máscara de red. El primer bloque define la dirección de la red a la que esta pertenece y  es representada con valores 1 binarios en su máscara de red, mientras que la segunda parte, porción de host, identifica a un host específico dentro de la red y es determinada en función de los valores 0 binarios de la máscara de red, esta porción determina el número máximo de host que podremos anidar a la red.

Vamos a seguir un ejemplo a modo de explicación. Supongamos que tenemos la siguiente IP y netmask.

Nota: Hemos añadido una segunda netmask (B) de tipo CIDR para duplicar el ejemplo y afianzar los conocimientos.

  • Dirección IP: 172.30.9.102
  • Máscara de red: 255.255.0.0
  • Una máscara de red CIDR (B): 255.255.255.224

Importante: Las máscara de red pueden representarse igualmente de la siguiente manera:

  • Dirección IP y netmask: 172.30.9.102/16
  • Dirección IP y netmask CIDR (B): 172.30.9.102/27

Lo primero que deberemos de hacer será pasar a binario estos números.

  • Dirección IP: 10101100.00011110.00001001.01100110
  • Máscara de red: 11111111.11111111.00000000.00000000
  • Máscara de red CIDR (B): 11111111.11111111.11111111.11100000

Nota: La parte Azul representa la porción de red mientras que la parte roja indica la porción de host.

De momento se ve claro el porque del /16 o /27, solo hay que contar los números 1 de las máscara de red anteriores. Ahora para conocer la IP de red y el número máximo de host deberemos de igualar de la siguiente manera estos números binarios:

11111111.11111111.00000000.00000000 -> Netmask: 255.255.0.0
011010101100.00011110.00001001.01100110 -> Red: 172.30.0.0

El número de hosts será de 2^16-2 , pues existen 16 bits con valor 0 que indican la porción de host menos dos que se usan: una para la dirección de red (la primera) y otra para broadcast (la última). Un total de 65534 dispositivos podrán ser anidados a la red 172.30.0.0

El ejemplo B sería algo mas complicado pero captaremos pronto el concepto. Quedaría algo así:

11111111.11111111.11111111.11100000 -> Netmask: 255.255.255.224
10101100.00011110.00001001.01100110 -> Red: 172.30.9.96

El número de hosts en este caso será de 2^5-2. Esto define una red mas reducida, útil si queremos mantener el control de redes pequeñas para evitar así el acceso a un gran número de dispositivos para los que realmente no necesitamos acceso.

Ahora que ya sabemos realizar subnetting sobre una red, esto es, crear redes en función del número de hosts que tengamos pensado anidar a una red, jugando con los bits de la porción de red y porción de host y sabemos determinar el valor IP de nuestra red a partir de una IP IPv4 y netmask, vamos a ver como identificar la IP de multidifusión de nuestra red.

Para identificar IP broadcast de nuestra red tendremos que igualar la IP binaria con la netmask binaria y cambiar los 0 binario por 1 en la IP en función de los 0 existentes en la netmask, tal que así.

  • Para el primero de los ejemplos teníamos una máscara de red con clase 255.255.0.0 que definía una IP de red 10101100.00011110.00000000.00000000 (172.30.0.0). Bastará con convertir los dos últimos octetos a 1 binario dándole así su máximo valor (.255.255), resultando: 172.30.255.255
  • Para el ejemplo (B), es decir IP de tipo CIDR haremos lo mismo pero con matices, ya que no solo existen 0. En este caso modificaremos los bits de la dirección IP que coincidan con los bits 0 de la netmask cambiándolos de 0 a 1 dejando intactos los que ya tienen como valor 1:

Netmask: 11111111.11111111.11111111.11100000
Dirección IP: 10101100.00011110.00001001.01100110

Broadcast: 0101100.00011110.00001001.01111111, resultando: 172.30.9.127

Conversión binaria-decimal: 01111111 = 127

 

Interés: Existe una web ( http://www.aprendaredes.com/cgi-bin/ipcalc/ipcalc_cgi ) donde podemos calcular de forma automática todo estos valores, algo que nos ayudará a la hora de encontrar conclusiones o corroborar nuestros resultados.

 

 Resolución de nombres de hosts

Los nombres de host se componen de dos partes: nombre del equipo y el nombre del dominio, separados por un punto ‘.‘. El primer campo hace referencia al nombre del propio ordenador mientras que el segundo a una colección de ordenadores. Por ejemplo vamos a suponer que tenemos una red local doméstica o empresarial que recibe el nombre de 4sysadmins y que nuestro equipo de trabajo y un servidor web que gestionamos y que se encuentra dentro de la red de la oficina se llaman nebul4ck y freeser, respectivamente. El nombre de host de estos equipos serán nebul4ck.4sysadmins para nuestro equipo de trabajo y freeser.4sysadmins para el servidor.

TCP/IP ofrece la posibilidad de vincular nombres de hosts con direcciones IP de varias maneras. Antes de aprender a relacionarlos, vamos a conocer un poco mas sobre los dominios.

Nota: Un conflicto de nombres podría impedir contactar con un sistema, a parte de causar probablemente otros problemas, como redireccionamientos de correo, registro en formularios webs, etc…

Los dominios se estructuran jerárquicamente.  Para los dominios de Internet de nivel superior o TLD (Top-Level Domain) encontramos los .com, .edu, .org, etc.. que normalmente corresponden a países o grandes corporaciones. Dentro de cada TLD hay dominios que identifican a otras organizaciones mas específicas como empresas, negocios y en definitiva a casi cualquier cosa para la que se haya registrado dicho dominio. Por ejemplo para un banco (mibanca.es) o para un usuario anónimo que quiere tener su propio dominio (jesuslafuentemedina.net). Estos dominios aún pueden dividirse en subdominios, un ejemplo de ello puede ser la dirección de este blog nebul4ck.wordpress.com, donde la plataforma wordpress.com presta un subdominio a cada usuario en ella registrada. Esta estructura puede continuar dividiéndose aunque no es lo habitual.

Cada uno de estos dominios y subdominios incluyen a ordenadores físicos o virtuales específicos.

Información: Podemos registrar nuestro propio dominio en Internet desde 11€ al año.

Ahora que conocemos algo mas sobre los dominios y la estructura que estos siguen podemos aprender algunas técnicas de resolución de nombres, esto es, convertir un nombre en una dirección IP o viceversa.

Cuando accedemos por ejemplo a google.es no escribimos la dirección IP del servidor con el que está enlazado el nombre, si no directamente el nombre (google.es). Esto es posible gracias a los DNS (Domain Name Server) que no es mas que una base de datos distribuida la cual realiza las conversiones oportunas entre direcciones IP y nombres de hosts.

Para que nuestro equipo o dominio pueda trabajar de esta manera es necesario incluir como mínimo un servidor DNS. Esto puede hacerse a nivel de configuración de router o del propio dominio o host. Lo ideal es contar con al menos dos servidores DNS que puedan resolver los nombres de Internet o si no, que se deleguen entre ellos esta tarea en caso de que uno deje de estar operativo o no pueda encontrar la relación IP-nombre. El proceso de resolución de nombres es transparente a nosotros ya que hay empresas encargadas de ofrecer servidores DNS para que una vez configurados en nuestra red hagan el trabajo de preguntar a otros DNS y así sucesivamente. No obstante podemos crear nuestros propios servidores DNS dentro de nuestra red doméstica o empresa, para que albergue en su base de datos distribuida todos los nombres y direcciones IP que queramos que sean conocidas dentro de nuestra red o dominio, de manera que entre los ordenadores del dominio exista la comunicación vía nombre de host y no necesariamente por IP. Esto no entra en los límites del examen pero es bueno saber que esta es una forma de trabajar con nombres y no con direcciones IP dentro de nuestro dominio o red.

Existen otros métodos para trabajar con nombres dentro de nuestro dominio (que abarca tanto a equipos en local como en remoto, siempre y cuando pertenezcan a nuestra red) que no necesariamente implica un despliegue como el de los servidores DNS. Por ejemplo a través del archivo /etc/hosts podremos crear asociaciones entre direcciones IP y nombres. Supongamos una red local cuyo dominio es 4sysadmins y en la que existen varios equipos y dispositivos (móviles, impresoras, servidores, portátiles, etc..). Tenemos un ordenador de trabajo desde el que normalmente accedemos al resto de dispositivos (LinMinCinn), ya sea por ssh, ftp, samba, etc.. y estamos cansados de tener que memorizar las IP. Podremos configurar el archivo /etc/hosts de la siguiente manera:

127.0.0.1    localhost
127.0.1.1    LiMinCinn.4sysadmins LiMinCinn

# IPS de la red

10.5.50.12    hprinter.4sysadmins hprinter
10.5.50.21    xiaomi.4sysadmins xiaomi
10.5.50.30    zopo.4sysadmins zopo
10.5.50.39    tab.4sysadmins tab
10.5.50.48    freeser.4sysadmins freeser

Nota: La segunda línea del archivo quizás no la encontréis en vuestros sistemas, es un bug de Debian que asigna esta IP al host al que no se le ha especificado una IP fija. Nada preocupante. Como sabemos está dentro del rango de IP de loopback.

Con un archivo de configuración como este podremos acceder desde el equipo LinMinCinn a cualquiera de los dispositivos listados mediante su nombre. La estructura es básica:

ip        nombre.dominio        nombre

La ventaja de resolver nombres mediante el archivo /etc/hosts es que es de fácil configuración, pero como desventaja, al ser un archivo local solo afecta al equipo en el que se ha configurado.

Antes de emplear el servicio DNS, Linux busca en el archivo /etc/hosts, comportamiento que se puede modificar desde la configuración del archivo /etc/nsswitch.conf. Este archivo configura el servicio NSS (Network Switching Subsystem, Subsistema de conmutación de red). Para modificar el comportamiento de orden de búsqueda de relaciones IP-nombre deberemos de modificar la línea ‘hosts:‘. Por defecto la línea hace que prevalezcan los archivos (files) sobre el servicio DNS (dns)

hosts:        files dns

Linux además del archivo /etc/hosts incluye un archivo llamado /etc/networks que funciona de un modo similar pero que aplica solo a direcciones de red. Además invierte la línea de formato, que pasan a ser:

nombre        ip

Otros tipos de configuraciones existentes para resolución de nombres pueden ser los del servicio LDAP (Lightweight Directory Access Protocol, Protocolo ligero de acceso a directorios) o utilizando invocaciones NetBIOS de Windows.

 

Herramientas para buscar manualmente información DNS

A veces, necesitaremos buscar la información proporcionada por DNS de manera manual. Existen varios programas para realizar esta tarea:

  • nslookup: Realiza búsquedas DNS, por defecto en ordenadores concretos y devuelve los resultados. Este programa está oficialmente obsoleto.
  • host: Sustituto para las funciones más sencillas de nslookup. Carece de un modo interactivo. En el caso más simple podemos escribir host nombre.dominio o la dirección IP que deseamos consultar.
  • dig: Realiza búsquedas DNS mas complejas que host. Podemos utilizar para localizar la dirección IP de un único nombre de host o viceversa. Es más flexible que host.
  • whois: Puede buscar la información de un dominio en conjunto. Su uso pasa por invocar el nombre del comando seguido del nombre del dominio (4sysadmins.com, por ejemplo) y mostrará información como el propietario del dominio, a nombre de quién se ha contratado, en que empresa de dominio se ha registrado, personas de contacto, etc… Muchos dominios no ofrecen esta información

 

Puertos de red

Cuando un cliente envía una petición a un servicio concreto de un servidor debe de especificar un número de puerto, pues no solo bastará con la dirección IP del servidor. Una analogía con el mundo ‘real‘ sería el tener que entregar un paquete a una vivienda concreta dentro de un edificio. Si tan solo tienes el número de edificio (lo que podría ser el servidor) pero no número de puerta (puerto) de la vivienda dentro de ese edificio no podrás entregar el paquete al destinatario.

Es por esto por lo que se agrega un número (número de puerto) a la dirección IP, de manera que el sistema pueda redirigir el tráfico a un programa/servicio específico dentro del servidor. Cuando iniciamos un servicio dentro de un servidor, por ejemplo un servicio FTP (File Transfer Protocol) por convención el servidor asignará un número concreto de puerto (el 21 para FTP) para este servicio. El archivo de configuración /etc/services es el archivo que asocia a cada servicio un número de puerto. Esto viene definido por convención, por lo que para un funcionamiento básico no será necesario modificar estas relaciones, a menos que usemos un servicio poco usual y queramos crear una relación entre el servicio y un número de puerto por el que redirigir los paquetes para ese servicio en concreto.

Si tenemos un servidor en el que corren diferentes servicios, como por ejemplo un servidor web apache, un servidor de correos y un servidor ssh (Secure Shell), cuando el cliente envíe un paquete a uno de estos servicios, el sistema asignará el puerto de entrada al destino en función de la petición realizada. Si lo que se ha enviado a sido un paquete de solicitud para mostrar una página web, esto irá dirigido por el puerto 80 del servidor.

Los clientes no poseen números fijos de puertos de salida. Esto se asigna de forma dinámica lo que permite que en un mismo ordenador se puedan ejecutar diferentes instancias de un mismo cliente. De este modo no competirán entre ellos para usar un único puerto de salida.

Nota: Un cliente es un programa que inicia una conexión de red para intercambiar datos mientras que un servidor es quien escucha dichas conexiones y responde a éstas. En una conexión web el cliente podría ser Firefox y el servidor Apache.

 

Números de puertos, uso y servicios típicos de Linux

Los números de puerto son características de los protocolos UDP y TCP. Algunos protocolos como ICMP no emplean números de puerto.

Una diferencia clave de los puertos TCP/IP es la existente entre puertos con y sin privilegios. Los puertos con privilegios indican que son usados por servicios configurados por el administrador (root) y usan números por debajo del 1.024.

A continuación una tabla con los puertos mas comunes utilizados por los principales servicios:

 

puertosExisten diferentes utilidades para comprobar incluso de manera remota que puertos tenemos abiertos en nuestro ordenador, cuales están siendo utilizados y porqué servicios, y además aquellos que se encuentran a la escucha esperando conexiones remotas o cerrados. Algunas de estas herramientas pueden ser netstat, lsof, nmap o nessus, de las que hablaremos en la sección “Diagnóstico de red

 

Configurar la red en Linux

Durante la instalación de una distribución de Linux, lo mas normal es que se pida que realicemos la configuración de la tarjeta de red de forma casi automática, con una serie de parámetros que nos permitan conectarnos a Internet o bien mantener comunicación con los dispositivos de nuestra red local. Normalmente basta con marcar que queremos recibir unos parámetros de forma automática vía DHCP. No obstante podremos introducir de forma manual y personalizada esos valores si indicamos que queremos conservar una configuración estática.

Los parámetros mínimos para que una red pueda tener comunicación con el resto de dispositivos son: la dirección IP del host, la máscara de red, la puerta de acceso y un servidor DNS. Veremos estos y otros parámetros en la sección de “configuración de red con parámetros estáticos

Para aprender a configurar la red desde 0 vamos a suponer que no la hemos configurado ya durante la instalación y que además no vamos a usar las herramientas GUI que se nos ofrecen para tal fin. Dicho esto comencemos.

 

Instalando el hardware de red

Lo primero que deberemos de hacer en caso de que nuestro equipo no cuente con un hardware de red interno, será instalar una tarjeta de red en la placa base o vía USB. Una vez tengamos la tarjeta instalada y el sistema en funcionamiento, deberemos de asegurarnos de que el módulo de la tarjeta está cargado. Esta operación de carga normalmente la lleva a cabo el propio sistema mediante scripts de inicio, pero si nuestro sistema no ha detectado nuestro hardware, podremos cargar nosotros mimos el controlador. Para cargar el módulo de la tarjeta será necesario contar con dicho módulo y conocer su nombre. A continuación pasaremos a cargarlo con el comando modprobe:

# modprobe <módulo>

Con la tarjeta ya instalada y cargado so módulo e incluso configurado para ser cargado al inicio pasaremos a configurarla.

Nota: De compilar un kernel deberemos de asegurarnos que incluimos el módulo para la tarjeta de red.

 

Configurando el hardware de red

Podemos configurar la tarjeta de red para que acceda a Internet o se comunique con el resto de dispositivos de la red local de varias maneras. Si descartamos como ya dijimos anteriormente las herramientas GUI, podremos configurar la red vía DHCP o con parámetros estáticos a través de los archivos de configuración.

 

Configurar la red con DHCP

Es la forma mas sencilla de configurar un ordenador para que utilice una red TCP/IP. Básicamente el funcionamiento con DHCP es el siguiente: En la red existirá un ordenador que ejecuta un servidor DHCP o bien un router, el cual tiene configurado los parámetros necesarios para que los ordenadores de la red puedan acceder a ella. Estos parámetros son normalmente una IP de red, un rango de IP dentro de la red, un servidor DNS, una máscara de red y una puerta de acceso. Es posible añadir otros parámetros como nombres de hosts o servidores DNS secundarios.

Todas las distribuciones Linux tienen como mínimo un cliente DHCP por defecto que inicia al arranque del sistema a través de su script de inicio o desde el archivo principal de configuración de la red. Cuando este arranca, el cliente DHCP envía una multidifusión en busca de un servidor DHCP. El servidor responde utilizando únicamente la dirección de hardware del cliente (es decir la MAC de la tarjeta de red) con la información de configuración que el cliente necesita para poder comunicarse con los demás ordenadores. De esta manera el cliente tendrá asignada una IP temporal (en caso de no ser renovada, esta puede pasar a utilizarse por otro dispositivo de la red) una puerta de enlace y aquellos parámetros configurados en el servidor o router.

Nota: En Linux hay tres clientes DHCP de uso habitual que son pump, dhclient y dhcpcd. Los tres pueden ser ejecutados además de por sus archivos de inicio o de configuración de red, como herramientas corrientes del sistema bajo el usuario root (# dhclient eth0). Por defecto en la gran mayoría de distribuciones el nombre de la interfaz es eth0, aunque esto puede cambiar

Ahora que conocemos el funcionamiento de DHCP, vamos a configurar nuestro ordenador para que haga uso de este servicio. Para esto solo tendremos que acudir al archivo de configuración de la interfaz de red y modificar una línea. Para sistemas Red-Hat y Fedora este archivo suele encontrarse en /etc/sysconfig/network-scripts/ifcfg-<nombre_interfaz>, mientras que para sistemas Debian y derivados puede que el archivo en cuestión sea /etc/network/interfaces cuyo objetivos son similares pero los detalles quizás difieran.

Una vez localizado el archivo de configuración de interfaz en nuestro sistema deberemos de modificar la siguiente línea:

  • Para Red-Hat y Fedora:
BOOTPROTO=dhcp
  • Para Debian y derivados:
iface eth0 inet dhcp

Nota: Como ya avisamos antes, el nombre de la interfaz puede cambiar.

 

Configurar la red con valores estáticos

Si una red carece de servidor DHCP o simplemente queremos que nuestro ordenador que va a funcionar como un servidor web mantenga su IP de forma estática, deberemos de configurar los valores IP mediante su archivo de configuración, uno a uno.

  • Archivo de configuración de Red-Hat y Fedora (otros como CentOS, derivado de Red-Hat usan el mismo formato y archivo):
$ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="static"
IPADDR="192.168.1.32"
NETMASK="255.255.255.0"
NETWORK="192.168.1.0"
BROADCAST="192.168.1.255"
GATEWAY="192.168.1.1"
ONBOOT="yes"

Los parámetros de configuración son ya conocidos (si hemos seguido el estudio de secciones anteriores), pero vamos a destacar DEVICE el cual es el identificador del dispositivo, BOOTPROTO que como vemos a diferencia de la configuración anterior, en este caso es estática, la GATEWAY que además de configurarse en este archivo podrá ser configurada igualmente mediante el comando route o de forma permanente en otro archivo como /etc/sysconfig/network/routes (Red-Hat y Fedora) y ONBOOT que al estar en ‘yes‘ lo que hará será arrancar la configuración al momento del inicio del sistema. Podemos preguntar que donde se encuentran configuradas las IP de los DNS, la respuesta es en el archivo /etc/resolv.conf, el cual admite hasta tres servidores y son definidos uno por línea con el siguiente formato:

namserver <ip-servidor>

También podemos definir en este archivo el nombre de nuestro dominio local utilizando la línea:

domain <nombre-de-nuestro-dominio>

Nota: La gateway no es necesaria en sistemas que no se vayan a conectar a redes mas grandes, es decir que sólo se encuentren trabajando en una red local que no contiene router.

  • Archivo de configuración Debian y derivados:
$ sudo cat /etc/network/interfaces
iface eth0 inet static
address 192.168.1.23
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
hwaddress 81:ab:1c:59:aa:7b
up <comando>

Nota: Como curiosidad debemos mencionar la posibilidad de ejecutar comandos desde este archivo de configuración. En este ejemplo se a utilizando up <comando> para ejecutar un comando al ‘levantar‘ la tarjeta de red, pero existe la posibilidad de ejecutarlo al ‘bajarla‘ o antes y después de levantarla/bajarla con down, pre-up, pre-down, post-up y post-down respectivamente.

Importante: Es importante saber que si estamos utilizando herramientas GUI como NetworkManager para la configuración de nuestros hardware de red, nos encontremos que los archivos anteriormente mencionados están vacios o sus líneas comentadas. Esto se debe a que estas aplicaciones guardan sus configuraciones en otros archivos. Por ejemplo el archivo de configuración para LinuxMint (derivado de Debian) es /etc/NetworkManager/system-connections/<nombre-conexión> y su contenido puede ser parecido al siguiente:

[802-3-ethernet]
mac-address=88:AE:1D:69:5A:5A

[connection]
id=wired-11
uuid=212274c7-08bc-4586-9h49-c1u218p9239f
type=802-3-ethernet
timestamp=1424866869

[ipv6]
method=auto

[ipv4]
method=manual
dns=8.8.8.8;8.8.4.4;
address1=192.168.1.50/24,192.168.1.1

 

Mostrar información sobre la configuración de la red

Con el comando ifconfig ya mencionado en secciones anteriores podremos mostrar la configuración de la red. Basta con escribir $ ifconfig y será mostrada la información de todas las interfaces configuradas. Si queremos mostrar solo una, deberemos de pasar su identificador como parámetro de ifconfig:

$ ifconfig eth0

El comando ifconfig nos permite ademas configurar una interfaz de red directamente desde la línea de comandos, siempre y cuando se siga su sintaxis y especifiquemos en ella los valores pertinentes:

# ifconfig eth0 up 192.168.50 netmask 255.255.255.0

Para añadir la puerta de acceso podemos usar route:

# route add default gw 192.168.1.1

Además, podemos utilizar route para efectuar un diagnóstico de la configuración de red, por ejemplo:

route

La primera línea indica que todo el tráfico saliente hacia Internet desde eth0 saldrá por la puerta de acceso 192.168.1.1 mientras que la segunda línea indica que los datos destinados a cualquier ordenador dentro de nuestra red local pasan directamente por eth0.

Una vez configurada la tarjeta de red y con esto la conexión a Internet o red del equipo, podremos hacer uso del comando ifup para levantar la red. ifup es también útil para comprobar la configuración, ya que de no levantar la red podríamos sospechar de que algo anda mal y posteriormente usar ifconfig o route para depurar la configuración. De la misma manera podremos usar ifdown para cerrar las conexiones. Ambos comandos se implementan como scripts que consultan los archivos de configuración y ejecutan entre bastidores comandos relevantes de bajo nivel.

 

Configurar el nombre de un equipo

Es importante dar un nombre a nuestro equipo, ya sea de forma local o dependiendo de servidores DNS de nuestra red. Podemos dar un nombre a nuestro equipo en la red para que sea reconocido por el resto de dispositivos de dos formas diferentes, bien a través de una entrada en la base de datos DNS o bien modificando los archivos /etc/hosts de todos los dispositivos de la red. Los equipos con Windows también disponen de este archivo solo que evidentemente en otra ruta.

Si por el contrario queremos dar un nombre a nuestro equipo de forma local podremos usar la herramienta hostname, la cual sirve tanto para cambiar el nombre de forma temporal, es decir al reiniciar volveremos al nombre anterior o, mostrar el nombre actual del equipo. Para mostrar el nombre bastará con escribir el comando sin parámetro alguno. Para cambiar el nombre deberemos hacer lo siguiente:

# hostname <equipo.dominio>

Si lo que queremos es nombrarlo de forma permanente deberemos de editar el archivo /etc/hostname o /etc/HOSTNAME (dependiendo de la distribución) y añadiendo una línea con el nombre del equipo y dominio.

Nota: Tanto en el uso de hostname como en la edición del archivo, el nombre del dominio es opcional.

Ya que nos hemos decidido a cambiar el nombre de forma permanente, una vez modificado el archivo /etc/hostname o /etc/HOSTNAME es recomendable cambiar los siguientes archivos:

  • /etc/hosts: Añadir una línea con nuestra IP y nombre:

myhost

  • /etc/sysconfig/network: En distribuciones como Fedora o CentOS puede ser interesante cambiar el nombre de cara a la red. Podremos modificar el valor de la variable HOSTNAME por nuestro nombre

Existen dos comandos con los que mostrar o cambiar el nombre del dominio del ordenador. Si queremos modificar el nombre del dominio del ordenador utilizado por NIS (Network Information System, Sistema de información de red) utilizaremos el comando domainname, mientras que con dnsdomainname definiremos el nombre del dominio utilizado por DNS.

Advertencia: Estos comando no afectan a los servidores remotos, solo al nombre dato a los programas que emplean llamadas a estos servidores.

 

Configuración del enrutamiento

Como regla general los encargados de redirigir el tráfico en una red son los routers. Estos routers disponen de una tabla de enrutamiento o tabla de reglas compleja en la que se definen las rutas a tomar por los paquetes. No obstante nuestro Linux dispone de una tabla de reglas básica como ya vimos anteriormente con el comando route por lo que podremos redirigir tráfico a determinadas redes. Antes de nada, debemos de saber que esto no es una opción que venga por defecto en el sistema si no que deberemos de editar un archivo para que Linux comience a aceptar paquetes que van a otra red y sea el quien los redirija a esta. Podremos hacer esto de la siguiente forma:

# echo "1" > /proc/sys/net/ipv4/ip_forward

Si queremos hacer este cambio permanente deberemos de localizar el archivo /etc/sysctl.conf o /etc/sysconfig/sysctl (dependiendo de la distribución esto puede cambiar). Una vez localizado lo editaremos con nuestro editor de texto favorito y cambiaremos el valor del parámetro ‘net.ipv4.ip_forward = 0‘ por 1.

Nota: Si tenemos problemas para localizar este archivo en nuestra distribución, recodemos que disponemos de grep para localizar cadena de texto. Podemos usar como patrón ip_forward o similar.

Ahora que ya tenemos el sistema configurado para redirigir tráfico, tendremos que utilizar una herramienta para configurar una nueva puerta de acceso y ruta. Para esto usaremos el comando route.

Por defecto nuestra red tiene su propia puerta de enlace, la cual es la dirección del router (normalmente 192.168.1.1). Por esta puerta pasarán todos los paquetes proveniente de nuestra red con destino al exterior. Pero como queremos que ciertos paquetes destinados por ejemplo a la red 172.20.8.0/16 sean filtrado por otra puerta de acceso, configuraremos esta ruta tal que así:

# route add -net 172.20.8.0 netmask 255.255.0.0 gw 172.20.9.1

Donde:

  • -net 172.20.8.0: Indica el destino. En este caso una red (-net) con IP. Podríamos haber usado -host si el destino fuese un equipo concreto
  • 172.20.90.1: Es el router (puerta de acceso) por el que deberán de pasar los paquetes.

El archivo /etc/sysctl.conf y el comando sysctl

Este archivo es especialmente importante y aunque no se abarca en los propósitos del LPIC-1 no está de más que sepamos ahora que lo hemos modificado para hacer el reenvío de paquetes, que función es la que desempeña y como poder cambiar los parámetros que se encuentran definidos en él. El archivo /etc/sysctl.conf es usado para pasarle parámetros de configuración al kernel en tiempo de ejecución, es decir, se utiliza para configurar o cambiar el comportamiento del kernel que se está ejecutando. Equivale a modificar los valores de los archivos del sistema de archivos virtual /proc y mas concretamente a los del directorio /proc/sys solo que de hacerlo a través de los archivos, al reiniciar estos cambios no serán conservados, mientras que si modificamos los parámetros directamente desde /etc/sysctl.sys los cambios permanecerán. Para cambiar los valores de este archivo una vez que el sistema se encuentra arrancado usaremos el comando sysctl, el cual sirve tanto para visualizar parámetros como para modificarlos. Los parámetros a modificar se encuentran como ya hemos comentado en /proc/sys y los mas significativos suelen ser:

  • dev : Establece los parámetros de configuración de los dispositivos conectados.
  • fs : Parámetros relacionados con los sistemas de ficheros como los inodes, quotas, etc..
  • kernel : Comportamiento general del kernel
  • net : Los relacionados con la configuración de la red.
  • vm : Utilizados para configurar la memoria virtual

La sintaxis de sysctl es sencilla, como casi todo comando este acepta una serie de opciones y se le pasa la variable/parámetro a modificar junto con su valor:

sysctl [opciones] variable=valor

Alguna de las opciones mas habituales para sysctl son: -a (muestra todos los parámetros y sus valores asignados que se encuentran configurados en el sistema), -w (establece un valor indicado, no será permanente pero nos ayudará a comprobar sus resultados. En caso de ser favorables podremos hacer posteriormente los cambios permanentes modificando sysctl.conf) y -p (carga los valores de sysctl.conf)

 

El comando IP

Para terminar esta larga sección sobre “Configuración del hardware de red” vamos a comentar sobre el comando ip. El comando ip es el comando que pretende sustituir a ifconfig y route, y por supuesto a ifup y ifdown, vamos que es la navaja suiza con respecto a la configuración de la red. A día de hoy seguimos utilizando estos comandos pero sin duda con el paso del tiempo iremos haciéndonos a ip.

El comando ip forma parte de la iproute2 suite. Su uso está destinado a mostrar información sobre la configuración de los dispositivos de red, configurar rutas, políticas de rutas y túneles.  Veremos este comando mas a fondo como siempre en la sección de comandos correspondiente a este capítulo – 7. No obstante y como venimos haciendo a lo largo de la guía de estudios, vamos a nombrar sus principales funciones.

  • Mostrar la configuración de las interfaces de red (parecido a ifconfig):
$ ip addr [list|show] [dispositivo]
  • Activar o desactivar una interfaz:
$ ip link set eth0 up | down
  • Configurar un dispositivo de red:
$ ip addr add 192.168.1.25/24 broadcast 192.168.1.255 dev eth0
  • Eliminar la configuración IP de un dispositivo:
$ ip addr del 192.168.1.25/24 dev eth0
  • Activar el modo multicast para eth0:
$ ip link set dev eth0 multicast on
  • Informar sobre la tabla de rutas:
$ ip route [list|show]

En realidad la sintaxis de ip es sencilla, admite pocas opciones tras el comando y luego indicamos el objeto (link, addr, route, tunnel, etc…) sobre el que realizaremos una determinada acción (set, show, on, etc..) para un dispositivo (dev) concreto (eth0). Existen casos donde detrás del dispositivo se indica un parámetro como en el caso de activar (on) una interfaz. Podremos recurrir a la man de ip o también podemos obtener información sobre un objeto concreto mediante help:

$ ip link help

 

Diagnóstico de red

Cuando configuramos una red en ocasiones las cosas no siempre funcionan como se planean, es por ello que necesitamos recurrir a ciertas herramientas de diagnóstico o depuración de red para encontrar posibles fallas o simplemente porque deseamos auditar una red en busca de errores o funcionamientos poco fiables. Linux ofrece gran variedad de utilidades destinadas a este tipo de tareas. Vamos a estudiar en las siguientes secciones aquellas que son requisito imprescindible para hacernos con la certificación LPI 1.

  • Verificar la conectividad con un host remoto: ping (ping6)
  • Rastrear una ruta entre dos puntos: traceroute (traceroute6) y tracepath (tracepath6)
  • Auditar la red: netcat (o nc), netstat, iptraf, lsof y nmap
  • Sniffer, husmeador de red: tcpdump y Wireshark
  • Herramientas de diagnóstico adicionales (aunque no estén diseñadas para tal fin): Telnet y FTP

Nota: Las variantes “nombre6” están diseñadas para trabajar con IPv6. Por lo general suelen funcionar casi idénticamente a las de IPv4.

 

Verificar la conectividad básica

Uno de los primeros pasos que podemos dar para verificar si nuestra red tiene una buena configuración, o al menos la suficiente como para llegar a un destino especificado es usar el comando ping o ping6, este último es el análogo de ping pero para direcciones IPv6

Información: A partir de este momento cuando hablemos de ping6, traceroute6 o tracepath6 estaremos refiriendonós a los comandos usados para direcciones IPv6.

Con ping podremos verificar la conectividad con otros puntos de la red. Para ello el comando envía un paquete ICMP al sistema remoto y espera una respuesta. Esto lo hace de forma reiterada y sin cesar pero podremos limitar el número de envíos mediante la opción -c <num>, donde num es el número de envíos que queremos realizar o bien detener los envíos pulsando Control-C, lo que cancelará la ejecución del comando.

# ping -c 4 80.25.32.18 | unequipo | unequipo.sudominio | www.unservidor.edu

Podremos usar cualquiera de las opciones anteriores para indicar el host, pero solo una. En este caso ping enviará cuatro paquetes. Una respuesta al comando ping podría ser la siguiente:

PING google.es (216.58.211.195) 56(84) bytes of data.
64 bytes from mad01s25-in-f3.1e100.net (216.58.211.195): icmp_seq=1 ttl=55 time=37.5 ms
64 bytes from mad01s25-in-f3.1e100.net (216.58.211.195): icmp_seq=2 ttl=55 time=37.7 ms
64 bytes from mad01s25-in-f3.1e100.net (216.58.211.195): icmp_seq=3 ttl=55 time=38.1 ms
64 bytes from mad01s25-in-f3.1e100.net (216.58.211.195): icmp_seq=4 ttl=55 time=37.7 ms
--- google.es ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 37.571/37.829/38.164/0.213 ms

Podemos ver que los 4 paquetes fueron recibidos por el host y que ninguno se perdió y todo en un tiempo de 3004ms, lo que indica que tenemos conectividad con el host remoto.

Otras opciones como -i, -f, -n, -l, -p o -s pueden ser usadas tanto con ping como con ping6. La opción -i nos permite indicar un intervalo de tiempo entre el envío de cada paquete ICMP al host remoto, con -f podemos hacer un envío masivo de ping, esta opción es incompatible con la opción -i y lo que hace por defecto es envíar los paquetes con la misma velocidad que los recibe o cien veces por segundo, dependiendo de cual de ellos es mayor. El parámetro -n muestra solo salidas numéricas, es decir no hace ningún intento por buscar nombres simbólicos para los host remotos. Con -l ping intentará envia tantos paquetes tan rápido como le sea posible antes de volver a su comportamiento normal. La opción -p resulta útil para diagnosticar problemas de red relacionados con los datos, nos permite mediante un patrón -p <patrón> se puede completar un paquete con mas 16 bytes. Por su parte -s especifica el número de bytes que se van a enviar. La cantidad por defecto es 56 que sumando los 8 de la cabecera de paquetes ICMP pasan a ser 64 bytes. Existen otras opciones pero son poco usuales.

Una de las conclusiones que podemos sacar de la respuesta de ping es que si podemos hacer ping a máquinas dentro de nuestra red local pero no a máquinas externas a esta, es que tenemos un problema de configuración hacia el exterior, o si podemos hacer ping a una máquina mediante su IP pero no a su nombre, quizás el servicio DNS esté experimentando problemas.

 

Rastrear una ruta

Una vez comprobada la conectividad con un host remoto, quizás nos interese conocer la traza o ruta que sigue el paquete hasta llegar al destino o bien determinar si existe un problema en la conectividad de la red. Esto podemos hacerlos con los comandostracepath (tracepath6)  o traceroute (traceroute6).

El comando traceroute envía una serie de tres paquetes de prueba a cada ordenador entre nuestro sistema y el host remoto especificado, mostrando todos los routers que existen de por medio y los tiempos de respuesta. Su uso es básico, aunque admite algunas opciones. Podemos ejecutar traceroute con su opción -n para mostrar las direcciones IP de los ordenadores de destino en vez de sus nombres, lo que puede acelerar el proceso, aunque en ocasiones es igualmente imporante conocer los nombres de estos. Aún así -n hace la salida mas legible en la mayoría de los casos

$ traceroute -n 82.123.78.50

Con traceroute podemos localizar también problemas de conectividad en la red, por ejemplo una alta variabilidad en los tiempos de respuestas o la ausencia de algunos de estos, lo cual se indica mediante asteríscos ‘‘, puede indicar que el router en el que nos encontramos el ‘‘ está sobrecargado o que tiene una conexión poco fiable. Un salto considerable en los tiempos, suele significar que existe una enorme distancia entre los dos router (habitual en conexiones entre continentes). No obstante si los dos sistemas están lo bastante cerca como para que este salto enorme carezca de sentido deberemos de realizar comprobaciones sobre la red, pues lo mas seguro es que existan problemas sin determinar.

El comando traceroute6 es equivalente a traceroute -6 y con ellos podremos usar opciones como -i que nos permite especificar por cual interfaz de red queremos enviar los paquetes, especificar el número máximo de saltos con -m <hops> (por defecto es 30), indicar una gateway alternativa con -g <gateway> o indicar el tiempo límite de espera para una respuesta, -w

Una alternativa a traceroute es tracepath. A diferencia de traceroute, tracepath genera una línea de salida por cada paquete de prueba, por lo que su salida es más extensa. tracepath admite menos opciones, aun así coinciden en su opción -n, dándonos además la posibilidad de mostrar tanto la dirección IP como el nombre de host mediante la opción -b. De la misma manera podemos especificar el número de saltos máximos con -m e indicar el puerto inicial de destino con -p, algo que también nos permite hace traceroute y que no hemos comentado. El puerto de destino se va incrementando en uno a medida que se envían paquetes de pruebas.

Nota: Igualmente tracepath6 admite las opciones de tracepath solo que en este caso, debemos de escribir tracepaht6 y no tracepath -6.

 

Auditar  la red

Existen multitud de redes para diagnosticar el estado de la red pero aquí solo abarcaremos las siguientes:

  • netcat o nc: Es una de las herramientas de diagnostico y seguridad mas populares dentro de la comunidad GNU/Linux. Trabaja tanto con conexiones TCP como UDP y permite hacer cosas como por ejemplo abrir puertos en host remoto quedándose a la escucha de posibles conexiones, rastrear puertos abiertos o realizar transferencias de archivos bit a bit entre dos equipos. Funciona tanto para IPv4 como para IPv6.

Para dejar a nc como servidor a la escucha (-l, listen) en un determinado puerto. nc aceptará la conexión de un único cliente y se cerrará:

# nc -l <unpuerto>

Para abrir una conexión como cliente del servidor del ejemplo anterior:

# nc <equiposervidor> <unpuerto>

Abrir una conexión en el servidor para recibir datos desde un cliente:

# nc -l <unpuerto> > <archivo-donde-se-vuelva-el-contenido>

Enviar desde el cliente un archivo para que sea volcado en la conexión del ejemplo anterior:

# nc <equiposervidor> <unpuerto> < <archivo-que-será-volcado-en-el-servidor>

Revisar que puertos TCP (opción por defecto) están abiertos dentro de un ranto de puertos determinado (para nuestro ejemplo usaremos el rango 10-50) en un sistema:

# nc -vz <unequipo> 10-50

Netcat acepta algunas opciones entre las que destacamos (a parte de -l, listen y -vz) -p para especificar un puerto, -k para cambiar el comportamiento de escucha del primero de los ejemplos, es decir aceptar infinitas conexiones y evitar que la conexión se cierre, cambiar el protocolo de puerto por defecto TCP a UDP con -u, especificar un retraso (delay) en el envío o recepción de mensajes -i.

  • netstat: Puede considerarse la herramienta por excelencia para el diagnóstico de red. Dependiendo de los parámetros que le pasemos podrá utilizarse en lugar de muchas otras. Si queremos recibir información sobre nuestras interfaces de red (similar a ifconfig) podemos pasar el parámetro -i, –interface. Para obtener un listado de la tabla de enrutamiento (similar a route) usamos la opción -r, –route. La opción -N o –masquerade nos informará sobre las conexiones en las que intervenga las funciones de NAT. Un uso de netstat sin opciones puede mostrarnos gran información, como por ejemplo los puertos que tenemos abiertos con conexiones establecidas o cerrados y ademas los hosts y servicios que se conectan a ellos. Podremos usar la siguiente línea para indicar valores específicos:
# netstat -punta <host>

Donde:

-p muestra el PID y el servicio que hace uso del puerto, -u informa de los puertos UDP (además de los TCP, opción por defecto), -n expresa los host y puertos mediante números (útil si queremos redireccionar la salida con una pipe para buscar un puerto específico con grep), -t muestra el estado de la conexión (LISTEN, ESTABLISHED, CLOSE, CLOSE_WAIT, etc..) y -a muestra todas las conexiones y puertos de escucha. Si queremos encontrar directamente servidores que escuchan conexiones podemos agregar -l a -p

Importante: El uso de la opción -p suele desplegar líneas de mas de 80 caracteres, podemos abrir una terminal adecuada para estas líneas o redirigir la salida a un archivo, para su comodo estudio.
Algo que conviene comentar sobre la salida del comando netstat es el significado por ejemplo de las columnas “Local Address” y “Foreign Address” que mas o menos queda claro que refieren a la dirección local y dirección remota respectivamente de la conexión. Otro aspecto es el uso del asterísco ‘*‘ en el campo de las direcciones IP o puertos. Este metacaracter representa que no hay activamente una conexión para un determinado servicio, el cual si que se encuentra en ejecución y es posiblre contactar con él.

Nota: Con el comando netstat podremos averiguar quien está conectado a un puerto determinado o si es necesario tener algunos puertos abiertos o servicios corriendo innecesariamente en nuestro sistema.

  • iptraf : Herramienta basada en consola que proporciona estadísticas de red a partir del trafico TCP de nuestras interfaces de red. Es parecida a netstat pero posee ciertas ventajas y características que la hacen bastante útil, como por ejemplo la posibilidad de medir el ancho de banda utilizado en cada conexión, monitorizar el tráfico IP,  posee un módulo de estadísticas sobre LAN que permite descubrir hosts en la red además de mostrar los datos de su actividad, admite la audición de múltiples protocolos como IP, TCP, UDP, ICMP, ARP y OSPF entre otros.

Podemos descargar iptraf desde los repositorios oficiales de nuestra distribución.

  • lsof: La utilidad lsof no está diseñada precisamente para el diagnóstico de la red pero al ser una herramienta desarrollada para la monitorización del sistema podremos utilizarla igualmente para monitorizar ciertos aspectos de la red. En realidad lo que hace lsof es identificar que archivos están abiertos en el sistema: archivos regulares, directorios, tuberías, librerías o socket de red entre otros, quién accede a ellos, nombre e ID del proceso, la ruta absoluta del archivo, su descriptor, etc… útil por ejemplo si queremos desmontar un sistemas de archivos (incluso los de red) pero existen conexiones abiertas a determinados archivos y queremos tener información al respecto

Nota: En el apartado de comandos estudiaremos las opciones de lsof, a continuación solo mostraremos el uso de la opción -i que es la que nos interesa en este momento.

Podremos usar lsof en lugar de netstat para determinadas tareas, entre las que se incluye localizar los servidores que se encuentran en uso gracias a su opción -i. En su forma más básica este comando acompañado de está opción nos motrarán conexiones entre hosts. Estas conexiones se indican mediante la sintaxis host:puerto->hostremoto:puerto. Al igual que con netstat si encontramos líneas que contengan un asterísco en el nombre del host seguido de un nombre de puerto tal que así *:ftp indicará en nuestro caso que estamos corriendo el servicio ftp pero con ninguna conexión activa en ese momento.

Si queremos restringir la salida a una determinada dirección podremos hacerlo mediante la siguiente sintaxis:

# lsof -i [4 | 6] [protocolo] [@nombrehost | direcciónIP] [:servicio | puerto]

Nota: 4 o 6 indica si es IPv4 o IPv6. Para indicar un protocolo servicio o puerto podremos guiarnos por la información del archivo /etc/services

Para realizar una auditoria general de las conexiones de red del sistema, debería escribir lsof -i, sin restringir la salida. De esta manera podremos ver conexiones sospechosas a las que deberemos de prestaler especial atención.No obstante podremos restringir las salidas con comandos como:

# lsof -i :ftp

Este comando mostrará todas las conexiones entrantes o salientes del puerto 21. Si no obtenemos salida queda claro que no existen conexiones.

# lsof -i |grep LISTEN

Mediante el uso de la tubería del ejemplo anterior podremos localizar directamente que servidores se encuentran a la escucha.

Nota: Si ejecutamos lsof como usuario normal solo veremos las conexiones relacionadas con nuestra propia red. Lo ideal es ejecutarlo con root.

  • nmap: El utilitario nmap es un escaner de puertos abiertos tanto del ordenador local como de un ordenador remoto.  El comando nmap trabaja por defecto con paquetes SYN, paquetes que intentan abrir conexiones bajo TCP. Cuando escaneamos puertos con nmap podemos encontrarnos con tres estados diferentes del puerto: OPEN (abierto), CLOSE (cerrado) o FILTERED (puerto no accesible, un cortafuego lo está filtrando).

Como la gran mayoría de herramientas Linux, nmap admite varias opciones, permitiendo incluso exámenes “secretos” que probablemente no detecten la mayoría de los cortafuegos y exámenes mediante ping (# nmap -sP <IP>, si usamos la opción -n evitamos conversiones DNS por lo que el examen será mas rápido) para detectar que host están activos. Vamos a tratar las opciones de nmap como modificadores entre los que destacan -sS que realiza un escáner que no deja registro en el sistema (requiere usuario privilegiado), -sT realiza un barrido de puertos TCP (no necesita ser ejecutado con root), -sU provoca un barrido de puertos UDP útil si necesitamos conocer puertos de nivel superior que pueden estar tras un firewall (realiza exámenes mas exactos), -sA usa paquetes ACK para lograr que el sistema responda (muchos firewall no filtran estos mensajes, por lo que podemos detectar puertos abiertos mas sutilmente), -sN y -sF puedes pasar un firewall mal configurado y permitirnos ver que servicios se están ejecutando en el sistema. Por último -sV que intenta identificar los servicios en relación con los puertos abiertos (puede detectar vulnerabilidades).

Utilidades como Nessus (otro escaner de puertos montado sobre nmap) ofrecen una GUI y medios para realizar pruebas automatizadas y mas sofisticadas que las que proporciona nmap. Pueden incluso  localizar vulnerabilidades conocidas, de modo que pueden indicar si un servidor esta en riesgo. Nessus puede funcionar tanto como cliente como de servidor. Será el cliente quien controle al servidor, que es quien realmente hace el trabajo.

Nota: Cuando utilicemos un scaner de red, deberemos de tener presente que los puertos que vemos desde nuestro sistema pueden no ser los mismos que ve un atacante. Es un detalle a tener en cuenta si el sistema que estamos probando esta trás un cortafuego. Es probable que nuestro equipo de pruebas revele puertos que realmente no son accesibles desde el exterior.

 

Examinar el tráfico de red sin procesar

Para examinar el tráfico de red, lo normal es usar un sniffer (husmeador), que son herramientas avanzadas para la resolución y diagnóstico de problemas en redes, ya que proporcionan una gran cantidad de información. Linux nos ofrece muchas herramientas para tal fin, pero la que se abarca en el exámen es tcpdump, no obstante veremos alguna otra como Wireshark (antes conocido como Ethereal).

tcpdump puede interceptar paquetes de red para registrarlos o mostrarlos por pantalla o, incluso almacenar los resultados en un archivo para su posterior estudio, siempre que empleemos la opción -w.

Para ejecutar tcpdump necesitaremos ser el administrador del sistema (root) y basta con escribir el nombre del comando (# tcpdump) aunque podemos modificar la salida con algunas opciones. Si queremos mostrar el contenido de los paquetes en código ASCII deberemos de indicarlo con -A. Para mostrar una lista de interfaces en las que puede escuchar tcpdump usaremos -D. Como en muchos comandos de los anteriormente estudiados, si empleamos la opción -n obtendremos salidas con direcciones IP en lugar de nombres y al igual pasa con la opción -v (o -vv, -vvv) de otros comandos, con la que podremos ampliar la información.

Por lo general las líneas de salida del comando tcpdump suelen ser extensas e incluso pueden llegar a ocupar mas de una línea de la pantalla. Suelen incluir una marca temporal, un identificador de pila, el nombre o la IP y el puerto del sistema de origen y destino (respectivamente) e información específica del paquete. Podemos usar la opción -c <num> para que muestre solo un número determinado de paquetes y luego finalice, al igual que hacemos con el comando ping, o pulsar directamente Control+C para finalizar la ejecución del comando.

Wireshark es un analizador de protocolos utilizado para realizar análisis y solucionar problemas en redes de comunicaciones. La funcionalidad que provee es similar a la de tcpdump, pero añade una interfaz gráfica y muchas opciones de organización y filtrado de información. Permite ver todo el tráfico que pasa a través de una red (usualmente una red Ethernet, aunque es compatible con algunas otras) estableciendo la configuración en modo promiscuo. También incluye una versión basada en texto llamada tshark.

Uso de herramientas adicionales

Existen otras herramientas que aunque no fueron diseñadas para la depuración de la red, pueden resultarnos útiles para deducir cierta información sobre la configuración de aspectos particulares de cierto ordenador, como por ejemplo comprobar si tiene un puerto específico abierto. Estas herramientas pueden ser Telnet y ftp.

Telnet es una herramienta de acceso remoto. No se recomienda su uso para tal fin ya que carece de encriptación. Por regla general debería de eliminar el servidor Telnet de su sistema y no utilizar nunca el programa cliente telnet. El programa SSH es una alternativa mucho mas segura para conexiones remotas. Estudiaremos el programa SSH en el capítulo 10. No obstante vamos a utilizar telnet en este caso para comprobar si una máquina dispone de un puerto abierto, como ya adelantábamos. Por ejemplo vamos a comprobar si el equipo ‘freeser‘ permite el acceso por el puerto 25 (puerto utilizado por SMTP)

# telnet freeser 25

Si obtenemos el mensaje de error Connection refused (conexión rechazada) indicará que el servidor remoto no está en ejecución o es inaccesible (puede que un firewall esté filtrando el puerto).

Nota: Esta prueba sólo funciona con protocolos que utilizan TCP

De la misma manera, el programa ftp como ya mencionamos puede sernos util por ejemplo para comprobar si tenemos acceso a una máquina por el puerto 21, o incluso para comprobar el tiempo de transferencia y la velocidad de la red. Para esto tendremos que conectar primero con el servidor:

# ftp freeser

Nos aparecerá un prompt que aceptará comandos como (cd, get, put, ls, etc…) nosotros usaremos get y put. Una vez estemos en el directorio donde se aloja un archivo de peso (ideal para comprobar las tasas), lo descargaremos a nuestro sistema con el comando get <archivo>. Si lo que queremos es comprobar la subida usaremos put <archivo> para subir un archivo desde nuestro sistema.

Al igual que Telnet, FTP es una pobre elección como protocolo por motivos de seguridad.


 

Capítulo 8

 

Licencia Creative Commons
Curso LPIC-1 400 Capítulo 8 por nebul4ck se distribuye bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.


4 comentarios

  1. qromsat dice:

    Aviso a navegantes: si tu distribución Linux utiliza como sistema de inicialización el paquete de arranque systemd, es posible que a la hora de acceder a tus interfaces de red te lleves la sorpresa de que no tienen cualquiera de los nombres que siempre hemos conocido, como son: eth0 (para la tarjeta de red Ethernet), wlan0 (para la tarjeta Wifi), y cosas así,… y, en vez de ello, te aparezcan nombres tan extraños como: eno1, enp2s0 o enxb827a4564ad4. Esto se debe a un cambio a la hora de nombrar las interfaces de red que llegó a partir de la versión 197 de systemd. Y para ver cuál es tu versión tan sólo tienes que ejecutar en la terminal el siguiente comando: $ systemd –version
    A partir de esa versión systemd/udev sigue un sistema de prelación por el cual asigna el nombre final de la interfaz de red. Ese sistema de prelación es el siguiente:

    1º. Nombres que incorporan información del Firmware o BIOS del hardware (ejemplo: eno1)
    2º. Nombres que incorporan información del Firmware o BIOS que proporciona el slot PCI Express (ejemplo: ens1)
    3º. Nombres que incorporan ubicación física del conector (ejemplo: enp2s0)
    4º. Nombres que incorporan la dirección MAC de las interfaces (ejemplo: enx78f8d1ea46da)
    5º. El estilo clásico del kernel (ejemplo: eth1)

    Con todo esto lo que se persigue es dar más estabilidad a la hora de nombrar a las interfaces de red. Pero esto, como casi todo en Linux, se puede desactivar.
    Aquí dejo algunos enlaces para mayor información:
    http://eithel-inside.blogspot.com.es/2016/02/nombres-de-interfaz-de-red-predictivos.html
    https://wiki.archlinux.org/index.php/Network_configuration_(Espa%C3%B1ol)
    https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

    Me gusta

  2. […] LPIC-1 Capítulo 8. – Pila TCP/IP, Puertos de red, dotted quad y CIDR, subnetting, diagnosticar la red… […]

    Me gusta

Deja un comentario, Gracias!

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: