lunes, 21 de enero de 2013

Convertir un Access point Cisco Aironet 1242 modo Lightweigth a Access point modo Autónomo/Stand Alone


Situacion:
La mayoría de estos equipos Cisco Aironet vienen con la IOS (Internetwork Operating System) para que funcione en modo Lightweigth y por más que trates de configurarlos por cualquier vía no lo vas a poder hacer si no tienes un WLC (Wireless Lan Controller) los cuales son algo costosos.

El problema de los Access Point (AP)  en modo Lighweigth es que toman la configuración del WLC (Wireless Lan Controller) que esté presente en la red, por esto estos AP se les conoce como zero touch debido a que no hace falta realizarle casi  ninguna configuración. En resumen si no tenemos un WLC no podremos configurar el AP vía web ni vía consola.

Si ingresas vía consola (Hiperterminal u otro) te va a pedir la contraseña de modo privilegiado la cual por defecto es “Cisco” después de eso cuando intentes pasar a modo global ejecutando el comando “configure terminal” como en el cualquier dispositivo CISCO te aparecerá el siguiente mensaje ”command not found”, yo también me preocupé en ese momento pensé que el dispositivo tenía algún tipo de problema, ejecuté cualquier cantidad de comandos existentes para pasar a modo de configuración pero nada.
Intenté conectarme vía web, por defecto el AP viene con la dirección 10.0.0.1 simplemente lo conecte mediante su puerto  Ethernet a mi computadora a la cual le asigne la dirección 10.0.0.2, probé la conectividad con el comando ping entre ellos y todo estaba perfecto pero en el momento de intentaba ingresar vía web (mediante un explorador de internet e.g Internet Explorer ,Mozilla Firefox ,colocaba la dirección 10.0.0.1) no me dejaba ,simplemente es que en el modo Lightweight no tenemos acceso al AP vía web.

La solución:
La solución es cambiarle la IOS al AP para que este funcione en modo Autónomo o Stand Alone en vez de Lightweight y así poder configurar el AP normalmente ya sea vía Web o mediante consola.

Procedimiento:
Los siguientes son los pasos para revertir un AP que esta en modo LWAPP a modo Autónomo cargando un Cisco IOS utilizando un servidor TFTP.

1.- En nuestra PC cargamos un servidor TFTP en esta misma maquina configuraremos el AP.
2.- El PC se comportara como el servidor TFTP le asignaremos por ejemplo la dirección 10.0.0.2 (acordémonos que el AP por defecto tiene la 10.0.0.1)al mismo tiempo nos conectamos mediante el cable de consola al AP mediante la aplicación Hiperterminal.
3.- Después que conseguimos la nueva IOS (c1240-k9w7-tar.default) la copiamos  a la carpeta donde guarda el servidor TFTP los archivos por defecto. (debemos que asegurarnos de que tenemos la nueva IOS en el PC que esta  como servidor TFTP)
4.- El siguiente paso simplemente es conectar el AP a nuestro PC (servidor TFTP) mediante un cable utp.
5.- Desconecte el AP de la corriente eléctrica.
6.- Conectamos el AP a la corriente eléctrica al mismo tiempo que mantenemos presionado  el botón MODE en el AP.
7.- Esto lo hacemos alrededor de 20 a 30 segundos el LED de AP se coloca de color lila, como tenemos abierta la aplicación  Hiperterminal en ella nos debería aparecer el siguiente mensaje “button is pressed ,wait for button to be released…”
8.- En este momento la nueva IOS se esta copiando desde el servidor TFTP a la flash del AP, simplemente debemos esperar a que se termine de copiar.
9.- Automáticamente la nueva IOS reemplazara a la anterior.
10.- Lo único que nos queda es por fin empezar a configurar nuestro AP ya sea vía consola o vía web.

