SSH – Llaves privadas y públicas

Key Authentication

Si un servidor SSH es visible a través de Internet, en lugar de las contraseñas, se recomienda utilizar la autenticación mediante llave pública.

Con la autenticación mediante llave pública, cada equipo tiene una llave privada y cada equipo remoto de confianza una llave pública (un gran número con propiedades particularmente matemáticas).

La llave privada se mantiene en el equipo de confianza desde el cual hacemos ingreso, mientras que la llave pública se almacena en el archivo .ssh/authorized_keys dentro de todos los equipos a los cuales se necesita ingreso para iniciar sesión.

Cuando se ingresa a otro equipo, el servidor SSH utiliza la llave pública para “bloquear” los mensajes de una manera que sólo pueden ser “desbloqueados” con nuestra propia llave privada – esto significa que incluso el atacante más curioso le será muy difícil espiar, o interferir con nuestra sesión.

Passphrase

Como medida de seguridad adicional, los programas SSH pueden almacenar la llave privada en un formato de contraseña-protegida, de modo que si el equipo es robado o quebrantado, se puede tener un tiempo suficiente para desactivar nuestra llave pública, antes de que terceros puedan romper la contraseña e iniciar sesióon utilizando nuestra propia llave privada.

Bruteforce

Las llaves son mucho más difíciles de quebrantar mediante la fuerza bruta, o de suponer contraseñas simples, presentan longitud de llave amplia de la clave.

Key Pairs

La autenticación mediante llaves utiliza “dos llaves”, una llave “pública” que nadie pueda ver, y otra llave “privada” que sólo cada propietario pueda ver. Para lograr una comunicación segura con otro equipo, mediante la autenticación basada en llaves, se debe crear una llave pública para cada equipo que se necesite acceder, de la misma manera se debe copiar de manera segura la llave pública que le vamos a confiar.

mkdir ~/.ssh

chmod 700 ~/.ssh
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -P "" -q
-f

Define el nomnbre de archivo de la llave.

-q

Genera las llaves en silencio.

-P

Proporciona la contraseña-protegida vieja.

Transferir la llave cliente al equipo

La llave que hay que transferir al otro equipo de confianza es la llave pública. Si podemos ingresar a otro equipo a través de SSH mediante una contraseña, entonces sí se puede transferir nuestra clave RSA desde nuestro propio ordenador:

ssh-copy-id user@example
ssh-copy-id -i ~/.ssh/id_rsa.pub user@example.com

Si el directorio ~/.ssh sí existe en el equipo remoto:

cat ~/.ssh/id_rsa.pub | ssh user@example.com 'cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys_original_backup; cat >> ~/.ssh/authorized_keys'
cat ~/.ssh/id_rsa.pub | ssh user@example.com 'cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys_original_`date +%F_%T | sed 's/[:-]/_/g'`; cat >> ~/.ssh/authorized_keys'

Si el directorio ~/.ssh no existe en el equipo remoto:

cat ~/.ssh/id_rsa.pub | ssh user@example.com 'mkdir ~/.ssh; chmod 700 ~/.ssh; cat >> ~/.ssh/authorized_keys'

Una vez que hay confianza en la autenticación mediante llaves los comandos como: ssh, rsync y scp se pueden usar con o sin el archivo de identidad o llave privada.

SCP

scp ~/scp.txt user@example.com:~/scp.txt
scp ~/scp.txt user@example.com:~/scp.txt_`date +%F_%T | sed 's/[:-]/_/g'`
scp -o IdentityFile=/home/user/.ssh/id_rsa -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ~/scp.txt user@example.com:~/scp.txt
scp -o IdentityFile=/home/user/.ssh/id_rsa -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ~/scp.txt user@example.com:~/scp.txt_`date +%F_%T | sed 's/[:-]/_/g'`

SSH

ssh user@example.com 'ls -la ~/'
ssh -i /home/user/.ssh/id_rsa -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@example.com 'ls -la ~/'

RSYNC

Las opciones SSH son esenciales para correr Rsync en silencio:

rsync --timeout=30 -q -e "ssh -i /home/user/.ssh/id_rsa -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" ~/rsync.txt user@example.com:~/rsync.txt_`date +%F_%T | sed 's/[:-]/_/g'`

El fin

ssh user@example.com 'rm -rf ~/scp.txt*; rm -rf ~/rsync.txt*; ls -la ~/'

Linux – Arbol de directorios y tamaños de archivos

“tree” usando “ls”:

ls -R /etc | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\//--/g' -e 's/^/   /' -e 's/-/|/'

Los archivos/directorios de mayor tamaño dentro de /var:

du -a /var | sort -nr | head -n20
for i in G M K; do du -ah /var | grep [0-9]$i | sort -k1 -nr; done | head -n20

Sólo los archivos de mayor tamaño dentro de /var:

find /var -type f -ls | sort -k7 -nr | awk '{print $7 " " $11}' | head -n20

Sólo los archivos de iguales o mayores a cierto tamaño dentro de /var:

find /var -type f -size +1024k -exec ls -lh {} \; | awk '{ print $5 ": " $9 }' | sort -k1 -hr | head -n20
find /var -type f -size +5M -exec ls -lh {} \; | awk '{ print $5 ": " $9 }' | sort -k1 -hr | head -n20

Encontrar los 25 archivos mayores a 1024kB que existen dentro de /var/log:

find /var/log -type f -size +1024k -exec ls -lS {} \+ | head -n25

Directorios iguales o mayores a 1GB:

du -h / | grep ^[0-9.]*G
find / -type d -size +1G

Direcotorios iguales o mayores a 10GB:

du -h / | grep ^[1-9][0-9][0-9.]*G | sort -rn

Direcotorios iguales omayores a 200GB:

du -h / | grep ^[2-9][0-9][0-9][0-9.]*G

Listar los 10 archivos de mayor tamaño (sin directorios), en el directorio actual, de manera recursiva:

find . -printf '%s %p\n' | sort -nr | head -n20

Para restringir el resultado al directorio actual:

find . -maxdepth 1 -printf '%s %p\n'|sort -nr| head -n20

Para listar los 20 archivos-directorio mayores en tamaño:

du -a . | sort -nr | head -n20

Encontrar los 25 directorios de mayor tamaño, de manera recursiva, en el directorio actual:

du -sm */ | sort -rn | head -n25

Encontrar los 25 directorios de mayor tamaño, de menera recursiva, dentro del directorio /var/log/:

