Blog de Javi

A continuación se muestra una pequeña configuracion de un punto de acceso Cisco AIR-AP1131-AG-E-K9 para una configuración básica casera.


version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname AIR-AP1131
!
logging rate-limit console 9
enable secret clave_enable
!
no aaa new-model
led display alternate
ip name-server 8.8.8.8
ip name-server 8.8.4.4
!
!
dot11 syslog
!
dot11 ssid MiSSID
authentication open
authentication key-management wpa
guest-mode
wpa-psk ascii miclavewpa
!
power inline negotiation prestandard source
!
!
username admin password clave_de_usuario_admin
!
!
bridge irb
!
!
interface Dot11Radio0
no ip address
no ip route-cache
!
encryption mode ciphers aes-ccm
!
ssid MiSSID
!
channel 2452
station-role root
no dot11 extension aironet
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
bridge-group 1 spanning-disabled
!
interface Dot11Radio1
no ip address
no ip route-cache
shutdown
no dfs band block
channel dfs
station-role root
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
bridge-group 1 spanning-disabled
!
interface FastEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
bridge-group 1
no bridge-group 1 source-learning
bridge-group 1 spanning-disabled
hold-queue 160 in
!
interface BVI1
ip address 192.168.1.254 255.255.255.0
no ip route-cache
!
ip default-gateway 192.168.1.1
ip http server
no ip http secure-server
ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
logging 10.0.0.1
snmp-server community public RO
snmp-server ifindex persist
snmp-server location Ubicacion
snmp-server contact Contacto
bridge 1 route ip
!
!
line con 0
line vty 0 4
login local
!
sntp server 150.214.94.5
sntp broadcast client
end

Proxmox VE (entorno virtual), una plataforma de virtualización de código abierto, muy fácil de usar al ejecutar accesorios y máquinas virtuales, acaba de alcanzar la versión 2.0.

Proxmox VE 2.0 está finalmente disponible, después del lanzamiento de una versión Beta y una versión Release Candidate. Podemos asumir sin dar lugar a dudas que esta versión presenta muchas mejoras y actualizaciones importantes.

Puntos destacados de Proxmox VE 2.0:

• Linux Kernel 2.6.32
• La distribución se basa en Debian Squeeze
• Se implementó una nueva GUI basada en el marco JavaScript Ext JS 4
• Se agregó soporte para múltiples fuentes de autenticación (MS Active Directory, LDAP, Linux PAM, autenticación de Proxmox VE)
• Se han agregado agentes de recursos para KVM y OpenVZ
• Las copias de seguridad se pueden realizar a través de la GUI
• Todos los trabajos pueden controlarse como «tareas recientes»
• Soporte High Availability Cluster para los huéspedes KVM y los contenedores OpenVZ

Aqui tenemos a un HP Proliant MicroServer N36L que tiene nada mas y nada menos que capacidad para 4 discos duros en la cabina de discos mas un SATA y USB interno, con lo cual podemos llegar hasta tener hasta 5 discos. Posteriormente puedes meter una controladora PCI-Express y meter un par de discos mas. Externamente dispone de 4 USB Frontales y 2 USB Traseros + 1 Puero eSata. Lleva la controladora de RAID de la «cabina de discos» y despues otra controladora independiente para el puerto SATA interno este esta preparado para no ir muy rapido ya que es destinado a un lector de DVD, pero hay una BIOS no capada con la cual ese puerto alcanza su velocidad real. Este puerto puede ser usado como disco de sistema, ya que en un principio, si lo usamos como servidor de almacenamiento o de virtualización de Proxmox no necesita mucha velocidad el disco de sistema.

Este equipo es ideal para ser algo mas que un simple servidor de almancenamiento, ya que su procesador dispone de instrucciones de virtualización y se le puede instalar un máximo de 8GB de RAM, por lo que podemos utilizarlo tranquilamente para un servidor de virtualización usando Proxmox o algun otro software de virtualización.

Hace unos dias adquiri un Mikrotik RB751U-2HnD y aqui teneis una pequeña revisión de este fabuloso dispositivo.

En primer lugar, cuenta con 5 interfaces de red 10/100 y un procesador de 400MHz, y según las pruebas realizadas por MikroTiklogra un Throughput de hasta 450Mbps en total (con frames de 1500 bytes) y hasta 92000 paquetes por segundo (con frames de 64 bytes).

