VPN Mac OS cisco IPSEC

Esta entrada es otro apunte.

Hoy toca documentar cómo conectarse por vpn (ipsec) a un cisco, bien sea un concentrador, router o firewall.

Nos hará falta el “group authentication” y el “password group”.

Para ello, nos vamos a la manzanita, preferencias del sistemapreferencias del siste,a

Seleccionamos el icono de red y luego hacemos click al botón de [+]:

Captura de pantalla 2013-01-23 a las 22.55.06

Seleccionamos Interfaz: vpn, tipo VPN: cisco Ipsec y le ponemos un nombre:

Captura de pantalla 2013-01-23 a las 22.57.06

Y le damos al botón de crear.

En dirección del servidor, colocamos la ip del dns. Nombre de la cuenta, colocamos nuestro usuario y en el password, pues eso, nuestro password.

Y le damos al botón de “ajustes de autenticación”

Captura de pantalla 2013-01-23 a las 23.01.30

En mi caso, suelo configurar siempre la vpn por clave pre-compartida / grupo, ya que por certificado lo veo excesivo…. queda la pantalla tal que:

Captura de pantalla 2013-01-23 a las 23.03.13

Luego, aplicar, aceptar, aceptar y nos queda tal que:
Captura de pantalla 2013-01-23 a las 23.08.42

Y para hacer pruebas, pues le damos al botón de “conectar” y listo. 😉

IPV6 :: una pequeña introducción :: Parte 2

Hoy seguimos con la introducción a IPv6.

Para entender bien las asignaciones de IP’s, suponemos que recibimos de nuestro proveedor un /48 (recordemos que la máscara puede ser hasta un /128, equivalente a un /32 en ipv4) y tenemos varios sites para distribuirlas…..

Tenemos el segmento:

2001:abcd:1234:0000:0000:0000:0000:0000 /48
Primera dirección IPv6 de la red
2001:abcd:1234:ffff:ffff:ffff:ffff:ffff /48
Última dirección IPv6 de la red

Es un ejemplo a lo grande… un /48 se le dará a los proveedores de servicios y ellos, a su vez, pueden dividirlo en un /64 para organizarlas por regiones (por ejemplo), que luego podrán sumarizarlas en los protocolos de routing para hacer más pequeñas las tablas de routing.

Imaginamos hacer un /64 …

2001:abcd:1234:
<-- global routing prefix -->
0000:

0000:0000:0000:0000

Contar los subnet-ID. … de [0000 .. 0FFF] Rango 1 con todas las interface-id / combinaciones disponibles….

Como ya comenté antes, todo interface con IPv6, tendrá al menos una IP de local Link, que se generará de manera automática con el método EUI-64.

Cabe destacar que Microsoft, siguiendo su sendero de mantener los “estándares” de los protocolos y su buen hacer, de manera predeterminada no los autoconfigura así, aunque se puede corregir el comportamiento.

Microsoft no lo hace de manera predeterminada, porque considera que son predecibles las ip’s de local link….. por favor, que se preocupen de mantener seguros sus sistemas operativos y dejen los estándares para lo que están.

Para corregir este comportamiento, en windows 2008 / w7 y demás dulzuras de sistemas operativos, en la consola, tecleamos:

netsh interface ipv6 set global randomizeidentifiers=disabled
netsh interface ipv6 set global randomizeidentifiers=enabled

Y aquí tenemos un artículo donde lo explica; merece la pena darle un vistazo (en inglés).

Bueno, pues eso, para generar las direcciones Link / local (recordemos, que no salen del segmento y son auto generadas), se usa la técnica EUI-64, que se encarga de coger la parte de ID de dispositivo y rellenándola con FFFE

Tenemos una mac de ejemplo:

001B:78 39:AB9B
<->oui<-> ID dispositivo

rellenamos hasta los 64 bits con la técnica Split / Flip (FFFE), con lo que nos quedará la ip de link local de la siguiente manera:

fe80::21b:78ff:fe39:ab9b

Observamos que hay una diferencia respecto a la mac address:
001B:78 39:AB9B
021B:78FF:FE39:AB9B
^