du -sm /var/log/* | sort -k1rn | head -n25

El tamaño total de /var/log:

du -sm /var/log
du -sh /var/log

Por favor consulte:

Linux – Encontrando lo recién modificado

Ordenados en orden inverso al tiempo de actualización (es decir, los archivos recientes de primero):

find /etc -type f -printf '%TY-%Tm-%Td %TT %p\n' | sort -r | more
find /etc -type f -exec stat --format '%Y :%y %n' {} \; | sort -nr | cut -d: -f2- | head -n50

Uso de -print0 para soportar espacios y también “linefeeds” en los nombres de archivo:

find /etc -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head -n50

Utilizando stat estando en el directorio actual:

stat --printf="%y %n\n" $(ls -tr $(find * -type f)) | sort -k1 -k2 -r | head -n50

Para buscar archivos dentro de /etc y todos sus sub-directorios, los archivos que hayan sido modificado en los últimos 45 minutos:

find /etc -type f -mmin -45

Para buscar archivos dentro de /etc y todos sus sub-directorios, los archivos que hayan sido modificado en los últimos 7 días:

find /etc -type f -mtime -7
for f in `find /etc -type f -mtime -7`; do ls -l $f; done

Por favor consulte:

Linux – Niveles de ejecución y Servicios

SysV Init Runlevels

El sistema de niveles de ejecución SysV init provee un proceso estándar para controlar cuáles programas init lanza o detiene cuando se inicializa un nivel de ejecución. SysV init fué escogido porque es más fácil de usar y más flexible que el proceso init estilo-BSD tradicional.

Los archivos de configuración para SysV init están en el directorio /etc/rc.d/

Dentro se encuentran los scripts:

  • rc
  • rc.local
  • rc.sysinit
  • rc.serial (opcional)

También se encuentran los siguientes directorios:

init.d/ rc0.d/ rc1.d/ rc2.d/ rc3.d/ rc4.d/ rc5.d/ rc6.d/

El directorio init.d/ contiene los scripts usados ​​por el comando /sbin/init utilizados para controlar los servicios. Cada uno de los directorios numerados representan los seis niveles de ejecución configurados por defecto bajo Red Hat Enterprise Linux.

Runlevels

La idea detrás de los niveles de ejecución SysV init gira alrededor del concepto de que diferentes sistemas se pueden utilizar de diferentes maneras.

Por ejemplo:

  • Un servidor corre de forma más eficiente sin el consumo de recursos del sistema absorbidos por “X Window System”.
  • En ocasiones un sysadmin puede necesitar operar el sistema en un nivel inferior, esto para realizar tareas de diagnóstico, como solucionar daños en el nivel de ejecución 1, en el disco .

Las características de un nivel de ejecución dado determinan qué servicios son detenidos o iniciados por init. Por ejemplo:

  • El nivel de ejecución 1 (single user mode) detiene cualquier servicio de red.
  • Mientras que el nivel 3 arranca estos servicios de red.

Al detener e iniciar diferentes servicios en diversos niveles dado, permite que con init se pueda cambiar de manera fácil el modo de la máquina, sin que el usuario deba arrancar o detener servicios de manera manual.

Por defecto, en Red Hat Enterprise Linux se encuentran definidos los siguientes niveles de ejecución:

0 — Halt

1 — Single-user text mode

2 — Not used (user-definable)

3 — Full multi-user text mode

4 — Not used (user-definable)

5 — Full multi-user graphical mode (with an X-based login screen)

6 — Reboot

En general, usuarios operan Red Hat Enterprise Linux en el nivel de ejecución 3 o en el nivel de ejecución 5. Ambos modos son multi-usuarios. Los usuarios a veces personalizan los niveles de ejecución 2 y 4 para satisfacer necesidades específicas, ya que no se utilizan.

Para conocer el nivel de ejecución por defecto del sistema, busque por la línea similar a la siguiente en la parte superior de

cat /etc/inittab

id: 5: initdefault:

El nivel de ejecución predeterminado en este ejemplo es 5, como lo indica el número después de los primeros dos puntos. Para cambiarlo, se puede modificar /etc/inittab como usuario root.

Advertencia

Hay que tener mucho cuidado cuando se modifica /etc/inittab. Errores muy simples pueden hacer que el sistema deje de arrancar. Si esto ocurre, hay que moverse, por ejemplo, para usar un disquete de arranque, seguidamente entrar en modo de usuario único o entrar en modo de rescate para iniciar el equipo y reparar el archivo.

Por favor consulte:

Imprimir nivel de ejecución actual

who -r

Archivo de configuración del nivel de ejecución

cat /etc/inittab
grep "^id:" /etc/inittab

Verficando el estado de un servicio

Con el parametro “–list” se pueden listar todos los servicios y su actual estado “start-up” en cada configuración de nivel de ejecución (run-level configuration).

chkconfig --list | egrep 'apache|http'

httpd      0:off  1:off  2:on   3:on   4:on   5:on   6:off

Iniciar un servicio en sus niveles de ejecución

chkconfig --level 35 httpd on
chkconfig --list | grep httpd

httpd      0:off 1:off 2:off 3:on 4:off 5:on 6:off

Verificar si un servicio se encuentra encendido

chkconfig rsync

rsync on
chkconfig --list | egrep 'network.*:on'

networking      0:on   1:off  2:off  3:off  4:off  5:off  6:off

Servicios encendidos

chkconfig --list | egrep '(3|5):on'
chkconfig --list | grep '0:on'
chkconfig --list | egrep '[1-6]:on'
chkconfig --list | grep ':on'

Servicios apagados

chkconfig --list | egrep '(3|5):off'
chkconfig --list | grep ':off'

Apagar un servicio en un cierto nivel de ejecución

chkconfig --level 2335 httpd off

Lista de programas escuchando y los puertos que usan

netstat -plnt

En Ubuntu es más simple

service --status-all | grep '?'
service --status-all | grep '+'
service --status-all | grep '-'

Por ejemplo, para verificar el estado de un servicio se puede usar:

service cron status
service networking status
service ssh status
service rsync status
service sudo status
service mysql status
service apache2 status
service monit status
service fail2ban status
service ufw status

¿Dónde está la configuración de los niveles de ejecución?

  • /etc/init es donde viven los archivos de configuración de upstart. Si bien no son scripts en si, en esencia ejecutan lo que sea necesario para reemplazar los scripts sysvinit.
    ls /etc/init
  • /etc/init.d es donde viven todos los scripts sysvinit tradicionales y los scripts compatibles con versiones anteriores de upstart. Los comandos compatibles con versiones anteriores, básicamente se ponen a funcionar usando: service SERVICIO start, Algunos sólo muestran un aviso para que se utilice el comando “service”.
    ls /etc/init.d
  • /etc/init/rc-sysinit.conf se controla la ejecución de los scripts agregados manualmente o con update-rc.d hacia niveles de ejecución tradicionales en /etc/rc*

    cat /etc/init/rc-sysinit.conf

    Instalar y quitar enlaces de scripts estilo System-V

    update-rc.d actualiza los enlaces de los scripts estilo System V/etc/rc{[0-9S]}.d/NN{Name}” cuyo objetivo es el script “/etc/init.d/name“. Estos enlaces son dirigidos por init cuando se cambian los niveles de ejecución, en general se utiliza para iniciar y detener servicios del sistema como demonios. El nivel de ejecución es uno de los niveles de ejecución soportados por init, a saber, {[0-9S]} y NN es el número de secuencia de dos dígitos que determina el lugar de la secuencia donde init ejecutará los scripts.

    man update-rc.d
  • /etc/default tiene archivos de configuración que le permiten controlar el comportamiento de los scripts sysvinit tradicionales y los nuevos scripts upstart.
    ls /etc/default
ls -ld /etc/init.d/rc*

-rwxr-xr-x 1 root root 8635 jul 26  2012 /etc/init.d/rc
-rwxr-xr-x 1 root root  801 jul 26  2012 /etc/init.d/rc.local
-rwxr-xr-x 1 root root  117 jul 26  2012 /etc/init.d/rcS
ls -d /etc/init.d/rc* | xargs file

/etc/init.d/rc:       POSIX shell script, ASCII text executable
/etc/init.d/rc.local: POSIX shell script, ASCII text executable
/etc/init.d/rcS:      POSIX shell script, ASCII text executable
ls -d /etc/rc*.d

/etc/rc0.d  /etc/rc1.d  /etc/rc2.d  /etc/rc3.d  /etc/rc4.d  /etc/rc5.d  /etc/rc6.d  /etc/rcS.d
ls -ld /etc/rc*.d

drwxr-xr-x 2 root root 4096 ago  4 11:51 /etc/rc0.d
drwxr-xr-x 2 root root 4096 ago  4 11:51 /etc/rc1.d
drwxr-xr-x 2 root root 4096 ago  4 11:51 /etc/rc2.d
drwxr-xr-x 2 root root 4096 ago  4 11:51 /etc/rc3.d
drwxr-xr-x 2 root root 4096 ago  4 11:51 /etc/rc4.d
drwxr-xr-x 2 root root 4096 ago  4 11:51 /etc/rc5.d
drwxr-xr-x 2 root root 4096 ago  4 11:51 /etc/rc6.d
drwxr-xr-x 2 root root 4096 may  8 19:07 /etc/rcS.d
find /etc/ -maxdepth 1 -name 'rc[0-5].d' | sort

/etc/rc0.d
/etc/rc1.d
/etc/rc2.d
/etc/rc3.d
/etc/rc4.d
/etc/rc5.d
find /etc/ -maxdepth 1 -name 'rc*' | sort

/etc/rc0.d
/etc/rc1.d
/etc/rc2.d
/etc/rc3.d
/etc/rc4.d
/etc/rc5.d
/etc/rc6.d
/etc/rc.local
/etc/rcS.d
find /etc/ -maxdepth 1 -name 'rc*' | sort | xargs file

/etc/rc0.d:    directory
/etc/rc1.d:    directory
/etc/rc2.d:    directory
/etc/rc3.d:    directory
/etc/rc4.d:    directory
/etc/rc5.d:    directory
/etc/rc6.d:    directory
/etc/rc.local: POSIX shell script, ASCII text executable
/etc/rcS.d:    directory

Por favor consulte:

Linux – Conversando con el aparato

uname -r

0.0.0-0-generic-pae

Versión del Kernel

uname -mrs

Linux 0.0.0-0-generic x86_64
cat /etc/redhat-release
cat /etc/*release

DISTRIB_ID=Josoroma
DISTRIB_RELEASE=00.00
DISTRIB_CODENAME=josoroma
DISTRIB_DESCRIPTION="Josoroma 00.00"
NAME="Ubuntu"
VERSION="00.00, Josoroma"
ID=josoroma
ID_LIKE=debian
PRETTY_NAME="Josoroma (00.00)"
VERSION_ID="00.00"
cat /etc/*version
josoroma/sid
cat /etc/*issue

Josoroma 00.00.0 \n \l
cat /proc/*version

Linux version 0.0.0-0-generic-pae (buildd@josoroma) (gcc version 0.0.0 (Josoroma/Linaro 0.0.0-1josoroma5) )

#77-Josoroma SMP Wed March 00 00:00:00 UTC 2013
lsb_release -a

Distributor ID: Josoroma
Description: Josoroma 00.00
Release: 00.00
Codename: name

Conociendo el hardware

Con lshw se pueden conocer detalles de la configuración de una máquina, por ejemplo:

  • Versión del firmware.
  • Configuración de la placa o tarjeta principal.
  • Versión y velocidad del CPU.
  • Configuración de la caché.
  • Velocidad del bus.

Compatible con

  • DMI (x86 y IA-64).
  • “OpenFirmware device tree” (PowerPC).
  • PCI / AGP.
  • CPUID (x86).
  • IDE / ATA / ATAPI.
  • PCMCIA (sólo probado en x86).
  • SCSI.
  • USB.
lshw -short | egrep -i 'system|processor|System Memory|Bios|display|multimedia|network|disk|volume'

system MacBookPro4,1 (System SKU#)
/0/0 processor Intel(R) Core(TM)2 Duo CPU T9500 @ 2.60GHz
/0/3 processor CPU
/0/6 memory 4GiB System Memory
/0/e memory 1MiB BIOS
/0/100/1/0 display G84M [GeForce 8600M GT]
/0/100/1b multimedia 82801H (ICH8 Family) HD Audio Controller
/0/100/1c.4/0 eth1 network BCM4321 802.11a/b/g/n
/0/100/1c.5/0 eth0 network 88E8058 PCI-E Gigabit Ethernet Controller
/0/2/0.0.0 /dev/cdrom disk DVDRW GSA-S10N
/0/5/0.0.0 /dev/sda disk 200GB Hitachi HTS72202
/0/5/0.0.0/1 volume 2047KiB EFI GPT partition
/0/5/0.0.0/2 /dev/sda2 volume 244MiB Linux filesystem partition
/0/5/0.0.0/3 /dev/sda3 volume 186GiB Non-FS data partition
Por favor consulte:
lshw -class display
lshw -class multimedia
lshw -class network

Información del CPU

cat /proc/cpuinfo | egrep -i 'procesor|vendor|cpu family|model|cpu cores' | sort -u

cpu cores : 2
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU T9500 @ 2.60GHz
vendor_id : GenuineIntel

CPUs

cat /proc/cpuinfo | egrep -i 'proc|vendor|name'

processor : 0
vendor_id : GenuineIntel
model name : Intel(R) Core(TM)2 Duo CPU T9500 @ 2.60GHz
processor : 1
vendor_id : GenuineIntel
model name : Intel(R) Core(TM)2 Duo CPU T9500 @ 2.60GHz

Con el comando lscpu podemos obtener información detallada como:

  • Cantidad de CPUs.
  • Threads (hilos).
  • Cores (núcleos).
  • Sockets (conexiones).
  • Nodos NUMA.
  • Caches de CPU.
  • Familia de CPU.
  • Modelo.
  • bogoMIPS.
  • Orden de bytes y el paso a paso de sysfs y /proc/cpuinfo.

También es compatible con CPUs fuera de línea. Se puede imprimiren un formato “parseable”, incluyendo cómo diferentes memorias de caché son compartidas por CPUs diferentes y también lo qué puede ser alimento para otros programas.

lscpu | egrep -i 'Arch|CPU|Vendor|Model'

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: GenuineIntel
CPU family: 6
Model: 23
CPU MHz: 800.000
NUMA node0 CPU(s): 0,1

La memoria libre y en uso del sistema

cat /proc/meminfo | egrep -i 'Mem(T|F)' | awk '{ printf ( "%.0fMB \n", ($2/1024) ); }';

3935MB
714MB
free -m | grep -i 'mem' | awk '{print $2 "MB " $3 "MB " $4 "MB" }'

3935MB 3221MB 714MB

Slot de la memoria de video

lspci | grep -i 'VGA' | awk '{print $1}'

01:00.0

Cantidad de memoria de video

lspci | grep -i 'VGA' | awk '{print $1}' | xargs lspci -vs | egrep ' prefetchable\) \[size=[0-9]+M' | perl -pe 's/.*size=([0-9]+)M.*/$1/g'

