Archivos Mensuales: octubre 2016

Las iDRAC molan. A veces. Salvo que te las cargues actualizando

Enviado por el 20/10/2016 Sin comentarios

Las iDRAC antiguas, en particular las iDRAC 6 y anteriores, tienen sus manías. Más manías cuanto más antiguo es el firmware, hasta el punto de ser poco menos que intratables: Solo funcionan con versiones prehistóricas de ie, les petan las actualizaciones, no les funciona https… En fin, esas cosillas.

A veces, es posible que una de estas iDRAC antiguas petardee al actualizar, y las cosas se van rápidamente a la alcantarilla. El peor caso que he conocido necesitó comprar un recambio. ¿Qué recambio? Ahí está lo gracioso: Dell parece hacer como si no existiera.

En los fiables (aunque ya venerables) r610, el acceso fuera de banda al servidor está compuesto de dos piezas separadas: La placa que contiene el puerto Ethernet (y que habitualmente se llama iDRAC a secas) y otra placa que se llama iDRAC express, y que no es otra cosa que una BMC glorificada. Para confundir las cosas, el firmware no va en la iDRAC, sino en la iDRAC express. Y la iDRAC express, va de serie en los r610, y no se vende como recambio normalmente. De hecho, en el esquema del servidor donde se dice dónde van hasta cosas tan raras como la licencia de iSCSI (que es una especie de llave física), no se hace ni mención a la iDRAC express, pero sí a la iDRAC, que es opcional.

Pues bien, cuando la actualización de firmware de iDRAC se va al desagüe… ¿A que no adivinas qué placa es la que se ha quedado gagá? Claro, como no podía ser de otra forma: La que «no existe».

¿La solución? Bueno, tal vez sea posible recuperarla por el método descrito aquí, usando el puerto serie virtual para acceder a la consola de recuperación. Pero si no, no hay problema: Nos vamos a eBay, y preguntamos por una iDRAC 6 express. Las he llegado a ver por un euro (mas 18 de envío). Os aseguro que es más barato que el tiempo que se puede llegar a perder peleando con una iDRAC 6 express mal flasheada (y disculpad el barbarismo). Creedme, aunque os costara 50 euros, seguiría siendo barato.

 

L2TP entre un router Cisco y uno Mikrotik

Enviado por el 15/10/2016 Sin comentarios

Supongamos que tenemos routers Cisco en casa de clientes funcionando desde tiempo inmemorial, estupendamente, y que no se quieren cambiar.

Supongamos además que, por el motivo que sea, necesitamos una VPN entre uno de esos routers Cisco y un Mikrotik que tenemos funcionando en otro sitio, como por ejemplo en un centro de datos.

Supongamos que nos ponemos a buscar documentación sobre el asunto… Y el resultado puede ser más descorazonador, pero por poco. Para saber qué versión de L2TP habla el Mikrotik, hay que remitirse al RFC (en resumen: La 2). Muchos IOS, no tienen una implantación completa de L2TP como la que he usado; si no existe pseudowire-class, lo mejor es ir directamente a otro IOS. Por ejemplo, en los 2801 que corren un venerable pero estabilísimo 12.4T, no hay en la IP Voice, pero sí en la IP Base. Los caminos del señor (el señor que empaqueta las versiones de IOS, quiero decir) son inescrutables.

Por resumir una horita de pelea: Esta configuración que adjunto, funciona. Ciertamente admite mejoras: Poner algo de encriptación, para empezar. Y seguramente sobre alguna cosilla, como por ejemplo la doble clave el en caso del Cisco. Pero tal como me ha quedado, lo cuento. Y cuando la mejore en un futuro, prometo intentar vencer la pertinaz procrastinación y actualizar el artículo.

Como ejercicio para el lector, dejo adivinar qué parte va en el Cisco, y qué parte en el Mikrotik.

El cliente:

l2tp-class Voz
 hostname l2tp-cliente
 password laclavequesea
!
pseudowire-class PseudoHilillo
 encapsulation l2tpv2
 protocol l2tpv2 EncapsulacionL2TP
 ip local interface Loopback0
!
interface Virtual-PPP1
 ip address negotiated
 ip mtu 1460
 ip tcp adjust-mss 1420
 ppp chap hostname l2tp-mikrotik
 ppp chap password laclavequesea
 pseudowire 10.0.0.1 11 pw-class PseudoHilillo
 !

Y el servidor:

/interface l2tp-server
 add comment=cliente name=l2tp-cliente user=l2tp-cliente

/interface l2tp-server server
set enabled=yes max-mru=1460 max-mtu=1460

/ppp secret
 add local-address=10.0.0.1 name=l2tp-cliente password=laclavequesea profile=l2tp-tunnel remote-address=10.0.0.2

 

A vueltas con las claves SSH

Enviado por el 02/10/2016 Sin comentarios

SSH es un protocolo estupendo, y OpenSSH es una implementación digna de estudio por su usabilidad y pulcro mantenimiento, lo que le ha llevado a una casi ubicuidad.

Con los años, los cifrados han ido cambiando, aconsejándose unos y otros según avanza la ciencia de la criptografía. Los siguientes son los más habituales, y los primeros tres los que más he usado:

  • RSA, el clásico. Aunque desaconsejado por haber sido superado por lo último, sigue siendo la única forma de tener autenticación con clave pública en, sin ir más lejos, los también ubicuos switches Cisco Catalyst, que no conocen otra cosa. No es aconsejable usarlo para nuevas claves salvo en casos como el mencionado si hay otros más modernos.
  • DSA, el que pudo ser. Hace bastantes años, DSA prometía mejorar RSA. Sin embargo, los avances en criptografía lo acabaron poniendo en un riesgo mayor que RSA. En los OpenSSH actuales, se desaconseja usar DSA. Incluso Mac OS Sierra lo trae desactivado de serie.
  • ECDSA, una nueva esperanza. DSA con curvas elípticas. Teóricamente, un DSA sin los problemas de DSA. En la práctica, también tiene sus «problemillas»: Su seguridad depende de lo bueno que sea el generador local de números aleatorios. Ni mencionar a alguien siquiera medio paranoico.
  • Ed25519, el salvador (al menos por ahora). Un algoritmo matemáticamente fuerte, implementable con buen rendimiento, que depende menos del generador local de números aleatorios y, en fin, al que no se le conocen por ahora grietas. En resumen, el que hay que usar si se ha de elegir uno para empezar.

Por cierto. .ssh/authorized_keys2 lleva años desaconsejado, pero aún se ve en servidores por el mundo alante. Trabajando con versiones siquiera medio actuales de SSH, es recomendable mv .ssh/authorized_keys2 .ssh/authorized_keys.