The good old SAR

Quick reference of this noble and old school command.

Very useful for troubleshooting and server performance.

Checking CPU Activity

By default, sar command will report the CPU activity of the server. The option -u can be used to get the CPU utilization report.

To get the CPU activity report in every 2 seconds for 3 times:

$ sar -u 2 3

Linux 3.10.0-1127.10.1.el7.x86_64 (localhost.localdomain) 	09/06/2020 	_x86_64_	(2 CPU)

22:26:54        CPU     %user     %nice   %system   %iowait    %steal     %idle
22:26:56        all      4,03      0,00      0,50      0,00      0,00     95,47
22:26:58        all      8,08      0,00      0,51      0,00      0,00     91,41
22:27:00        all     12,50      0,00      1,00      0,00      0,00     86,50
Average:        all      8,21      0,00      0,67      0,00      0,00     91,11

CPU usage for each processor

To find the CPU activity on all processors separately, you need to use the -P option.

$ sar -P ALL 1 1

Linux 3.10.0-1127.10.1.el7.x86_64 (localhost.localdomain) 	10/06/2020 	_x86_64_	(2 CPU)

05:38:18        CPU     %user     %nice   %system   %iowait    %steal     %idle
05:38:19        all      3,03      0,00      0,00      0,00      0,00     96,97
05:38:19          0      3,96      0,00      0,99      0,00      0,00     95,05
05:38:19          1      3,00      0,00      0,00      0,00      0,00     97,00

Average:        CPU     %user     %nice   %system   %iowait    %steal     %idle
Average:        all      3,03      0,00      0,00      0,00      0,00     96,97
Average:          0      3,96      0,00      0,99      0,00      0,00     95,05
Average:          1      3,00      0,00      0,00      0,00      0,00     97,00

Check Memory usage

To find the memory usage (used and free memory of the server) over time using the -r switch.

$ sar -r 1 3

Linux 3.10.0-1127.10.1.el7.x86_64 (localhost.localdomain) 	10/06/2020 	_x86_64_	(2 CPU)

05:41:04    kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
05:41:05       855300   3025220     77,96         0   1495276   2426864     30,55   1265008   1158172       100
05:41:06       854800   3025720     77,97         0   1495276   2426864     30,55   1265132   1158172       100
05:41:07       855032   3025488     77,97         0   1495276   2426864     30,55   1265012   1158172       100
Average:       855044   3025476     77,97         0   1495276   2426864     30,55   1265051   1158172       100

Check Swap Activity

Check the swap usage of the machine using the -W option:

$ sar -W 1 3
Linux 2.6.18-274.18.1.el5 (myserver) 09/06/2012
03:31:12 PM pswpin/s pswpout/s
03:31:13 PM 16.16 0.00
03:31:14 PM 16.00 0.00
03:31:15 PM 15.84 0.00
Average: 16.00 0.00

Find load averages over time

You can find the load averages overtime using the -q option:

$ sar -q 1 3

Linux 3.10.0-1127.10.1.el7.x86_64 (localhost.localdomain) 	10/06/2020 	_x86_64_	(2 CPU)

06:16:13      runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15   blocked
06:16:14            0       329      0,00      0,04      0,09         0
06:16:15            0       329      0,00      0,04      0,09         0
06:16:16            0       329      0,00      0,04      0,09         0
Average:            0       329      0,00      0,04      0,09         0

Statistics for currently mounted filesystems

$ sar -F 2 3

Linux 3.10.0-1127.10.1.el7.x86_64 (localhost.localdomain) 	10/06/2020 	_x86_64_	(2 CPU)

06:30:18     MBfsfree  MBfsused   %fsused  %ufsused     Ifree     Iused    %Iused FILESYSTEM
06:30:20        30410      5532     15,39     15,39  18245113    166407      0,90 /dev/mapper/centos-root
06:30:20          796       218     21,52     21,52    523947       341      0,07 /dev/sda1

