Proxmox – Interfaces promiscuas.

Otra entrada corta sobre interfaces promiscuas… y últimamente ya van unas cuantas.

En este caso la necesidad es capturar tráfico desde una vm que corre sobre proxmox. Por defecto esto se realiza con normalidad, una interfaz física es asociada a un Vbridge, el cual es usado por la/las máquinas virtuales.

La interfaz en la VM se puede configurar promiscua sin mayor problema.

ethX –> vmbrX –> VM(ethx promisc)

El problema viene cuando al capturar tráfico desde la VM, solo vemos tráfico multicast y no todo el trafico como era de esperar.

Según parece por defecto esta deshabilitada la posibilidad de que un bridge actúe en modo promiscuo desde proxmox, por temas de seguridad.

Para habilitar esta posibilidad, es necesario, el parámetro «bridge_ageing 0» el cual no es posible configurar desde la WUI. (Ni como admin, lo cual estaría bastante bien)

Podemos configurarlo desde el fichero «interfaces» en el propio proxmox

/etc/network/interfacesauto vmbr4
iface vmbr4 inet manual
    bridge_ports eth1
    bridge_stp off
    bridge_fd 0
    bridge_ageing 0#PROMISC

Este cambio según las indicaciones de proxmox, requiere reboot aunque hay maneras de recargarlo correctamente, sin necesidad de reboot completo.

Nota: Según las pruebas, si editamos desde la WUI tras este cambio, el parámetro se mantiene y no es «machacado».

Nota2: Este cambio solo es valido para entornos con máquinas bajo kvm y no bajo qemu (Sin verificar)

Tras esto la VM, ya recibe el tráfico promiscuo como se esperaba.

Configurando Bond promisc

Hace poco he tenido la necesidad, de agregar varias interfaces  en modo promiscuo, en solo una interfaz virtual.

Ya escribí una pequeña introducción sobre configuración de bond, hace mucho tiempo, en la que se indican los distintos tipos.

En esta ocasión el modo usado es el «3» o Broadcast.

La configuración de la interfaz de bond y de sus interfaces físicas es la siguiente.

/etc/sysconfig/network-scripts/ifcfg-bond0

TYPE="Bond"
BONDING_MASTER="yes"
BOOTPROTO="none"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
IPV6_FAILURE_FATAL="no"
NAME="bond0"
DEVICE="bond0"
ONBOOT="yes"
PROMISC="yes"
BONDING_OPTS="mode=3"
NM_CONTROLLED="no"

/etc/sysconfig/network-scripts/ifcfg-eno1

DEVICE="eno1"
ONBOOT="yes"
BOOTPROTO="none"
TYPE="Ethernet"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
IPV6_FAILURE_FATAL="no"
NAME="eno1"
PROMISC="yes"
MASTER="bond0"
SLAVE="yes"
NM_CONTROLLED="no"

/etc/sysconfig/network-scripts/ifcfg-eno2

DEVICE="eno2"
ONBOOT="yes"
BOOTPROTO="none"
TYPE="Ethernet"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
IPV6_FAILURE_FATAL="no"
NAME="eno2"
PROMISC="yes"
MASTER="bond0"
SLAVE="yes"
NM_CONTROLLED="no"

Tras esta configuración, simplemente queda garantizar que las interfaces levanten en modo promiscuo, para lo que editamos rc.local

/etc/rc.local

/sbin/ip link set bond0 promisc on
/sbin/ip link set eno1 promisc on
/sbin/ip link set eno2 promisc on

Llegados aquí podremos capturar todo el tráfico de las interfaces enoX en la interfaz bond0

Notas sobre Rsyslog

En esta nota dejaré algunos apuntes interesantes, sobre configuraciones que estoy encontrando, al hacer un uso mas intensivo de rsyslog.
Es una nota un poco desordenada, más como recordatorio que como post estructurado.

– Problemas de drops en Rsyslog por exceso de msg. RedHat 6.X –

Rsyslog define el numero de mensajes por intervalo de tiempo. Superado este umbral se producirá un dropeo y perderemos entradas.

Superar este umbral deja una entrada en los logs de la máquina, en:

/var/log/messages
Jul 5 18:51:01 localhost rsyslogd-2177: imuxsock lost 538 messages from pid 433 due to rate-limiting

Esto implica que tenemos cargado el modulo imuxsock con la librería  /usr/lib/rsyslog/imuxsock.so en el fichero /etc/rsyslog.conf

$ModLoad imuxsock

La configuración de estos intervalos se define con los parámetros :

$SystemLogRateLimitInterval 10
$SystemLogRateLimitBurst 500