Para esta operación, seleccionamos el 7º bit y lo cambiamos de 0 a 1 / viceversa….

0 0 1
0000 0000 0001 …… resto
^
Si lo ponemos a 1 el cero, quedará tal que:

0 2 1
0000 0010 0001 ……. resto

Y por hoy es todo.

IPV6 :: una pequeña introducción ::

Estos días estoy liado con el tema IPV6 y voy a resumir un poco mis limitados conocimientos del tema.

Ya sabemos que los rangos de IPV4 se están agotando y RIPE, prácticamente ya no ofrece, con lo que, o reutilizamos las nuestras o no queda otra que empezar a migrar cosas a ipv6.

El camino es lento, pero las cifras de uso de ipv4 son:

– 1981: Publicación del protocolo IPV4.
– 1985: 6% de ipv4 usadas.
– 2001: 66% de ipv4 utilizadas.
– 2010: 96% en uso.

De las características de IPV6 nuevas tenemos:

– Direccionamiento IP casi infinito
– Desaparece el NAT
– Eliminación de la dirección de broadcast (un gran paso)
– Se simplifica los headers, para permitir mayor eficiencia en los routers
– Soporte para movilidad y seguridad nativo.

Otros cambios importantes que tenemos, comparando con ipv4:

– IPv4 –> 32 bits de longitud, que hacen un total de 4.200.000.000 de nodos posibles.
– IPv6 –> 128 bits o 16 bytes: 4 veces los bits de ipv4 !!!!
– 3.4 x 10^38 de posibles direcciones IP’s

Cambios en el Header :
IPv4

——————————————————-

version | IHL | type of service | total Length
——————————————————-
identification | Flags | Fragment Offset
——————————————————-
Time To Live | Protocol | Header Checksum
——————————————————-
source address
——————————————————-
destination address
——————————————————-
options | padding
——————————————————-

Algunas notaciones de la cabecera:

– Version : en ipv4, el valor es 4 😉
– IHL : Internet header lenght, que resumiendo un poco, este campo especifica el tamaño de la cabecera.
– Type Of Service: Contiene el type of Service o el DSCP (Differentiated Services Code Point), usado para el QoS y marcar los paquetes.
– Total Lenght: Este campo de 16 bit, define el tamaño total del paquete, incluyendo la cabecera y los datos, en Bytes. El valor mínimo son 20 bytes y el máximo 65535.
– Identification: Como bien indica este campo, es usado principalmente para identificar de manera única los fragmentos de un un datagrama.
– Flags : un campo de 3 bits que son :
– bit 1 = 0 ; reservado y debe ser 0
– bit 2 = DF o don’t fragment
– bit 3 = MF o More fragments
– Fragment Offset
– TTL : usado para prevenir loops. El valor inicial es 255 y a medida que el paquete atraviesa routers, se va decrementando 1.
– Protocol : Especifica el tipo de protocolo que transporta, siendo:
– 17 : udp
– 6 : tcp
– 51 : esp
– 50 : AH
– 47 : Gre
– Header ckechsum : Cuando un paquete llega al router, calcula el checksum de la cabecera y compara el valor con el campo checksum …. si no coincide, el paquete es descartado.
– Source address
– Destination Address
– options

Y ahora una cabecera de IPv6 :

——————————————–
Version | Traffic Class | Flow Label
——————————————–
Payload Lenght | Next Header | Hop Limit
——————————————–
source address
——————————————–
destination address
——————————————–

A primera vista, observamos que se ha simplificado bastante el tema, facilitando la vida a los routers ( el procesador, entre otras cosas…)

– Version : 4 bits y fijo 0110 (6 en binary) 😉
– Traffic Class : Idem que en IPv4; contiene por ejemplo el DSCP
– Flow Label (20 bits): Se puede usar para clasificar los distintos flujos… por ejemplo, en ipv4 los flujos son determinados a partir de las direcciones IP origen / destino, puertos y transporte.
– Payload Lenght (16 bits)
– Next Header (8 bits): Apunta al siguiente header (rollo puntero en C 😉 )
– Hop Limit (8 bits) : Sustituye al TTL en version ipv4… si el valor llega a 0, el paquete es descartado.
– Source address: dirección ip, esta vez pasa de 32 a 128 bit el tamaño del campo
– Destination address: idem de arriba.

