martes, 2 de septiembre de 2014

IPv6 y Enlaces Satelitales: La solución correcta para el resto del mundo

Resumen:



 Hoy en día, el acceso a Internet es un derecho. Es como tener electricidad y agua. Siendo un extremista, me atrevería a decir que es como el oxígeno en algún modo.
 Este pequeño post trata de resumir una simple combinación de tecnologías que se supone sea una solución a largo plazo para lugares remotos donde el acceso a Internet es generalmente difícil de conseguir.
 Una de las metas de la humanidad de hoy debe ser la de ofrecer un buen acceso, seguro, libre, sin bloqueos a la información y fiable a Internet a todo el mundo, sin importar la locación del individuo. Nuestra motivación actual se orienta a lugares donde un enlace terrestre es imposible de encontrar. Entiendase como terrestre, Wireless, Radio, Fibra, Cobre, etc, etc.
 Básicamente queremos mezclar dos conocidas tecnologías que lamentablemente pienso aun no estan trabajando de la mano: 1) los enlaces por satélite y 2) IPv6. La primera de ellas, con la ventaja de alcanzar casi cualquier rincón del planeta. El segundo, es el estándar de facto para el futuro próximo.
Introducción:
 En los últimos 14 años de mi vida he estado trabajando en el área de enlaces satelitales. Además, desde 1998 he tenido curiosidad acerca de IPv6, pero fue no fue hasta hace siete años que he tenido la oportunidad de trabajar e implementarlo en redes en producción. Por último, siempre he sido un apasionado de Internet, las comunicaciones y la libertad de acceso a la información.
Siendo mis bases muy técnica mi orden de preferencia en el mundo de últimas millas (enlaces) van en este orden: 1) Enlaces cableados (Fibra, Cobre), 2) luego enlaces inalambricos terrestres (microondas, Wi-Fi, WiMAX, Celular etc) y 3) finalmente enlaces satelitales. Los dos primeros por diferentes razones no siempre son posibles, principalmente en zonas remotas, rurales y topologicamente dificiles.
Propuesta:
 Una de las cosas maravillosas de los enlaces por satélite, es su capacidad de llegar a prácticamente cualquier lugar del mundo. Ha lo largo de mi experiencia he tenido la oportunidad de participar en las instalaciones portuarias de enlaces satelitales, en lugares muy remotos, tales como embarcaciones, en sitios rurales o selváticos remotos donde no hay ni señal de teléfono celular. A su vez he visto todo tipo de soluciones implementadas en estos enlaces: ATM (cajeros automáticos), POS (Punto de Venta), agencias bancarias, enlace empresarial privado y por supuesto: acceso a Internet donde he visto VoIP, VPNs y aplicaciones regulares como correo electronico y navegación.
 Durante los últimos años he estado profundamente involucrado con IPv6. Yo soy un firme creyente en el concepto "Internet de las cosas", donde la mayoría de los dispositivos estarán conectados a Internet. IPv6 ofrece una cantidad de ventajas que aún estamos esperando conseguir, el dia (no muy lejano) que sea IPv6 se implemente de extremo a extremos entre la mayoría de los internautas el sin fin de servicios que veremos será notable.
 Desafortunadamente, por diversos  motivos,  el pensamiento convencional -principalmente en paises en vias de desarollo- es que  las conexiones a Internet son eficientes en los sitios urbanos. Esto es parcialmente cierto y es exactamente donde quiero llegar con este artículo, no debemos olvidar las grandes masas de población (y cosas) en las zonas no urbanas, notablemente mayor en los países en vias desarrollo. Al final, este hecho se vuelve muy negativo. Estas personas en el mundo rural (millones) se están quedando atrás, cuando las ventajas de la conexión de poseer Internet son excesivamente notables, por mencionar tan solo algunas: el acceso a e-learning, e-nursering (enfermería), la telemedicina, la investigación, el cloud computing, las consultas en línea y muchos otros beneficios que ofrece. Una vez más, el acceso debe ser libre, eficiente, no restringida, seguro y sin bloqueos a ningún tipo de información.
 Aunque enlaces como fibra, híbrida fibra-coaxial y enlaces inalámbricos de muy alta velocidad están creciendo en todos los países, hay lugares donde nunca se ven estas tecnologías o no podrán contar con estos durante varias décadas. La solución que veo venir, y que debemos mantener, es la pareja formada por el nuevo protocolo de Internet (IPv6) y las comunicaciones por satélite.  Sabemos existen enlaces por satélite en todas partes e IPv6 como “nuevo” protocolo va creciendo y avanzando, por lo que mi propuesta es combinar ambas tecnologías.