Por defecto son bastante conservadores, así que podemos ajustarlos como necesitemos.

$SystemLogRateLimitInterval (Tiempo en segundos)
$SystemLogRateLimitBurst (Número de msg)

También podemos encontrar entradas equivalentes más «legacy», aunque no es lo normal:

$IMUXSockRateLimitBurst [number] - equivalent to: RateLimit.Burst
$IMUXSockRateLimitSeverity [numerical severity] - equivalent to: RateLimit.Severity
$IMUXSockRateLimitSeverity [numerical severity] - equivalent to: RateLimit.Severity

Si queremos eliminar este control podemos definir el tiempo en «0s»

$SystemLogRateLimitInterval 0

Tras los cambios, reiniciamos rsyslogd

– Problemas de drops en Rsyslog por exceso de msg. RedHat 7.X –

En RedHat 7, podemos tener este problema tanto en rsyslog como en systemd-journald, dejando en ambos casos, sus respectivos logs:

Jun 28 03:08:43 localhost systemd-journal[1864]: Suppressed 917 messages from /

o

Jun  28 10:32:15 localhost rsyslogd-2177: imjournal: begin to drop messages due to rate-limiting
Jun  28 10:32:17 localhost rsyslogd-2177: imjournal: 236 messages lost due to rate-limiting

Para systemd-journald, editamos /etc/systemd/journald.conf casi como en el caso anterior

RateLimitInterval= (Tiempo en segundos)
RateLimitBurst= (Numero de msg.)

Tras los cambios, reiniciamos systemd-journald

Para rsyslog y con el formato tradicional, como en el caso de RedHat 6, editamos, /etc/rsyslogd.conf

$imjournalRatelimitInterval = (Tiempo en segundos)$imjournalRatelimitBurst = (Numero de msg)

También podemos encontrar esto, aunque aun no lo he visto.

if rsyslog.conf has been modified to use new-style module-loading syntax, well, stick with thatExample excerpt:
module(load=»imjournal» StateFile=»/var/lib/rsyslog/imjournal.state» ratelimit.interval=»300″ ratelimit.burst=»30000″)

Tras los cambios, reiniciamos rsyslogd

– Problemas por  tamaño de msg. –

También podemos tener problemas con el tamaño de msg. tanto para recibir como para enviar, si este supera el valor por defecto. 2k
UDP soporta un valor máximo de 4k

testing showed that 4k seems to be the typical maximum for UDP based syslog. This is an IP stack restriction. Not always … but very often.

Más detalle (aquí), así que si queremos tamaños mayores debemos usar TCP.
Por ejemplo, los registros de sucesos de windows tienen tamaños de hasta 64k
Si detectamos msg incompletos, deberemos ajustar el tamaño máximo, usando la directiva:

$MaxMessageSize (Tamaño en bytes)

Tras los cambios, reiniciamos rsyslogd

Añadir DS a RRD – Problema PNP4Nagios – No DS called …

Me he encontrado varias veces problemas con los ficheros rrd que usa pnp para graficar en Nagios.
Indicando que faltan uno o varios (DS)-DataSource… esto sucede normalmente, porque se ha cambiado el plugin de un servicio y el nuevo plugin genera una salida diferente, lo cual genera un nuevo XML, pero el RRD que teníamos sigue con la definición anterior y faltan los (DS) indicados.

NOTA:
Para cada servicio, tenemos dos ficheros….

• XML –> Estructura de BBDD rrd.
• RRD –> BBDD

Como proceder… tenemos dos alternativas….

1.- Mas rápida… pero con perdida de histórico del servicio.
Borramos el rrd y el xml, y en el siguiente check se generaran de nuevo, pero habremos perdido el histórico para ese servicio.

2.- Creamos los DS que faltan.
De este modo mantendremos el historico del servicio para el resto de DS’s
NOTA: El script usado «rrd_add_datasource.pl» se puede descargar o copiarlo directamente.-

– Caso Practico –
1.- Verificar los DS que tenemos en el XML:

#cat /var/lib/pnp4nagios/XXXXXXX/DISK-linux.xml |grep ""
1
2
3
4
5

2.- Verificar los DS que tenemos en el rrd:

#rrdtool info /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd |grep type
ds[1].type = "GAUGE"
ds[2].type = "GAUGE"
ds[3].type = "GAUGE"

3.- Debemos añadir el DS 4 y 5

# /root/rrd_add_datasource.pl /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd 4 GAUGE
Processing /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd... ok.
# /root/rrd_add_datasource.pl /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd 5 GAUGE
Processing /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd... ok.

4.- Verificamos que el RRD ya tiene los DS correctos