06:30:20     MBfsfree  MBfsused   %fsused  %ufsused     Ifree     Iused    %Iused FILESYSTEM
06:30:22        30410      5532     15,39     15,39  18245113    166407      0,90 /dev/mapper/centos-root
06:30:22          796       218     21,52     21,52    523947       341      0,07 /dev/sda1

06:30:22     MBfsfree  MBfsused   %fsused  %ufsused     Ifree     Iused    %Iused FILESYSTEM
06:30:24        30410      5532     15,39     15,39  18245113    166407      0,90 /dev/mapper/centos-root
06:30:24          796       218     21,52     21,52    523947       341      0,07 /dev/sda1

Summary:     MBfsfree  MBfsused   %fsused  %ufsused     Ifree     Iused    %Iused FILESYSTEM
Summary         30410      5532     15,39     15,39  18245113    166407      0,90 /dev/mapper/centos-root
Summary           796       218     21,52     21,52    523947       341      0,07 /dev/sda1

Details of inode, kernel tables and file tables

$ sar -v 2 3

Linux 3.10.0-1127.10.1.el7.x86_64 (localhost.localdomain) 	10/06/2020 	_x86_64_	(2 CPU)

06:57:23    dentunusd   file-nr  inode-nr    pty-nr
06:57:25       160833      2400    132081         3
06:57:27       160833      2400    132081         3
06:57:29       160833      2400    132081         3
Average:       160833      2400    132081         3

Network statistics

$ sar -n DEV

Linux 3.10.0-1127.10.1.el7.x86_64 (localhost.localdomain) 	10/06/2020 	_x86_64_	(2 CPU)

19:20:23        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
19:20:24       ens192     11,00      4,00      1,80      2,75      0,00      0,00      0,00
19:20:24           lo     79,00     79,00     43,62     43,62      0,00      0,00      0,00

Average:        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
Average:       ens192     11,00      4,00      1,80      2,75      0,00      0,00      0,00
Average:           lo     79,00     79,00     43,62     43,62      0,00      0,00  

Which interrupt number could be causing a CPU bottleneck?

$ sar -I XALL 2 10
02:07:10 AM INTR intr/s
02:07:12 AM 0 992.57
02:07:12 AM 1 0.00
02:07:12 AM 2 0.00
02:07:12 AM 3 0.00
02:07:12 AM 4 0.00
02:07:12 AM 5 0.00
02:07:12 AM 6 0.00
02:07:12 AM 7 0.00
02:07:12 AM 8 0.00
02:07:12 AM 9 350.50

‘/proc/interrupts’ file will also provide helpful information. Interrupt halts CPU processing so that I/O or other operations can occur. Processing resumes after the specific operation takes place. It is very important that each device installed in machine is provided with an interrupt setting that does not conflict with the settings used by the hardware and other devices.

$ sudo cat /proc/interrupts

           CPU0       CPU1       
  0:         48          0   IO-APIC-edge      timer
  1:         54          0   IO-APIC-edge      i8042
  8:          1          0   IO-APIC-edge      rtc0
  9:          0          0   IO-APIC-fasteoi   acpi
 12:         35        116   IO-APIC-edge      i8042
 14:          0          0   IO-APIC-edge      ata_piix
 15:          0          0   IO-APIC-edge      ata_piix
 16:        118       2513   IO-APIC-fasteoi   vmwgfx
 24:          0          0   PCI-MSI-edge      PCIe PME, pciehp
 25:          0          0   PCI-MSI-edge      PCIe PME, pciehp
 26:          0          0   PCI-MSI-edge      PCIe PME, pciehp
 27:          0          0   PCI-MSI-edge      PCIe PME, pciehp
NMI:          0          0   Non-maskable interrupts
LOC:   35392807   14792833   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:          0          0   Performance monitoring interrupts
IWI:    2677624     215297   IRQ work interrupts

Linux Kernel Tuning: page allocation failure