En mi opinión, esta combinación es la única que realmente ofrece una viabilidad a largo plazo, siendo factible en la actualidad.  Esta es la mejor manera de conectar a todos en el “resto” mundo.
Desafortunadamente los fabricantes de tecnología por satélite han sido de los últimos en ofrecer soluciones basadas en IPv6. En la actualidad, si colocamos en un buscador de Internet algo así como: "IPv6 hubs satelitales " no obtendrá un enlace con información concreta al respecto. En mi experiencia, el año pasado sólo había un fabricante de Hub satelitales que habia añadido soporte IPv6 para su solución. Dicho esto, hemos visto un cambio, aunque pequeño, por un solo proveedor de equipos. No parece haber en el mercado varias opciones satelitales con IPv6 de manera nativa. Mi creencia es que con un poco de apoyo y colaboración de la comunidad, y probablemente de alguna organización,podemos hacer esta combinación un "deber ser" entre los proveedores satelitales. Pensamos que si la industria de satélites   sigue creciendo sin IPv6, será peor para ellos a largo plazo. Nuestra hipótesis se basa en que IPv6 tiene que ser la manera de llegar a donde solo los satélites son capaces. En pocas palabras: 1) La falta de IPv6 en la tecnología satelital en esos lugares le hará daño al desarrollo tecnologico, 2) Esos lugares no podrán disfrutar de algunos de los beneficios que ofrece IPv6.
 Por último, me gustaría mencionar que los problemas tradicionales que se encuentran en los enlaces por satélite, tales como: 1) Retardo de ida y vuelta y 2) los costos; ya están siendo resueltos con modernas tecnologías. También hay algunas nuevas iniciativas que impulsará aún más esta situación.


Conclusión:
 La combinación de enlaces satelitales e IPv6 es la manera correcta de alcanzar ese 50% de población que no tiene Internet en Latinoamérica, la manera correcta de ofrecer servicios básicos de Internet en nuevos clientes, la forma correcta de crear nuevos servicios en la nube y es la única solución existente para enfrentar el agotamiento de IPv4.
Locators is the command that tells Selenium python to identify elements, find_element_by_id, find_element_by_XPath, find_element_by_link_text, find_element_by_tag_name, find_element_by_class_name, find_element_by_css_selector. Selenium find element by class Thereby, we can say that more effective the locator is, stabler will be the automation script. Every pythn bindings requires locators to find web elements. I hope this gives you a clear understanding of how find element by class locator works in pyth
read the info
read the info

miércoles, 23 de julio de 2014

NAT66 en Linux

Hola,
  El dia de hoy voy a hacer un post el cual no deseo que sea tomado de mala manera. Indiscutiblemente no estoy a favor del NAT pero aun asi pienso que es un mecanismo que no desaparecera en IPv6 (se reducira drasticamente) pero siempre existira. En lo posible recomiendo evitar hacer NAT cuando exista la posibilidad.
  Pueden haber muchas razones para implementar NAT66, a) seguramente los clientes acostumbrados a hacer NAT querran hacerlo en IPv6 (suene feo o bonito), b) personas que quieran ocultar su topologia a Internet, c) empresas que consideren NAT como mecanismo para cambiar los IPs de sus redes, d) la tendencia mundial de no permitir tethering en los celulares, e) querer ofrecer IPv6 detras de un dispositivo y mi proveedor no tenga DHCPv6-PD o solo me entregue una red /64, f) alguien que piense que NAT sirve de mecanismo de seguridad, etc, etc, etc, etc.

  En base a lo anterior la intencion de este post no es estar a favor o en contra de NAT, solo deseo indicar que esta disponible en el mundo de IPv6 y ofrecer un sencillo ejemplo. Para bien o para mal puede ser utilizado en algunos escenarios.

Requerimientos:
  El equipo a realizar el NAT66 debe tener:
  - Kernel > 3.9 
  - iptables > 1.4.18

  Ubuntu 14.04 cubre ambos requerimientos "out-of-the-box" y por ello es muy sencillo hacerlo.

  Existen patch para hacer NAT66 en versiones previas pero no lo indicare en este momento.