Otra cosa que me llama la atención, es que, teóricamente, desaparece la fragmentación de paquetes, con lo que ganamos en eficiencia en los routers…. Para ello, IPv6 usa un proceso de MTU discovery que determina el valor óptimo que deberá tener: el source, intenta el envío de un paquete con el tamaño que ha especificado los protocolos de capa superior (tcp, udp..)… si el dispositivo recibe la respuesta con “packet too big”, entonces :
– Retransmite el paquete mtu discover con una mtu más pequeña.
– Este proceso es repetido mientras que el dispositivo reciba “packet too big”.

Ahora toca ver la representación de ip’s en IPv6:

2001:0114:abcd:0000:0000:0000:0001:0004

Y ésto se puede representar como:

2001:0114:abcd::1:4
||
—–> usado para acortar 0 y SÓLO SE PUEDE USAR 1… si tenemos más 0, o lo usamos la primera vez o con la segunda… IMPORTANTE

la máscara, puede llegar hasta los 128 bits (equivalente en IPv4 al /32).

::/0 –> es la IP por default, mientras dura la negociación de IP, equivalente a ipv4 0.0.0.0 o unespecified address

Copiando un poco la notación de las clases de IPv4 (Clase a,b o c), tenemos con el primer grupo:

0000 | Rango reservado por EEUU (ejército ??)
1FFF | ” ” ” ”
2000 | min: usado por direcciones ip’s públicas
3FFF | max: usado por direcciones ip’s públicas
…. | resto reservadas por ahora
FC00 | Ip’s privadas dentro de un site
FE80 | Direcciones de link local
FF00 | Direcciones de multicast

Haciendo referencia a las direcciones de link local:

– No son enrutables, por lo que no salen del segmento de red.
– se generan en parte, con la mac address del dispositivo (EUI 64)
– Cada host, debe de tener una.

Las direcciones FE80, son equivalentes a las 169.254.0.0 /16 (PIPA o private ip address) y se generan en función de la mac address con las funciones de SPLIT y FLIP, que definiremos en la siguiente entrada.

Coming soon !!!!

Mikrotik & Netflow setup

El primer post del 2013.

Un apunte para recordar cómo configuraremos el netflow en una Mikrotik.

Entramos por telnet o winbox (prefiero telnet):

# telnet 192.168.2.251
mikroTik v5.22
login: miuser
password: xxxxxx

Entramos en modo netflow y lo habilitamos:

/ip traffic-flow
/ip traffic-flow> set enabled=yes

Y comprobamos la config:

[craem@router] /ip traffic-flow> print
enabled: yes
interfaces: all
cache-entries: 4k
active-flow-timeout: 30m
inactive-flow-timeout: 15s
[craem@router] /ip traffic-flow>

Y ahora añadimos el destino para los traps de netflow:

[craem@router] /ip traffic-flow target
[craem@router] add address=192.168.2.3:9996 version=9

Y comprobamos la config:

[craem@router] /ip traffic-flow target> print
Flags: X – disabled
# ADDRESS VERSION
0 192.168.2.3:9996 9
[craem@router] /ip traffic-flow target>

Y con ésto, ya lo tenemos configurado.

Netflow, es un protocolo desarrollado inicialmente por cisco, que sirve para recolectar toda la info que pasa por los routers / interfaces.

Podríais decir que snmp hace lo mismo, pero no es cierto. SNMP captura el volumen de tráfico ( a lo mejor con los mibs adecuados, si), pero netflow nos desgrana en detalle ip’s origen / destino / puerto y con el programa adecuado, por ejemplo , obtendremos unas estadísticas interesantes, que nos puede servir, por ejemplo, para saber en qué gastamos nuestro ancho de banda, cantidad, etc..

Enjoy your netflow 🙂