If you start seeing these errors it means your server or instance started running out of kernel memory.

[10223.291166] java: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null)
[10223.301794] java cpuset=/ mems_allowed=0-1
[10223.307211] CPU: 29 PID: 19395 Comm: java Not tainted 4.14.154-99.181.amzn1.x86_64 #1
[10223.315658] Hardware name: Xen HVM domU, BIOS 08/24/2006
[10223.322004] Call Trace:
[10223.325230]  <IRQ>
[10223.328193]  dump_stack+0x66/0x82
[10223.332213]  warn_alloc+0xe0/0x180

In particular, these Order 0 (zero) errors, mean there isn’t even a single 4K page available to allocate.

This might sound weird on a system were we have a lot of RAM memory available. And actually, this may be a common situation on systems where the kernel is not tuned up properly.

In particular, we need to look at the following kernel parameter:


This is used to force the Linux VM to keep a minimum number
of kilobytes free.  The VM uses this number to compute a
watermark[WMARK_MIN] value for each lowmem zOn one in the system.
Each lowmem zone gets a number of reserved free pages based
proportionally on its size.

Some minimal amount of memory is needed to satisfy PF_MEMALLOC
allocations; if you set this to lower than 1024KB, your system will
become subtly broken, and prone to deadlock under high loads.

Setting this too high will OOM your machine instantly.

On systems with very large amount of RAM memory, this parameter is usually set too low. Change default value (have a look to the previous paragraph to avoid too low or too high values) and restart with sysctl. 1GB is the value I use on most of the large memory servers (64GB+).

sudo sed -i '${s/$/'"\nvm.min_free_kbytes = 1048576"'/}' /etc/sysctl.conf
sysctl vm.min_free_kbytes

echo "reloading the settings:"
sudo /sbin/sysctl -p

EBS Storage Performance Notes – Instance throughput vs Volume throughput

I just wanted to write a couple lines/guidance on this regard as this is a recurring question when configuring storage, not only in the cloud, but can also happen on bare metal servers.

What is throughput on a volume?

Throughput is the measure of the amount of data transferred from/to a storage device per time unit (typically seconds).

The throughput consumed on a volume is calculated using this formula:

IOPS (IO Ops per second) x BS (block size)= Throughput

As example, if we are writing at 1200 Ops/Sec, and the chunk write size is around 125Kb, we will have a total throughput of about 150Mb/sec.

Why is this important?

This is important because we have to be aware of the Maximum Total Throughput Capacity for a specific volume vs the Maximum Total Instance Throughput.

Because, if your instance type (or server) is able to produce a throughput of 1250MiB/s (i.e M4.16xl)) and your EBS Maximum Throughput is 500MiB/s (i.e. ST1), not only you will hit a bottleneck trying to write to the specific volumes, but also throttling might occur (i.e. EBS on cloud services).

How do I find what is the Maximum throughput for EC2 instances and EBS volumes?

Here is documentation about Maximum Instance Throughput for every instance type on EC2:

And here about the EBS Maximum Volume throughput:

How do I solve the problem ?

If we have an instance/server that has more throughput capabilities than the volume, just add or split the storage capacity into more volumes. So the load/throughput will be distributed across the volumes.

As an example, here are some metrics with different volume configurations:

1 x 3000GB – 9000IOPS volume:


3 x 1000GB – 3000IOPS volume:


Look at some of the metrics: these are using the same instance type (m4.10xl – 500Mb/s throughput), same volume type (GP2 – 160Mb/s throughput) and running the same job:

  • Using 1 volume, Write/Read Latency is around 20-25 ms/op. This value is high compared to 3x1000GB volumes.
  • Using 1 volume, Avg Queue length 25. The queue depth is the number of pending I/O requests from your application to your volume. For maximum consistency, a Provisioned IOPS volume must maintain an average queue depth (rounded to the nearest whole number) of one for every 500 provisioned IOPS in a minute. On this scenario 9000/500=18. Queue length of 18 or higher will be needed to reach 9000 IOPS.
  • Burst Balance is 100%, which is Ok, but if this balance drops to zero (it will happen if volume capacity keeps being exceeded), all the requests will be throttled and you’ll start seeing IO errors.
  • On both scenarios, Avg Write Size is pretty large (around 125KiB/op) which will typically cause the volume to hit the throughput limit before hitting the IOPS limit.
  • Using 1 volume, Write throughput is around 1200 Ops/Sec. Having write size around 125Kb, it will consume about 150Mb/sec. (IOPS x BS = Throughput)

Linux Kernel Tuning: task blocked for more than 120 seconds

This might be old school, and maybe even boring reading. But, if you concern about performance on Linux servers, at some point, you will have to have a look to the kernel messages.

The problem:

When we run very stressful jobs running on large servers (large number of CPU’s and RAM memory), where IO activity is very high. It is pretty common to start seeing these messages on the ‘dmesg’ kernel output:

[24169.372862] INFO: task kswapd1:1140 blocked for more than 120 seconds.
[24169.375623] Tainted: G E 4.9.51-10.52.amzn1.x86_64 #1
[24169.378445] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[24169.382533] kswapd1 D 0 1140 2 0x00000000
[24169.385066] ffff8811605c5a00 0000000000000000 ffff8823645dc900 ffff882362844900
[24169.389208] ffff882371357c00 ffffc9001a13ba08 ffffffff8153896c ffffc9001a13ba18
[24169.393329] ffff881163ac92d8 ffff88115e87f400 ffff882362844900 ffff88115e87f46c
[24169.445313] Call Trace:
[24169.446981] [<ffffffff8153896c>] ? __schedule+0x23c/0x680
[24169.449454] [<ffffffff81538de6>] schedule+0x36/0x80
[24169.451790] [<ffffffff8153907e>] schedule_preempt_disabled+0xe/0x10
[24169.454509] [<ffffffff8153a8d5>] __mutex_lock_slowpath+0x95/0x110
[24169.457156] [<ffffffff8153a967>] mutex_lock+0x17/0x27
[24169.459546] [<ffffffffa0966d00>] xfs_reclaim_inodes_ag+0x2b0/0x330 [xfs]
[24169.462407] [<ffffffffa0967be3>] xfs_reclaim_inodes_nr+0x33/0x40 [xfs]
[24169.465203] [<ffffffffa0978f59>] xfs_fs_free_cached_objects+0x19/0x20 [xfs]

Why is this happening?

This indicates that the process requested a block device such as a disk/swap, and wasn’t able to be fulfilled for more than 120 seconds and subsequently abandoned by the kernel.

As mentioned before, the probability of observing this behavior will increase when we use instances with large number of vCores (e.g. 64+ vCores), given that the volume of IO requests could be higher, and, the kernel buffer queues not configured for such load.

This is also very common on clustered environments. Even though the framework will retry, on Hadoop/YARN environments, this will impact in performance, and, might also lead to application failures.

The Solution:

To solve this problem, we have to increase the ‘dirty_background_bytes‘ kernel setting  to higher values to be able to accommodate the throughput.

As a base formula, we usually consider a value of dirty_background_bytes=10MB for 40MB/Sec throughput.

The goal is to have the page cache to allow the OS to write asynchronously to disk whenever possible. Otherwise, when the write becomes synchronous, it would involve a waiting time.

Additionally to the dirty_background_bytes kernel parameter, we can also set:

  • dirty_background_ratio = 10 (represents the percentage of system memory which when dirty then system can start writing data to the disks. When the dirty pages exceed ratio 10, I/O starts, i.e they start getting flushed / written to the disk)
  • dirty_ratio = 15 (is percentage of system memory which when dirty, the process doing writes would block and write out dirty pages to the disks. When total number of dirty pages exceed ratio 15, all writes get blocked until some of the dirty pages get written to disk. This is like an upper limit)