Cuenta también con un puerto USB, el cual se puede usar para conectar un módem GSM y tener avisos/alertas por SMS. Este último atributo también permite enviarle un SMS al MikroTik para que ejecute algún script. El puerto además se puede usar para conectar un dispositivo de almacenamiento externo (como un pendrive o disco externo) y hacer caché ahí mismo. Personalmente conecté un disco de 80GB y me lo detectó sin problemas.

Quizá una de las cosas que más se esperaban de un RouterBOARD de bajo costo, es la incorporación de una placa inalámbrica. Lo bueno de este dispositivo es que cuenta con una tarjeta en 2.4GHz que soporta los estándares 802.11 b/g/n con 1W de potencia máxima y una antena incorporada de 2.5 dBi. La verdad que tiene un alcance interesante para ser un equipamiento indoor. Incluso si por algún motivo se deseara extender el alcance del mismo, cuenta con un conector externo MMCX para agregarle una antena de mayor ganancia.

En resumen, este Mikrotik es el más completo para las soluciones de interior de bajo coste. Se lo puede utilizar como un balanceo de carga de hasta 5 WANs y distribuirlo de manera inalámbrica, como firewall para la protección de la red interna, como Traffic Shaper para la priorización de las aplicaciones que sean más sensibles a la disponibilidad del ancho de banda y latencia, como sistema de monitoreo de los dispositivos de red, control de protocolos y mucho más por un precio muy bajo.

Hoy vamos a instalar un servidor secundario/failover del servicio DHCP de nuestra red Linux. Como todos sabemos, una simple caida del servidor DHCP puede dejar a toda la red sin funcionar ya que nuestros clientes (si usan el servicio de DHCP), no podran obtener una dirección IP válida y seria imposible que les funcionase algo. Para evitar posibles caidas de este servicio, vamos a instalar un segundo servidor failover.

Suponemos que ya tenemos el servidor principal funcionando en la subred 192.168.200.0/24 como se puede ver en el ejemplo. Tan solo tenemos poner las primeras lineas que estan entre los corchetes de failover, poniendo en address la IP del servidor principal, y en peer adress la IP del servidor failover. Aqui lo vemos:

#
# /etc/dhcpd.conf for primary DHCP server
#
 
authoritative;
ddns-update-style none;
 
failover peer "dhcp-failover" {
   primary; # declare this to be the primary server
   address 192.168.200.2;
   port 647;
   peer address 192.168.200.3;
   peer port 647;
   max-response-delay 30;
   max-unacked-updates 10;
   load balance max seconds 3;
   mclt 1800;
   split 128;
   }
 
subnet 192.168.200.0 netmask 255.255.255.0 {
   option subnet-mask 255.255.255.0;
   option broadcast-address 192.168.200.255;
   option routers 192.168.200.1;
   option domain-name-servers 192.168.200.1;
   pool {
      failover peer "dhcp-failover";
      max-lease-time 1800; # 30 minutes
      range 192.168.200.100 192.168.200.254;
      }
   }

En el servidor secundario quedaria algo asi como lo siguiente. Fijaros que en address pone la IP del servidor secundario, y en peer address la IP del servidor principal:

#
# /etc/dhcpd.conf for secondary DHCP server
#
 
authoritative;
ddns-update-style none;
 
failover peer "dhcp-failover" {
   secondary; # declare this to be the secondary server
   address 192.168.200.3;
   port 647;
   peer address 192.168.200.2;
   peer port 647;
   max-response-delay 30;
   max-unacked-updates 10;
   load balance max seconds 3;
   }
 
subnet 192.168.200.0 netmask 255.255.255.0 {
   option subnet-mask 255.255.255.0;
   option broadcast-address 192.168.200.255;
   option routers 192.168.200.1;
   option domain-name-servers 192.168.200.1;
   pool {
      failover peer "dhcp-failover";
      max-lease-time 1800; # 30 minutes
      range 192.168.200.100 192.168.200.254;
      }
   }

Lo respecto a la declaracion de las subredes, es exactamente igual en un servidor que en otro, por lo que tenemos que tener cuidado al hacer un cambio en un servidor, sea exactamente igual que en otro. Para solucionar esto podemos sacar todo el bloque subnet a un archivo y hacer un include de ese archivo, asi sincronizando el archivo de la subred entre los servidores no hay posible error.