Escenario:
  Esta es la topologia en la que estoy trabajando. Deseo que "Device 2"  traduzca la direccion IPv6 origen de "Device 1" con la direccion IPv6 de la interfaz saliente (eth2). Con el comando NAT implementado estoy realmente haciendo NAT de toda la subred 2001:db8:12::/48




Configuraciones:

En DEVICE 1:
#ifconfig eth0 inet6 add 2001:db8:12::2/48
#route -A inet6 add default gw 2001:db8:12::1

En DEVICE 2:

Configurar las direcciones IPv6 en el equipo
#ifconfig eth1 inet6 add 2001:db8:12::1/48
#ifconfig eth2 inet6 add 2001:db8:23::1/48

Habilitar enrutamient o IPv6 entre las interfaces:
#sysctl -w net.ipv6.conf.all.forwarding=1

Configurar el NAT66:
#ip6tables -t nat -A POSTROUTING -o eth2 -s 2001:db8:12::/48 -j MASQUERADE

(es de notar que existen muchas otras maneras de hacer NAT con ip6tables)

En DEVICE 3:
#ifconfig eth1 inet6 add 2001:db8:23::2/48
#route -A inet6 add default gw 2001:db8:23::1


  Del lado de Device 3 pueden verificar de muchas maneras que todo funcione, incluso sin ruta por default en Device 3, DEVICE 1 puede llegarle. De igual manera tcpdump, wireshark o una sencilla revision de los logs puedes verificar que efecticamente el NAT esta llevandose a cabo.

  Espero sea de tu utilidad



jueves, 10 de abril de 2014

Super sencillo sniffer en python3

Hola,
  Luego de mucho sufrir y mucho buscar logre adaptar con muy pocos cambios un sniffer que esta en python2 y llevarlo a python3...,  es el unico sniffer que me ha funcionado usando python3.3. Lamentablemente es MUY basico pero creo que alguien le puede servir, por ello se los dejo.
  Al menos captura y muestra origen, destino, puertos TCP e incluso la data en hex. Lo que no he podido hacer es "unpack" la data sobre TCP.

-----

#!/usr/bin/python3.3
#Sniffs only incoming TCP packet

import socket, sys
from struct import *

#create an INET, STREAMing socket
try:
    s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_TCP)
except:
    print ('Socket could not be created. Error Code : ' + str(msg[0]) + ' Message ' + msg[1])
    sys.exit()

# receive a packet
while True:
    packet = s.recvfrom(65565)
     #packet string from tuple
    packet = packet[0]

    #take first 20 characters for the ip header
    ip_header = packet[0:20]

    #now unpack them :)
    iph = unpack('!BBHHHBBH4s4s' , ip_header)
   
    version_ihl = iph[0]
    version = version_ihl >> 4
    ihl = version_ihl & 0xF

    iph_length = ihl * 4
    ttl = iph[5]
    protocol = iph[6]
    s_addr = socket.inet_ntoa(iph[8]);
    d_addr = socket.inet_ntoa(iph[9]);

    print ('Version : ' + str(version) + ' IP Header Length : ' + str(ihl) + ' TTL : ' + str(ttl) + ' Protocol : ' + str(protocol) + ' Source Address : ' + str(s_addr) + ' Destination Address : ' + str(d_addr))

    tcp_header = packet[iph_length:iph_length+20]

    #now unpack them :)
    tcph = unpack('!HHLLBBHHH' , tcp_header)

    source_port = tcph[0]
    dest_port = tcph[1]
    sequence = tcph[2]
    acknowledgement = tcph[3]
    doff_reserved = tcph[4]
    tcph_length = doff_reserved >> 4

    print ('Source Port : ' + str(source_port) + ' Dest Port : ' + str(dest_port) + ' Sequence Number : ' + str(sequence) + ' Acknowledgement : ' + str(acknowledgement) + ' TCP header length : ' + str(tcph_length))

    h_size = iph_length + tcph_length * 4
    data_size = len(packet) - h_size

    #get data from the packet
    data = packet[h_size:]

    print ('Data : ' + str(data))
    print ()


(solo captura TCP pero es muy sencillo adaptarlo a otros protocolos)
------

Basado en:

http://www.binarytides.com/python-packet-sniffer-code-linux/

sábado, 5 de abril de 2014

Solucion a tres errores cuando queremos arrancar ISC DHCP 4.3


Error 1: 
Can't open lease database /var/lib/dhcp/dhcpd6.leases: No such file or directory --
  check for failed database rewrite attempt!

