Al periódico nunca lo reemplazará Internet.
A continuación algunos de los más importantes usos del periódico.
USOS DOMÉSTICOS:
* Madurar los platanos.
* Recoger la basura.
* Limpiar los cristales.
* Hacer las montañas del pesebre.
* Calzar las patas de la mesa coja.
* Empaquetar la vajilla en la mudanza.
* Cubrir el suelo de la jaula del pájaro.
* Recoger la caca del perro.
* Cubrir los muebles y el suelo antes de pintar.
* Evitar que se meta el agua debajo de la puerta.
* De protector en el suelo del garaje si el coche gotea aceite.
* Matar moscas, cucarachas y demás insectos rastreros.
USOS EDUCATIVOS:
* Pegarle al perro en el hocico cuando se mea en la casa.
* Recortar letras y fotos para los deberes de los niños.
* Elaborar títeres o piñatas.
* Hacer barcos de papel.
* Arrancarle en el pedacito en blanco de arriba para anotar números de teléfono.
USOS COMERCIALES:
* Ensanchar zapatos.
* Rellenar los bolsos para que conserven su forma.
* Empaquetar clavos en la ferretería.
* Hacer un sombrero de pintor ó albañil.
* Dar trabajo a vendedores y periodistas.
* Envolver flores.
* Cortar patrones para modistas y sastres.
* Envolver cuadros.
USOS FESTIVOS:
* Para prender el carbón de la barbacoa.
* Rellenar las cajas de los regalos sorpresa.
* Fabricar el embudo de mago que desaparece el agua.
* Dominar a los toros en los Sanfermines.
OTROS USOS:
* Para que los secuestradores usen sus letras en las cartas.
* Para ponerlo encima del banco y no mancharse en el parque.
* Hacer bolitas y pegarles a los compañeros de clase.
* Como paraguas para que la lluvia finita no dañe el peinado.
* Para que 'los malos', en las películas, escondan el revolver..
* Como funda para guardar el cuchillo de jamón.
* Para esconderse detrás de él cuando no quieres que te vean.
AH!!!!... Y POR ÚLTIMO, PARA ENTERARSE DE LAS NOTICIAS.
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.
Mostrando entradas con la etiqueta internet. Mostrar todas las entradas
Mostrando entradas con la etiqueta internet. Mostrar todas las entradas
viernes, 18 de marzo de 2016
sábado, 2 de enero de 2016
Virualbox en Windows. Adaptador puente/bridge + IPv6 no sirve
Situación:
Cuando intentamos tener IPv6 en la interfaz inalambrica utilizando modo Bridge/Puente IPv6 no funciona correctamente, quizás hace SLAAC satisfactoriamente pero al momento de navegar o hacer ping6 sencillamente no sirve.
Solución
Para resolver esta situacion reinstala/repara tu actual Virtualbox (versión 5) agregando como parámetros lo siguiente: "-Win.exe -msiparams NETWORKTYPE=NDIS5"
Sería algo así:
G:\>VirtualBox-5.0.12-104815-Win.exe -msiparams NETWORKTYPE=NDIS5
Cuando intentamos tener IPv6 en la interfaz inalambrica utilizando modo Bridge/Puente IPv6 no funciona correctamente, quizás hace SLAAC satisfactoriamente pero al momento de navegar o hacer ping6 sencillamente no sirve.
Solución
Para resolver esta situacion reinstala/repara tu actual Virtualbox (versión 5) agregando como parámetros lo siguiente: "-Win.exe -msiparams NETWORKTYPE=NDIS5"
Sería algo así:
G:\>VirtualBox-5.0.12-104815-Win.exe -msiparams NETWORKTYPE=NDIS5
Nota que no puedes hacer doble click sobre el archivo, es decir, debes hacerlo desde el prompt de DOS con privilegios de administrador
Workaround:
Conectarse cableado y hacer el bridge/puente con la interfaz cableada del host
Más referencia:
Suerte,
martes, 5 de mayo de 2015
Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 1/2)
El video muestra un ejemplo de como ocurre un secuestro de un prefijo de red en Internet y a su vez muestra como RPKI ayudaría a prevenir esta situación
lunes, 27 de abril de 2015
Construyendo una topología de red 464XLAT (mecanismo de transicion)
Introducción:
El siguiente post indica el procedimiento que puedes seguir para tener una topología de red con 464XLAT
Topología:
Que se necesita:
Del lado del cliente:
- Un cliente CLAT, en nuestro ejemplo utilizamos: https://github.com/toreanderson/clatd
- Tayga como NAT64 (http://www.litech.org/tayga/) En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)
y del lado del servidor:
- Tayga como NAT64 (http://www.litech.org/tayga/) En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)
- Para nuestro ejemplo un DNS Server pero si tienes otro puedes obviarlo. Es recomendable utilizar DNS64 para facilitar el reconocimiento de red cuando se ejecute el clatd.
- radvd (para hacer los anuncios RA y que el cliente se auto-configure), una vez puedes obviarlo y hacer tus configuraciones manuales
Configuraciones:
Del lado del cliente:
En lineas generales no es necesario configuar nada. El tayga utiliza un archivo de ejemplo construido en el momento y el clatd verifica todo lo necesario. Por favor asegura que el archivo /etc/resolv.conf contenga la línea;
nameserver 2001:13c7:100:f101::1
IMPORTANTE: Del lado del cliente lo unico que hay que hacer es ejecutar el cliente clatd. El procedimiento es el siguiente:
#unzip clatd-master
#cd clatd-master
#./clatd
Con este último comando el clatd será capaz de reconocer que NO hay direcciones IPv4 en el equipo donde se ejecuta y reconocer como es su conectividad hacia el exterior.
Del lado del servidor (6 pasos):
1) El radvd se configura en el archivo /etc/radvd.conf y debe quedar así:
interface eth0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix 2001:13c7:0100:f101::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
2) Tayga: Del lado del servidor si es muy importante realizar una configuración de tayga. Para nuestro ejemplo:
En /usr/local/etc/tayga.conf:
tun-device nat64
ipv4-addr 192.168.64.1
prefix 64:ff9b::/96
dynamic-pool 192.168.64.0/24
data-dir /var/log/tayga
ipv6-addr 2001:13c7:100:f101::1
3) Las interfaces del lado del servidor deben quedar así:
/usr/local/sbin/tayga --mktun
/sbin/ip link set nat64 up
/sbin/ip addr add 10.0.3.15 dev nat64
/sbin/ip addr add 64:ff9b::1 dev nat64
/sbin/ip route add 192.168.64.0/24 dev nat64
/sbin/ip route add 64:ff9b::/96 dev nat64
4) Levantar tayga:
/usr/local/sbin/tayga -d &
5) Hacer NAT de la red IPv4:
/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE
Anexo:
a) ping a un destino IPv4 desde el cliente:
El siguiente post indica el procedimiento que puedes seguir para tener una topología de red con 464XLAT
Topología:
Que se necesita:
Del lado del cliente:
- Un cliente CLAT, en nuestro ejemplo utilizamos: https://github.com/toreanderson/clatd
- Tayga como NAT64 (http://www.litech.org/tayga/) En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)
y del lado del servidor:
- Tayga como NAT64 (http://www.litech.org/tayga/) En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)
- Para nuestro ejemplo un DNS Server pero si tienes otro puedes obviarlo. Es recomendable utilizar DNS64 para facilitar el reconocimiento de red cuando se ejecute el clatd.
- radvd (para hacer los anuncios RA y que el cliente se auto-configure), una vez puedes obviarlo y hacer tus configuraciones manuales
Configuraciones:
Del lado del cliente:
En lineas generales no es necesario configuar nada. El tayga utiliza un archivo de ejemplo construido en el momento y el clatd verifica todo lo necesario. Por favor asegura que el archivo /etc/resolv.conf contenga la línea;
nameserver 2001:13c7:100:f101::1
IMPORTANTE: Del lado del cliente lo unico que hay que hacer es ejecutar el cliente clatd. El procedimiento es el siguiente:
#unzip clatd-master
#cd clatd-master
#./clatd
Con este último comando el clatd será capaz de reconocer que NO hay direcciones IPv4 en el equipo donde se ejecuta y reconocer como es su conectividad hacia el exterior.
Del lado del servidor (6 pasos):
1) El radvd se configura en el archivo /etc/radvd.conf y debe quedar así:
interface eth0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix 2001:13c7:0100:f101::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
2) Tayga: Del lado del servidor si es muy importante realizar una configuración de tayga. Para nuestro ejemplo:
En /usr/local/etc/tayga.conf:
tun-device nat64
ipv4-addr 192.168.64.1
prefix 64:ff9b::/96
dynamic-pool 192.168.64.0/24
data-dir /var/log/tayga
ipv6-addr 2001:13c7:100:f101::1
3) Las interfaces del lado del servidor deben quedar así:
/usr/local/sbin/tayga --mktun
/sbin/ip link set nat64 up
/sbin/ip addr add 10.0.3.15 dev nat64
/sbin/ip addr add 64:ff9b::1 dev nat64
/sbin/ip route add 192.168.64.0/24 dev nat64
/sbin/ip route add 64:ff9b::/96 dev nat64
4) Levantar tayga:
/usr/local/sbin/tayga -d &
5) Hacer NAT de la red IPv4:
/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE
6) El DNS Server debe quedar con la siguiente directiva dentro de /etc/bind/named.conf.options:
dns64 64:ff9b::/96 {
clients {
any; };
}; // End of DNS64 Section
Un poco mas de como quedas las interfaces. La salida de ifconfig del lado del servidor:
eth10 Link encap:Ethernet HWaddr 00:0c:29:06:e9:cc
inet addr:10.0.3.15 Bcast:10.0.3.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe06:e9cc/64 Scope:Link
inet6 addr: 2001:13c7:7001:500::21/64 Scope:Global ---> HACIA WAN
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:42282238 errors:0 dropped:307 overruns:0 frame:0
TX packets:11377224 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5706072894 (5.7 GB) TX bytes:2226397897 (2.2 GB)
eth9 Link encap:Ethernet HWaddr 00:0c:29:06:e9:d6
inet addr:10.64.0.1 Bcast:10.64.0.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe06:e9d6/64 Scope:Link
inet6 addr: 2001:13c7:100:f101::1/64 Scope:Global --- HACIA LAN
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:652093 errors:0 dropped:72 overruns:0 frame:0
TX packets:2662969 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:84197892 (84.1 MB) TX bytes:1461857730 (1.4 GB)
nat64 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.3.15 P-t-P:10.0.3.15 Mask:255.255.255.255
inet6 addr: 64:ff9b::1/128 Scope:Global
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:1135938 errors:0 dropped:0 overruns:0 frame:0
TX packets:1074859 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:939693414 (939.6 MB) TX bytes:931853538 (931.8 MB)
Explicando todo lo anterior:
1) Supongamos que el cliente quiere acceder una direcciones IPv6.., no pasa nada extraño :-). El routing es 100% IPv6, no hay NAT, todo normal.
2) En el supuesto que el cliente quiera acceder a una dirección IPv4:
a) El cliente clatd otorgará un socket IPv4 a la aplicación
b) El paquete que construya el cliente será 100% IPv6. Será su dirección IPv6 origen y el destino será 64:ff9b::/96 + 32 bits de la dirección IPv4 destino. Recordemos que no hay IPv4 en el core de la red.
c) El PLAT (Tayga del lado del servidor) al recibir un paquete con destino 64:ff9b::/96 lo enruta por la interfaz TUN NAT64 (interfaz lógica) donde tayga remueve los primeros 96 bits del destino dejando unicamente los 32 bits menos significativos (la dirección IPv4). Al origen (IPv6) se le hace una mapeo stateless con una direccion IPv4 (del pool en el archivo de configuración (192.168.64.0/24).
d) Cuando el paquete con el origen 192.168.64.0/24 del servidor desee salir del equipo será nateado con iptables al IPv4 que tenga eth10 (/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE)
Anexo:
a) ping a un destino IPv4 desde el cliente:
b) Clatd ejecutándose:
c) Captura en Wireshark de un ping desde el cliente (IPv6 only) a un destino IPv4:
lunes, 26 de enero de 2015
Tecno-cuento: La triste historia de un ISP sin IPv6
Erase una vez..... Erase una vez, en un tiempo no muy lejano, un ISP muy grande que dominaba las telecomunicaciones de un país, se sentía poderoso y sin competencia. Cuando alguien necesitaba conectarse a Internet siempre recurrian a ellos. Tenían una penetración en el mercado envidiable para todos. Sin embargo, este ISP tan grande no había querido implementar nunca IPv6, pensaba que tenía suficientes direcciones IP para abastecerse, no percibían indicador alguno que dijera: tengo que tener el nuevo protocolo. Durante esos años, otro pequeño ISP si implementó IPv6, comenzaron a crecer lentamente, se dieron cuenta que el protocolo si marcaba una diferencia en sus clientes, ganaban usuarios gracias a tener soporte de dicho protocolo. Su penetración en el mercado crecía, ganaban más dinero y más respeto. Siendo más grandes le era más fácil conseguir mejores precios de equipos, de tráfico, de interconexión. Todo funcionaba muy bien. El ISP pequeño sencillamente no lo podía creer, algo tan sencillo de implementar como IPv6 le rendía frutos inimaginables. Sus clientes le decian que tenian crear VPNs y conferencias contra otras partes del mundo, que sus subsidiarias, clientes y aliados de negocio en Europa y Asia si tenían IPv6, por ello IPv4 no les era importante. El ISP grande, a pesar de ser tan poderoso comenzó a tener problemas internos, no eran problemas de facturación o dinero. Eran quejas del personal de ventas que no podían cerrar las mismas porque los clientes empezaron a pedir IPv6 y ellos siendo tan grandes e importantes sencillamente no tenían!!. Clientes corporativos pedían IPv6, usuarios residenciales solicitaban lo mismo, incluso grandes licitaciones del estado. Cuando eso empezó a ocurrir el Gerente de Ventas tuvo quejas hacia los departamentos de Producto, IngenierÃa y Operaciones. Estos últimos se quedaron sin palabras y algunos empleados fueron removidos por los dueños de las empresas. Al final, a Ventas no les importaba donde estaba la culpa, sencillamente no podían obtener nuevos clientes. Posteriormente algunos vendedores al percatarse que estaban perdiendo clientes fueron contratados por el ISP pequeño que estaba buscando personal, total ahora sí podían pagar a importantes vendedores porque en realidad ya no eran tan chicos. Lo mismo ocurrió con el jefe de redes del ISP grande que sabía mucho de IPv6 pero la burocracia no le había permitido llevar a producción el novedoso protocolo. Luego el jefe de redes lógicamente trajo a su administrador de servidores de confianza y su persona de seguridad. El ISP grande no podía creer lo que estaba pasando. Los vendedores contratados por el ISP chico (provenientes del ISP grande) venían con su enorme cartera de clientes, todos potenciales para ser instalados. Se avecinaba una estampida de clientes del ISP grande. Pasaban los meses y el ISP chico ya no solo ofrecía Internet, su Data Center era mucho más grande, importantes empresas trajeron servidores nuevos, de cache y mucho más. Ahora ofrecían co-location, hosting, virtual hosting, voz, video y más. Cuando el proveedor grande quiso implementar IPv6, tuvo que hacer las cosas muy rápidas, les salian mal, varios errores, además consultores y empresas se aprovecharon de sus problemas y cobraban mucho más para hacer las tareas con la premura que solicitaban. Aumentó el downtime de red, las llamadas al call center y la prestigiosa reputación se venía abajo. Como es de esperar, al final de la historia todos en el cuento: clientes y proveedores terminaron implementando IPv6, unos más felices que otros pero todos con IPv6 en sus redes Espero lo hayan disfrutado, y Colorín Colorado este cuento se ha acabado Abrazos a todos, Alejandro,
Get ready for Black Friday deals in South Africa with bidorbuy. We at bidorbuy are as excited as you are! We are hard at work to find the best deals at the best price to bring you a whole week of awesome Black Friday deals!
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...