Nota: para conseguir la IOS que necesitamos solo debemos colocar  en google lo siguiente        “ c1240-k9w7-tar.default shared “   abrimos el primer resultado que nos arroje, y la descargamos.
Nota: para poder ingresar vía web al AP este necesita tener configurado una dirección ip, además de un usuario con nivel 15 de privilegio, lo creamos de la siguiente manera:
AP (config) username “nombre usuario” privilege 15 password “password”.
Nota: para descargar el servidor TFTP simplemente hazlo desde esta página http://www.winagents.com/en/downloads/download-tftp-server.php.

1.-Le colocamos nombre al AP
Router (config)hostname AP

2.-Configuramos un SSID al AP podemos tener varios SSID.(por ejemplo le colocamos WIRELESS)
AP (config)dot11 ssid WIRELESS
AP (config-ssid)authentication open 
AP (config-ssid)infraestructura ssid
AP (config-ssid) guest mode     (el AP divulgara el SSID para que los clientes lo puedan ver)
AP (config-ssid) authentication key management wpa versión 2(opcional le configuramos el protocolo WPA versión 2 para la forma en que administrara las claves)
AP (config-ssid)wpa-psk  ascii “clave”(definimos la contraseña para que los clientes puedan conectarse al AP)

El AP posee 2 interfaces dot11radio0 (2.4 GHz) y dot11radio1 ( 5 GHz)

3.-Asociamos el SSID a la interface a cual queremos que los clientes se conecten.

Interface Dot11radio0
AP (config-if) ssid WIRELESS
AP (config-if) station-role root (por defecto viene así)
AP (config-if) encryption mode ciphers aes-ccm (opcional, definimos AES como el algoritmo de encriptamiento)
AP (config-if) no shutdown (levantamos la interface)

4.-Le asignamos una ip al AP estáticamente para administración (por ejemplo 192.168.1.1) o si existe un servidor DHCP simplemente dejamos que el AP  reciba un IP del mismo.
(config) interface BVI 1
(config-if) ip address 192.168.1.1 255.255.255.0
(config-if) no shutdown







Procedimiento realizado por:  @AlejandroFerrer

miércoles, 2 de enero de 2013

DNS64 y NAT64 paso a paso con explicación

Introducción:
DNS64 y NAT64 son dos tecnología diferentes que comunmente trabajan en conjunto.

DNS64 y NAT64 es ideal para colocar en el borde una red donde unicamente existan host con IPv6, algo cada día es más común sobre todo en el mundo de redes celulares y se gran cantidad de sensores.

En Internet hay mucha información sobre como configurar NAT64 y DNS64, la mayoría dice que muy fácil, otros lo colocan más complicado. En lo personal no conseguí ninguna que explicara paso a paso como hacerlo y adicionalmente que explicara la topología de red donde se estaba configurando.

En este post comienzo instalando DNS64 y luego procedemos con NAT64. Se puede instalar en cualquier orden.

Que se necesita antes de comenzar:

- Una subred IPv6 libre (una /96 esta bien) para realizar el mapeo DNS entre IPv4 e IPv6. Esta misma subred la utilizaremos dentro de Tayga para el NAT64

- Logicamente conectividad IPv6 entre los clientes y el servidor DNS64 y NAT64 (no se requiere IPv4)



Topología:
a) Servidor realizando. Solo tiene una interfaz (eth1)

IPv6: 2001:db8:1:1::/64 (eth1).
IPv4: 192.168.124.107

b) IP de un cliente (eth2):

2001:db8:1:1::2/64


c) Subredes IPv6:

Red que "retorna" el DNS64 2001:db8:1:ffff::/96
Pool de NAT en el NAT64: 2001:db8:1:ffff::/96

(si, son el mismo bloque)


d) Interfaz dns64:

192.168.124.107/32
2001:db8:1::1/128


(correcto!, la IPv6 e IPv4 de eth1 se solapan con interfaz dns64)



Procedimiento de DNS64.

Paso 1:

Instalar BIND9:

#aptitude install bind9


Paso 2:

Configurar /etc/bind/named.conf.options:

a) Asegurar que BIND escuche en IPv6 (recordemos que los clientes van a estar en IPv6)