Ejemplo:
root@IPv6-RTR:/etc#  /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Can't open lease database /var/lib/dhcp/dhcpd6.leases: No such file or directory --
  check for failed database rewrite attempt!
Please read the dhcpd.leases manual page if you
don't know what to do about this.
root@IPv6-RTR:/etc# touch /var/lib/dhcp/dhcpd6.leases


Solucion a error 1:
#touch /var/lib/dhcp/dhcpd6.leases

Adicionalmente verificar si el usuario con el que se esta ejecutando dhcpd posee escritura en /var/lib/dhcp

Quizas tambien hay que:
#cd /var/lib/
#chown -R root.root dhcp

--------------------------

Error 2:
   No subnet6 declaration for eth5 (fe80::a00:27ff:fee7:b7c)

Ejemplo del error:
root@IPv6-RTR:/etc/dhcp# /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Wrote 0 NA, 0 TA, 0 PD leases to lease file.

No subnet6 declaration for eth5 (fe80::a00:27ff:fee7:b7c).
** Ignoring requests on eth5.  If this is not what
   you want, please write a subnet6 declaration
   in your dhcpd.conf file for the network segment
   to which interface eth5 is attached. **


Not configured to listen on any interfaces!


Solucion a error 2:
   Quitar la declaracion de subnet6 en dhcpd6.conf y copiarla a dhcpd.conf

-------------------------

Error 3:
   Can't set SO_REUSEPORT option on dhcp socket: Protocol not available

Ejemplo del error:

root@IPv6-RTR:/etc/dhcp# /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Wrote 0 NA, 0 TA, 0 PD leases to lease file.
Can't set SO_REUSEPORT option on dhcp socket: Protocol not available

Solucion a error 3:
 Actualizar el kernel a una version >= 3.9

SO_REUSEPORT es requerido por ISC DHCP 4.3 por ello es necesario tener un kernel > 3.9

miércoles, 2 de abril de 2014

Instalar ISC DHCP 4.3 en Linux (Ubuntu 13.04) (IPv6)

Situacion:
  Deseo instalar DHCP ISC 4.3 en Linux para mejorar el soporte de DHCP para IPv6.

Procedimiento:
  1) Agregar la siguiente linea al final de /etc/apt/sources.list:

deb http://ftp.de.debian.org/debian experimental main

  2) Eliminar cualquier dhcp de ISC que tuviesemos antes:

#apt-get purge isc-dhcp-server  (notese que podemos usar purge o remove, lo dejo a tu criterio)


  3) Actualizar la DB de repositorios:
#apt-get update

  4) Instalar el isc-dhcp-server indicando que use el repositorio experimental:

 #apt-get -t experimental install isc-dhcp-server


Importante:
  La configuracion del DHCP(d) debe estar funcionando, sino, el DHCPD no levantara y dara un error (logico, no?)


Más información:
http://blog.acostasite.com/2014/04/solucion-tres-errores-cuando-queremos.html


lunes, 10 de febrero de 2014

Configurando Quagga para manipular prefijos (Local Preference) utilizando RPKI

Objetivo:
   En el siguiente mini laboratorio configuraremos Quagga para manipular prefijos BGP y asignar Local Preference segun el estado RPKI (valid, invalid, Not Found).
 
Escenario:
- R1 publica un prefijo con un AS que no le corresponde (segun ROA)
- R2 publica el mismo prefijo que R1 pero desde un AS que si es valido
- R2 publica un prefijo sin ROA.
- En este escenario el validador y el router Quagga estan en el mismo equipo

Diagrama del laboratorio:




Requisitos:
- Quagga con soporte para RPKI
- RPKI Validator de RIPE NCC
- Un prefijo que sepamos que se tiene ROA valido. En nuestro caso utilizamos el prefijo 200.85.64.0 que sabiamos que tiene un ROA que indica que debe ser publicado por el AS 7908
- Ejecutar el validador de RIPE NCC antes de ejecutar Quagga


Configuraciones de todos los equipos

Conf-Quagga-RPKI-Mini-LAB.txt

hostname RPKI-RTR
password test
!
router bgp 65000
 bgp router-id 10.0.0.10
 bgp bestpath prefix-validate allow-invalid
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 route-map rpki in
 neighbor 10.0.0.2 remote-as 7908
 neighbor 10.0.0.2 route-map rpki in
 neighbor 10.0.0.3 remote-as 65003
 neighbor 10.0.0.3 route-map rpki in