[root@s2-argos ~]# rrdtool info /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd |grep type
ds[1].type = "GAUGE"
ds[2].type = "GAUGE"
ds[3].type = "GAUGE"
ds[4].type = "GAUGE"
ds[5].type = "GAUGE"

Tras esto el mapa se mostrara correctamente.
– Script «rrd_add_datasource.pl» –

#!/usr/bin/perl
use strict;
use warnings;
use RRD::Simple();
my $rrd_file = shift @ARGV;
my $DS_name = shift @ARGV;
my $DS_type = shift @ARGV;
my $rrd = RRD::Simple->new();
print "Processing $rrd_file...";
$rrd->add_source($rrd_file, $DS_name => $DS_type);
print " ok.\n";

e.j.

./rrd_add_datasource.pl $RRD_FILE $DS_NAME $TYPE
./rrd_add_datasource.pl /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd 5 GAUGE

Configurando VLAN tagging sobre Bond

No hace mucho, he tenido que configurar un bond con tagging y he tenido algunos problemas que me parece buena idea, dejar por escrito.

La configuración de una interfaz «tagueada» con el id de una VLAN, no tiene más complicación. Existe mucha documentación al respecto.

Defines tu fichero de interfaz ifcfg-eth0 y su copia «link» con un «.» seguido del vlan_id…. ifcfg-eth0.10 (En este fichero, se define la configuración de red y se añade la clausula «VLAN=yes»)

Hasta aquí, todo según la documentación….

Al combinar, bond y tagging, es cuando he tenido estos problemas principalmente:

1.- Para vlans, necesitamos el modulo 8021q, el cual no carga por defecto, por lo que creamos un fichero /etc/modules-load.conf/8021q.conf

8021q

2.- Según la documentación consultada, desde la versión 6.3 de CentOS, existen problemas con bonding+tagging y NetworkManager. En los «bug reports» se recomienda que se pare NetWorkManager.

Estas pruebas se han realizado con CentOS 7.2 y tenia el mismo problema.

3.- Al parar NetworkManager, el modulo de bond no se carga al arranque. Para esto, tenemos dos alternativas:

3a.- Definir la carga del modulo creando un fichero en /etc/modprob.d/bond.conf

alias bond0 bonding
options bond0 miimon=100 mode=0

El detalle de los modos disponibles, lo tenéis aqui

3b.- Definir en el fichero de configuración del bond, la opción BONDING_OPTS:

BONDING_OPTS="mode=balance-rr miimon=100"

Esto hace que el modulo se cargado al arranque
Tras esto, la configuración siguiente funciona sin problemas:

ifcfg-eno1

TYPE="Ethernet" BOOTPROTO="none" NAME="eno1" DEVICE="eno1" ONBOOT="yes" NM_CONTROLLED="no" MASTER="bond0" SLAVE="yes"

ifcfg-eno2

TYPE="Ethernet" BOOTPROTO="none" NAME="eno2" DEVICE="eno2" ONBOOT="yes" NM_CONTROLLED="no" MASTER=bond0 SLAVE=yes

ifcfg-bond0

TYPE="Bond" BOOTPROTO="none" DEVICE="bond0" NAME="bond0" ONBOOT="yes" BONDING_OPTS="mode=balance-rr miimon=100" NM_CONTROLLED="no"

ifcfg-bond0.10

BOOTPROTO="none" DEFROUTE="yes" NAME="bond0.10" DEVICE="bond0.10" NM_CONTROLLED="no" ONBOOT="yes" IPADDR="192.168.1.23" PREFIX="24" GATEWAY="192.168.1.1"DNS1="8.8.8.8"DNS2="8.8.4.4"BONDING_MASTER=yes VLAN="yes"

Con esto tendremos nuestro bond «tagueado» con el id de la vlan, como vemos a continuación.

# ip -d link show bond0.107: bond0.10@bond0: UP> mtu 1500 qdisc noqueue state UP mode DEFAULT     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff promiscuity 0     vlan protocol 802.1Q id 10 addrgenmode eui64

[root@XXXXnetwork-scripts]# ip a l 1: lo: ...2: eno1: LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 3: eno2: LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 4: ...5: ...6: bond0: UP,LOWER_UP> mtu 1500 qdisc noqueue state UP     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff     inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link        valid_lft forever preferred_lft forever 7: bond0.10@bond0: UP> mtu 1500 qdisc noqueue state UP     link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff     inet 192.168.1.23/24 brd 192.168.1.255 scope global bond0.10
       valid_lft forever preferred_lft forever     inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link        valid_lft forever preferred_lft forever