256

Descripcion de la tarjeta de video

lspci -v | grep -i -A12 --color 'VGA'

01:00.0 VGA compatible controller: NVIDIA Corporation G84M [GeForce 8600M GT] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Apple Inc. Device 00a3
Physical Slot: 1
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at d2000000 (32-bit, non-prefetchable) [size=16M]
Memory at c0000000 (64-bit, prefetchable) [size=256M]
Memory at d0000000 (64-bit, non-prefetchable) [size=32M]
I/O ports at 7000 [size=128]
[virtual] Expansion ROM at d3000000 [disabled] [size=128K]
Capabilities:
Kernel driver in use: nvidia
grep -i --color 'memory' /var/log/Xorg.0.log

[ 27.073] (--) NVIDIA(0): Memory: 524288 kBytes
[ 28.105] (II) NVIDIA: Using 768.00 MB of virtual memory for indirect memory access.
[ 28.482] (==) NVIDIA(0): Disabling shared memory pixmaps

Buses PCI

lspci es útil para conocer información sobre los buses PCI en el sistema y los dispositivos que se encuentran conectados a ellos.

Por defecto, se muestra una lista breve de dispositivos. Para informar sobre errores en los controladores de dispositivos PCI o sobre lspci en sí, se recomienda incluir la salida de “lspci-vvx” o mejor aún de “lspci-vvxxx” (sin embargo, ver a continuación las posibles salvedades).