!
route-map rpki permit 10
 match rpki invalid
 set local-preference 10
!
route-map rpki permit 20
 match rpki valid
 set local-preference 30
!
route-map rpki permit 30
 match rpki notfound
 set local-preference 20
!        
line vty
!
enable-rpki
  rpki polling_period 1000
  rpki timeout -1216757171
!
  rpki group 1
    rpki cache 127.0.0.1 8282
! 

R1.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
enable password test
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.1 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 password test
 login
!
end

R2.cfg

!
!
!
!
hostname R2
!
no ip domain lookup
no ip icmp rate-limit unreachable
ip tcp synwait 5
!
!
interface Ethernet0
 ip address 10.0.0.2 255.255.255.0
 half-duplex
!
!
router bgp 7908
 no synchronization
 bgp log-neighbor-changes
 network 200.85.64.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 200.85.64.0 255.255.255.0 Null0
no ip http server
!
line con 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
line aux 0
 exec-timeout 0 0
 logging synchronous
 privilege level 15
 no login
!
!
end

R3.cfg

!

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
memory-size iomem 15
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
!
ip cef
ip audit po max-events 100
!
!
!
!
ip tcp synwait-time 5
! 
!
!
!
interface Ethernet0
 ip address 10.0.0.3 255.255.255.0
 half-duplex
!
interface FastEthernet0
 no ip address
 shutdown
 speed auto
!
router bgp 65003
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.0
 neighbor 10.0.0.10 remote-as 65000
 no auto-summary
!
ip classless
ip route 192.168.0.0 255.255.255.0 Null0
no ip http server
no ip http secure-server
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
line vty 0 4
 login
!
end



Salida final en Quagga:
(Notese los flags N, I, V) (Notese los local preference)

RPKI-RTR# sh ip bgp
BGP table version is 0, local router ID is 10.0.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
N*> 192.168.0.0      10.0.0.3                 0     20      0 65003 i
I*  200.85.64.0      10.0.0.1                 0     10      0 65001 i
V*>                  10.0.0.2                 0     30      0 7908 i

Total number of prefixes 2




domingo, 9 de febrero de 2014

Paso a paso. Instalando Quagga con soporte RPKI

(realizado en Ubuntu 13.04)
1) Instalar varios aplicativos & librerias necesarias:
#apt-get install autoconf
#apt-get install libtool  (es necesario el libtoolize)
#apt-get install gawk  (con solo awk no funciona)
#apt-get install libssh-dev  (libssh es necesario para RPKI)
#apt-get install libreadline-dev  (es necesario para vtysh de quagga)
#apt-get install texti2html
#apt-get install texinfo

#apt-get install cmake
#apt-get install doxygen
#apt-get install build-essential
#apt-get install git


2) Es necesario instalar RTRLIB para tener RPKI en Quagga:
#cd /usr/src
#wget https://github.com/rtrlib/rtrlib/archive/v0.2.3.tar.gz

#tar -zxvf v0.2.3.tar.gz
#cd rtrlib-0.2.3/
#cmake -D CMAKE_BUILD_TYPE=Release -D LIBSSH_LIBRARY=/usr/lib/i386-linux-gnu/libssh.so -D LIBSSH_INCLUDE=/usr/lib/i386-linux-gnu .
#make
#make install

3) Instalar Quagga con soporte RPKI:
#adduser quagga (quagga correra con este usuario)
#cd /usr/src
#git clone git://github.com/rtrlib/quagga-rtrlib.git
#cd quagga-rtrlib/
#./bootstrap.sh  (this will create the configure file)
#./configure --enable-vtysh --enable-rpki   --disable-zebra  --localstatedir=/usr/local/etc
#make
#make install

Hay que decirle al sistema operativo como conseguir RTRlib
#echo "/usr/local/lib/i386-linux-gnu" >> /etc/ld.so.conf
(la linea de arriba depende de la arquitectura)
#ldconfig


Los permisos para el directorio de quagga
#cd /usr/local
#chown -R quagga.quagga etc/


4) Una micro configuracin de BGP para probar que todo levante:
#echo "password test" > /usr/local/etc/bgpd.conf

5) Probar si todo funciona (al menos BGP)
#cd/usr/local/sbin
#./bgpd &

#ps -ef | grep bgpd
#telnet localhost bgpd  (deberias obtener un prompt, password test)


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...