listen-on-v6 { any; };

b) Permitir consultas desde cualquier IP. Si estas utilizando un servidor público o en producción favor restringir las consultas a tus clientes

allow-query { any; };

c) Realizar el DNS64 con la siguiente directiva.

dns64 2001:db8:1:ffff::/96 { 
    clients { 
      any; };
 };

La configuración del punto "c" lo que indica es que aquellas consultas DNS de aquellos registros que SOLO tienen tienen registro A (no tienen registro AAAA) serán entregadas a los clientes añadiendo 2001:db8::1:ffff::/96


d) Reiniciar bind9

#/etc.init.d/bind9 restart


Probar DNS64:

a) En un PC cliente colocar como servidor DNS: 2001:db8:1:1::1


b) Ubicarse en un cliente y realizar consultar DNS de hosts solo con direcciones IPv4 (registros A). Por ejemplo:


root@ubuntu-VirtualBox:~# dig ipv4.google.com aaaa @2001:db8:1:1::1

; <<>> DiG 9.8.0-P4 <<>> ipv4.google.com aaaa @2001:db8:1:1::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 64252="64252" br="br" id:="id:" noerror="noerror" opcode:="opcode:" query="query" status:="status:">;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;ipv4.google.com.               IN      AAAA

;; ANSWER SECTION:
ipv4.google.com.        0       IN      CNAME   ipv4.l.google.com.
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8268
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8269
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:826a
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8293
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8263
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8267

;; AUTHORITY SECTION:
google.com.             171975  IN      NS      ns1.google.com.
google.com.             171975  IN      NS      ns4.google.com.
google.com.             171975  IN      NS      ns2.google.com.
google.com.             171975  IN      NS      ns3.google.com.

;; Query time: 219 msec
;; SERVER: 2001:db8:1:1::1#53(2001:db8:1:1::1)
;; WHEN: Wed Jan  2 16:11:57 2013
;; MSG SIZE  rcvd: 294




Nota: La parte a destacar en esta salida son las direcciones IPv6 que comienzan por: 2001:db8:1:ffff..., ya en este momento sabemos que DNS64 esta funcionando.



Ahora NAT64

1) Utilizamos Tayga. El sitio oficial y link para descargarlo se encuentra en: http://www.litech.org/tayga/


2) Lo descomprimimos y desempaquetamos:

#tar -jxvf tayga-0.9.2.tar.bz2
#cd tayga-0.9.2
#./configure
#make
#make install


3) Creamos el directorio donde Tayga guardará los logs:

#mkdir /var/log/tayga

4) Editamos el archivo /usr/local/etc/tayga.conf

y copiamos y pegamos:

tun-device nat64
ipv4-addr 192.168.255.1
prefix 2001:db8:1:ffff::/96
dynamic-pool 192.168.255.0/24
data-dir /var/log/tayga



Tayga es stateless y realiza un nat 1:1 entre IPv6 e IPv4. En la configuración anterior a cada cliente IPv6 se le asignará un IP del pool 192.168.255.0/24; por ello si tenemos más de 255 hosts será necesario utililzar un pool más grande que /24. En caso de que tengas IPv4 públicas suficientes puede ser útil para evitar un doble NAT IPv4.

La directiva prefix indica el prefijo que utilizará Tayga para reconocer los 32 bits de IPv4, es decir, cuando el destino IPv6 sea: 2001:db8:1:ffff::/96, Tayga tomará los ultimos 32 bits para reconocer que ese es el destino IPv4

5) Habilitar routing IPv6 e IPv4 en el servidor.

#echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
#echo "1" > /proc/sys/net/ipv4/ip_forward


6) Creación y configuración de la interfaz nat64:

#tayga --mktun
#ip link set nat64 up
#ip addr add 192.168.124.107 dev nat64
#ip addr add 2001:db8:1::1 dev nat64


(estos comandos crean la interfaz nat64 con las direcciones ip 192.168.0.1/32 y 2001:db8:1::1/128, como dije anteriormente no importa que se solape con los IPs de eth1).