Algunas partes de la salida anterior, especialmente en los modos altamente detallados, probablemente son interesantes sólo para hackers apasionados.

Para conocer las definiciones exactas de los campos, se puede consultar cualquiera de las especificaciones de PCI o el header.h, y también /usr/include/linux/pci.h

Buses USB

lsusb es útil para conocer información sobre los buses USB en el sistema y los dispositivos que se encuentran conectados a ellos.

Con la opción “-v, –verbose“:

Se le dice a lsusb que sea más explícito y que presente información más detallada sobre los dispositivos que se muestran. Esto incluye descriptores de configuración sobre la velocidad actual del dispositivo. Los descriptores de clase se muestran, cuando esté disponible, para las clases de dispositivos USB incluyendo:

  • hub.
  • audio.
  • HID.
  • comunicaciones.
  • tarjetas chip.

Dispositivos SCSI (o hosts) y sus atributos

Utiliza la información de sysfs (desde el Linux kernel serie 2.6 y posteriores) para listar los dispositivos scsi (o hosts) que se encuentren conectados al sistema. Las opciones se pueden usar ​​para controlar la cantidad y el tipo de información de cada dispositivo.

Por defecto, los nombres de los nodos de los dispositivos (por ejemplo, “/dev/sda” o “/dev/root_disk“) se obtienen mediante la anotación de los números mayores y menores para el dispositivo obtenido desde sysfs (por ejemplo, el contenido de “/sys/block/sda/dev“) seguidamente busca una coincidencia en el directorio “/dev“. Esta coincidencia “match by major and minor” permite que los dispositivos con un nombre diferente por causa de udev (por ejemplo) sean informados correctamente en esta utilidad.

En algunas situaciones es muy útil ver el nombre de nodo de dispositivo que Linux produce de forma predeterminada, por esto se ofrece la opción –kname. Un ejemplo donde esta opción puede ser útil es cuando el registro de errores del kernel se reportan los mensajes de error de disco utilizando el nombre del kernel por defecto.

lsscsi --kname

[0:0:0:0]    cd/dvd  HL-DT-ST DVDRW  GSA-S10N  AP12  /dev/sr0 
[2:0:0:0]    disk    ATA      Hitachi HTS72202 DC4A  /dev/sd

Dispositivos de bloques del sistema

lsblk muestra información sobre algunos o todos los dispositivos de bloque especificados. El comando lee el sistema de ficheros sysfs para recopilar información.

Por defecto, lsblk imprime todos los bloques dispositivos de bloque (excepto los discos RAM) con un formato de árbol. Por favor utilice lsblk –help para conocer la lista con todas las columnas disponibles.

lsblk -m

NAME SIZE OWNER GROUP MODE
sr0 1024M root cdrom brw-rw----
sda 149,1G root disk brw-rw----
├─sda1 243M root disk brw-rw----
├─sda2 1K root disk brw-rw----
└─sda5 148,8G root disk brw-rw----
├─scorpion-root (dm-0) 146,8G root disk brw-rw----
└─scorpion-swap_1 (dm-1) 2G root disk brw-rw----
lsblk -f

NAME FSTYPE LABEL MOUNTPOINT
sr0
sda
├─sda1 ext2 /boot
├─sda2
└─sda5 LVM2_member
├─scorpion-root (dm-0) ext4 /
└─scorpion-swap_1 (dm-1) swap [SWAP]

Sondear el hardware presente en el sistema

hwinfo se utiliza para generar un reporte general que más tarde pueda ser utilizado por el equipo de soporte para solucionar problemas.

hwinfo --short --partition 2>&1 | grep '/dev/'

/dev/sda1 Partition
/dev/sda2 Partition
/dev/sda3 Partition
Información disponible:
all, bios, block, bluetooth, braille, bridge, camera, cdrom, chipcard,
cpu, disk, dsl, dvb, fingerprint, floppy, framebuffer, gfxcard, hub,
ide, isapnp, isdn, joystick, keyboard, memory, modem, monitor, mouse,
netcard, network, partition, pci, pcmcia, pcmcia-ctrl, pppoe, printer,
scanner, scsi, smp, sound, storage-ctrl, sys, tape, tv, usb, usb-ctrl,
vbe, wlan, zip
hwinfo --short --cpu 2>&1 | grep -v 'cpu:' | grep -i 'cpu'

Intel(R) Core(TM)2 Duo CPU T9500 @ 2.60GHz, 2400 MHz
Intel(R) Core(TM)2 Duo CPU T9500 @ 2.60GHz, 2600 MHz
hwinfo --disk 2>&1 | egrep -i 'Model|Vendor|Device|Driver|Status' | egrep -v 'Device Files|Device Link'

Model: "Hitachi HTS72202"
Vendor: "Hitachi"
Device: "HTS72202"
Driver: "ata_piix", "sd"
Driver Modules: "ata_piix"
Device File: /dev/sda
Device Number: block 8:0-8:15
Config Status: cfg=new, avail=yes, need=no, active=unknown
hwinfo --gfxcard 2>&1 | egrep -i 'Model:|Vendor:|Device:|Driver:|Modules:|Status:'

Model: "nVidia GeForce 8600M GT"
Vendor: pci 0x10de "nVidia Corporation"
Device: pci 0x0407 "GeForce 8600M GT"
SubVendor: pci 0x106b "Apple Computer Inc."
SubDevice: pci 0x00a3
Driver: "nvidia"
Driver Modules: "nvidia"
Config Status: cfg=new, avail=yes, need=no, active=unknown
hwinfo --memory 2>&1 | egrep -i 'memory size'

Memory Size: 3 GB + 768 MB
hwinfo --netcard 2>&1 | egrep -i 'Model:|^Vendor:|^Device:|Driver:|Device File:|HW Address:|Status:|Cmd:'

Model: "Broadcom BCM4328 802.11a/b/g/n"
Driver: "wl"
Device File: eth1
HW Address: 00:1f:5b:d0:7b:5b
Driver Status: ssb is not active
Driver Activation Cmd: "modprobe ssb"
Driver Status: wl is active
Driver Activation Cmd: "modprobe wl"
Config Status: cfg=new, avail=yes, need=no, active=unknown

Model: "Marvell Yukon 88E8058 PCI-E Gigabit Ethernet Controller"
Driver: "sky2"
Device File: eth0
HW Address: 00:1f:f3:d7:33:a9
Driver Status: sky2 is active
Driver Activation Cmd: "modprobe sky2"
Config Status: cfg=new, avail=yes, need=no, active=unknown
hwinfo --network 2>&1 | egrep -i 'Model:|Driver:|Modules:|Device File:|HW Address:|Link detected:|Config Status'

Model: "Ethernet network interface"
Driver: "sky2"
Driver Modules: "sky2"
Device File: eth0
HW Address: 00:1f:f3:d7:33:a9
Link detected: no
Config Status: cfg=new, avail=yes, need=no, active=unknown

