Problemas básicos con Redes en Linux

Al haber tantos servicios, librerías y herramientas, es normal que hayan errores. Ya sea por malas configuraciones, incompatibilidad o errores de tipeo. En este apartado estaremos indagando sobre los posibles problemas básicos con redes que se pueden presentar en Linux. Si desea saber sobre el funcionamiento de algún comando de diagnóstico puede verlo en uno de los apartados anteriores.

Problemas de Resolución de Nombres

Si tenemos un problema de red, por ejemplo, supongamos que hacemos ping a un determinado host como google.com y no obtenemos respuesta, podemos hacer ping al dns de google que es 8.8.8.8:

Como podemos ver, hemos obtenido una respuesta icmp, entonces seguramente tenemos un Problema de resolución de nombres. Este representa uno de los problemas básicos con redes en linux, ya que se da cuando una aplicación no puede traducir de nombres de dominio a direcciones IP. Es importante recordar que la manera que tendrán la mayoría de las aplicaciones en Linux para resolver nombres está determinada por el archivo /etc/nsswitch.conf

# /etc/nsswitch.conf | grep hosts

Podemos ver en la respuesta que tenemos “files” y al final “dns”. Esto significa que la resolución se realizará primero mediante el archivo /etc/hosts y luego usando DNS. Si el nombre no está en dicho archivo, entonces se realizará una consulta DNS. En cuyo caso se usará el archivo /etc/resolv.conf, el cual contiene las entradas DNS que ayudan a nuestro sistema Linux a resolver nombres de dominio en direcciones IP. En el caso de que este no se encuentre, crearemos uno, y si existe podríamos configurarlo agregando los dns de un servidor o el dns público de google.

Veamos estas dos opciones:

# cat /etc/resolv.conf

Luego guardamos los cambios y reiniciamos el servicio resuelto por el sistema como vemos a continuación. También puede ser conveniente reiniciar el equipo completo.

# systemctl restart systemd-resolved.service

Estado de Salida

En el caso que la configuración anterior siga fallando, puede ser conveniente usar una herramienta que nos den un diagnóstico más completo:

El estado de salida de getent (2) nos dice que no podemos encontrar ninguna entrada para dns.google.com. Sin embargo, aún no es suficiente, entonces hay que usar alguna herramienta más específica como pueden ser los comandos host, dig o nslookup. Estas herramientas NO consultan el archivo /etc/hosts, sino que consultan directamente a los servidores DNS especificados en el archivo /etc/resolv.conf (o en la configuración de la interfaz).

# host google.com

Si obtenemos un error, podemos consultar por cada servidor específicamente para ver si es alguno de ellos el que está fallando:

# host 172.27.2.10

Servicios que interfieren

Otros de los problemas básicos con redes que suelen ocurrir en linux, es que los servicios interfieran con la configuración que tenemos. Entonces de ser necesario se pueden detener y deshabilitar. Es importante revisarlos para ver si están en correcto funcionamiento.

Algunos de ellos son:

• resolvconf.
• rdnssd.
• systemd-resolved.

Resolución paralela de IPv4/IPv6

Desde la versión 2.10 de glibc, esta librería realiza en paralelo consultas usando IPv4 e IPv6. Hay servidores que pueden manejar de manera inapropiada este modo, por lo tanto, se puede deshabilitar agregando en el archivo de configuración /etc/resolv.conf: options single-request

Problema en la configuración del Firewall

El caso de que la configuración anterior siga fallando, otro de los problemas básicos con redes, puede ser debido a las restricciones del Firewall que impide la resolución de dns en linux. Para verificar esto, primero debemos testear si los puertos 53 (usado para DNS – Resolución de nombres de dominio) y el puerto 43 (Usado para búsqueda de whois) están abiertos. En caso de estar bloqueados podemos abrirlos de la siguiente forma.

Para Firewall UFW (Uncomplicated Firewall) de distribuciones basadas Debian/Ubuntu y Mint, haremos:

#ufw allow 53/tcp ; ufw allow 43/tcp ; ufw reload

Para firewalld (RHEL / CentOS / Fedora) es decir sistemas basados en distribuciones Red Hat, haremos:

#firewall-cmd –add-port=53/tcp –permanent ; firewall-cmd –add-port=43/tcp –permanent

#firewall-cmd –reload

En cuanto al firewall de Linux netfilter/iptables podría estar rechazando o descartando paquetes. Una manera rápida de verificarlo, es realizar lo siguiente en el host que no puede recbir paquetes:

# iptables -P INPUT ACCEPT; iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -F; iptables -X

Cabe aclarar que es importante tener en cuenta que solo debemos realizar esto como proceso de resolución de problemas. Desactivar las reglas de iptables en un host expuesto en Internet, es muy peligroso .

Para Resumir

El problema de resolución de dns puede ser causado por una mala configuración en el archivo /etc/resolv.conf, algún servicio que esté interfiriendo en dicha configuración como los mencionados anteriormente (para lo cual se pueden usar herramientas como host, nslookup, dig) y también, las restricciones que podemos tener en nuestro firewall.

Problemas de Enlace

Uno de los problemas básicos con redes que suelen darse en linux, son aquellos relacionados con las conexiones. Por tato, uno de los métodos más comunes para probar la conectividad a través de múltiples redes es el comando ping. Esta herramienta envía paquetes “ICMP echo” que solicitan una respuesta “ICMP echo-reply” correspondiente del dispositivo en la dirección de destino. Por ejemplo:

# ping -c3 192.168.1.3

También podemos intentarlo con ping6 para ipv6:

# ping6 -I eth1 -c10 ff02::1

En el último ejemplo vemos que el comando ping nos permite seleccionar la interfaz de red en el caso que tengamos más de una. Entonces esto nos puede servir para determinar si el problema está en una interfaz específica.

Una falta de respuesta de ping podría ser debido a:

• Hay un enrutamiento incorrecto. Compruebe las rutas y las máscaras de subred en ambos lados, los servidores locales y remotos, también los routers del medio. Un síntoma clásico de rutas incorrectas en un servidor es la capacidad de sólo hacer ping a los servidores de la red local y no a ninguna otra parte. Podemos usar el comando traceroute para verificar que se está tomando el camino correcto.
• El dispositivo origen o destino tiene una dirección IP o una máscara de subred incorrecta.
• Un servidor con esa dirección IP no existe.
• El servidor ha sido configurado para no responder a consultas de ping.
• Un firewall o router a lo largo de la ruta de red está bloqueando el tráfico ICMP.

Verificar las interfaces

Si seguimos con fallas podríamos usar el comando ip link show, como también el comando ifconfig –a.

También, la herramienta ethtool proporciona mucha información. A continuación podemos ver los parámetros esenciales para verificar su correcto funcionamiento.

Podríamos complementar con el comando ip addr para verificar las direcciones y máscaras de red. Debemos tener en cuenta, como mencionamos en la introducción. Muchos problemas básicos en redes se deben a características ausentes o no configuradas del driver en linux. Por lo tanto, suponiendo que tenemos una interfaz etho, podemos verificarlo de la siguiente manera:

#ethtool -i eth0

Ese comando nos dará el módulo del kernel que usa la interfaz, y podemos consultar la documentación del mismo en el caso que sea necesario modificar algún parámetro o actualizarlo. En ocasiones, ciertos parámetros del kernel pueden estar seteados de manera incorrecta. Dichos parámetros se pueden encontrar en el directorio /proc/sys. Por ejemplo, para permitir que los paquetes de una interfaz sean retransmitidos a otra interfaz de red, el archivo /prov/sys/net/ipv4/ip_forward debe estar con un valor igual a 1. Entonces podríamos hacer:

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

O bien con el comando:

#sysctl -w net.ipv.ip_forward

Cuando un host en Linux se comporta como router, es imprescindible que ese parámetro esté habilitado. Podemos ver el resto de los parámetros con sysctl -A. Si queremos que los cambios queden persistentes debería guardarse el parámetro en algún archivo de configuración: /etc/sysctl.conf o /etc/sysctl.d .

Verifiacar configuraciones guardadas