Para revisar:
root@aacosta-ThinkPad-E420:~# ifconfig nat64
nat64     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.0.1  P-t-P:192.168.0.1  Mask:255.255.255.255
          inet6 addr: 2001:db8:1::1/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2393 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2395 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:1615556 (1.6 MB)  TX bytes:1614316 (1.6 MB)


7) Creación de rutas:
#ip route add 192.168.255.0/24 dev nat64

#ip route add 2001:db8:1:ffff::/96 dev nat64

8) Ejecutamos Tayga

#tayga -d

(el -d es opcional, solo es para tener más información)


PROBAR NAT64
a) Probamos que todo este bien (el ping debe ser satisfactorio):

root@aacosta-ThinkPad-E420:~# ping6 2001:db8:1:ffff::192.168.0.1
PING 2001:db8:1:ffff::192.168.0.1(2001:db8:1:ffff::c0a8:1) 56 data bytes
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=109 ttl=63 time=2.18 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=110 ttl=63 time=0.209 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=111 ttl=63 time=0.190 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=112 ttl=63 time=0.126 ms



b) Realizamos NAT con la interfaz IPv4 saliente (solo si el pool IPv4 en Tayga es privado):

#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 
#iptables -A FORWARD -i eth0 -o nat64 -m state --state RELATED,ESTABLISHED -j ACCEPT 
#iptables -A FORWARD -i nat64 -o eth0 -j ACCEPT

c) Ahora solo debes dirigirte a la máquina cliente y todo debe estar funcionando. Ejemplos de ping y trace:


[root@localhost ~]# traceroute6 www.algo.com -n
traceroute to algo-com-prod-elb-170663297.us-east-1.elb.amazonaws.com (2001:db8:1:ffff::36f3:7ac3) from 2001:db8:1:1::2, 30 hops max, 16 byte packets
 1  2001:db8:1:1::1  1.224 ms  3.8 ms  0.352 ms
 2  2001:db8:1:ffff::c0a8:ff01  0.787 ms  0.772 ms  0.268 ms
 3  2001:db8:1:ffff::c0a8:1  0.76 ms  0.869 ms  0.278 ms


[root@localhost ~]# ping6 www.parmalat.com.ve -n
PING www.parmalat.com.ve(2001:db8:1:ffff::c82f:4f04) 56 data bytes
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=1 ttl=56 time=7.30 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=2 ttl=56 time=5.82 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=3 ttl=56 time=5.93 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=4 ttl=56 time=8.38 ms



  Puedes ver un estado de las asignaciones de Tayga en: /var/log/tayga/dynamic.map



Voila!... todo debe estar funcionado en este momento!


Mas información: 
http://www.litech.org/tayga/
http://www.litech.org/tayga/README-0.9.2

http://kurser.iha.dk/eit/itifn/workshops/vne_workshop_2.html
http://ipvsix.me/?tag=tayga

Notas importantes:
- El DNS64 no funciona cuando la respuesta DNS tenga registros AAAA y A. En realidad no es una eroor porque se asume que el host tiene acceso IPv6 a Internet
- Es importante que el DNS64 y NAT64 compartan el mismo prefijo IPv6 (en el ejemplo de este post 2001:db8:1:ffff::/96. 
- Durante todo el post describo el procedimiento utilizando la subred IPv6 2001:db8::/32. Favor notar que esta subred debe ser sustituida por sus redes respectivas (al igual que la información referente a IPv4).
- Pueden utilizar 2001:db8::/32 y va a funcionar igualmente pero sin acceso a destinos a IPv6
- El servidor DNS64 y NAT64 pueden ser diferentes equipos/máquinas



to get detailed information about Managed IT Services visit https://wetheitteam.com

BGP Stream: un año de análisis sobre incidentes BGP

BGP Stream: un año de análisis sobre incidentes BGP 04/03/2024 Por  Alejandro Acosta , Coordinador de I+D en LACNIC LACNIC presenta  la prim...