Model: "Ethernet network interface"
Driver: "wl"
Driver Modules: "wl"
Device File: eth1
HW Address: 00:1f:5b:d0:7b:5b
Link detected: yes
Config Status: cfg=new, avail=yes, need=no, active=unknown

Model: "Loopback network interface"
Device File: lo
Link detected: yes
Config Status: cfg=new, avail=yes, need=no, active=unknown
hwinfo --sound 2>&1 | egrep -i 'Model:|Vendor:|Device:|Driver:|Modules:|Status:|Cmd:'

Model: "Intel 82801H (ICH8 Family) HD Audio Controller"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x284b "82801H (ICH8 Family) HD Audio Controller"
SubVendor: pci 0x106b "Apple Computer Inc."
SubDevice: pci 0x00a3
Driver: "snd_hda_intel"
Driver Modules: "snd_hda_intel"
Driver Status: snd_hda_intel is active
Driver Activation Cmd: "modprobe snd_hda_intel"
Config Status: cfg=new, avail=yes, need=no, active=unknow

Tablas de particiones

fdisk -l 2>&1 | egrep -v "warning|doesn't" | egrep 'dev/'

Disk /dev/sda: 200.0 GB, 200049647616 bytes
/dev/sda1 1 4095 2047+ ee GPT
/dev/sda2 * 4096 503807 249856 83 Linux
/dev/sda3 503808 390721535 195108864 da Non-FS data
Disk /dev/mapper/ubuntu--vg-root: 195.5 GB, 195513286656 bytes
Disk /dev/mapper/ubuntu--vg-swap_1: 4273 MB, 4273995776 bytes
cat /proc/partitions

major minor #blocks name

11 0 1048575 sr0
8 0 195360984 sda
8 1 1024 sda1
8 2 249856 sda2
8 3 195108864 sda3
252 0 190930944 dm-0
252 1 4173824 dm-1

Parámetros del hardware de los discos IDE y SATA

hdparm es una utilidad de línea de comandos que permite ver y ajustar los parámetros del hardware de los discos IDE y SATA (aunque los SATA también cuentan con una utilidad específica llamada sdparm). Con esta utilidad se pueden ajustar parámetros como el caché de disco, el modo de descanso, el control de energía, la gestión acústica y los ajustes DMA. Suele venir instalado por defecto en la mayoría de distribuciones GNU/Linux.

hdparm proporciona una interfaz de línea de comandos para diferentes interfaces del kernel que son soportadas por el subsistema Linux SATA/PATA/SAS “libata”, también soporta susbsistemas más viejos de controladores IDE.

Muchos Unidades USB recientes (2008 y posteriores) también son compatibles con “SAT” (Traducción de comandos SCSI-ATA) por lo tanto pueden trabajar con hdparm.

Algunas opciones pueden funcionar correctamente sólo con los núcleos (kernels) más recientes.

hdparm -i /dev/sda | egrep -i 'Model|DMA modes|Drive'

Model=Hitachi HTS722020K9SA00, FwRev=DC4AC77A, SerialNo=080520DP0440DTGJKPZP
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7

Tabla de Contenidos DMI (algunos dicen SMBIOS)

Permite conocer la Tabla de Contenidos DMI (algunos dicen SMBIOS) en un formato legible. Esta tabla contiene una descripción de los componentes de hardware del sistema, así como de otras piezas útiles de información como: números de serie y la revisión del BIOS.

Gracias a la Tabla de Contenidos DMI, se puede recuperar esta información sin tener que probar el hardware actual. Si bien permite un reporte agil y seguro, también puede ser probable que la información presentada algunas veces pueda ser poco fiable.

Por favor consulteHow to Forge: dmidecode

dmidecode -t 16 -t 17 | egrep -i 'capacity|devices|width|size|locator:|type:|speed' | egrep -iv 'error|bank'

Maximum Capacity: 4 GB
Number Of Devices: 2
Total Width: 64 bits
Data Width: 64 bits
Size: 2048 MB
Locator: DIMM0
Type: DDR2
Speed: 667 MHz
Total Width: 64 bits
Data Width: 64 bits
Size: 2048 MB
Locator: DIMM1
Type: DDR2
Speed: 667 MHz

Dispositivos de audio