En distribuciones basadas en Red Hat (por ejemplo Fedora y CentOS) hay que revisar los archivos /etc/sysconfig/network-scripts/ifcfg-* y en las derivadas de Debian los archivos /etc/network/interfaces y /etc/network/interfaces.d/* .

Sumado a esto, es muy importante verificar si la interfaz está administrado por Network-Manager. Ya que una mala configuración aquí, puede suponer uno de los problemas básicos con redes o interfaces de red en Linux. Esto lo verificamos de la siguiente manera:

# nmcli device status

En este caso hay que tener en cuenta que la configuración automática de NetworkManager podría interferir con la que se realiza por archivos.

Estado de Cableado

En la mayoría de los casos, la falta de un enlace es debido al uso equivocado del tipo de cable. Para Ethernet, por ejemplo hay dos tipos de cables, uno es “crossover” y el otro es “straight-through”. Otras fuentes de fallo relacionadas también pueden ser:

• Mala conexión de los cables.

• Mal estado de los cables.

• El router o modem al que está conectado el servidor se encuentra apagado.

La inversión en un probador de cable es esencial para realizar pruebas y evitar dicos problemas básicos de conectividad con redes en Linux, en el caso de contar con una red extensa. Los modelos más sofisticados en el mercado pueden indicar la ubicación aproximada donde ocurre la rotura del cable, también cuando un cable Ethernet es demasiado largo para ser utilizado.

Problema de Ruteo

Recordemos que con el comando ip route podemos verificar la tabla de ruteo. Sin embargo, como hemos visto anteriormente, la herramienta traceroute juega un papel importante aquí. Este comando es útil para ver los router intermedios que existen para llegar a un determinado destino en la capa de interntet, como asi también, para detectar cuellos de botella.

¿Cómo funciona esta herramienta?

Cuando usamos el comando ping podemos verificar que nos devuelve información sobre los TTL e ICMP. Este comando envía series de 3 datagramas en paralelo cada vez con un tiempo de vida decreciente. De manera predeterminada el TTL (tiempo de vida) del primer paquete IP es 1, mientras que el último es 30.

Cada vez que un paquete llega a un nuevo router pierde un TTL, por lo tanto decrece en una unidad de vida. Tomando como ejemplo la tercera tanda de paquetes, haría lo siguiente:

Punto de origen TTL = 3  Router 1 TTL – 1 = 2  Router 2 TTL -1 = 1  Router 3 TTL-1 = 0 y se envía un paquete icmp de tipo “time exceeded”, avisando a la máquina de origen que ha habido un error en la llegada de paquetes. Cada paquete espera hasta 5 segundos para que el Gateway responda. Por defecto traceroute utiliza paquetes UDP, sin embargo podemos cambiar esta opción. Hay firewalls que descartan datagramas traceroute.

En ese caso se puede probar con TCP o directamente con ICMP, como se ve respectivamente a continuación:

Otras opciones pueden ser:

Fallos en alcanzar su destino

1) La máquina o servidor destino no existe en la red. Podría estar desconectado o apagado. (Se pueden producir los mensajes !H o N!).

2) La red en la que se espera que el host destino puede residir no existe en la tabla de enrutamiento de uno de los routers en el camino. (Se pueden producir los errores !H o !N).

3) Puede haber un error tipográfico en la dirección IP del servidor de destino.

4) Puede haber un bucle de enrutamiento en que los paquetes “rebotan” entre dos routers y nunca llegan al destino deseado.

5) Los paquetes traceroute están siendo bloqueando por un router en el camino. El router inmediatamente después del último visible suele ser el culpable. Por lo tanto es bueno revisar la tabla de enrutamiento y/o cualquier otro estado de este siguiente dispositivo en la ruta.

6) Los paquetes no tienen una ruta apropiada de retorno a nuestro servidor. El último nodo visible es aquel en el que los paquetes vuelven correctamente. El router inmediatamente después del último nodo visible es en el que el enrutamiento cambia.

Prácticas Recomendadas

Por lo general es bueno hacer lo siguiente:

• Iniciar sesión en el último nodo enrutador visible.

• Mirar la tabla de enrutamiento para determinar cuál es el siguiente nodo destino previsto.

• Iniciar sesión en el siguiente router.

• Hacer un traceroute desde este router hacia servidor destino previsto.

• Si esto funciona: El enrutamiento hacia servidor de destino está bien. Hacer un traceroute de nuevo hacia nuestro servidor de origen. Entonces probablemente el traceroute fallará en el router malo que se encuentra en el camino de regreso.

• Si esto no funciona: Hay que probar la tabla de enrutamiento y/o cualquier estado de todos los nodos entre este y el destino previsto.

Cabe mencionar que, por lo general los sistemas Linux suelen tener un TTL aproximado de 64 y, los sistemas Windows un TTL de 124 aproximadamente. Además, contamos con los comandos tracepath y tracepath6 , similares a traceroute y traceroute6 respectivamente, pero no necesitan privilegios de root y tienen menos funcionalidades.

Bufferbloat

Como hemos visto, nuestro router está constantemente recibiendo y enviando paquetes. Todos estos que entran y salen son analizados por el router, y reenviados a la dirección apropiada. Sin embargo, llega un momento en el que hay demasiados paquetes circulando y el router no va a poder gestionarlos todos. En este caso suele producirse lo que conocemos como “embotellamiento”. Estos cuellos de botella son otros de los problemas básicos con redes en sistemas Linux.

Este problema se traduce en una pérdida de paquetes, lo que suele ser muy conflictivo porque genera que el sistema funcione más lento y genere trabas debido al aumento de tráfico. Por tal motivo, hay que volver a pedir el mismo paquete al servidor, incluso hay que empezar de nuevo el proceso. No obstante, ante estos problemas, los routers poseen una memoria interna o buffer donde se guardan los paquetes que no pueden ser recibidos al instante. Por lo tanto, en cuanto el router está libre, toma un paquete del buffer y lo gestiona. Incluso en momentos de mucha carga el router puede dedicar más tiempo a gestionar el buffer que los paquetes en si.

Cuando los buffers dejan de absorber ráfagas de paquetes y solamente introducen demoras. En estos casos, incrementar el ancho de banda no solamente NO mejora las cosas, sino que las puede empeorar. Lo más importante es verificar que el algoritmo utilizado en la disciplina de paquetes de red (qdisc) sea SQM.

Las qdisc’s que usan SQM son:

• cake.

• fq_codel.

• pie.

En el documento CoDel Overview hay más información al respecto. También, se puede probar como alternativa modificar el valor de la cola de transmisión de paquetes:

# ip link set dev wlp2s0 txqueuelen 100

Limpiar la Configuración

Cuando estamos ante un problema general en que todo falla y estamos trabajando de manera local sobre el equipo, o bien con una máquina virtual, podemos borrar la configuración actual:

1. ip addr flush dev eth0
2. ip route flush dev eth0
3. ip rule flush

Podemos hacer lo mismo con cada interfaz.

Presencia de Cliente DHCP

A veces puede ser que un cliente DHCP esté corriendo en el host causando que se ignoren nuestras configuraciones. En caso de que no necesitemos tener un cliente dhcp corriendo podemos matar el proceso y/o detener y deshabilitar el servicio. A veces, también como en el siguiente ejemplo, podemos desinstalar el paquete en Debian:

# apt remove – -purge packet

Restricciones

Las restricciones suelen ser uno de los problemas básicos con redes en Linux, ya que son los encargamos de «acceder y denegar» parámetros específicos dentro de ciertas configuraciones en los archivos de los sistema. A continuación veremos ejemplo de estos:

Restricción por TCP Wrapper

Existe una herramienta llamada tcpd también conocida como TCP Wrapper que puede bloquear la solicitud para utilizar determinados servicios de acuerdo a la coincidencia con un patrón determinado.

El programa tcpd usa los archivos /etc/hosts.allow y /etc/hosts.deny . Los cuales funcionan de la siguiente manera:

• Primero lee el archivo /etc/hosts.allow, y si existe alguna regla coincidente se permitirá el acceso.

• Si no hay coincidencias, lee el archivo /etc/hosts.deny y si existe alguna regla que coincida se denegará el acceso.

• Si tampoco hay coincidencias, se permite el acceso.

También se puede denegar desde el archivo /etc/hosts.allow y manejar todo desde allí. A continuación veremos las opciones y funciones que estos poseen:

Restricción por inetd

Este programa invoca todos los servicios de internet de acuerdo a la demanda. En la actualidad se lo usa rara vez. Si un servicio está configurado para correr con inetd pero no está presente en el archivo de configuración de inetd, entonces no estará activo. Las líneas siguientes muestran como habría que activar ssh y tftp desde inetd:

ssh stream tcp nowait root /usr/sbin/sshd –I tftp dgram udp wait root /usr/sbin/tcpd in.tftpd

Restricción por xinetd

Existe un servicio llamado xinetd que cada vez se usa menos, pero que podría estar activo. Dicho servicio es usado para controlar varios servicios a la vez e imponer ciertas restricciones. Por ejemplo, consideremos el archivo /etc/xinetd.d/ssh con el siguiente contenido:

service ssh

{

socket_type = stream

wait = no

user = root

server = /usr/sbin/sshd

server_args = -i

log_on_failure += USERID

disable = not

cps = 3 10

per_source = 1

}

Hace que el acceso a ssh permita solamente 3 conexiónes a la vez, y el servicio queda deshabilitado por 10 segundos. Además, se permite el acceso desde una sola dirección IP a la vez.