Buenas tardes,
Este año deseo enviar un correo un poco diferente a los anteriores, ¿Por qué?. Porque existen aspectos distintos a años anteriores, voy a enumerar solos dos para no extenderme y en honor a vuestro tiempo.
a) Este será mi último período como moderador de la lista. No voy a postularme para 2015-2017 (muy pronto habrá un llamado de selección), y
b) En mi opinión personal el despliegue de IPv6 este año ha sido significativo en la región de LAC.
En base a lo anterior, puntualmente el item número 2 y tomando en cuenta que finaliza el año 2014, es el mejor momento para utilizar la palabra "Retrospectiva", definida en Wikipedia [1] como: "..... es una enumeración y celebración de eventos ya ocurridos ....", vamos a comentar al respecto en nuestra region.
Les dejo mi humilde análisis sin ser estadista ni literato
1) El Caso Perú:
Este caso específico se ha discutido mucho en la lista. Tanto así que conllevó a una de los más tormentosos intercambios de correos en los últimos años [2], [3] y [4].
En este momento, al menos según datos de Google la penetración de tráfico IPv6 en el país es de 10%, siendo el único país de la region con doble dígito y uniéndose al grupo mundial de países con penetración mayor al 10% junto a Alemania (12.35), USA (10.95), Suiza (10.28) (espero no haber olvidado ningún otro).
Como información adicional, desde Lacnic comenzamos el observatorio de tráfico IPv6 para los países de nuestra región en Mayo de este año, específicamente para Perú nuestras primeras mediciones daban en aquel entonces un grado de penetración de 4.6% y observando caídas hasta de 3.4%. Después del 18 de Junio apreciamos un crecimiento sostenido de tráfico IPv6 y superando como se mencionó anteriormente el 10%.
2) El Caso Ecuador
Ecuador es un país con una rata relativamente baja de penetración de Internet en la población (35% para el 2012 según [6]) sin embargo con una infraestructura que ha mejorado notablemente en los últimos 2.5 años - según [7]-. Por ello voy a trabajar en base a que Ecuador tiene una penetración de Internet de 40%
Para nuestro observatorio, Ecuador es el país con mayor velocidad de adopción de IPv6 en la región, en menos de 60 días pasaron de tener menos de 1% a más de 3.6%.
Teniendo en cuenta que 40% de ~16.000.000 de la población tiene Internet quiere decir que pasaron de: 64.000 abonados a 229.000 entre Octubre y Diciembre.
3) El caso Brasil
Para este caso en particular me hubiese gustado incluso llegar a estadísticas de dispositivos conectados, computadoras en el país pero me costo conseguir data actualizada (ubiqué hasta 2011), pero de igual manera quería indicar:
Segun [5] Brasil tiene 202.000.000 de habitantes, donde 107,822,831 (2014) son usuarios de Internet lo que representa 53% de la población.
En base que en este momento la tasa de penetración de IPv6 para este país indica 0.17% podemos asumir que hay 183.298 usuarios.
Estoy seguro que muchos pensarán que es un número bajo, pero desde Mayo 2014 hasta mediados de agosto fue un número fijo de 0.03%, es decir apenas 60.000 usuarios, incrementaron más de 280.000 abonados en un lapso de 7 meses, ello se traduce a un incremento superior a 400 %.
Finalmente, es perceptible que subir el porcentaje en un país como Brasil es muy complicado por su gran cantidad de población. En cualquier otro país si colocamos 200.000 suscriptores ya hace bastante mella en los termómetros de IPv6.
4) El caso Bolivia
Bolivia parece ser un evento MUY importante que esta ocurriendo sin pena ni gloria. No ha habido discusión en la lista y en lo personal no he escuchado mucho (¿nada?) en otros medios.
Pero en definitiva se merecen un aplauso, nuestros respetos y nuestras felicitaciones.
En estos momentos el país tienen ~0.70% de tráfico IPv6, habiendo comenzado su despliegue a mediados de año con mayor énfasis a finales de Agosto.
Por ahora, el número global del país no lo vemos crecer significativamente porque al parecer es un proveedor pequeño (una cooperativa) quienes estan llevando a cabo el despliegue. De igual manera una vez más extiendo mis felicitaciones.
5) Promedio de LAC
Dentro de las mediciones realizadas por Lacnic hemos calculado el promedio de los países de la región obteniendo un promedio para LAC alrededor del 0.5%.
El punto el cual considero resaltante en LAC es que para mediados de Junio el porcentaje era: 0.12%..., quiere decir que en el lapso de seis meses se ha cuadruplicado la adopción de IPv6 en la región.
¿Qué esperar para el 2015?
Indiscutiblemente deseamos ver un despliegue muy fuerte para el próximo año en la región de LAC. Recuerdo comenzando el 2014 pronostiqué 0.4% de tráfico al finalizar el año y afortunadamente me quedé corto (¡¡me alegra haberme equivocado!!).
Mi predicción -y lo digo solo para dejarlo público-, pienso que en el 2015 vamos a llegar a 2.5% pero honestamente esta muy díficil decir algo certero, quizás más complicado que el pronóstico del tiempo y el fútbol juntos. Son muchas las organizaciones que sabemos que están implementado IPv6, universidades, gobiernos, ISPs, en todos los países y en todas las regiones. Lógicamente espero quedarme corto pero solo indicar 5 veces el número actual es bastante prometedor.
Una vez mas: ¿alguna killer application?
Deseo mencionar algo muy llamativo que ocurrió en repetidas oportunidades este año y pienso que es un motivador gigante:
Hubo muchas empresas en LAC que querían conectarse a empresas en Asia…, en LAC tenían IPv4 pero en Asia no, es decir, necesitaban IPv6, para comunicarse, esto trajo consigo que el ISP en nuestra región tuvo que correr e implementar IPv6 o perdía al cliente. Con lo anterior, recordemos que los países no estan solos, Internet no tiene fronteras, necesitan comunicarse con el resto del mundo. Los países que no implementen IPv6 corren el riesgo de quedarse incomunicados. Quizás ustedes aún tengan IPv4 pero el otro extremos no necesariamente tenga.
Sin querer extenderme mucho más, mis mejores deseos en esta navidad, espero la pasen en familia y anhelo tengan tengan un 2015 espectacular.
Abrazos.
Alejandro Acosta,
Moderador LACTF
Chair FLIP6
Todos los números arriba indicados fueron tomados de: IPv6 Google stats, Cisco IPv6 stats y APNIC IPv6 stats.
[1] http://es.wikipedia.org/wiki/Retrospectiva
[2] https://mail.lacnic.net/pipermail/lactf/2014-February/005333.html
[3] https://mail.lacnic.net/pipermail/lactf//2013-April/004805.html
[4] https://mail.lacnic.net/pipermail/lactf/2014-October/005513.html
[5] http://www.internetlivestats.com/internet-users/
[6] http://en.wikipedia.org/wiki/Telecommunications_in_Ecuador
[7] http://gringosabroad.com/ecuador/ecuador-internet-2013/
[8] http://data.worldbank.org/region/LAC
Blog en espanol destinado a diferentes temas tecnicos principalmente en IT y Networking. Se desea cubrir Linux, DNS, DNSSEC, RPKI, BGP, Cisco, Programacion (Bash, Python, etc), Protocolos de Enrutamiento, Seguridad en Redes, VoIP.
martes, 23 de diciembre de 2014
martes, 9 de diciembre de 2014
Python Script: Probably useless but functional IPv6 Network scanner
Below is the code of what is probably useless but a functional IPv6 host scanner written in Python using threading.
To perform a regular (brute force) network scans in an IPv6 Network is almost impossible and it can take over 5.000 years to finish.
This project was purely academic and I just wanted to learn about threading in Python.
This software is not recommended for general usage.....
This script will call the OS to actually perform the ping
This software receives two parameters:
a) Prefix to scan in the format 2001:db8::/64 (subnet, not host)
b) Number of simultaneous processes it can run (MAXPINGS)
One more time it was purely academic stuff but hopefully it can make your day
Finally, AFAIK nmap does not yet support IPv6 network scan.
The code was written in python3:
--- cut here ---
#!/usr/bin/python3
import threading
import sys
import ipaddress
import subprocess
import time
CURRENTPINGS=0 # Number of simultaneous ping at a time
def DOPING6(IPv6ADDRESS):
global MAXPINGS, CURRENTPINGS
CURRENTPINGS+=1
CMD="ping6 -c 3 "+str(IPv6ADDRESS) + " 2> /dev/null > /dev/null"
return_code = subprocess.call(CMD, shell=True)
if return_code == 0: #If ping was succesful
print (IPv6ADDRESS," is alive")
CURRENTPINGS-=1
def main():
global MAXPINGS, CURRENTPINGS
if len(sys.argv) != 3: #Validate how many parameters we are receiving
print(" Not enough or too many parameter")
print(" Usage: ./scanipv6.py IPv6Prefix/lenght MAXPINGS")
print(" Example: ./scanipv6.py 2001:db8::/64 20")
print(" Prefix lenght can be between 64-128")
print(" MAXPINGS corresponds to how many pings will be running at the same time")
exit()
SUBNET,MASK=sys.argv[1].split("/")
MAXPINGS=int(sys.argv[2])
for addr in ipaddress.IPv6Network(sys.argv[1]): #Let's loop for each address in the Block
ping_thread=threading.Thread(target=DOPING6,args=(addr,))
while CURRENTPINGS >= MAXPINGS: # With this while we make it possible to run max simultaneous pings
time.sleep(1) # Let's wait one second before proceeding
#print ("Interrumping...., CURRENTPINGS > MAXPINGS") #Uncomment this line just for debugging
ping_thread.start()
main()
To perform a regular (brute force) network scans in an IPv6 Network is almost impossible and it can take over 5.000 years to finish.
This project was purely academic and I just wanted to learn about threading in Python.
This software is not recommended for general usage.....
This script will call the OS to actually perform the ping
This software receives two parameters:
a) Prefix to scan in the format 2001:db8::/64 (subnet, not host)
b) Number of simultaneous processes it can run (MAXPINGS)
One more time it was purely academic stuff but hopefully it can make your day
Finally, AFAIK nmap does not yet support IPv6 network scan.
The code was written in python3:
--- cut here ---
#!/usr/bin/python3
import threading
import sys
import ipaddress
import subprocess
import time
CURRENTPINGS=0 # Number of simultaneous ping at a time
def DOPING6(IPv6ADDRESS):
global MAXPINGS, CURRENTPINGS
CURRENTPINGS+=1
CMD="ping6 -c 3 "+str(IPv6ADDRESS) + " 2> /dev/null > /dev/null"
return_code = subprocess.call(CMD, shell=True)
if return_code == 0: #If ping was succesful
print (IPv6ADDRESS," is alive")
CURRENTPINGS-=1
def main():
global MAXPINGS, CURRENTPINGS
if len(sys.argv) != 3: #Validate how many parameters we are receiving
print(" Not enough or too many parameter")
print(" Usage: ./scanipv6.py IPv6Prefix/lenght MAXPINGS")
print(" Example: ./scanipv6.py 2001:db8::/64 20")
print(" Prefix lenght can be between 64-128")
print(" MAXPINGS corresponds to how many pings will be running at the same time")
exit()
SUBNET,MASK=sys.argv[1].split("/")
MAXPINGS=int(sys.argv[2])
for addr in ipaddress.IPv6Network(sys.argv[1]): #Let's loop for each address in the Block
ping_thread=threading.Thread(target=DOPING6,args=(addr,))
while CURRENTPINGS >= MAXPINGS: # With this while we make it possible to run max simultaneous pings
time.sleep(1) # Let's wait one second before proceeding
#print ("Interrumping...., CURRENTPINGS > MAXPINGS") #Uncomment this line just for debugging
ping_thread.start()
main()
Linux - Touchpad no funciona al primer arranque pero si al reiniciar
Situacion:
El touchpad de la laptop no funciona la primera vez que arranca la laptop/computadora pero si al reiniciar la misma
Solucion:
1. Edita el archivo /etc/default/grub (NO es grub.cfg)
2. Ubica la siguiente linea:
GRUB_CMDLINE_LINUX=" "
3. Agrega lo siguiente entre "":
i8042.nomux=1 locale=fr_FR i8042.reset
4. La linea debe quedar asi:
GRUB_CMDLINE_LINUX="i8042.nomux=1 locale=fr_FR i8042.reset"
5. Graba el archivo y sal.
6. En el terminar ejecuta:
#sudo update-grub
7. Listo, apaga y prende tu computadora.
Creditos a:
http://ubuntuforums.org/showthread.php?t=2217553
El touchpad de la laptop no funciona la primera vez que arranca la laptop/computadora pero si al reiniciar la misma
Solucion:
1. Edita el archivo /etc/default/grub (NO es grub.cfg)
2. Ubica la siguiente linea:
GRUB_CMDLINE_LINUX=" "
3. Agrega lo siguiente entre "":
i8042.nomux=1 locale=fr_FR i8042.reset
4. La linea debe quedar asi:
GRUB_CMDLINE_LINUX="i8042.nomux=1 locale=fr_FR i8042.reset"
5. Graba el archivo y sal.
6. En el terminar ejecuta:
#sudo update-grub
7. Listo, apaga y prende tu computadora.
Creditos a:
http://ubuntuforums.org/showthread.php?t=2217553
lunes, 17 de noviembre de 2014
$GENERATE usando registros A en BIND. Match forward y rDNS
Hola,
Este post es muy corto pero quizas muy util. Hay menos documentacion en Internet que la esperada.
Objetivo:
a) Configurar los DNS reversos y los DNS forward de una red /24 en BIND9 utilizando $GENERATE.
b) Que coincida la resolucion forward a la resolucion reversa
Requisitos:
- Una red /24 (claro, el ejemplo se puede ajustar a otras redes)
- BIND9
- Usaremos registros A y PTR
Ejemplo:
La red 192.168.30.0/24
Dominio: ejemplo.com
Vamos a hacer que los reversos de 192.168.30.X resuelvan a: X.cliente.ejemplo.com
De igual manera, X.cliente.ejemplo.com resolverá a 192.168.30.X
Sería así:
192.168.30.1 ---> 1.cliente.ejemplo.com
192.168.30.2 ---> 2.cliente.ejemplo.com
192.168.30.3 ---> 3.cliente.ejemplo.com
1.cliente.ejemplo.com ---> 192.168.30.1
2.cliente.ejemplo.com ---> 192.168.30.2
3.cliente.ejemplo.com ---> 192.168.30.3
(etc)
Pasos:
Creamos la zona reversa en /etc/bind/named.conf.
a) La zona reversa:
zone "30.168.192.in-addr.arpa" {
type master;
file "30.168.192.in-addr.arpa.db";
allow-query { any; };
};
Luego en el archivo 30.168.192.in-addr.arpa.db colocamos lo siguiente:
$TTL 86400 ; 24 hours, could have been written as 24h or 1d
@ 1D IN SOA localhost. hostmaster.ejemplo.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; minimum
)
; Name servers for the zone - both out-of-zone - no A RRs required
NS localhost.
$GENERATE 1-255 $ PTR $.cliente.ejemplo.com.
b) La zona forward, utilizando registros A es:
$TTL 86400 ; 24 hours, could have been written as 24h or 1d
@ 1D IN SOA localhost. hostmaster.ejemplo.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; minimum
)
; Name servers for the zone - both out-of-zone - no A RRs required
NS localhost.
$GENERATE 1-255.cliente.ejemplo.com $ A 192.168.30.$
Pruebas:
Para probar:
#dig -x 192.168.30.3 (reverso dns)
#dig 3.cliente.ejemplo.com (forward dns)
Espero haya sido de utilidad
Este post es muy corto pero quizas muy util. Hay menos documentacion en Internet que la esperada.
Objetivo:
a) Configurar los DNS reversos y los DNS forward de una red /24 en BIND9 utilizando $GENERATE.
b) Que coincida la resolucion forward a la resolucion reversa
Requisitos:
- Una red /24 (claro, el ejemplo se puede ajustar a otras redes)
- BIND9
- Usaremos registros A y PTR
Ejemplo:
La red 192.168.30.0/24
Dominio: ejemplo.com
Vamos a hacer que los reversos de 192.168.30.X resuelvan a: X.cliente.ejemplo.com
De igual manera, X.cliente.ejemplo.com resolverá a 192.168.30.X
Sería así:
192.168.30.1 ---> 1.cliente.ejemplo.com
192.168.30.2 ---> 2.cliente.ejemplo.com
192.168.30.3 ---> 3.cliente.ejemplo.com
1.cliente.ejemplo.com ---> 192.168.30.1
2.cliente.ejemplo.com ---> 192.168.30.2
3.cliente.ejemplo.com ---> 192.168.30.3
(etc)
Pasos:
Creamos la zona reversa en /etc/bind/named.conf.
a) La zona reversa:
zone "30.168.192.in-addr.arpa" {
type master;
file "30.168.192.in-addr.arpa.db";
allow-query { any; };
};
Luego en el archivo 30.168.192.in-addr.arpa.db colocamos lo siguiente:
$TTL 86400 ; 24 hours, could have been written as 24h or 1d
@ 1D IN SOA localhost. hostmaster.ejemplo.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; minimum
)
; Name servers for the zone - both out-of-zone - no A RRs required
NS localhost.
$GENERATE 1-255 $ PTR $.cliente.ejemplo.com.
b) La zona forward, utilizando registros A es:
$TTL 86400 ; 24 hours, could have been written as 24h or 1d
@ 1D IN SOA localhost. hostmaster.ejemplo.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; minimum
)
; Name servers for the zone - both out-of-zone - no A RRs required
NS localhost.
$GENERATE 1-255.cliente.ejemplo.com $ A 192.168.30.$
Pruebas:
Para probar:
#dig -x 192.168.30.3 (reverso dns)
#dig 3.cliente.ejemplo.com (forward dns)
Espero haya sido de utilidad
domingo, 19 de octubre de 2014
Existe alguna relacion respecto al despliegue de IPv6 entre entidades con ASN de 16 y 32 bits?
Hola,
El dia de hoy se me ocurrio esta pregunta: ¿Existe alguna relacion respecto al despliegue de IPv6 entre entidades con ASN de 16 y 32 bits?. Posteriormente me di cuenta que la data existia y me era sencillo ubicar la respuesta. Para ello estuve revisando alguna data de APNIC (*1) que tengo ya varias semanas consultando. Voila!!, que suerte..
Ellos (APNIC) almacenan por ASN un valor porcentual que llaman ipv6capable, basicamente es un numero que indica para X ASN que porcentaje tiene capacidad de v6. Tienen otra variable llamada ipv6 preferred pero no vamos a hablar de ella ahorita.
Lo cierto es que para mi muestra tome tres dias: 11, 12 y 15 de Octubre 2014
Mis resultados fueron:
Dia 15 de Octubre (miercoles)
1.34 en asn de 16
1.12 en asn de 32
Avg 1.26 todos los ASN
----
Dia 11 de Oct (sabado)
1.34 en asn de 16 bits
1.15 en asn de 32 bits
Avg 1.27 todos los ASN
---
Dia 12 de Oct (domingo)
1.35 en asn de 16 bits 2058
1.12 en asn de 32 bits 1225
Avg 1.27 todos los ASN (3313 ASNs)
----
Fueron evaluados alrededor de 2050 ASN de 16 bits y 1200 ASN de 32 bits. La diferencia de ipv6capable entre ASN de 16 y 32 bits es aprox 0.2, ciertamente es un numero muy chico sin embargo cuando se refiere a trafico y usuarios en Internet estos numeros tradicionalmente represantan un volumen significativo.
Mi humilde conclusion para este sencillo estudio es: Pareciera que hubiese una *muy* ligera preferencia al despliegue de IPv6 en ASN de 16 bits.
Saludos,
(*1) http://labs.apnic.net/ipv6-measurement/AS/
El dia de hoy se me ocurrio esta pregunta: ¿Existe alguna relacion respecto al despliegue de IPv6 entre entidades con ASN de 16 y 32 bits?. Posteriormente me di cuenta que la data existia y me era sencillo ubicar la respuesta. Para ello estuve revisando alguna data de APNIC (*1) que tengo ya varias semanas consultando. Voila!!, que suerte..
Ellos (APNIC) almacenan por ASN un valor porcentual que llaman ipv6capable, basicamente es un numero que indica para X ASN que porcentaje tiene capacidad de v6. Tienen otra variable llamada ipv6 preferred pero no vamos a hablar de ella ahorita.
Lo cierto es que para mi muestra tome tres dias: 11, 12 y 15 de Octubre 2014
Mis resultados fueron:
Dia 15 de Octubre (miercoles)
1.34 en asn de 16
1.12 en asn de 32
Avg 1.26 todos los ASN
----
Dia 11 de Oct (sabado)
1.34 en asn de 16 bits
1.15 en asn de 32 bits
Avg 1.27 todos los ASN
---
Dia 12 de Oct (domingo)
1.35 en asn de 16 bits 2058
1.12 en asn de 32 bits 1225
Avg 1.27 todos los ASN (3313 ASNs)
----
Fueron evaluados alrededor de 2050 ASN de 16 bits y 1200 ASN de 32 bits. La diferencia de ipv6capable entre ASN de 16 y 32 bits es aprox 0.2, ciertamente es un numero muy chico sin embargo cuando se refiere a trafico y usuarios en Internet estos numeros tradicionalmente represantan un volumen significativo.
Mi humilde conclusion para este sencillo estudio es: Pareciera que hubiese una *muy* ligera preferencia al despliegue de IPv6 en ASN de 16 bits.
Saludos,
(*1) http://labs.apnic.net/ipv6-measurement/AS/
martes, 14 de octubre de 2014
La mala idea de bloquear Internet
Toda mi vida lo
que siempre he querido es un Internet libre, sin bloqueos, rápido
que ayude al mundo a comunicarse, a educarse, a estar informado. En mi
humilde opinión el internauta tiene acceso a visitar la pagina que
quiera y cuando quiera, sin
importar el contenido lo que diga, lo que vea, lo
que escuche. No se
nada de leyes pero creo que debe verse como un derecho del
ciudadano a leer, ver y escuchar en Internet lo que la persona desee.
Bloquear paginas
no es una solución, es mas un problema, no se llega a nada, la solución
a los problemas esta en otra dirección muy lejana a bloquear las
paginas y contenidos.
Supongamos un caso
donde alguien realiza una publicación indicando que el cielo es rojo,
las nubes anaranjadas o que esta lloviendo para arriba, ¿van a
bloquear ese contenido?. ¿Tú no tienes derecho a poner esa información en una
pagina Web?.
Ahora bien,
imaginemos otro caso donde en la esquina de tu urbanización esta ocurriendo algo
ilegal (y tu lo ves desde tu apartamento) ¿puedes o no publicar lo que
esta ocurriendo en Internet?, ¿tomar fotos?, ¿realizar un artículo al
respecto?. ¿Puedes ponerlas en Internet?, ¿te lo bloquean?, ¿tu pierdes la
libertad de expresión y yo pierdo el acceso a tu informacion?. Peor
aún, en segundos un familiar tuyo va a pasar por esa esquina.....
gracias a la NO libertad de expresión y al NO acceso a
la información algo
indeseado ocurrió que honestamente no quiero describir.
En los últimos
meses (en realidad años) he visto como algunos países han decidido
bloquear su acceso a Internet imposibilitando a sus habitantes a
acceder a contenido legitimo a la información, pero peor aun dañando
poco a poco la super autopista de la información.
Solo por mencionar
algunos países con historial por bloquear -al menos un poco- su
acceso a Internet (tomado de http://www.usatoday.com/story/news/world/2014/02/05/top-ten-internet-censors/5222385/ y http://en.wikipedia.org/wiki/Internet_censorship: ):
- Irán
- Egipto
- Coreo del Norte
- Venezuela
- Cuba
- China
- Turquía
- Arabia Saudita
- Siria
- Vietman
Antes de
proseguir, quiero indicar que por más de un año me he tomado la
libertad de averiguar que manera utilizan para bloquear paginas Web u
otros servicios a los usuarios, he recibido básicamente dos
respuestas:
- Bloqueos por DNS
- Bloqueos por
dirección IP destino
(claro, por detrás puede haber un montón de cosas que complican el escenario como firewalls, IDS, IDP, etc, etc)
Muchas personas,
principalmente los técnicos dirán que ambos métodos son
ineficientes y que se pueden evitar utilizando una VPN y/o cambiando
los servidores DNS que utilizan los usuarios. Es muy cierto este
pensamiento sin embargo en la realidad y en la practica son MUY pocas
personas las que tienen conocimiento de DNS, muchos menos de VPN y a
su vez este ultimo en algunas situaciones hay opciones pagas ($$) lo
que reduce aun mas la poblacion dispuesta a realizar estos cambios.
Por lo anterior pienso que bloquear contenido por DNS e/o IP destino
es BASTANTE eficiente.
El objetivo de
este post es indicar porque pienso que es mala idea bloquear Internet
para un país:
1) Rompemos el
Internet poco a poco y luego armarlo puede ser muy complicado
Esta razón es
fatal para Internet y el país. Al estar constantemente creando y
modificando rutas en los routers va a ir creando una especie de
"agujeros parciales" a ciertas direcciones IP destino. Pero
el problema no es solo este, sino la persecución de bloquear sitios
trae consigo el bloqueo "actual" del destino sin nuevamente
"permitir" el anterior. Esto ultimo conlleva a ir rompiendo
poco a poco muchas direcciones IP legítimas en Internet que no
pueden ser accedidas.
Multiplicando el
efecto anterior, un caso similar ocurre en el mundo DNS.
2) Los inocentes
pagan como pecadores
Siguiendo un poco
con lo anterior supongamos el siguiente escenario de ejemplo: Un
ciudadano común tiene un blog de cocina. Por cosas del destino su
página web esta alojada en un virtualhosting bajo la misma dirección
IP que una pagina que quiere ser bloqueada. ¿Qué va a ocurrir?. No
puede ser accedida la pagina del blog de cocina. Para el ciudadano
común y para el proveedor del virtualhosting identificar esta
situación y solventar el caso seria muy complicado.
3) Teletrabajo
Hoy en día es
normal trabajar, compartir y jugar de manera remota con diferentes
personas en el mundo. Lamentablemente el bloqueo de IPs y de nombres
DNSs obstaculiza el Teletrabajo; un ejemplo es que la persona con la
que nos encontramos laborando remotamente quisiera compartir
información/contenido utilizando medios que se encuentren bloqueados
en uno de los países. Lo anterior es un entorpecimiento explícito
que siendo antagónico me atrevo a decir que convierte al ciudadano
en una persona menos productiva.
4) Dudas a los
ciudadanos
Caso a) En
el supuesto que una persona en el país bloqueado no pueda acceder a
un sitio ¿qué va a pasa?: Quizás llame a su proveedor de servicio
(perdiendo tiempo, dinero, creando molestias). Es muy probable que la
persona que atienda el teléfono sencillamente no sepa revisar los
DNS y rutas en los enrutadores, haya que escalar el caso y mucho mas.
Para los proveedores esto es un costo que tiene que ser trasladado a
alguien, por supuesto que al cliente. Es decir, el servicio de
Internet se encarece.
Caso b) El
ciudadano probablemente llame directamente a un amigo con
conocimientos en informática, una vez mas: perdiendo tiempo, dinero
y creando molestias
Caso c) Las
dos anteriores
5) Perspectiva
ante un bloqueo _nuevo_ del ciudadano:
Cuando un ciudadano
no puede entrar a un sitio Web (o servicio) no sabe si fue bloqueado
por el gobierno, por el ISP, el sitio web caído o si es algo
temporal. Esto conlleva a una serie de molestias directas e
indirectas que a su vez más trae problemas colaterales.
6) El error
humano
Los
administradores de red son personas como cualquiera, son propensos a
cometer errores al igual que todos nosotros.
Es bien sabido que
____ % de errores en red son causados por errores humanos, ahora
traslademos esta estadística a los administradores red que deben
estar manipulando los servidores DNS y los routers creando rutas
frecuentemente con el objetivo de bloquear algunos sitios y
contenidos. Lastimosamente el resultado es un peor Internet para el
ciudadano.
7) Históricos +
falsos positivos (negativos?)
Este punto lo
describiré con un ejemplo: Un proveedor de Internet contrata a un
nuevo administrador de red; este último observa gran cantidad de
direcciones IPs bloqueadas en los routers, es muy complicado que el
nuevo administrador NO sepa si estos IPs fueron bloqueados
momentáneamente por defenderse de un ataque de red anterior o
corresponde a un bloqueo solicitado por el regulador del país (o el
ente respectivo)
8) Daños
colaterales:
Es
común
que muchas organizaciones realicen eventos 1,2 ó 3 veces al año y
roten su sede en diferentes países.
Es bien sabido que estas organizaciones evitaran los países con
bloqueos a Internet.
9) Se rompe el acceso a sitios legítimos:
Un caso que he visto en varias oportunidades es el bloqueo por DNS apuntando a direcciones IP, quizás www.example.com a 1.1.1.1. Luego: supongamos que por asegurar el bloqueo a nivel de routing se enruta 1.1.1.1 a un hoyo negro (null 0) el ciudadano no podrá entrar ni al sitio que se bloqueo ni al sitio legítimo que se encuentre en la dirección IP bloqueada
Iba a colocar otras razones y puntos negativos de pasar a través de una VPN y cambiar los DNS en las máquinas tales como enlentecimiento de Internet, lentitud en la VPN y problemas de geolocalizacion pero lo dejaré para otra oportunidad.
Mi conclusión:
Si existe algo que
yo quisiera y pudiera bloquear en Internet seria: pornografía
infantil y ventas ilegales de armas (algo realizado por un pais en
Latino América). He llegado a ver países que bloquean contenido de
sus propios ciudadanos, esto a mi parecer deja mucho que desear.
Lo he dicho mil
veces, un Internet 100% libre tendrá unas MUY pocas cosas malas pero
tiene MUCHAS mas ventajas que desventajas. Ir bloqueando poco a
poco Internet en los países a la larga trae desventajas
competitivas, subdesarrollo, imagen ante el mundo poco amigable y muchas
otras cosas. Lo anterior repercute entre otros en los ámbitos económico
y social. Internet debe ser utilizado como una herramienta para el
desarrollo.
Antes de terminar;
un Internet debe ser sin bloqueos, Internet debe ser con banda ancha de
buena velocidad, acceso a nivel nacional, decirle NO al throttling y
lógicamente seguro y con privacidad.
Reciban un saludo,
zcodesystemexclusive
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:
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
Suscribirse a:
Entradas (Atom)
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...
-
Debido al crecimiento moderado que ha tenido el presente blog se me ocurrió añadir/integrar las estadisticas de google analytics a mi blog. ...
-
Introduccion: En algunas ocasiones es necesario "bajar" o deshabilitar iptables en nuestro Linux, el procedimiento depende de...
-
Saludos, Lo primero que debemos de hacer para quitar el stacking entre los switches es desconectar los cables Stack que los unen.... Es buen...