We try to keep these two values low to avoid  I/O bottlenecks. We can experiment setting both down to zero, to force fast flushes on high stress environments.

Another parameter we can use is dirty_bytes, which represents the amount of dirty memory at which a process generating disk writes will itself start writeback. We should set dirty_ratio = 0 if we set dirty_bytes, as only one of these might be specified at a time.


dirty_bytes = 2147483648

More details on these parameters is available here.

Linux Kernel Tuning: failed to alloc buffer for rx queue

If we put enough pressure over the ENA network driver, we’ll start seeing these “failed to alloc buffer for rx queue” messages on the ‘dmesg‘ output.

[56459.833033] ena 0000:00:05.0 eth0: failed to alloc buffer for rx queue 4
[56459.836477] ena 0000:00:05.0 eth0: refilled rx qid 4 with only 85 buffers (from 168)

This message will raise when the napi handler fails to refill new Rx descriptors, typically due to lack of memory. This situation might lead to performance decrease, given that some requests would have to be rescheduled. 

The code handling these situations can be found here.

The solution for this is related to a memory increase on “min_free_kbytes” kernel parameter. As example:

vm.min_free_kbytes = 1048576

Place the following commands in /etc/sysctl.conf. And load the new setting with:

sysctl -p

It is recommended to have at least 512MB, with a minimum of 128MB for constrained environment. On large instance types running stress jobs (e.g. 64+ vCores + 256GiB + RAM), this value can typically be set to 10MB.





Importar contactos de gmail, yahoo, hotmail, facebook, con openinviter

OpenInviter es una herramienta open source, para importar contactos de libretas de direcciones de servidores de correo y otros servicios como facebook.
Al instalarlo en nuestro servidor, nos provee de una interfaz web donde ingresamos los datos de la cuenta de la que queremos obtener los contactos y nos devolvera la lista completa.

Para instalarlo, vamos a necesitar tener instalado PHP5 y DOMDocument.

Supongo que ya tenemos PHP5, pero si no tenemos instalado el DOMDocument, lo  instalamos:
# yum install php-xml

Descargamos el paquete de instalación desde

# tar -zxvf openinviter.tar.gz

Movemos el directorio completo a nuestro webserver:
# mv openinviter /var/www/html/

Ejecutamos el script de configuración de openinviter desde un navegador de internet:

Aquí el instalador nos indicará si falta instalar algún paquete o nos dará un warning si no puede ejecutar algún plugin.
Si nos falta algo lo instalamos. El postinstall.php no podrá ejecutarse nuevamente por dos minutos.

Editamos el config.php de acuerdo a nuestras necesidades.

Finalmente, debemos eliminar el postinstall.php para que quede funcionando.

Apuntando a http://localhost/openinviter/ y tendremos la interfaz para introducir los datos de la cuenta y obtener los contactos.

Manuales / Tutoriales de uso de herramientas de Software Libre

Dejo un par de sitios que almacenan documentos, manuales y tutoriales de uso de Herramientas de Software Libre.

Gleducar – Tutoriales Intec-GCBA: Manuales y tutoriales de 7-zip, Avidemux,  Audacity, TuxPaint, GIMP, Scribus, Scratch, VLC, OpenOffice Calc, Writer e Impress.
Creados por el Ministerio de Educación de la Ciudad de Buenos Aires. Publicados originalmente en el Campus Virtual del INTEC.

Cenatic: Material de divulgación y referencia en el uso de Herramientas de Software Libre. Manuales de Firefox, Evolution, GIMP, Inkscap, Writer, Calc, entre otros. Gracias Clau por este enlace.

Código QR: Codificando y Decodificando en Linux