arecord --list-devices

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC889A Analog [ALC889A Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: ALC889A Digital [ALC889A Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
cat /proc/asound/cards

0 [Intel]: HDA-Intel - HDA Intel
           HDA Intel at 0xdb500000 irq 46
En este caso sólo hay una tarjeta de sonido, la cual es la tarjeta de sonido incorporada HDA-Intel.
ls /proc/asound/card*

/proc/asound/cards

/proc/asound/card0:
codec#0  id  pcm0c  pcm0p  pcm1c  pcm1p  pcm2c

Donde X indica el número de tarjeta, por ejemplo, si se muestra card0 y card1, esto quiere decir que hay dos tarjetas de sonido.

ls -ld /proc/asound/card* | grep ^d

dr-xr-xr-x 7 root root 0 ago 11 11:06 /proc/asound/card0

Cantidad de dispositivos conectados a la tarjeta de sonido

cat /proc/asound/devices

1: : sequencer
2: [ 0- 2]: digital audio capture
3: [ 0- 1]: digital audio playback
4: [ 0- 1]: digital audio capture
5: [ 0- 0]: digital audio playback
6: [ 0- 0]: digital audio capture
7: [ 0- 0]: hardware dependent
8: [ 0] : control
33: : timer

Detalles del módulo del núcleo o del driver para una tarjeta de sonido

El módulo relacionado con la tarjeta de sonido se representa con la cadena de texto “snd” en su nombre. Por lo tanto, si podemos buscar sobre /proc/asound/modules o sobre la salida del comando lsmod, entonces si podremos encontrar fácilmente qué tarjeta de sonido está en uso, por ejemplo:

grep snd /proc/asound/modules

0 snd_hda_intel

La versión de software de la tarjeta de sonido

cat /proc/asound/version

Advanced Linux Sound Architecture Driver Version k0.0.0-0-generic.

Linux networking – Descubriendo vecinos en la red

arp-scan -I eth1 192.168.0.0/24 10.0.0.0/8
nmap -sP 192.168.0.0/24 10.0.0.0/8
fping -g -r1 -s 192.168.0.0/24
arp-scan --interface=eth1 --localnet
for ip in $(seq 1 254); do ping -c1 -w1 192.168.0.$ip &>/dev/null; [ $? -eq 0 ] && echo "192.168.0.$ip"; done
for ip in 192.168.0.{1..254}; do if ping -c1 -w1 $ip &>/dev/null; then echo $ip; fi done

LAN IP

hostname -Iip
ifconfig | grep 'eth0' | tr -s ' ' | cut -d ' ' -f5
ifconfig | grep 'eth1' | tr -s ' ' | cut -d ' ' -f5
cat /sys/class/net/eth0/address
cat /sys/class/net/eth1/address

Router

netstat -r
route -n
traceroute -m 1 -N 1 1.2 | grep ms | perl -nle'/\((\S+)/&&print$1' | tr -d \)

Por favor consulte:

Linux networking – Solución simple de problemas

Es muy probable que la mayoría de los problemas relacionados con la red aparecen de las siguientes dos formas:

Lentitud

  • “NIC Duplex” y las incompatibilidades de velocidad.
  • Congestión de la red.
  • Pobre enrutamiento.
  • Error en el cableado.
  • Interferencia eléctrica.
  • Un servidor sobrecargado en el extremo remoto de la conexión.
  • DNS mal configurados.

Todas las fuentes de lentitud pueden llegar a ser tan severas que se termina perdiendo la conectividad.

Falta de conectividad

  • Fallos de alimentación de poder.
  • El servidor remoto está apgando.
  • Un servicio en el servidor remoto se encuentra abajo.

Pruebas de cableado y estado del enlace

Un servidor no puede comunicarse con otro dispositivo de la red a menos que la luz “link” de la tarjeta de red (NIC) se encuentre encendida. Esto indica que la conexión entre el servidor y el switch/router está funcionando de manera correcta.

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

  • Los cables no funcionan.
  • El switch o router al que está conectado el servidor está apagado.
  • Los cables no están bien conectados.

Si se cuenta con una red extensa, la inversión en un probador de cable es esencial para realizar pruebas básicas de conectividad. 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.

Probando la NIC

En la solución de problemas, es una buena práctica dar seguimiento al estado de una tarjeta NIC desde la línea de comandos.

Viendo sólo las interfaces activas

ifconfig
netstat -ie
ifconfig | egrep 'Link encap|HWaddr|inet addr|RX|TX|errors|collisions'

Todas las interfaces, aunque no estén activas

ifconfig -a

Consideraciones sobre DHCP

Los clientes DHCP de manera automática proporcionan sus tarjetas de red (NICs) y direcciones IP que comienzan con 169.254.xx hasta que puedan entrar en contacto con el servidor DHCP. Cuando se logra el contacto se reconfiguran las direcciones IP a los valores proporcionados por el servidor DHCP. Por lo tanto, una interfaz con una dirección 169.254.xx significa que hay un fallo en la comunicación con el servidor DHCP.

Estado del enlace (link status)

Conocer información sobre las velocidades de autonegociación compatibles de la tarjeta de red, es útil para resolver problemas de velocidad y dúplex.

mii-tool

mii-tool -v | egrep -i 'eth|link ok'
eth0: negotiated 100baseTx-FD flow-control, link ok
basic status: autonegotiation complete, link ok

eth1: negotiated 100baseTx-FD, link ok
basic status: autonegotiation complete, link ok

apt-get install ethtool

El comando ethtool proporciona mucha más información que el comando mii-tool, además pronto el comando mii-tool será obsoleto en Linux.

ethtool
ethtool eth0 | grep detected
ethtool eth0 | grep Speed

Errores en la tarjeta de red (NIC) 0.5%

Los errores son un síntoma común de una conectividad lenta debido a:

  • Una mala configuración.
  • Un uso excesivo del ancho de banda.

Las tasas de error superiores a 0.5% pueden causar una lentitud bastante notable.

ethtool -S eth0

Con la opción -S de ethtool se puede consultar un dispositivo de red específico con el objetivo de obtener estadísticas sobre:

  • La tarjeta de red NIc
  • El controlador.

netstat

El comando netstat es bastante útil en los sistemas que no cuentan con los comandos mii-tool y ethtool.

Muestra información relacionada con todas las interfaces de red. Datos de las transacciones de paquetes de red, incluyendo tanto la transferencia de paquetes como la recepción de paquetes con un tamaño de MTU.

netstat -i
  • RX-OK: Correct packets received on this interface.
  • RX-ERR: Incorrect packets received on this interface
  • RX-DRP: Packets that were dropped at this interface.
  • RX-OVR: Packets that this interface was unable to receive.

Definiciones similares para las columnas TX que describen los paquetes transmitidos.

Tabla de enrutamiento IP del núcleo (kernel)

netstat -r
route -e
  • A Receive all multicast at this interface.
  • B OK broadcast.
  • D Debugging ON.
  • M Promiscuous Mode.
  • O No ARP at this interface.
  • P P2P connection at this interface.
  • R Interface is running.
  • U Interface is up.
  • G Not a direct entry.

Nombre de servicio con PID

netstat -tp

Monitoreo constante

netstat -ic

Posibles causas de errores de Ethernet

  • Colisiones: Cuando la tarjeta NIC se detecta así misma y otro servidor en la LAN trata de transmitir datos al mismo tiempo. Las colisiones se puede esperar como una parte normal de la operación de Ethernet y están típicamente por debajo de 0,1% de todas las tramas enviadas (frames sent). En general, las altas tasas de error son probablemente causadas ​​por tarjetas de red NIC defectuosas o cables mal terminados.
  • Colisiones individuales: La trama Ethernet atravesada después de sólo una colisión.
  • Colisiones múltiples: La NIC tuvo que intentar varias veces antes de enviar con éxito la trama debido a las colisiones.
  • CRC: Cuando las tramas son eviadas pero se corrompen en el tránsito. La presencia de errores CRC, pero sin muchas colisiones por lo general es una indicación de que existe ruido eléctrico. Hay que verificar el tipo correcto de cable, que el cableado no se encuentre dañado y que los conectores estén bien fijados.
  • Trama (Freme errors): Un CRC incorrecto y un número no entero de bytes se reciben. Esto suele ser el resultado de colisiones o porque un dispositivo Ethernet se encuentra defectuoso.
  • FIFO y saturación: El número de veces que la NIC no fue capaz de entregar datos a sus buffers de memoria debido la tasa de datos de las capacidades del hardware. Esto suele ser un signo de exceso de tráfico.
  • Longitud: La longitud de la trama recibida fue menor o superior al estándar Ethernet. En general, se debe a una configuración dúplex incompatible.
  • Carrier: Debido a que la tarjeta NIC pierde su conexión de enlace (link connection) con el hub o switch. Verifique que el cableado, las interfaces NIC y los equipos de red no encuentren defectuosos.

¿Cómo se ven las direcciones MAC?

Hay momentos en que se puede perder conectividad con otro servidor que está directamente conectado a nuestra red local. Echar un vistazo a la tabla ARP desde el servidor con problemas puede ayudar a determinar si la tarjeta de red NIC del servidor remoto está respondiendo bien a cualquier tipo de tráfico desde mi equipo Linux. La falta de comunicación a este nivel puede significar:

  • Cualquier servidor puede estar desconectado de la red.
  • Es posible que haya cableado de la red dañado.
  • Una tarjeta de red NIC podría estar deshabilitada o el servidor remoto se encuentra abajo.
  • El servidor remoto puede estar corriendo un firewall tal como iptables o como el firewall propio de Windows o Mac. Típicamente, en este caso, se puede ver la dirección MAC y que el servidor está corriendo el software adecuado, pero la comunicación deseada no parece estar ocurriendo para el cliente en la misma red.

A continuación, una descripción de los comandos que se pueden usar para determinar los valores ARP:

El comando ifconfig -a muestra tanto la dirección de MAC de la NIC como las direcciones IP asociadas al servidor en el que nos encontramos. Por lo tanto puede ser posible que una sola interfaz pueda tener dos direcciones atadas al mismo tiempo.

El comando arp -a muestra las direcciones MAC en la tabla ARP del servidor y todos los demás servidores de la red conectada directamente. En general, se puede ver que se tiene algún tipo de conexión con algún router en alguna dirección.

arp -e

Nota: En ambos lados se recomienda verificar que las direcciones IP que aparecen en la tabla ARP coinciden con los de los servidores esperados y aceptables en la red. Si no coinciden, el servidor puede estar conectado en el interruptor del switch o router equivocado.

Si servidor problemático está conectado a la red local o no, es una buena práctica forzar una respuesta de él.

Ping

Uno de los métodos más comunes utilizados para probar la conectividad a través de múltiples redes es el comando ping.

ping envía paquetes “ICMP echo” que solicitan una respuesta “ICMP echo-reply” correspondiente del dispositivo en la dirección de destino. Como la mayoría de los servidores responden a consultas de ping, este comando se convierte en una herramienta muy útil. Una falta de respuesta de ping podría ser debido a:

  • 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.
  • Hay un enrutamiento incorrecto. Compruebe las rutas y las máscaras de subred en ambos lados, los servidores locales y remotos, también en los routers en el 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 traceroute para verificar que se está tomando el camino correcto.
  • Cualquiera de los dos, el dispositivo origen o destino tiene una dirección IP o una máscara de subred incorrecta.

Notas:

  • El comando ping Linux envia pings continuos, uno cada segundo, hasta que se detiene con Ctrl-C.
  • Hay una variedad de códigos de respuesta ICMP que pueden ayudar en la solución de problemas.

Si se obtiene un mensaje “Destination Host Unreachable“. Es probable que el mensaje es causado por el router o servidor sabiendo que la dirección IP de destino es parte de una red válida, pero no recibe ninguna respuesta por parte del servidor de destino. Hay un número de razones para esto:

Si se está tratando de hacer ping a un host en una red directamente conectada:

  • El cliente o el servidor puede estar abajo, o desconectado de la red.
  • La NIC no tiene la configuración dúplex adecuada, esto se puede verificar esto con el comando mii-tool.
  • Es posible que se cuente con un tipo incorrecto de cable de conexión desde nuestra máquina Linux hacia la red. Hay dos tipos básicos, “straight through” y “crossover”.
  • En el caso de una red inalámbrica, puede ser que los SSID o las claves de cifrado pueden estar incorrectas.

Si se está tratando de hacer ping a un host de red remoto:

  • El dispositivo de red no tiene una ruta en su tabla de enrutamiento para la red de destino y envía una respuesta ICMP tipo 3 que desencadena el mensaje. El mensaje resultante podría ser “Destination Host Unreachable” o “Destination Network Unreachable”.

Probando la conectividad de red con telnet

Una manera fácil de saber si un servidor remoto está escuchando en un puerto TCP específico es utilizar el comando telnet. De forma predeterminada, telnet intentará conectarse en el puerto TCP 23, pero se pueden especificar otros puertos TCP después de la dirección IP de destino. Por ejemplo, HTTP utiliza el puerto TCP 80 y HTTPS utiliza el puerto 443.

Al usar telnet para la solución de problemas, hay algunas pautas útiles que permiten aislar el origen del problema:

  • Pruebe la conectividad desde el equipo remoto.
  • Verificar la conectividad en el propio servidor. Trate de hacer la conexión a la dirección “loopback”, así como la dirección IP del NIC. Si el servidor se encuentra usando un firewall tal como iptables, se verifica que “loopback” permita toda conectividad, aunque algunas veces la conectividad a ciertos puertos TCP en la interfaz de red NIC algunas vences pueden estar bloqueados.
  • Pruebe la conectividad desde otro equipo de la misma red que el servidor destino. Esto ayuda a eliminar la influencia de “firewalls” que protegen toda la red desde fuera.

Encontrando solución de problemas con telnet

Recuerde iptables. Es probable que muchos servidores de Linux tienen el firewall iptables instalado por defecto. Esto muy a menudo es la causa de muchos problemas de conectividad, por lo que las reglas del “firewall” deben actualizarse de la manera adecuada. En algunos casos en que la red ya está protegida por un “firewall”, iptables pueden ser apagado de forma segura.

En Linux una conexión telnet con éxito siempre presenta un saludo de conexión.

Mensajes de rechazo de conexión

  • Se puede recibir un mensaje de rechazo de conexión por una de las siguientes razones:
  • La aplicación que estamos tratando de probar no se ha iniciado en el servidor remoto.
  • Existe un “firewall” bloqueando y rechazando el intento de conexión.
telnet 192.168.0.20 22
Trying 192.168.0.20...

telnet: Unable to connect to remote host: Connection timed out

Solución de problemas en Windows

A veces hay que solucionar servidores Linux desde un equipo con Windows. Los comandos de telnet son los mismos, pero los resultados son diferentes. Si la pantalla queda en blanco, entonces la conexión es correcta. Si hay conectividad, la pantalla del símbolo del sistema se mostrará en blanco. Con la combinación de teclas Ctrl-C le se puede salir del intento de telnet.

Mensajes “Connect Failed”

Los mensajes “Connect Failed” en Windows son el equivalente de “Connection refused” en Linux.

Tiempo de espera se cuelga usando telnet

Como se menciona arriba, si no hay conectividad, la sesión aparecerá como colgada o agotada. De manera general, esto es causado porque el servidor de destino está apagado o por que un “firewall” se encuentra bloqueando la conexión.

Probando sitios Web con las utilidades curl y wget

Obtener una buena idea de la fuente de rendimiento de un servidor web utilizando sólo un navegador Web es insuficiente. Muchos códigos de error HTTP útiles a menudo no se muestran en los navegadores, lo que hace difícil la solución de problemas.

Una mejor combinación de herramientas es utilizar telnet para probar el tiempo de respuesta del puerto TCP 80 de un sitio en conjunto con los datos obtenidos por utilidades como curl y wget.

Tiempos rápidos de respuesta TCP, con tiempos lentos de curl y wget apunta a que no es un problema de red, pero sí puede ser un problema de lentitud en la configuración del servidor Web, los servidores de aplicación o en la base de datos que se utilizan para generar la página Web.

Usando curl

La utilidad curl actúa como un navegador Web basado en texto en el que se puede elegir si se desea ver sólo el encabezado o sólo cuerpo completo del código HTML de una página Web que se muestra en la pantalla.

Un buen comienzo es usar el comando curl -I para ver sólo el encabezado de la página Web y el código de estado HTTP. Si no utiliza la bandera -I entonces se desplegará todo el código HTML de la página Web que se muestra en la pantalla. Cualquier método puede proporcionar una buena idea del rendimiento de su servidor.

curl -I www.josoroma.com

Usando wget

Se puede usar wget para descargar un directorio local y de forma recursiva todas las páginas de un sitio Web, incluyendo la estructura de directorios del sitio Web.

Sin usar recursividad, y activando la función de “timestamp” (la opción -N), permite no sólo ver el contenido HTML de la página del index del sitio Web en el directorio local, también se puede ver la velocidad de descarga, el tamaño del archivo y el tiempo preciso de inicio y finalizacón de la descarga. Esto puede ser muy útil para obtener “snapshots” de rendimiento del servidor.

El comando netstat

Tal como curl y wget, netstat puede ser muy útil para ayudar a determinar el origen de los problemas. Usar netstat, con la opción -an permite listar todos los puertos TCP en los que el servidor Linux está escuchando, incluyendo todas las conexiones de red activas desde y hacia el servidor. Esto puede ser muy útil para determinar si la lentitud se debe a los altos volúmenes de tráfico:

netstat -an

La mayoría de las conexiones TCP crean conexiones permanentes, HTTP es diferente porque las conexiones se cierran por sí solas después de un tiempo de espera predeterminado de inactividad o de “time_wait” en el servidor Web. Por lo tanto, es una buena idea centrarse en este tipo de conexiones de corta duración también.

Se puede determinar el número de conexiones establecidas y el número de conexiones “time_wait” TCP en el servidor usando el comando netstat, seguidamente filtrado por los comandos grep y egrep y, con el número de coincidencias (matches) que sean contabilizados por el comando wc.

netstat -an | grep tcp | egrep -i 'established|time_wait' | wc -l

El famoso firewall iptables

Una fuente inesperada de problemas de conectividad en servidores nuevos, con frecuencia, puede ser por el firewall iptables. Algunas veces es posible tratar de detener iptables mientras se solucionan problemas.

La gestión de iptables es fácil de hacer, pero el procedimiento es suele ser diferente entre las diversas distribuciones de Linux. Algunas cosas que hay que tener en mente son las siguientes:

  • En primer lugar, las diferentes distribuciones de Linux utilizan diferentes sistemas de gestión de demonios. Cada sistema tiene su propio conjunto de comandos para hacer operaciones similares. Los sistemas de gestión de demonio más comunes son SysV y Systemd.
  • En segundo lugar, el nombre demonio necesita ser conocido. En el caso de iptables el nombre del demonio es iptables.

Con esta información, se puede saber cómo:

  • Comenzar demonios automáticamente en el arranque (booting).
  • Detener, iniciar y reiniciar demonios al momento de resolver problemas.
  • Cuando un cambio en un archivo de configuración necesita y debe aplicarse.

Probando la conectividad con traceroute

Otra herramienta para solucionar problemas de red es el comando traceroute. Ofrece una lista con todos los nodos (hops) de enrutador entre nuestro servidor origien y el servidor de destino. Esto ayuda a verificar que el enrutamiento a través de las redes en el medio es correcto.

El comando traceroute funciona enviando un paquete UDP hacia el destino con un TTL de 0. El primer router en la ruta reconoce que el TTL de hecho ya ha se ha excedido en tiempo, por esta razón descarta el paquete, pero también envía un mensaje ICMP de tiempo excedido de regreso a la fuente. El programa traceroute registra la dirección IP del router que envía el mensaje y sabe que ese es el primer nodo en la ruta hacia el destino final. Seguidamente el programa traceroute intenta de nuevo, esta vez con un TTL de 1. El primer nodo de la ruta no ve nada extraño con el paquete, entonces disminuye el TTL a 0 como se esperaba, y reenvía el paquete al segundo nodo en la ruta. Router 2, ve el TTL de 0, descarta el paquete y responde con un mensaje ICMP de tiempo excedido. Por lo tanto, ahora traceroute conoce bien la dirección IP del segundo router. Esto continúa de nodo en nodo hasta que se alcanza el destino final.

Usando traceroute sólo se reciben respuestas de dispositivos que funcionan. Si un dispositivo responde quiere decir que es menos probable que sea la fuente de los problemas de conectividad.

50 ms es aceptable

Observe que todos los tiempos en los diversos nodos de la ruta sean inferiores a 50 milisegundos (ms), lo cual es bastante aceptable.

traceroute google.com

Respuesta dentro de 5 segundos

Si no hay respuesta dentro de un intervalo de 5 segundos de tiempo de espera, la prueba se marca con asterisco (*).

Algunos dispositivos evitan paquetes traceroute dirigidos a sus interfaces, pero sí permiten paquetes ICMP. Usar traceroute con la opción -I fuerza traceroute a utilizar paquetes ICMP. En ese caso, el esado de mensaje *** desaparece:

traceroute -I google.com

Falsa alarma de lentitud

Muchas veces traceroute da la impresión de que un sitio Web o una Ip puede ser lenta porque hay alguna congestión en el camino en el sector, entre por ejemplo el nodo 6 y 7 de la ruta, donde algun tiempo de respuesta puede ser de más de 200ms.

Esto indica que sólo los dispositivos en los nodos 6 y 7 de la ruta están lentos para responder con mensajes ICMP de TTL excedido, pero no es una indicación de: congestión, latencia o pérdida de paquetes. Si alguna de estas condiciones existiera entonces todos los puntos anteriores en el vínculo problemático mostrarían alta latencia.

Muchos dispositivos de enrutamiento en la Internet dan muy poca prioridad al tráfico relacionado con traceroute para favorecer el tráfico de generación de ingresos (revenue generating traffic).
Muere en el router justo antes del servidor

En este caso, el último dispositivo en responder a traceroute es el router que actúa como puerta de enlace predeterminada del servidor. Entonces el problema no es con el router, pero sí con el servidor. Recuerde, usted sólo recibirá respuestas traceroute desde dispositivos que sí funcionan. Las posibles causas de este problema podrían ser las siguientes:

  • Un servidor tiene una puerta de enlace predeterminada mala.
  • El servidor se encuentra ejecutando algún tipo de “firewall” que bloquea traceroute.
  • El servidor está apagado, desconectado de la red o tiene un NIC mal configurado.

Siempre probar un traceroute bidireccional

Es mejor obtener un traceroute desde la IP origen hasta la IP destino y también desde la IP de destino hasta la IP origen. Esto se debe a que la ruta de retorno de paquetes desde el destino a veces no es la misma ruta tomada para llegar allí.

Un traceroute alto equivale al tiempo de ida y vuelta (round trip time), tanto para la consulta traceroute inicial para cada nodo de la ruta y la respuesta de cada nodo de la ruta.

Resolución de problemas con ping y traceroute

En este ejemplo, un ping a una IP da un mensaje de tiempo de espera TTL (TTL timeout message). Los tiempo de espera ocurren sólo si hay un bucle de enrutamiento en el que el paquete rebota entre dos enrutadores en su camino hacia el destino. Cada rebote hace que el TTL disminuya su conteo en 1 hasta que el TTL alcanza 0, en este momento se obtiene el “TTL timeout message”.

Estos problemas reconfigurando (reseteando) ambos routers. El problema inicial fue provocado por un enlace inestable en la red que causaba cálculos de enrutamiento frecuentes. Dicha actividad constante dañó las tablas de enrutamiento en uno de los routers.

traceroute para Sitios Web

Muchos ISP ofrecen la posibilidad de hacer un traceroute desde servidores llamados “Internet looking glass”. Permiten correr traceroute desde una variedad de lugares que pueden ayudar a identificar si el problema es con el ISP del servidor Web o con el ISP utilizado que usamos acceder a la Internet desde nuestra casa o trabajo. Una forma cómoda de hacerlo es utilizando el sitio www.traceroute.org que proporciona una lista de espejos por país.

Razones por las que puede fallar traceroute

Un traceroute puede fallar en alcanzar su destino por una serie de razones, incluyendo las siguientes:

  • 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.
  • El servidor destino no existe en la red. Podría estar desconectado o apagado. (Se pueden producir los mensajes !H o N!).
  • 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).
  • Puede haber un error tipográfico en la dirección IP del servidor de destino.
  • Puede haber un bucle de enrutamiento en que los paquetes rebotan entre dos routers y nunca llegan al destino deseado.
  • Los paquetes no tienen una ruta apropiada de retorno a nuestro servidor. El último nodo visible es el último nodo en el que los paquetes vuelven correctamente. El router inmediatamente después del último nodo visible es en el que el enrutamiento cambia. Por lo general es bueno hacer lo siguiente:
    • Iniciar sesión en el último nodo enrutador visible.
    • Mira 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 porbar la tabla de enrutamiento y/o cualquier estado de todos los nodos entre este y y el destino previsto.

Nota: Si no hay algo que bloquee el tráfico traceroute, entonces el último enrutador visible de un traceroute es el último router bueno en el camino, o el último router que tiene un retorno válido hacia el servidor emitiendo el traceroute.

Por favor consulte: Simple Network Troubleshooting