El código QR se ha puesto de moda ahora, dado el auge de los smartphone, sin embargo fué creado en el año 1994 por una compañía japonesa e inicialmente se usó para registrar repuestos en la industria automotriz.
QR significa Quick Response, respuesta rápida y no es mas que un formato especial de código de barras.
Sus principales ventajas son, en principio, sus capacidades de almacenamiento:
Solo numérico: 7089 caracteres.
Alfanumerico: 4296 caractéres.
Binario (una imágen por ejemplo): 2953 bytes.

En nuestra vida diaria, están tomando popularidad, dado que comercialmente se los utiliza mucho. De que manera ?
Por ejemplo: se coloca un código QR en una publicidad en la vía pública o en un diario. Con nuestro smartphone, sacamos una foto del código QR, y automaticamente nos muestra el texto e imágenes almacenado o nos abre el navegador de internet con la página del producto.
También podría colocar un código QR en una tarjeta de visita, de manera de que alguien que lee la tarjeta con su teléfono no deba cargar todos los datos de contacto…interesante, no?

Como generamos codigos QR con Linux ? muy facilmente:
1) Instalamos un programa codificador, por ejemplo el qrencode:
# yum install qrencode

2) Generamos un código QR que nos redirecione a este sitio:
$ qrencode -o hvivani.png -s8 ‘;

la opción -s8 indica el tamaño del punto en pixels. El dafault es 3.

Si vemos la imágen almacenada, veremos esto:

Ahora, como leemos o decodificamos un código QR ?
1) Debemos instalar un programa lector de código de barras como por ejemplo el zbar:
# yum install zbar

2) Luego, si queremos decodificar el código QR almacenado en una imágen, utilizamos el comando:
$ zbarimg hvivani.png

scanned 1 barcode symbols from 1 images in 0.07 seconds

Si queremos decodificar el código QR que obtenemos a través de una webcam, utilizamos el comando:
$ zbarcam –raw

Por supuesto que hay muchas aplicaciones para codificar y decodificar y en muchas plataformas, asi que: a explorar !

Monitoreando la red por consola con iftop

Muchas veces es necesario tener un pantallazo rápido del estado del tráfico de la red, en particular cuando necesitamos saber quien se está consumiendo todo el ancho de banda de un servicio determinado…
Hay muchas herramientas para esto, una de ellas es iftop, similar al comando top, pero en este caso para el tráfico de red.

Para instalar, es necesario tener instaladas las librerias libpcap, entonces:
# yum install libpcap libpcap-devel

Luego descargamos:
# wget

descomprimimos e instalamos:
# tar -zxvf iftop-0.17.tar.gz
# cd iftop-0.17
# ./configure
# make
# make install

luego ya podremos ejecutar la aplicación:
# iftop

– Presionando h obtenemos la ayuda en pantalla.
– La vista default es port display off, two lines per host pair.
– El tráfico total lo obtenemos con: hosts names hidden, source port shown, one line per host pair

Enlazando redes con OpenVPN

En el presente apunto los pasos necesarios para instalar openvpn de modo de enlazar dos subredes. Hay un servidor central corriendo openvpn y uno o mas clientes (equipos o subredes) conectados al servidor central tambien a través de openvpn.

Aplicable a: centOS, fedora, Redhat

Configuración del Servidor openvpn:

Instalamos el openVPN y sus dependencias:

# yum install openvpn

Copiamos al directorio de trabajo:

# cp -R /usr/share/openvpn/easy-rsa/2.0/* /etc/openvpn/

Editamos el archivo vars:

# vi /etc/openvpn/vars

Y modificamos las últimas líneas con nuestros datos:

export KEY_CITY=”SanFrancisco”
export KEY_ORG=”Fort-Funston”
export KEY_EMAIL=”me@myhost.mydomain”

Cargamos las variables de entorno:

# source /etc/openvpn/./vars

Limpiamos firmas digitales previas:

# sh /etc/openvpn/clean-all

Creamos certificado del servidor:

# sh /etc/openvpn/build-ca

Creamos el archivo con los parámetros del protocolo Diffie Hellman:

# sh /etc/openvpn/build-dh

Generamos la firma digital:

# sh /etc/openvpn/build-key-server server

Creamos los certificados de los clientes:

# sh /etc/openvpn/build-key cliente1
# sh /etc/openvpn/build-key cliente2
# sh /etc/openvpn/build-key cliente3

Para poder utilizar los certificados, creamos el archivo:

# vi /etc/openvpn/servidorvpn-udp-1194.conf

Adentro  detallaremos la configuración, teniendo en cuenta utilizar una subred no muy estandard para evitar conflictos:

port 1194
proto udp
dev tun
#—- Seccion de llaves —–
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pem
ifconfig-pool-persist ipp.txt
keepalive 10 120
status openvpn-status-servidorvpn-udp-1194.log
verb 3

Los parámetros anteriores significan:

Port: Especifica el puerto que será utilizado para que los clientes vpn puedan conectarse al servidor.

Proto: tipo de protocolo que se empleará en a conexión a través de VPN

dev: Tipo de interfaz de conexión virtual que se utilizará el servidor openvpn.

ca: Especifica la ubicación exacta del archivo de Autoridad Certificadora [.ca].

cert: Especifica la ubicación del archivo [.crt] creado para el servidor.

key: Especifica la ubicación de la llave [.key] creada para el servidor openvpn.

dh: Ruta exacta del archivo [.pem] el cual contiene el formato de Diffie Hellman (requirerido para –tls-serversolamente).

server: Se asigna el rango IP virtual que se utilizará en la red del túnel VPN.

Ifconfig-pool-persist: Archivo en donde quedarán registrado las direcciones IP de los clientes que se encuentran conectados al servidor OpenVPN.

Keepalive 10 120 : Envía los paquetes que se manejan por la red una vez cada 10 segundos; y asuma que el acoplamiento es abajo si ninguna respuesta ocurre por 120 segundos.

comp-lzo: Especifica los datos que recorren el túnel vpn será compactados durante la trasferencia de estos paquetes.

persist-key: Esta opción soluciona el problema por llaves que persisten a través de los reajustes SIGUSR1, así que no necesitan ser releídos.

Persist-tun: Permite que no se cierre y re-abre los dispositivos TAP/TUN al correr los guiones up/down

status: archivo donde se almacenará los eventos y datos sobre la conexión del servidor [.log]

verb: Nivel de información (default=1). Cada nivel demuestra todo el Info de los niveles anteriores. Se recomienda el nivel 3 si usted desea un buen resumen de qué está sucediendo.

0 –No muestra una salida excepto errores fatales. 1 to 4 –Rango de uso normal. 5 –Salida Ry Wcaracteres en la consola par los paquetes de lectura y escritura, mayúsculas es usada por paquetes TCP/UDP minúsculas es usada para paquetes TUN/TAP.

Creamos el archivo log:

# touch /etc/openvpn/openvpn-status-servidorvpn-udp-1194.log

Starteamos el servicio:

# service openvpn start

Definimos el servicio para que arranque automaticamente al inicio:

# chkconfig –level 2345 openvpn on

Configuración de los Clientes GNU/Linux:

Instalamos el paquete OpenVPN:

# yum install openvpn

Creamos el archivo:

# vi /etc/openvpn/cliente1-udp-1194.conf

con el siguiente contenido:

dev tun
proto udp
remote dominio-o-ip.del.servidor.vpn 1194
resolv-retry infinite
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cliente1.crt
key /etc/openvpn/keys/cliente1.key
ns-cert-type server
verb 3

Verificar que en la carpeta /etc/openvpn/keys del cliente tengamos los certificados que se detallan en este archivo.

(ca.crt, cliente1.crt, cliente1.key)

Starteamos el servicio en el cliente:

# service openvpn start

Con esto, el cliente, debe conectarse con el servidor.

Debemos verificar en el servidor reglas de firewall que impidan la entrada al puerto configurado.

Ante cualquier error, verificamos la salida en /var/log/messages.