Ya es oficial, no quedan rangos de IPv4 que puedan ser reservados por nuevas compañías, sólo queda implantar oficialmente y a nivel mundial el protocolo IPv6.

En resumidas cuentas, no es que sólo hayan aumentado el número de IPs disponibles, cambia toda la filosofía y tanto los conceptos como la configuración no son del todo intuitivos.

En cuanto los IPs lo implementen de forma nativa, en principio la mayoría de routers basados en linux ya están preparados para utilizar IPv6 o podrían estarlo simplemente con una actualización de software.

A priori esto no es un problema para usuarios ni la mayoría de ISPs existentes, puesto que tienen sus rangos ya comprados y salvo que se les agoten por ahora pueden ir tirando; sinembargo es un problema para los ISPs nuevos y todo aquel que necesite comprarse un hueco en internet.

Básicamente lo que ha sucedido es que todo el rango de ips versión 4 que va desde 0 – 255 dividido en 4 segmentos: 0.0.0.0 está vendido. Hasta la fecha se había trampeado esta situación con el uso de NAT en las redes locales.

El funcionamiento del NAT es muy simple, se forma un subconjunto de redes, enlazadas entre sí por un enrutador, para los rangos de redes locales se reservan 3 segmentos: 10.0.0.0 (clase A), 172.16.0.0 (clase B) y 192.168.1.0 (clase C), los equipos de la red local tendrán IPs dentro de esos rangos. Cuando quieran acceder a una ip de un rango externo preguntarán al enrutador asignado en la red, el cual tiene 2 tarjetas de red (de ahora en adelante referidas como interfaces) lo que le permite hacer de puente.

Dicho de otro modo, ahora mismo todas las peticiones de cualquier equipo de una red local se ven desde internet como que proceden desde la misma IP:

IPv6 es totalmente nuevo, en todos los sentidos, por un lado las IPs pasan a abarcar de 0 – 65535 dividido en 8 segmentos, es decir, MUCHOS. La forma de representarlo también cambia, se opta por el hexadecimal para simplificar y compactar los números. Además existen muchas formas de escribir la misma IP, recomiendo echar un vistazo a la explicación que está en la wikipedia (sí, para variar este post no será muy técnico por ahora, sólo conceptual ya que este tema podría abarcar varios posts).

La filosofía cambia, como hay tantas IPs disponibles, la idea es que todos los aparatos sean accesibles directamente desde internet, hasta podrás conectarte a la tostadora de tu casa con tu móvil. Desaparece por tanto el concepto de NAT, aunque es posible hacer alguna chapucilla no oficial por ahí (hacer que sólo el router tenga IPv6 y el resto de equipos usen un proxy http a través de él, o bien asignar un rango de IPv6 local y hacer un pseudo-nat).

¡Las pilas de red son paralelas! ¿Qué significa esto? que tener un sistema dual IPv4 e IPv6 significa que ese equipo tiene que tener configurados dos firewalls por separado, uno para cada protocolo. Pensadlo gráficamente como que acabáis de instalar una tarjeta de red más nueva y un cableado paralelo al que ya teníais.

Y hay mucho más, mientras los ISPs no implantan nativamente el protocolo IPv6, se puede utilizar mediante un túnel 6to4. Lo que se hace es pasar el tráfico IPv6 encapsulado bajo el protocolo 41. El primer paso sería habilitarlo en el firewall IPv4:

echo “Habilitando IPV6…”
iptables -I INPUT -j ACCEPT –proto 41

Para habilitar el túnel depende de si teneis ip estática o dinámica. Si es dinámica tendreis que daros de alta en algun servicio que os permita utilizarlo de túnel, se parece a como se hacía antiguamente con las conexiones PPP de módem, se lanza un cliente que nos crea una interfaz TAP en el equipo. En caso de tener una IPv4 estática y si la tenemos directamente en el equipo porque el router está en modo bridge, podremos crear nosotros de forma nativa el puente 6to4. Es algo complejo entender todos los parámetros y el porqué, hay manuales ya creados por internet, procupro detallar en este post todo lo que no he visto o me ha costado encontrar por ahí. Os pondré como ejemplo mi configuración:

# En /etc/network/interfaces definiríamos algo como sigue:

auto tun6to4
iface tun6to4 inet6 v4tunnel
address 2002:YYYY:YYYY:1::1
netmask 16
gateway ::192.88.99.1
endpoint any
local XXX.XXX.XXX.XXX
up ip -6 route add ::/0 dev tun6to4 metric 1
up ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1
up ip -6 route add 2000::/3 via 2002:YYYY:YYYY::1 dev tun6to4 metric 1
up ip -6 addr add 2002:YYYY:YYYY::1/16 dev tun6to4
up ip -6 addr add 2002:YYYY:YYYY:1::1/64 dev br0
down ip -6 route flush dev tun6to4
up /etc/network/ipv6rules.sh
ttl 255
mtu 1480

# Donde pone XXX.XXX.XXX.XXX es vuestra IPv4 pública, donde ponga YYYY.YYYY es vuestra IPv4 convertida a hexadecimal, el prefijo 2002 en las IPv6 indica que es un formato de compatibilidad y ésto supone que disponemos de un rango de 65535 IPv6 para nosotros solitos, hasta el despertador puede tener IP.

Con esto se creará una interfaz que automáticamente enrutará el tráfico IPv6 por nosotros. Fijaos en que llamo al script /etc/network/ipv6rules.sh para configurar el firewall IPv6 (en mi caso es ipv6tables, que es nativo del kernel de linux).

Una vez creado y lanzado el túnel de cualquiera de las formas antes indicadas, faltaría instalar un programa que transfiera las rutas al resto de equipos de la red, en el caso de linux se usa radvd. Si no se instala y configura, sólo el equipo con el túnel 6to4 tendrá conectividad IPv6, mientras que si se instala y configura, el resto de equipos sabrán como llegar al siguiente enrutador y ser visibles públicamente, así es cómo soluciona IPv6 el problema del NAT (recuerda al típico: Para salir afuera hay que usar la puerta de la entrada ¡pásalo!).

Si quereis hacer pruebas para verificar si vuestra configuración funciona o si ya teneis habilitado el acceso por IPv6, os recomiendo las siguientes direcciones web:

• http://test-ipv6.com/
• http://ipv6-test.com/
• http://www.sixxs.net/tools/ipv6calc/

¡Me olvidaba! Por si habeis pensado en asociar un dominio o subdominio a una IPv6, es posible mediante los DNS actuales, especialmente con bind, sólo hay que crear un registro de tipo AAAA.

Para probar si teneis conexión desde los equipos de la red, además de navegar por páginas web, podéis utilizar la utilidad ping6 para saber si los paquetes llegan:

debian:~# ping6 ipv6.google.com
PING ipv6.google.com(2a00:1450:8002::93) 56 data bytes
64 bytes from 2a00:1450:8002::93: icmp_seq=1 ttl=56 time=289 ms
64 bytes from 2a00:1450:8002::93: icmp_seq=2 ttl=56 time=207 ms
64 bytes from 2a00:1450:8002::93: icmp_seq=3 ttl=56 time=216 ms
64 bytes from 2a00:1450:8002::93: icmp_seq=4 ttl=56 time=231 ms
^C
— ipv6.google.com ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 207.244/236.297/289.250/31.796 ms
debian:~#

Y bueno, hay mucho, mucho, por leer, y es bueno estar preparado para que luego no nos coja por sorpresa.

Si teneis cualquier duda planteádmela e intentaré ayudaros hasta donde pueda.

Un saludo.

Existe una costumbre muy extendida por parte de los webmasters y administradores de páginas web y servidores de crear subdominios específicos para acceder a partes ocultas, de administración o base de datos.

Existe una forma de recuperar la lista de subdominios de un dominio normal,  y aunque es facilmente bloqueable por el propietario del dominio, por norma general está habilitado.

Estoy hablando del registro AXFR, cuya finalidad original es permitir el traspaso del control de un dominio a otro o bien la creación de servidores DNS de apoyo al primario.

Existen multitud de páginas web que utilizan los programas que voy a describir a continuación, por ejemplo Magic-Net, pero quiero explicar en que se basan para obtener la información que nos muestran.

Toda la información publicada aquí es pública y accesible por cualquier persona, no se trata de ningún fallo de seguridad, sencillamente es una configuración que nos otorga cierta información de un dominio, esto puede sacarnos de algún problema tratando de reparar un dominio que está en un servidor DNS ajeno.

Existen tres utilidades principales para obtener información de los dominios en linux:

1. whois – Nos devuelve información del registro de un dominio.
2. host – Resuelve la dirección IP de un dominio y viceversa.
3. dig – Interroga a un servidor DNS para que le dé la información sobre un dominio.

Voy a explicarlo de forma práctica esta vez, vamos a intentar obtener más información sobre el dominio meneame.net. Empezaremos buscando información sobre el dominio utilizando el comando whois:

Como podeis ver, el comando whois nos devuelve numerosos datos sobre el registro, de los cuales para nuestro propósito nos interesa saber sus servidores DNS: ns1.meneame.net y ns0.meneame.net. Utilizando el comando host podemos indagar donde está hospedada la página:

Expandir »

debian:~# host www.meneame.net
www.meneame.net is an alias for web-balancer-177968158.eu-west-1.elb.amazonaws.com.
web-balancer-177968158.eu-west-1.elb.amazonaws.com has address 46.51.177.152
debian:~# host 46.51.177.152
152.177.51.46.in-addr.arpa domain name pointer ec2-46-51-177-152.eu-west-1.compute.amazonaws.com.

debian:~#

Como se puede ver, está hospedado en los servicios web de amazon. No es ningún secreto, el administrador Ricardo Galli ha explicado en su blog la infraestructura de su red hace algún tiempo, pero si no lo hubiera hecho también podríamos saberlo.

Por último podemos trastear con el comando dig para obtener información del dominio:

Expandir »

debian:~# dig meneame.net

; <<>> DiG 9.7.2-P3 <<>> meneame.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55025
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;meneame.net.            IN    A

;; ANSWER SECTION:
meneame.net.        2152    IN    A    79.125.22.108

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 20 17:57:13 2010
;; MSG SIZE  rcvd: 45

debian:~# dig meneame.net soa

; <<>> DiG 9.7.2-P3 <<>> meneame.net soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41788
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;meneame.net.            IN    SOA

;; ANSWER SECTION:
meneame.net.        86400    IN    SOA    ns0.meneame.net. gallir.gmail.com. 2010111303 7200 3600 2419200 86400

;; Query time: 126 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 20 17:57:33 2010
;; MSG SIZE  rcvd: 85

debian:~#

Como se puede ver, utilizando consultas simples sólo obtenemos la información básica del dominio, si el uso del registro AXFR está habilitado nos devolverá una lista con todos los subdominios, sinó mostrará un error indicando que el traspaso de dominios está deshabilitado:

Expandir »

debian:~# dig meneame.net axfr

; <<>> DiG 9.7.2-P3 <<>> meneame.net axfr
;; global options: +cmd
; Transfer failed.
debian:~#

Normalmente el acceso a los registros AXFR se restringe indicando qué servidores DNS pueden acceder (un filtro por IP, vamos), pero normalmente cometen un error: los servidores del dominio tienen permiso para acceder a los registros AXFR. Veamos un ejemplo con este mismo dominio, ejecutamos la misma consulta de antes, pero en vez de preguntar a nuestro servidor dns, preguntamos al que maneja el dominio:

Expandir »

debian:~# dig @ns0.meneame.net meneame.net axfr

; <<>> DiG 9.7.2-P3 <<>> @ns0.meneame.net meneame.net axfr
; (1 server found)
;; global options: +cmd
; Transfer failed.
debian:~# dig @ns1.meneame.net meneame.net axfr

; <<>> DiG 9.7.2-P3 <<>> @ns1.meneame.net meneame.net axfr
; (1 server found)
;; global options: +cmd
meneame.net.        604800    IN    SOA    ns0.meneame.net. gallir.gmail.com. 2010111303 7200 3600 2419200 86400
meneame.net.        14400    IN    NS    ns0.meneame.net.
meneame.net.        14400    IN    NS    ns1.meneame.net.
meneame.net.        3600    IN    A    79.125.22.108
meneame.net.        14400    IN    MX    1 ASPMX.L.GOOGLE.COM.
meneame.net.        14400    IN    MX    5 ALT1.ASPMX.L.GOOGLE.COM.
meneame.net.        14400    IN    MX    5 ALT2.ASPMX.L.GOOGLE.COM.
meneame.net.        14400    IN    MX    10 ASPMX2.GOOGLEMAIL.COM.
meneame.net.        14400    IN    MX    10 ASPMX3.GOOGLEMAIL.COM.
meneame.net.        604800    IN    TXT    ”v=spf1 a mx include:authsmtp.com ~all”
aws.meneame.net.    14400    IN    CNAME    web-balancer-177968158.eu-west-1.elb.amazonaws.com.
*.aws.meneame.net.    14400    IN    CNAME    web-balancer-177968158.eu-west-1.elb.amazonaws.com.
googleffffffffe59670b4.aws.meneame.net.    3600 IN    CNAME google.com.
aws0.meneame.net.    14400    IN    CNAME    ec2-79-125-22-108.eu-west-1.compute.amazonaws.com.
aws1.meneame.net.    14400    IN    CNAME    ec2-79-125-19-251.eu-west-1.compute.amazonaws.com.
awsb.meneame.net.    14400    IN    CNAME    ec2-79-125-120-237.eu-west-1.compute.amazonaws.com.
blog.meneame.net.    14400    IN    CNAME    meneame.wordpress.com.
cdn.meneame.net.    14400    IN    CNAME    d1rpqr8jxr6cd6.cloudfront.net.
dev.meneame.net.    3600    IN    CNAME    aws.meneame.net.
ec2-db-server.meneame.net. 14400 IN    CNAME    ec2-79-125-120-237.eu-west-1.compute.amazonaws.com.
ec2-db-slave.meneame.net. 14400    IN    CNAME    ec2-79-125-22-108.eu-west-1.compute.amazonaws.com.
ec2-log-server.meneame.net. 14400 IN    CNAME    ec2-79-125-22-108.eu-west-1.compute.amazonaws.com.
ec2-nfs-server.meneame.net. 14400 IN    CNAME    ec2-79-125-22-108.eu-west-1.compute.amazonaws.com.
gallir.meneame.net.    14400    IN    A    127.0.0.1
gallir.meneame.net.    604800    IN    TXT    ”google-site-verification: 0HFtuQQVJqZa0LwbTMsilaRx58Mw9V2SZpSRKhPu2rI”
googleffffffffe59670b4.meneame.net. 3600 IN CNAME google.com.
m.meneame.net.        14400    IN    CNAME    web-balancer-177968158.eu-west-1.elb.amazonaws.com.
dev.m.meneame.net.    3600    IN    CNAME    aws.meneame.net.
media.meneame.net.    14400    IN    CNAME    media.meneame.net.s3.amazonaws.com.
ns0.meneame.net.    3600    IN    A    79.125.22.108
ns1.meneame.net.    3600    IN    A    79.125.120.237
ns2.meneame.net.    3600    IN    A    79.125.120.237
static.meneame.net.    14400    IN    CNAME    web-balancer-177968158.eu-west-1.elb.amazonaws.com.
svn.meneame.net.    3600    IN    CNAME    aws0.meneame.net.
test.meneame.net.    300    IN    CNAME    ec2-79-125-35-242.eu-west-1.compute.amazonaws.com.
*.test.meneame.net.    300    IN    CNAME    ec2-79-125-35-242.eu-west-1.compute.amazonaws.com.
tv.meneame.net.        14400    IN    CNAME    atiza.me.
viewvc.meneame.net.    3600    IN    CNAME    aws.meneame.net.
websvn.meneame.net.    3600    IN    CNAME    aws.meneame.net.
www.meneame.net.    14400    IN    CNAME    web-balancer-177968158.eu-west-1.elb.amazonaws.com.
meneame.net.        604800    IN    SOA    ns0.meneame.net. gallir.gmail.com. 2010111303 7200 3600 2419200 86400
;; Query time: 110 msec
;; SERVER: 79.125.120.237#53(79.125.120.237)
;; WHEN: Mon Dec 20 18:03:53 2010
;; XFR size: 41 records (messages 1, bytes 1265)

debian:~#

Como diría Juan Tamariz… Tachaaannnn!!!!

Como nota a mayores habría que decir que es un error nefasto utilizar como servidor dns de un dominio, un subdominio del propio dominio: meneame.net -> ns1.meneame.net. Si el dominio caduca, se anula o le pasa cualquier cosa administrativa, se va todo al traste, incluída la resolución DNS.

Por cierto, este tema de la configuración AXFR está muy extendida, os pongo a continuación algunos ejemplos ilustrativos (pongo dominios de nuestros políticos para mostrar la transparencia que no tienen con otros temas ):

PSOE

Expandir »

debian:~# dig @ns1.psoe.es psoe.es axfr

; <<>> DiG 9.7.2-P3 <<>> @ns1.psoe.es psoe.es axfr
; (1 server found)
;; global options: +cmd
psoe.es.        60    IN    SOA    ns0.psoe.es. hostmaster.psoe.es. 2010120900 3600 900 2592000 3600
psoe.es.        60    IN    NS    ns0.psoe.es.
psoe.es.        60    IN    NS    ns1.bt.es.
psoe.es.        60    IN    NS    ns1.psoe.es.
psoe.es.        60    IN    NS    ns2.bt.es.
psoe.es.        60    IN    MX    10 mx3.psoe.es.
psoe.es.        60    IN    MX    30 mx1.psoe.es.
psoe.es.        60    IN    A    213.192.237.42
*.psoe.es.        60    IN    CNAME    www.psoe.es.edgesuite.net.
11congresograncanaria.psoe.es. 60 IN    A    213.192.237.38
14congresoaragon.psoe.es. 60    IN    A    213.192.237.38
36congreso.psoe.es.    60    IN    A    217.140.16.54
37cdemo.psoe.es.    60    IN    A    213.192.237.38
37congreso.psoe.es.    60    IN    A    213.192.237.38
5congressocialistespalma.psoe.es. 60 IN    A    213.192.237.38
accesovpn.psoe.es.    60    IN    A    213.192.237.134
acreditacion.psoe.es.    60    IN    A    194.140.40.43
37congreso.acreditacion.psoe.es. 60 IN    A    194.140.40.44
acreditaciones.psoe.es.    60    IN    A    194.140.40.43
actualizadatos.psoe.es.    60    IN    A    213.192.237.32
agrupaciones.psoe.es.    60    IN    MX    10 mx1.psoe.es.
agrupaciones.psoe.es.    60    IN    MX    30 mx3.psoe.es.
agrupaciones.psoe.es.    60    IN    A    194.140.40.46
america.psoe.es.    60    IN    MX    10 mx3.psoe.es.
america.psoe.es.    60    IN    MX    30 mx1.psoe.es.
aphilia.psoe.es.    60    IN    A    194.140.40.45
aragon.psoe.es.        60    IN    NS    dns7.servidoresdns.net.
aragon.psoe.es.        60    IN    NS    dns8.servidoresdns.net.
*.blogs.psoe.es.    60    IN    A    213.192.237.42
boletines.psoe.es.    60    IN    A    213.192.237.230
cambiagalicia.psoe.es.    60    IN    A    213.192.237.227
cefintranet.psoe.es.    60    IN    A    213.192.236.33
cefsites.psoe.es.    60    IN    A    213.192.236.34
cefsitespki.psoe.es.    60    IN    A    213.192.236.35
chat.psoe.es.        60    IN    A    213.192.237.222
comunicaciones.psoe.es.    60    IN    MX    10 server32.dyr.es.
conferencia.psoe.es.    60    IN    A    213.192.237.43
conferencia-datos.psoe.es. 60    IN    A    213.192.237.44
conferencia2004.psoe.es. 60    IN    A    213.192.237.227
conferencia2006.psoe.es. 60    IN    A    84.233.205.172
conferenciaextremadura.psoe.es.    60 IN    A    213.192.237.38
conferenciagalicia.psoe.es. 60    IN    A    213.192.237.38
conferenciapolitica2004.psoe.es. 60 IN    A    213.192.237.227
conferenciapolitica2004adm.psoe.es. 60 IN A    213.192.237.227
congresocoruna.psoe.es.    60    IN    A    213.192.237.38
congresolugo.psoe.es.    60    IN    A    213.192.237.38
congresoourense.psoe.es. 60    IN    A    213.192.237.38
convenciomallorca.psoe.es. 60    IN    A    213.192.237.38
cp2006.psoe.es.        60    IN    A    84.233.205.172
cp2006.psoe.es.        60    IN    A    217.130.22.199
cuarentena.psoe.es.    60    IN    A    213.192.236.13
cuestionarioigualdad.psoe.es. 60 IN    A    213.192.237.227
debug.psoe.es.        60    IN    A    213.192.236.199
descargas.psoe.es.    60    IN    A    213.192.237.236
descargas.psoe.es.    60    IN    A    213.192.237.246
devgalicia.psoe.es.    60    IN    A    217.140.16.54
diariodelparlamentario.psoe.es.    60 IN    A    213.192.237.30
diccionariobiografico.psoe.es. 60 IN    A    213.192.237.41
emoticones.psoe.es.    60    IN    A    213.192.237.219
37congreso.enmiendas.psoe.es. 60 IN    A    213.192.237.38
avalesprimarias.psoe.es.psoe.es. 60 IN    A    213.192.237.37
conferenciaeuskadi.psoe.es.psoe.es. 60 IN A    213.192.237.38
www.orgullo2006.psoe.es.psoe.es. 60 IN    CNAME    orgullo2006.psoe.es.
especiales.psoe.es.    60    IN    A    213.192.237.227
europa.psoe.es.        60    IN    MX    10 mx3.psoe.es.
europa.psoe.es.        60    IN    MX    30 mx1.psoe.es.
europa.psoe.es.        60    IN    A    213.192.237.236
europa.psoe.es.        60    IN    A    213.192.237.246
europa2004.psoe.es.    60    IN    A    217.140.16.54
europasi.psoe.es.    60    IN    A    217.140.16.54
europeosocialistayorgullosodeserlo.psoe.es. 60 IN A 213.192.237.225
www.europeosocialistayorgullosodeserlo.psoe.es.    60 IN A    213.192.237.225
eventos.psoe.es.    60    IN    A    213.192.237.34
expdev.psoe.es.        60    IN    A    213.192.237.227
experiencias.psoe.es.    60    IN    A    213.192.237.27
fedpatrimonio.psoe.es.    60    IN    A    213.192.237.41
flash.psoe.es.        60    IN    A    213.192.237.32
foroeuropasi.psoe.es.    60    IN    A    213.192.237.227
frcenso.psoe.es.    60    IN    A    213.192.236.133
frcenso1.psoe.es.    60    IN    A    213.192.236.132
frcenso2.psoe.es.    60    IN    A    213.9.180.239
ftp.psoe.es.        60    IN    A    213.192.236.198
ftp-old.psoe.es.    60    IN    A    213.192.237.230
galizaagora.psoe.es.    60    IN    A    213.192.237.227
generador.psoe.es.    60    IN    A    213.192.237.38
gestionweb.psoe.es.    60    IN    A    213.192.237.239
gestionweb.psoe.es.    60    IN    A    213.192.237.240
gestionweb.psoe.es.    60    IN    A    213.192.237.241
granada.psoe.es.    60    IN    CNAME    www.psoe.es.edgesuite.net.
23congreso.granada.psoe.es. 60    IN    A    213.192.237.38
guadalajara.psoe.es.    60    IN    MX    30 mx1.psoe.es.
guadalajara.psoe.es.    60    IN    MX    30 mx3.psoe.es.
haremosmas.psoe.es.    60    IN    A    213.97.168.236
jaen.psoe.es.        60    IN    CNAME    www.psoe.es.edgesuite.net.
xiicongreso.jaen.psoe.es. 60    IN    A    213.192.237.38
listas.psoe.es.        60    IN    A    213.192.237.39
listas2.psoe.es.    60    IN    A    213.192.237.219
listas3.psoe.es.    60    IN    A    213.9.180.231
localhost.psoe.es.    60    IN    A    127.0.0.1
mail.psoe.es.        60    IN    A    213.192.236.26
mail3.psoe.es.        60    IN    A    213.97.168.236
mailcer.psoe.es.    60    IN    A    213.9.180.244
mailgate.psoe.es.    60    IN    A    213.192.236.10
mails.psoe.es.        60    IN    A    213.192.236.18
malaga.psoe.es.        60    IN    CNAME    www.psoe.es.edgesuite.net.
congreso.malaga.psoe.es. 60    IN    A    213.192.237.38
mallorca.psoe.es.    60    IN    CNAME    www.psoe.es.edgesuite.net.
11congres.mallorca.psoe.es. 60    IN    A    213.192.237.38
media.psoe.es.        60    IN    A    213.192.237.32
movil.psoe.es.        60    IN    A    213.192.236.17
movilizacion.psoe.es.    60    IN    A    213.9.180.231
movilmail.psoe.es.    60    IN    A    213.9.180.251
mx0.psoe.es.        60    IN    A    213.97.168.236
mx1.psoe.es.        60    IN    A    213.192.236.13
mx3.psoe.es.        60    IN    A    213.192.236.23
navarra.psoe.es.    60    IN    CNAME    www.psoe.es.edgesuite.net.
9congreso.navarra.psoe.es. 60    IN    A    213.192.237.38
ns0.psoe.es.        60    IN    A    213.192.236.25
ns1.psoe.es.        60    IN    A    213.192.236.21
ns2.psoe.es.        60    IN    A    213.192.237.222
nuevasenergias.psoe.es.    60    IN    A    213.192.237.42
objetivo2004.psoe.es.    60    IN    A    213.9.180.231
objetivo2004adm.psoe.es. 60    IN    A    213.192.237.227
operaciones.psoe.es.    60    IN    A    213.192.237.38
orgsectoriales.psoe.es.    60    IN    MX    30 mx1.psoe.es.
orgsectoriales.psoe.es.    60    IN    MX    30 mx3.psoe.es.
orgullo07.psoe.es.    60    IN    A    213.97.168.236
orgullo09.psoe.es.    60    IN    A    213.192.237.219
orgullo2006.psoe.es.    60    IN    A    213.192.237.227
patrimonio.psoe.es.    60    IN    A    213.192.237.219
pki-lcr.psoe.es.    60    IN    A    213.192.237.33
player.psoe.es.        60    IN    A    213.192.237.40
ponencia36congreso.psoe.es. 60    IN    A    213.192.237.227
pontevedra.psoe.es.    60    IN    CNAME    www.psoe.es.edgesuite.net.
congreso.pontevedra.psoe.es. 60    IN    A    213.192.237.38
pop3.psoe.es.        60    IN    A    213.9.180.252
pops.psoe.es.        60    IN    A    213.192.236.19
prepro.psoe.es.        60    IN    A    213.192.237.215
programa2004.psoe.es.    60    IN    A    213.192.237.227
programaelectoral2008.psoe.es. 60 IN    A    213.9.180.231
propuestas.psoe.es.    60    IN    A    213.192.237.29
proxy1.psoe.es.        60    IN    A    213.192.236.12
proxy2.psoe.es.        60    IN    A    213.192.236.201
pscanarias.psoe.es.    60    IN    CNAME    www.psoe.es.edgesuite.net.
11congreso.pscanarias.psoe.es. 60 IN    A    213.192.237.38
pscantabria.psoe.es.    60    IN    CNAME    www.psoe.es.edgesuite.net.
11congreso.pscantabria.psoe.es.    60 IN    A    213.192.237.38
pse-ee.psoe.es.        60    IN    MX    10 sollube.sarenet.es.
pse-ee.psoe.es.        60    IN    A    213.195.76.220
www.pse-ee.psoe.es.    60    IN    A    213.195.76.220
pse002r0-04.psoe.es.    60    IN    A    213.192.237.225
pse002r0-24.psoe.es.    60    IN    A    213.192.237.36
pse002r0-26.psoe.es.    60    IN    A    213.192.237.42
pse002r0-30.psoe.es.    60    IN    A    213.192.237.236
psib.psoe.es.        60    IN    CNAME    www.psoe.es.edgesuite.net.
www.psib.psoe.es.    60    IN    A    217.76.130.33
xicongres.psib.psoe.es.    60    IN    A    213.192.237.38
psm.psoe.es.        60    IN    CNAME    www.psoe.es.edgesuite.net.
11congreso.psm.psoe.es.    60    IN    A    213.192.237.38
www.pspv.psoe.es.    60    IN    A    83.175.218.163
publicaciones.psoe.es.    60    IN    A    213.192.237.246
rsites.psoe.es.        60    IN    A    213.192.236.42
sectorial09.psoe.es.    60    IN    A    213.192.237.38
sectoriales09.psoe.es.    60    IN    A    213.192.237.219
seta1.psoe.es.        60    IN    A    213.192.237.33
seta2.psoe.es.        60    IN    A    213.192.237.32
seta3.psoe.es.        60    IN    A    213.192.237.39
seta5.psoe.es.        60    IN    A    213.192.237.30
seta6.psoe.es.        60    IN    A    213.192.237.34
seta7.psoe.es.        60    IN    A    213.192.237.35
setratadeeuropa.psoe.es. 60    IN    A    217.140.16.54
siti.psoe.es.        60    IN    A    213.192.237.42
sms.psoe.es.        60    IN    MX    10 mail.sms.psoe.es.
mail.sms.psoe.es.    60    IN    A    212.170.234.141
streaming.psoe.es.    60    IN    A    213.192.237.40
streaming2.psoe.es.    60    IN    A    213.192.237.102
tenerife.psoe.es.    60    IN    CNAME    www.psoe.es.edgesuite.net.
14congreso.tenerife.psoe.es. 60    IN    A    213.192.237.38
tsfederaciones.psoe.es.    60    IN    A    213.192.236.11
usos-ca.psoe.es.    60    IN    A    213.192.237.33
vertebra.psoe.es.    60    IN    A    213.192.237.235
vistalegre09.psoe.es.    60    IN    A    213.192.237.225
vs.psoe.es.        60    IN    A    213.192.237.246
wap.psoe.es.        60    IN    A    213.192.237.227
wapadmin.psoe.es.    60    IN    A    213.192.237.227
backup1.web.psoe.es.    60    IN    A    213.192.237.236
backup2.web.psoe.es.    60    IN    A    213.192.237.246
node1.web.psoe.es.    60    IN    A    213.192.237.236
node2.web.psoe.es.    60    IN    A    213.192.237.246
node3.web.psoe.es.    60    IN    A    213.192.237.235
webagrupaciones.psoe.es. 60    IN    A    213.192.237.219
webcampana2008.psoe.es.    60    IN    A    213.192.237.248
webcampana2008-backup.psoe.es. 60 IN    A    213.192.237.225
mx1.webmail.psoe.es.    60    IN    A    213.9.180.253
webs.psoe.es.        60    IN    CNAME    www.psoe.es.edgesuite.net.
widget.psoe.es.        60    IN    A    213.192.237.42
wikiprograma.psoe.es.    60    IN    A    213.192.237.42
www.psoe.es.        60    IN    CNAME    www.psoe.es.edgesuite.net.
psoe.es.        60    IN    SOA    ns0.psoe.es. hostmaster.psoe.es. 2010120900 3600 900 2592000 3600
;; Query time: 96 msec
;; SERVER: 213.192.236.21#53(213.192.236.21)
;; WHEN: Mon Dec 20 18:08:56 2010
;; XFR size: 199 records (messages 1, bytes 5193)

debian:~#

Expandir »

debian:~# dig  @ns2.eurovia.es ciu.cat axfr

; <<>> DiG 9.7.2-P3 <<>> @ns2.eurovia.es ciu.cat axfr
; (1 server found)
;; global options: +cmd
ciu.cat.        3600    IN    SOA    ns.convergencia.org. postmaster.convergencia.org. 2010111501 900 600 86400 3600
ciu.cat.        3600    IN    NS    ns.convergencia.org.
ciu.cat.        3600    IN    NS    ns1.eurovia.es.
ciu.cat.        3600    IN    NS    ns2.eurovia.es.
ciu.cat.        3600    IN    A    178.79.133.226
ciu.cat.        3600    IN    MX    10 correu2.convergencia.org.
ciu.cat.        3600    IN    MX    20 correu.convergencia.org.
ciu.cat.        3600    IN    TXT    “v=spf1 a mx a:tdtres.ciu.cat  mx:correu.convergencia.org mx:correu2.convergencia.org ~all”
blocs.ciu.cat.        3600    IN    A    178.79.133.226
parlament.ciu.cat.    3600    IN    MX    10 mail.parlament.ciu.cat.
mail.parlament.ciu.cat.    3600    IN    A    213.151.125.11
tdtres.ciu.cat.        3600    IN    A    178.79.140.175
tdtresmedia.ciu.cat.    3600    IN    CNAME    d1yeolr9yncan9.cloudfront.net.
videobloc.ciu.cat.    3600    IN    MX    10 correu.videobloc.ciu.cat.
correu.videobloc.ciu.cat. 3600    IN    A    213.151.125.11
www.ciu.cat.        3600    IN    A    178.79.133.226
ns2.eurovia.es.        3600    IN    A    217.113.248.4
ciu.cat.        3600    IN    SOA    ns.convergencia.org. postmaster.convergencia.org. 2010111501 900 600 86400 3600
;; Query time: 91 msec
;; SERVER: 217.113.248.4#53(217.113.248.4)
;; WHEN: Mon Dec 20 18:10:51 2010
;; XFR size: 18 records (messages 1, bytes 584)

debian:~#

Sorprendentemente el PP lo tiene bien restringido aunque su dominio vulnera la convención de registros con extensión .es, cuya longitud mínima son 3 caracteres y ellos sólo usan 2, enchufes de la política…

Los de IU registraron un dominio legal, no como los anteriores, y parece restringido el acceso a los registros AXFR.

Lo mismo con BNG, UPyD y PNV. No se me ocurren más dominios que probar, puedes seguir tú mismo.

No estuvo mal el experimento, es sorprendente la cantidad de subdominios que tiene el actual gobierno en su página web, amen que tienen la página hospedada en Akamai, seguramente para que no se note el descontento con la infame “ley Sinde”.

Un saludo.

Proveniente de la mitología nórdica, Muninn era uno de los dos cuervos que proveía al Dios Odín con información diaria de lo sucedido en todo el mundo.

Sin duda, un nombre excelente para resumir lo que hace este magnífico proyecto. Munin es una aplicación con infraestructura cliente – servidor que recopila información de los nodos de una red y genera gráficas con las estadísticas.

Esto nos permite encontrar cuellos de botella en servidores, ver que ordenadores estan haciendo un uso más intensivo de la red, detectar y predecir fallos en el hardware (especialmente en discos duros), etc…

La arquitectura de este programa es bastante simple, por un lado en cada ordenador que queramos monitorizar debemos instalar el paquete munin-node y configurarlo para permitir conexiones desde el servidor central. En el servidor central hay que instalar el paquete munin, tiene que ser configurado indicando qué ordenadores tiene que monitorizar y donde debe generar las gráficas.

Para instalar los paquetes:

apt-get install munin munin-node munin-plugins-extra apache2

Existe un port para Windows del paquete munin-node, pero no ofrece tanta información útil como las versiones para Linux.

Para configurar el paquete munin-node:

Editamos el archivo /etc/munin/munin-node.conf añadiendo la IP del servidor central como permitida, en este ejemplo el servidor tendrá la IP 192.168.0.1:

allow ^192\.168\.0\.1$

En este mismo archivo podemos cambiar en que interfaz de red debe escuchar el programa y que puerto utilizar (por defecto 4949), no es necesario modificarlos pero sí tenerlo en cuenta si es necesario configurar el firewall.

Para configurar el paquete munin:

Editamos el archivo /etc/munin/munin.conf añadiendo los ordenadores que debe explorar cada 5 minutos:

[pcubuntu]
address 192.168.0.2
use_node_name yes

[pcwindows]
address 192.168.0.3
use_node_name yes

Y en el archivo /etc/munin/apache2.conf modificaremos la configuración para acceder a los gráficos generados, en principio sólo es recomendable cambiar el primer Alias, aunque también podríais ponerle contraseña HTTP si quereis restringir el acceso.:

Alias /monitor /var/cache/munin/www

Por defecto el número de gráficos que genera munin es cuantioso, y más si se instalan plugins adicionales o los creais vosotros mismos. No es dificil, permite crear los plugins como un script shell cualquiera (incluído PHP, python ó PERL) lo que nos permite monitorizar cualquier cosa, como por ejemplo un termómetro USB. En este caso no me voy a detener mucho explicando esta funcionalidad. Si quereis investigarlo, los plugins se pueden encontrar en /etc/munin/plugins donde la mayoría son enlaces blandos hacia /usr/share/munin/plugins.

Tras configurar todo y darle algo de tiempo para que genere datos (monitoriza cada 5 minutos, así que habría que esperar una hora aproximadamente para tener algo que analizar), podremos acceder a los gráficos generados bajo la ruta (continuando con la IP del servidor anterior):

http://192.168.0.1/monitor

Estos gráficos se generan gracias a la librería RRDtool, que da muy buenos resultados.

Podemos ver una lista de los equipos monitorizados, pinchando en cada uno accederemos a un listado de gráficos detallados. Os pongo aquí como ejemplo algunos datos recogidos en mi servidor y algunos comentarios sobre los mismos:

Hay muchos otros gráficos interesantes como el uso de SWAP, estadísticas de Samba, Squid, información S.M.A.R.T. de los discos duros, etc…

Si utilizamos este programa en un servidor de producción, podremos detectar si en algún momento el número de peticiones HTTP hace que el servidor se quede sin memoria libre y empiece a utilizar la SWAP, además, si alguno de los gráficos da valores de riesgo, munin resalta esos gráficos para que fijemos la atención en ellos. También podemos diagnosticar cuellos de botella en la red si no da abasto el procesador en operaciones de copia por red o con los discos duros, etc…

En mi caso hacía mucho tiempo que buscaba una aplicación como esta y supe de su existencia gracias a un post de barrapunto. Espero que este post sirva como referencia para quien busque una aplicación de monitorización bastante completa.

Si alguien tiene algún problema o duda en el proceso de instalación o configuración podeis plantearlo en los comentarios, os ayudaré en lo que pueda.

Un saludo.

Tras quemarse el SMC y perder por tanto el VOIP en casa, compré un Linksys WRP400 para tener separado lo que es el teléfono del router en sí. Tras configurarlo y abrir los puertos correspondientes (cosa que me llevó algunas horas puesto que el número de opciones es considerable) con el Zyxel no hubo problema.

Sin embargo al tener que utilizar el Conceptronic había problemas de conexión, precisamente por esto he investigado el tema central de este artículo.

Encontré dos problemas con este router, por un lado, según desde que IP se conecte desde fuera, las conexiones (donde lo he notado es al utilizar SSH) funcionan bien o mal. Tras algunas investigaciones y entrar directamente a la consola del router, si se limpian las reglas del iptables manteniendo la tabla NAT, las conexiones pasan a funcionar siempre bien; aunque no hay forma de guardar el comando para que lo ejecute en cada arranque del router, sólo hay que lanzar esto en la consola:

iptables -F

Pero apareció otro problema más serio, el Linksys enviaba paquetes SIP pero no recibía ni uno. Revisé todas las configuraciones, esnifé el tráfico desde mi servidor utilizando la excelente herramienta WireShark y efectivamente los paquetes SIP enviados eran correctos pero no se recibía respuesta alguna. El router tenía configurada una DMZ, así que todas las conexiones deberían estar redireccionadas hacia mi servidor, que actúa como firewall y router NAT. Todo estaba correctamente configurado pero sencillamente no conectaba.

Se me ocurrió entonces probar a delegar más trabajo del router en mi servidor, es decir, poner el router en modo bridge (en los inicios del ADSL esto se conocía como poner el router en modo monopuesto) para que sólo tenga que negociar la velocidad de sincronismo, el resto de enrutado y demás lo gestionará el servidor Linux.

Se podría considerar que esto viene siendo la guinda a lo que ya expliqué en los anteriores post de ¿Conexión ADSL lenta? Mejora la velocidad de tu conexión a Internet (Capítulo I de III).

Manos a la obra:

Durante mucho tiempo cuando tenía Telefónica intenté configurar la red de esta forma y me pasé horas viendo documentación sobre los encapsulados ATM, PPOA, PPOE y el paquete brctl 2684 sin mucho éxito. Con Ya.com hubo más suerte, utilizan un encapsulado ETHERNET, lo que significa que el router se conecta como si se tratase de una red local. En el caso de PPPOE la autentificación se realiza mediante un usuario y contraseña, en el caso del ETHERNET, la solicitud DHCP es la que valida al cliente.

Si teneis un router funcionando con Ya.com hay que configurar sólo un par de cosas. Por un lado se debe desactivar la Wifi y dejar sólo un equipo conectado por cable, sino habrá disputas entre los demás equipos de la red para conseguir la IP pública; lo que significa también que una vez configurado el router en modo bridge no podremos acceder a él a menos que forcemos la IP de red. Después, sería bueno desactivar el DHCP en la red y en WAN settings, debe quedar algo similar a lo siguiente (el VPI y VCI igual que como ya los tenías o te ha comunicado tu ISP):

Wan settings en modo bridge del router Conceptronic C54APRA2+

Y con esto terminamos de configurar el router, aunque faltaría guardar y reiniciarlo.

Si la IP local que teneis asignada en el equipo es fija (sin utilizar DHCP) podreis seguir accediento al router (con lo que recomiendo aprovechar para hacer una backup de la configuración) pero no funcionará la conexión hacia Internet. Esto se debe a que el router ahora no utiliza NAT para enrutar los paquetes hacia Internet, eso debe hacerlo directamente el servidor Linux. ¿Cómo? Sencillísimo, activando DHCP en la tarjeta de red conectada hacia el router en lugar de dejar la IP local estática. Como ahora el router sólo envía y recibe lo que llega por la línea ADSL, nuestro servidor recibirá directamente la IP pública desde el servidor DHCP de Ya.com.

He intentado utilizar un alias de red para asignar las dos IPs a la vez a la tarjeta de red conectada al router pero no acaba de funcionar, supongo que si estan en rangos diferentes la tarjeta se monta un lío:

debian:~# nano /etc/network/interfaces

auto eth0
iface eth0 inet dhcp
hwaddress ether 00:13:F7:E6:01:02

#iface eth0:1 inet static
#        address 192.168.1.10
#        netmask 255.255.255.0
#        network 192.168.1.0
#        broadcast 192.168.1.255

debian:~# ifdown eth0 && ifup eth0

Con eso obtenemos lo siguiente al consultar la información de la interfaz:

debian:~# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:13:f7:e6:01:02
inet addr:92.56.202.15  Bcast:92.56.207.255  Mask:255.255.248.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:41865677 errors:0 dropped:0 overruns:0 frame:0
TX packets:53608913 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1565578348 (1.4 GiB)  TX bytes:2633735228 (2.4 GiB)
Interrupt:18 Base address:0x2c00

debian:~#

Excelente.

Por último, recordad que al cambiar la IP de red a lo mejor teneis que realizar algún ajuste en las reglas del firewall o en la configuración de algún servicio que tenga indicada directamente la IP local de red en lugar de la interfaz; a mi me ha pasado con el cliente P2P Transmission que lo tengo configurado para que escuche sólo en una IP en particular.

Si habeis sido observadores, os habreis dado cuenta de que hay una línea importante, la referida a hwaddress ether. La he puesto a posteriori despues de realizar algunas pruebas porque sospecho que Ya.com valida la dirección MAC del router que se conecta para decidir si conecta el VOIP o no. En este caso utilizo una MAC dentro del rango que tenía el router SMC (ojo que no es la misma MAC de la Wifi del router que la del chipset de ADSL).

Conclusión final:

Además de solventar de un plumazo el problema de conexión del VOIP y del SSH, se nota y MUCHO una mejora general en la navegación por Internet. Ello se debe a que en lugar de estar utilizando un router de 50 euros con un procesador de unos 100 Mhz y 15 Mb de RAM, generalmente con un límite de 1000 conexiones simultáneas máximas, estoy utilizando un Pentium 4 Celeron a 1,7 Ghz con 768 Mb de RAM con Linux y una tabla de conexiones configurada para soportar hasta 32000 conexiones simultáneas.

Recomiendo a quien pueda montar esta configuración que la pruebe, realmente merece la pena y se nota la diferencia.

Foto publicada por JorgeMiente en Flickr

La disposicion final primera de la LES (Ley de Economía Sostenible) conocida como “ley Sinde” pretende bloquear páginas web que contengan enlaces a descargas no autorizadas de material cultural. Voy directo al grano, creo que no hace falta andarse con rodeos ni más explicaciones intermedias, estos son los principales fallos de dicha ley y formas de saltársela a la torera (incluso antes de que hipotéticamente sea aprobada) ó también podríamos decir, “Al menos 10 formas de saltarse la Ley Sinde”:

1. No utilizar páginas web:
   • Envío de torrents, enlaces, o directamente porciones de archivos mediante listas de correo electrónico, si los chistes circulan en cadenas masivas de correos, el resto también podría hacerlo.
   • Implementación de un protocolo alternativo al HTTP, como por ejemplo XML, o reutilización de algún otro estándard existente, conque no se trate de una página web sería suficiente.
   • Uso de servidores FTP públicos sólo para almacenar archivos .torrent.
   • Uso de servidores de News para publicación de torrents o elinks (esto si que está en desuso, pero podría revivir rápidamente).
2. Utilizar páginas web inbloqueables:
   • Google Hacking: Utilizar el sistema de búsquedas avanzadas de google, por ejemplo buscar MP3 de Mózart.
   • Lo mismo pero aplicado a cualquier otro buscador como Bing, Altavista, Yahoo, etc.
   • Uso de foros de terceras compañías o foros de servicio técnico para intercambio de enlaces, la empresa que da soporte no es responsable de las opiniones expresadas por los visitantes.
   • Uso de comentarios en páginas web para publicación de enlaces, legalmente ocurre lo mismo que en el caso anterior.
   • El propio creador de una página web presuntamente ilegítima podría subirla de nuevo en otro dominio, o bien otro usuario podría hacer una copia exacta de la misma.
3. Utilizar servicios de descarga directa:
   • Si van a bloquear páginas como ImageShack (pueden incluirse archivos ocultos en imágenes utilizando Esteganografía), Rapidshare, Megaupload y demás va a ser simpática la reaccion por parte de dichas empresas.
   • También existen empresas españolas en este ámbito, por ejemplo que se me ocurra, SubirImagenes.
4. Utilizar alguna de las miles páginas de búsqueda dentro de las páginas de descarga directa:
   • No conozco ninguna en particular pero una rápida búsqueda en Google nos sugiere algunas como:
     rapidshare-search-engine.com
     rapidshare1.com
     megadownload.net
     searchshared.com
     etc…
5. Utilizar programas P2P descentralizados:
   • El ya viejo eMule implementó un protocolo bastante conocido aunque no muy popular llamado Kademlia, dicho sistema está basado en una red descentralizada (no existen servidores, sólo clientes, incluso para las búsquedas) similar a la anterior GNutella.
6. Bajarse música con licencias no restrictivas:
   • Nos intentan hacer creer lo contrario, pero existe vida más allá del Copyright, un ejemplo de ello es la Música publicada bajo licencias Creative Commons.
7. Utilizar redes VPN encriptadas:
   • Existen diversos servicios públicos gratuitos de VPN, que permiten conectarse de forma anónima a Internet.
   • Podría montarse una subred dentro de internet con otras reglas (con un contrato privado antes de entrar) donde poder compartir libremente.
8. Crear macroredes Wifi abiertas paralelas a Internet:
   • Las redes Wifi son privadas e incontrolables, volver a apostar por las redes abiertas y una red alternativa a internet, no es tan locura como parece, un proyecto al respecto es Guifi.net.
9. Regalar copias de los discos:
   • Esto en sí no es una medida directa contra la ley, pero evitaría el incordio de tener que bajarse la música.
   • Que todo el mundo tenga discotecas privadas bestiales facilitaría mucho el intercambio de música de forma libre entre usuarios.
10. No descargar más música, y desde luego, no comprarla al precio al que la venden:
    • Suena a perogrullo, pero no por no descargar música o películas se va a invertir más dinero en los discos que se venden.

Lógicamente existen más formas de no caer en hipotética ilegalidad aunque dicho anteproyecto siga adelante, en cualquier caso su inutilidad queda patente y demuestra una vez más, que más que bloquear páginas de descarga, será simplemente una forma de censurar todo aquello que no guste. Además existen problemas técnicos a la hora de bloquear las páginas que no han querido detallar, porque no se puede bloquear una IP concreta si dicho servidor sirve más páginas web aparte de la presunta ilegítima, filtrar las resoluciones DNS se saltaría utilizando unos DNS alternativos, etc… parece que los ISPs tendrán que encontrar la forma mágica de conseguir dicho filtrado Web.

Desde luego las próximas elecciones se plantean interesantes, al menos a mí no me gusta que me tomen por tonto y tendré muy en cuenta las decisiones de nuestros representantes.

Un saludo.

¿Es un twitter? ¿Es un vueling? ¡No! ¡Es TOR – The Onion Router que viene al rescate!

Independientemente de lo sucedido en los últimos días con la polémica ley de Economía Sostenible (vía meneame) aunque relacionado aleatoriamente, en estos días que estuve de baja monté en mi casa una red wifi abierta con un foro interno al que se es redireccionado automáticamente si se intenta navegar por la web.

La idea principal del proyecto era montar una red abierta donde quedar para jugar en red, un punto de reunión abierto para cualquiera, ya sea algún amigo que venga a visitarme y querramos echar una partida rápida sin tener que andar configurando nada ni tener que andar tirando cables, como algún vecino cercano o cualquier otro desconocido.

Como servicios de valor añadido, monté un servidor dedicado de OpenArena (una versión totalmente libre del famosísimo Quake III y que utiliza su mismo motor gráfico) con el cliente descargable directamente desde el foro, sin necesidad de conexión a Internet. Así por lo menos había ya un juego para jugar en condiciones.

Posteriormente pensé en cómo ofrecer a cualquier persona Internet sin pillarme los dedos y sin que me suponga un uso abusivo del mismo por parte de cualquier persona, pero a la vez sin restringir lo que se quiera hacer. La mejor solución fue montar un proxy Privoxy + TOR de manera que la conexión sea anónima y no se pueda trazar su origen.

¿Cómo funciona? a grandes rasgos, Privoxy controla el contenido de las páginas para asegurarse de que no obtienen información sobre el cliente mediante javascript y otras tretas y TOR se encarga de crear rutas encriptadas por donde pasar la conexión. Automáticamente cada 10 minutos cambia la ruta.

Puedes consultar una explicación más extensa en la página web oficial de TOR.

La red TOR no destaca por tener una velocidad asombrosa pero es completamente funcional. Esto también fue un aliciente a la hora de montarlo, puesto que no quería que un posible cliente utilizase todo el ancho de banda disponible y tampoco quería liarme montando controles QoS.

A continuación os dejo una captura del foro, si entras en una red abierta y te sale esto al navegar, estás muy cerca de donde vivo.

Lector: Muy bien, bonito relato, pero… ¿Qué pretendes con todo esto?

Warning: los siguientes párrafos son mi opinión personal, si no la compartes por lo menos respétala (principio de democracia).

Sencillo, si más gente copiase de forma altruista esta idea, por lo menos la parte de montar una wifi abierta con un proxy TOR, el acceso a Internet sería muchísimo más accesible y a la vez más seguro y confidencial.

Propuestas absurdas, inconstitucionales y absolutamente lucrativas como la reforma oculta de la LSSI y LPI incluida en el anteproyecto de Ley de Economía Sostenible serían vías muertas que no acotarían el supuesto problema. Sobre estas reformas, está explicado en muchos sitios online, a grandes rasgos han incluído en dicha Ley la creación de un departamento con la potestad para desconectar usuarios de Internet o cerrar/censurar ciertas páginas web según su contenido. Se trata de una censura en toda regla, similar a la existente en la dictadura China.

En este caso en concreto, si la página web se encuentra en España presuntamente ordenarán a la empresa que ofrece el Hosting a que cierre dicha web (hasta el día de hoy sólo el poder Judicial tiene esta potestad, tal como se indica en la constitución española). Si la página web se encuentra fuera de España, ordenarán bloquear el dominio web a los ISPs. Esto podría hacerse mediante un trucaje en el servidor de nombres (lo mismo que hicimos en Cómo suplantar dominios de Internet en tu red local pero a gran escala) o bloqueando directamente las conexiones a dichas IPs. Lo primero se solucionaría utilizando los servidores abiertos OpenDNS, lo segundo (además de provocar problemas con otros dominios no relacionados almacenados en el mismo servidor), se puede evitar utilizando TOR.

Es decir, estas reformas atentan directamente contra los derechos fundamentales de los ciudadanos y dichos derechos deben ser defendidos. Si aun así, nos vemos sumidos en una sociedad como la mostrada en la excelente película V de Vendetta o en la novela 1.984, nuestros políticos deben tener claro que no se puede detener ni a la cultura ni al conocimiento, que Internet es el medio de comunicación más importante que existe, es la nueva biblioteca de Alejandría y no puede/debe ser manipulada como hacen con los medios de comunicación tradicionales (radio/televisión).

Si alguien intenta poner barreras a la tecnología, la tecnología acabará desbordando dichas barreras.

Desde aquí de la misma forma que apoyo y revindico el uso de tecnologías libres, también quiero mostrar mi total e incondicional apoyo al manifiesto en favor de los derechos en Internet elaborado de forma comunitaria por los usuarios:

Manifiesto “En defensa de los derechos fundamentales en internet”

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial – un organismo dependiente del ministerio de Cultura -, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Este manifiesto, elaborado de forma conjunta por varios autores, es de todos y de ninguno. Si quieres sumarte a él, difúndelo por Internet.

Espero que esta información os sea de provecho. Si te unes a la idea de montar la wifi abierta dejame un comentario por aquí por favor (y si no también, si quieres, claro…).

Un saludo.

Continuando con la cruzada personal para ajustar cualquier cosa para que funcione como yo quiero, voy a enseñaros un caso práctico que utilizo en mi casa para mostrar lo útil que puede llegar a ser suplantar algunos dominios de internet.

La idea principal es hacer que un dominio (como por ejemplo www.microsoft.com) no apunte a la IP original, sino a una dentro de nuestra red local o bien hacia otra distinta en Internet.

Para empezar, nos hace falta montar un entorno como sigue:

1. Enrutador (realmente es opcional, pero si lo tenemos nos evitará tener que modificar las configuraciones en cada equipo. Uso el script apf que simplifica la administración con iptables)
2. Servidor caché DNS (dnsmasq en este ejemplo)
3. Servidor web (en mi caso uso apache)
4. Proxy caché HTTP (opcional, transparente o no, recomendable usar squid)

Asumo que la mayoría de la gente no tiene en casa un cluster o un rack de servidores, así que todos estos servicios probablemente estarán en el mismo equipo. Para los posibles ejemplos que se mostrarán, la interfaz de red que va conectada hacia internet sería eth0 y la que va conectada a la red local sería eth1. En eth1 el servidor tendrá la IP 192.168.1.1.

Todos los clientes de la red deben utilizar el servidor DNS local como servidor principal de DNS; o bien, si el equipo está actuando de enrutador entre la red local e internet, redireccionar todas las peticiones salientes hacia el puerto UDP 53 (DNS) hacia nuestro servidor DNS local. De esta forma aunque se intenten conectar a un DNS externo a la red, se están conectando en realidad al DNS local.

Esta redirección de puertos se hace muy facilmente con iptables:

iptables -A PREROUTING -t nat -i eth1 -p udp --dport 53 -j DNAT --to 192.168.1.1:53

Incluso se podría conseguir lo mismo realizando unos ajustes en la configuración del router ADSL.

El proxy caché HTTP no es necesario a priori, pero sí recomendable si queremos poder analizar el tráfico que se utiliza en nuestra red y poder tomar acciones sobre ello. Más adelante profundizaré en este tema.

Redireccionar un servidor a otro:

En ocasiones tengo jugado a algún juego online en servidores privados, lo que normalmente se consigue modificando el archivo C:\Windows\System32\drivers\etc\hosts de Windows (burda copia de los sistemas UNIX de /etc/hosts) haciendo que cierto dominio apunte a cierta IP en lugar de hacia la IP real. El problema es que muchos juegos verifican si se ha modificado este fichero y no te dejan continuar.

Lo que vamos a hacer es esta misma modificación pero directamente desde la configuración del dnsmasq.

En mi caso particular, tengo probado el juego Lineage 2 (cuyo cliente puedes descargar gratuitamente) y jugado en el servidor privado de Guerreros del caos cuya IP es 88.198.49.101.

Modificamos el archivo /etc/dnsmasq.conf añadiendo lo siguiente:

address=/l2testauthd.lineage2.com/88.198.49.101
address=/l2authd.lineage2.com/88.198.49.101
address=/nprotect.lineage2.com/216.107.250.194

Reiniciamos el servicio:

/etc/init.d/dnsmasq restart

Y probamos si funciona:

debian:/# host l2authd.lineage2.com
 l2authd.lineage2.com    A    88.198.49.101
 !!! l2authd.lineage2.com A record has zero ttl
debian:/#

Excelente, se nos indica también que se obtiene una respuesta inmediata (TTL=0, lo que muy probablemente implica que está siendo suplantada ).

Si probamos a instalar ahora el juego en cualquier ordenador de la red y lo ejecutamos tal cual (sin modificar el archivo hosts) veremos que se conecta correctamente al servidor de Guerreros del caos en lugar de al servidor original de NCSoft.

Filtrar publicidad de páginas web:

Aunque existen plugins para Mozilla Firefox para evitar ver la publicidad de las páginas web, esto no evita que se consuma ancho de banda descargando dichos anuncios.

Toda mi red está pasando por un proxy caché transparente squid. Actualmente uso tres analizadores de logs de squid para sacar conclusiones:

1. SquidGraph: Genera gráficas del uso de ancho de banda, peticiones cacheadas y sin cachear etc… Se ejecuta cada minuto y lo utilizo para sacar datos instantáneos de consumo de ancho de banda en la red.
2. Calamaris: Genera informes agrupados de efectividad del proxy, dominios más visitados, ancho de banda consumido y numero de peticiones por tipo de archivo, dominio, cliente, etc…
3. Sarg: Genera informes detallados de todas las páginas visitadas por cada cliente, esto permite ver muy detalladamente donde ha navegado cada uno. Aunque puede suponer una violación de la intimidad en mi caso no lo utilizo con esos fines, sino para observar el volumen de peticiones segun cada dominio.

Mi padre es asíduo visitante de páginas como As, Marca o El País y suele dejar el pc encendido con las páginas cargadas todo el día. Curiosamente todas estas páginas pertenecen a la misma empresa, Prisacom. Pues bien, revisando el top 10 de dominios más visitados me encontré con lo siguiente (extraído del log de ayer):

He marcado en rojo aquellos dominios que me llamaron mucho la atención. Investigando cada uno de ellos ví que unos eran gestores de estadísticas (207.net y wunderloop.net), que premiumtv.co.uk era la televisión online que utilizaba As para sus videos y que prisacom era la empresa que poseía dichas webs.

Pero detrás de todo esto hay mucho más, resulta que el numero de peticiones es una burrada, estan marcados en verde el número de peticiones web. Utilizando el log de Sarg pude ver miles de líneas como las siguientes:

http://petra.prisacom.com/RealMedia/ads/adstream.track/1471560644?
http://ads.prisacom.com/RealMedia/ads/adstream_nx.ads/www.as.com/portada/1987259978@Middle,Position1,Top,x02,x03,x05,x06,x08,x09!x03?
http://tu.connect.wunderloop.net/TU/922/2396/8095/?

http://ds.serving-sys.com/BurstingScript/ebBannerServing_1025909.js

Todas relacionadas con publicidad, en concreto de las dos primeras hay una auténtica salvajada de peticiones, más que de as.com.

Bueno, la primera acción a tomar está clara, hacer que todos esos dominios de publicidad apunten al servidor local. Editamos el archivo /etc/dnsmasq.conf como antes y añadimos lo siguiente:

address=/doubleclick.net/192.168.1.1
address=/ads.prisacom.com/192.168.1.1
address=/safebrowsing-cache.google.com/192.168.1.1
address=/safebrowsing.cache.l.google.com/192.168.1.1
address=/safebrowsing.clients.google.com/192.168.1.1
address=/petra.prisacom.com/192.168.1.1
address=/247realmedia.com/192.168.1.1
address=/2o7.net/192.168.1.1
address=/ads.prisacom.com/192.168.1.1
address=/flashtalking.com/192.168.1.1
address=/serving-sys.com/192.168.1.1
address=/connextra.com/192.168.1.1
address=/wunderloop.net/192.168.1.1
address=/imrworldwide.com/192.168.1.1

De esta forma, todas las solicitudes se realizarán contra nuestro servidor apache. Hay que tener en cuenta que todos los subdominios de los dominios que redireccionemos también estarán redireccionados (si añadimos 2o7.net, también estará añadido ads.2o7.net, por ejemplo…). El problema está (y no tardaréis mucho en daros cuenta si sólo haceis esto) en que no existe ninguna de estas páginas en nuestro servidor. En algunos banners que son de texto se visualiza el error 404 Página no encontrada, cosa que no queda nada bien… además de que se nos inundan los logs con basura y peticiones inexistentes.

Lo que vamos a hacer es crear un dominio virtual en el apache para que atienda todas estas peticiones. Todas las peticiones realizadas contra la IP 192.168.1.1 que no vengan de un dominio que esté en otro host virtual configurado en el apache, serán tratados por esta configuración por defecto (no vamos a incluir el ServerName en las directivas).

En la tabla anterior teneis en color naranja el tiempo que tarda una vez redireccionada la petición (ahora es instantánea) y los bytes que genera (muchísimos menos que antes, sale un promedio de 208 bytes por petición ).

Seguimos, empezamos creando un nuevo archivo en /etc/apache2/sites-availiable/ (por ejemplo ‘default‘) con la siguiente configuración:

<virtualhost 192.168.1.1:80>
 ServerAdmin webmaster@localhost

 DocumentRoot /var/www
 <directory />
   DirectoryIndex index.html
   Options FollowSymLinks
   AllowOverride None

 <directory /var/www>
   DirectoryIndex index.html
   Options Indexes FollowSymLinks MultiViews
   AllowOverride All
   Order allow,deny
   allow from all
 </directory>

 ErrorLog /var/log/apache2/error.log

 # Possible values include: debug, info, notice, warn, error, crit,
 # alert, emerg.
 LogLevel warn

 CustomLog /var/log/apache2/access.log combined

</virtualhost>

Creamos un enlace blando a esta configuración en /etc/apache2/sites-enabled para activar el sitio, y otro enlace blando del módulo rewrite y ya podemos reiniciar el servicio:

debian:/# ln -s /etc/apache2/sites-availiable/default /etc/apache2/sites-enabled/default
debian:/# ln -s /etc/apache2/mods-availiable/rewrite.load /etc/apache2/mods-enabled/rewrite.load
debian:/# /etc/init.d/apache2 restart

Ahora que funciona el servidor (podemos probarlo entrando en http://192.168.1.1), tenemos que crear una página vacía y añadir unas reglas para el mod-rewrite para que cualquier archivo solicitado sea devuelto como un archivo de longitud 0:

debian:/# touch /var/www/index.html
debian:/# vi /var/www/.htaccess

Ahora en el archivo .htaccess escribimos lo siguiente, esto redireccionará cualquier petición al archivo index.html que acabamos de crear:

Options +FollowSymLinks
RewriteEngine on
rewriterule ^.*$ index.html [L]

Ya está, si probamos a abrir ahora alguna de las páginas analizadas por Sarg veremos que devuelve una página en blanco.

Probando con el navegador, por ejemplo, la web de As se ve así (fijaos en la cantidad de Click! Click!):

Listo, ya está funcionando. Con esto también se puede gastar alguna broma o hacer alguna travesura “¡Han hackeado Google!” , “¡Microsoft vende Linux!” , etc…

Espero que os haya gustado.

Índice:

19/07/2009 – Capítulo I – Revisar y mejorar la instalación telefónica de nuestra casa
21/07/2009 – Capítulo II – Parámetros y configuraciones de ADSL, cómo configurar el router para sacar el mayor partido a tu ADSL
28/07/2009 – Capítulo III – Cuando no hay pan, buenas son migas. Si tu conexión es lenta, te interesará saber cómo cachear contenidos para acelerar la conexión a Internet

Para terminar, en esta última entrega hablaremos sobre como intentar hacer un uso eficiente del ancho de banda. La idea general es, teniendo una conexión a internet lenta, tratar de hacer el menor número de peticiones hacia ella y utilizar contenido cacheado para ahorrar ancho de banda.

Para racionar el uso de ancho de banda entre cualquier protocolo, tal y como mencionaba en el anterior capítulo, puede conseguirse usando QoS. En este capítulo vamos a centrarnos en mejorar la navegación Web especialmente, ya que es uno de los principales usos que le daremos a nuestra conexión.

Para conocer como mejorar la navegación debemos conocer como funciona nuestro navegador (en resumidas cuentas):

1. Tecleamos una dirección web en la barra de direcciones.
2. El navegador tiene que utilizar el protocolo DNS (Domain Name System) para resolver que ordenador es el que maneja ese dominio.
3. Tras conocer la IP del ordenador, se conecta a él y hace una petición HTTP (Hyper Text Transfer Protocol) para obtener el contenido de la página.
4. Si la página posee imágenes o enlaces, deberá solicitarlas al mismo servidor (o a otro externo) volviendo al punto 2. Si se trata del mismo servidor generalmente no necesita volver a resolver la IP.

En una página web típica como podría ser la web de Marca, puede haber más de 120 imágenes estáticas repartidas entre varios servidores de contenidos (estaticos[01,02,03,04,05].marca.com), enlaces de publicidad, vídeos, etc…

Esto implica que el navegador tendrá que resolver cada uno de los dominios que alojan los contenidos y tendrá que ir conectándose a cada uno para solicitar los datos y finalmente componer la página web final.

Si hacemos cuentas, una resolución DNS suele tardar alrededor de unos 100 milisegundos (dependiendo de la carga de la red y del servidor), si la web hace referencia a unos 30 dominios distintos, sólo en resoluciones DNS se perderán 3 segundos. Después tiene que conectarse a cada servidor y hacer más de 120 peticiones, añadiendo al propio retraso de la transferencia de las imágenes un pequeño retraso en el manejo del protocolo HTTP.

En definitiva, la web no carga rápidamente. Muchos navegadores son muy competentes y para solucionar esto hacen lo que se llama cacheo de contenidos, es decir, almacenan durante algún tiempo los dominios ya resueltos y el contenido estático para no tener que volver a solicitarlo al servidor.

El protocolo HTTP implementa una serie de controles para marcar la caducidad de los contenidos, el problema es que en muchos casos las páginas web son dinámicas y usan trucos anti-cache para asegurarse de que el contenido que recibe el cliente sea fresco, a costa de consumir un mayor ancho de banda y ralentizar la carga.

Lo que voy a explicar a continuación es cómo montar un servidor DNS local y un proxy caché web. El servidor DNS local nos permitirá hacer cache de las resoluciones DNS durante más tiempo, además, si tenemos una red con varios equipos ahorraremos peticiones desde éstos.

En mi caso tengo montado un equipo en red actuando como servidor de ficheros, proxy web, cache DNS, etc… usando debian GNU/Linux. No es estrictamente necesario tener un equipo destinado exclusivamente como servidor, aunque si te gusta experimentar seguramente podrás conseguir un ordenador entre 400 y 800 Mhz que cumpla con la tarea. Existen más programas que los utilizados en este post, inclusive para Windows, así que si no te convence alguno siempre puedes utilizar otro que se ajuste más a tus necesidades.

Como caché de DNS voy a utilizar dnsmasq, que es un pequeño servidor DNS ligero que implementa caché de DNS por defecto y está en los repositorios de debian:

apt-get install dnsmasq dig

Ni siquiera es necesario modificar la configuración por defecto, a menos que queramos que escuche en una interfaz determinada. Además nos da una serie de configuraciones interesantes:

vi /etc/dnsmasq.conf

address=/doubleclick.net/127.0.0.1
address=/router/192.168.1.1

Podemos bloquear ciertos dominios que sabemos que sólo aportan publicidad para que el navegador no consiga conectarse a ellos, también podemos asignar un nombre de dominio a nuestro router o, si tenemos un dominio propio, hacer que los equipos de dentro de la red resuelvan la IP local del servidor en lugar de la de Internet.

Modificamos el archivo /etc/resolv.conf para utilizar nuestro servidor DNS:

nameserver 127.0.0.1

Y probamos que funcione:

jdf@debian:/tmp$ date
Tue Jul 28 12:21:16 CEST 2009
jdf@debian:/tmp$ dig terra.es

; <<>> DiG 9.5.1-P2 <<>> terra.es
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51021
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;terra.es.            IN    A

;; ANSWER SECTION:
terra.es.        24419    IN    A    213.4.130.210

;; Query time: 72 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 28 12:21:25 2009
;; MSG SIZE  rcvd: 42

jdf@debian:/tmp$ date
Tue Jul 28 12:22:18 CEST 2009
jdf@debian:/tmp$ dig terra.es

; <<>> DiG 9.5.1-P2 <<>> terra.es
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 84
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;terra.es.            IN    A

;; ANSWER SECTION:
terra.es.        24363    IN    A    213.4.130.210

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 28 12:22:21 2009
;; MSG SIZE  rcvd: 42

jdf@debian:/tmp$

Indiscutiblemente, mucho mejor con el cache DNS.

El proxy caché web que vamos a utilizar es squid. También está disponible en los repositorios de debian  e incluso hay versiones portadas a Windows. Se trata de un proxy HTTP altamente configurable y muy utilizado a nivel empresarial.

squid es muy flexible, nos permite hacer un proxy HTTP que no haga cache (sólo para controlar que páginas se visitan y generar estadísticas de uso) o incluso un servidor proxy caché transparente (que cachea todo el contenido de forma transparente para el usuario final, almacenando el contenido incluso durante más tiempo que el indicado por el servidor).

En nuestro caso queremos cachear todo el contenido estático de la web, en general, la mayor parte de las páginas no suelen modificar las imágenes que ya tienen sino que añaden imágenes nuevas o las sustituyen. Existen páginas web que generan contenido dinámico (misma imagen renombrada cada vez que se pide, por ejemplo) evitando que podamos cachearlo. Un ejemplo perfecto de web incacheable es Youtube .

Instalamos el servidor squid y una utilidad para ver como está procesando las peticiones:

apt-get install squid squidview

Y procedemos a configurarlo:

vi /etc/squid/squid.conf

# Primero configuramos el puerto donde va a escuchar el servidor y le indicamos que queremos utilizar un proxy transparente
http_port 8080 transparent
icp_port 3130

# Las ACL (Access lists, Listas de Acceso) definen grupos de IPs a las que se le aplicarán determinados permisos, es crucial tener bien definida la siguiente:
acl all src 0.0.0.0-0.0.0.0/0.0.0.0

# Definimos los nuevos periodos de refresco segun el dominio o el tipo de contenido, probablemente no es la mejor configuración, la modifiqué de otra que encontré en la web en su momento.
# Por defecto el contenido se cacheará durante una semana, ampliable hasta un mes segun el caso
# los modificadores añadidos al final significan lo siguiente:
# override-lastmod -> Ignorar la fecha de última modificación,se utilizará la indicada en la configuración
# override-expire -> Ignorar la fecha de caducidad indicada por el servidor
# ignore-private -> Ignorar las etiquetas que indican que el contenido es privado, se cacheará de todas formas
# reload-into-ims -> Las peticiones que fuerzan la recarga de la página (Control + F5 en Internet Explorer ó Control + Shift + R en Mozilla Firefox) se convierten en peticiones If-Modified-Since, es decir, sólo actualizará si el contenido se ha modificado desde la última vez.
# ignore-reload -> Se ignoran las peticiones de recarga forzada de la página

refresh_pattern windowsupdate.com/.*\.(cab|exe) 4320 100% 43200
refresh_pattern download.microsoft.com/.*\.(cab|exe) 4320 100% 43200
refresh_pattern ^http://.*\.cnn\.com 360 50% 4320 override-lastmod
refresh_pattern ^http://news\.bbc\.co\.uk 360 50% 4320 override-lastmod
refresh_pattern microsoft 1080 150% 10080 override-lastmod
refresh_pattern msn\.com 4320 150% 10080 override-lastmod
refresh_pattern ^http://.*\.doubleclick\.net 10080 300% 40320 override-lastmod override-expire ignore-private reload-into-ims ignore-reload
refresh_pattern ^http://.*\.google-analytics\.com 10080 300% 40320 override-lastmod override-expire ignore-private reload-into-ims ignore-reload
refresh_pattern ^http://.*FIDO 360 1000% 480
refresh_pattern \.r[0-9][0-0]$ 10080 150% 40320
refresh_pattern ^http://.*\.gif$ 1440 50% 20160 ignore-no-cache override-lastmod ignore-private reload-into-ims ignore-reload
refresh_pattern ^http://.*\.asis$ 1440 50% 20160
refresh_pattern -i \.pdf$ 10080 90% 43200
refresh_pattern -i \.art$ 10080 150% 43200
refresh_pattern -i \.avi$ 10080 150% 40320
refresh_pattern -i \.mov$ 10080 150% 40320
refresh_pattern -i \.wav$ 10080 150% 40320
refresh_pattern -i \.mp3$ 10080 150% 40320
refresh_pattern -i \.qtm$ 10080 150% 40320
refresh_pattern -i \.mid$ 10080 150% 40320
refresh_pattern -i \.viv$ 10080 150% 40320
refresh_pattern -i \.mpg$ 10080 150% 40320
refresh_pattern -i \.flv$ 10080 150% 40320 ignore-no-cache override-expire ignore-private reload-into-ims ignore-reload
refresh_pattern -i \.swf$ 10080 150% 40320 override-lastmod ignore-no-cache override-expire reload-into-ims ignore-reload
refresh_pattern -i \.jpg$ 10080 150% 40320 override-lastmod ignore-no-cache ignore-private reload-into-ims ignore-reload
refresh_pattern -i \.rar$ 10080 150% 40320
refresh_pattern -i \.ram$ 10080 150% 40320
refresh_pattern -i \.gif$ 10080 300% 40320 override-lastmod ignore-no-cache ignore-private reload-into-ims ignore-reload
refresh_pattern -i \.txt$ 1440 100% 20160  override-lastmod ignore-no-cache ignore-private reload-into-ims ignore-reload
refresh_pattern -i \.zip$ 2880 200% 40320
refresh_pattern -i \.arj$ 2880 200% 40320
refresh_pattern -i \.exe$ 2880 200% 40320
refresh_pattern -i \.tgz$ 10080 200% 40320
refresh_pattern -i \.gz$ 10080 200% 40320
refresh_pattern -i \.tgz$ 10080 200% 40320
refresh_pattern -i \.tar$ 10080 200% 40320
refresh_pattern -i \.Z$ 10080 200% 40320
refresh_pattern -i \.png$ 10080 150% 40320 override-lastmod ignore-no-cache ignore-private reload-into-ims ignore-reload

# Estos son los patrones de refresco por defecto segun el protocolo utilizado, es muy importante dejar el último con un retraso de 0, sino puede suceder que las páginas web dinámicas no se actualicen correctamente
refresh_pattern ^ftp:// 1440 50% 10080
refresh_pattern ^gopher:// 1440 10% 1440
refresh_pattern . 0 20% 4320

# Recordamos las páginas web que dieron error al intentar solicitarlas
negative_ttl 1 minutes
positive_dns_ttl 15 hours
negative_dns_ttl 1 minutes
half_closed_clients off

# Definimos ciertas listas de acceso para dominios que queremos intentar cachear
acl youtube dstdomain .youtube.com
acl youtubeip dst 64.15.112.0/24
acl youtubeip2 dst 74.125.15.0/24
acl googlevideo dstdomain .googlevideo.com
acl imageshack dstdomain .imageshack.us
acl router dst 192.168.1.1

# Permitimos cachear estas listas de acceso
cache allow youtubeip
cache allow youtubeip2
cache allow youtube
cache allow googlevideo
cache allow imageshack

# Evitamos cachear la web del router, por ejemplo
no_cache deny router

# Modifico la cabecera User-Agent para que parezca que todos los equipos de la red utilizan Linux
header_access User-Agent deny all
header_replace User-Agent Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.0.11) Gecko/2009060309 Ubuntu/9.04 (jaunty) Firefox/3.0.12

# Podemos indicarle a squid que cachee los contenidos en base al tipo de objeto MIME, estas configuraciones pueden guardarse en un archivo externo, como es el caso:
acl CACHEMIME rep_mime_type -i “/etc/squid/cache_mime.lst”

# De las configuraciones que utilizamos antes, algunas violan el protocolo HTTP, así que es posible que tengamos problemas de fresco con determinadas páginas web. Para subsanarlo creamos un archivo con una lista de dominios que no queremos cachear. En mi caso me he topado con que as.com y elpais.com dan problemas con el caché.
acl NOCACHE dstdomain “/etc/squid/nocache.lst”

cache allow CACHEMIME
no_cache deny NOCACHE

# Aquellas páginas web que sean dinámicas (esten en cgi-bin o tengan parámetros) no se cachean nunca
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY

# Le indicamos que muestren los mensajes de error en Español
error_directory /usr/share/squid/errors/Spanish

# Bloqueamos algunas cabeceras HTTP para que no se note que estamos utilizando un proxy:
header_access X-Cache deny all
header_access X-Cache-Lookup deny all
header_access X-Cache-Hit deny all
header_access Via deny all
header_access X-Forwarded-For deny all

# Usamos 128 Mb de memoria
cache_mem 128 MB
cache_swap_low 90
cache_swap_high 95

# No se cachearan contenidos mayores de 64 Mb
maximum_object_size 65535 KB

# La caché en disco podrá ocupar hasta 15 Gb
cache_dir ufs /var/spool/squid 15000 16 256

# Sólo queremos el log de acceso
cache_access_log /var/log/squid/access.log
cache_log none
cache_store_log none

El resto de configuración del squid puede dejarse por defecto, más que nada quería centrarme en aquellos parámetros menos comunes.

Para poder ver si funciona el proxy, debemos configurarlo en los navegadores en las opciones de conexión, o si tenemos el servidor haciendo NAT entre el router y el resto de la red, redirigir las peticiones al puerto HTTP 80 hacia el puerto de nuestro proxy.

Desde consola usando squidview podemos ver la efectividad de las peticiones:

168.1.2          www.softonic.com/
168.1.2     m  www.softonic.com/linux
168.1.2     R  www.softonic.com/specials_leaderboard/home/910

Recomiendo consultar la página web oficial para entender los datos que se muestran por pantalla.

Si queremos generar estadísticas diarias de la efectividad del proxy recomiendo utilizar calamaris (también disponible en el repositorio de debian) que genera un informe muy detallado con el ratio de efectividad del proxy, porcentaje de ahorro de ancho de banda, dominios más consultados, etc…

Aquí podeis ver la sección de resumen del informe que genera:

Si probamos a navegar a través del proxy notaremos que tiene mucha más fluidez y menos latencia. Las páginas cargan casi instantáneamente y el contenido dinámico se actualiza bien. Esto se debe a que la mayor parte del tráfico de la página, especialmente todo el contenido estático (imágenes, flash, etc…), nos lo sirve nuestro servidor proxy sin tener que conectar al servidor real; sólo es necesario actualizar el código html de la página, que es realmente lo que varía.

Y bueno, hasta aquí pretendía llegar, si has conseguido leer los tres capítulo te felicito, me temo que han sido bastante extensos (espero que no fuesen espesos ).

Si tienes cualquier duda no dudes en preguntar. Espero que estos consejos le sean útiles a alguien (aparte de mí mismo, claro xD), si es así agradecería que me dejases un comentario.

P.D.- Por petición popular, en unos días liberaré el código fuente completo del script que almacena datos estadísticos del router de Ya.com. Puede ser adaptado para funcionar con cualquier router, puliré un poco el código fuente y será publicado bajo licencia GPL. Con él puedes intentar diagnosticar cual es el origen de tus problemas basandote en los horarios, así como poder reclamarle a tu operadora cualquier tipo de incidencia con datos reales. No lo publico directamente aquí porque creo que el capítulo ha sido suficientemente extenso.

Índice:

19/07/2009 – Capítulo I – Revisar y mejorar la instalación telefónica de nuestra casa
21/07/2009 – Capítulo II – Parámetros y configuraciones de ADSL, cómo configurar el router para sacar el mayor partido a tu ADSL
28/07/2009  – Capítulo III – Cuando no hay pan, buenas son migas. Si tu conexión es lenta, te interesará saber cómo cachear contenidos para acelerar la conexión a Internet

Continuando con el anterior capítulo, en éste nos centraremos en aspectos más teóricos sobre la conexión ADSL, la calidad de la línea y los parámetros que intervienen en ella.

Como primer punto de partida, para conocer más a fondo como estás conectado a internet desde la central de tu operadora hasta el PTR de tu casa, te recomiendo que visites el foro de ADSL Pro, ya que explica de forma muy precisa y con imágenes como se hacen todas las conexiones. Si el enlace fallase, en el siguiente enlace tienes un PDF con el mismo post sobre las instalaciones de ADSL en una compañía telefónica (Sala OBA, DSLAM, Repartidores, etc…) (¡OJO! 3,6 Mb de tamaño).

Esta bien saber todo esto para que cuando te hagan alguna oferta de otra compañía no te cuelen goles como que “ellos tienen unos servidores más nuevos que no estan saturados como los de Telefónica y por eso te pueden ofrecer más velocidad” cuando en realidad prácticamente la totalidad de las líneas ADSL son alquiladas a Telefónica. Como mucho pueden tener un equipo DSLAM propio para poder dar ofertas de bucle totalmente desagregado, pero aun así en cuanto a prestaciones pocas diferencias hay con Telefónica.

Volviendo al tema, voy a utilizar como ejemplo mi propia línea de ADSL que ha resultado ser un espécimen interesante. Estoy a más de 6 Km de la central (tengo suerte de tener ADSL, Telefónica no instala a más de 4,5 Km de la central, en mi caso la tengo desde que la velocidad estándar eran 128 Kbps), tanta distancia afecta a la señal emitida por la central, es decir, se atenúa y pierde fuerza.

La atenuación se mide en decibeles (db) que es una escala logarítmica, lo que significa que si tenemos una atenuación de 10 db, la señal que llega es 10 veces menos potente que la que envió la central, con 20 dB la señal es 100 veces menos potente, etc…

En mi caso teniendo el router en otra habitación la atenuación era de 63 ó 64 db (la señal llega más de un millon de veces más débil), tras conectarlo al PTR, conseguí bajarla a 61 db, y tras el cambio de Telefónica a Ya.com Total (bucle totalmente desagregado de Telefónica) bajó a 59 db. Esta última mejora puede deberse al cambio de cableado dentro de la sala OBA, probablemente el cable es de más calidad o sencillamente es más corto. Todas estas medidas las he corroborado con dos routers, un Zyxel 660HW y un Conceptronic C54APRA2+. Me hizo mucha gracia el día que instalé el router SMC7908A-ISP de Ya.com porque marca una atenuación de 67 db, sigo con la duda de si es que mide mal o que los circuitos internos estan hechos con alambres del pan bimbo.

En cualquier caso es una atenuación bestial y la distancia no ayuda tampoco con los problemas de ruido en la línea. Cuanto más distancia exista, más posibilidades hay de que aparezcan inducciones de señales aéreas o de campos electromagnéticos cercanos al cableado. Además el propio cableado introduce una cierta resistencia que se hace más notable por cada Km de distancia a la central. Para medir el ruido de la linea se utiliza generalmente un índice llamado SNR (Signal to Noise Ratio, Índice de Señal/Ruido) que mide precisamente la relación entre la frecuencia de la señal y el ruido de la línea; se expresa también en decibeles.

El ruido de la línea normalmente es constante, aunque puntualmente por dilataciones del cable en verano o problemas en el entramado público (obras, cables que pasan cerca de otros con corriente, etc…) puede verse aumentado a algunas horas del día.

La frecuencia a la que trabaja el router es precisamente el sincronismo que se negocia con el DSLAM, a mayor frecuencia, mayor velocidad, pero también aumenta la sensibilidad al ruido latente en la línea.

Un ejemplo rápido: Si el router sincroniza a 512 Kbps y el SNR tiene un valor de 18 db, es muy probable que se pueda alcanzar una velocidad mayor. Si resincronizase a 1024 Kbps, probablemente el SNR habría caido hasta los 12 db, aproximadamente. Cuanto más alto sea el valor del SNR, mejor. El límite del SNR está en torno a los 8 db, por debajo de ese valor es prácticamente imposible mantener el sincronismo y la velocidad cae, el router resincroniza de nuevo una frecuencia más baja. Cuando se alcanza un SNR de 8 db se considera que se ha llegado al límite posible de la línea en ese momento (siempre que el ruido no aumente o disminuya).

Otro factor importante es el protocolo que estemos usando, no es lo mismo usar G.992.1 (G.DMT)  que se utiliza para sincronizar en modo ADSL normal a utilizar G.992.5 (ADSL2+) que utiliza la nueva tecnología ADSL2+. A grandes rasgos, las principales diferencias entre ADSL normal y ADSL2+ son que el límite de velocidad máximo teórico del ADSL normal está en 8 Mb y del ADSL2+ en 24 Mb; esto se consigue gracias a que ADSL2+ utiliza frecuencias muy superiores a las del ADSL normal, lo que lo hace más óptimo para distancias cortas, en larga distancia pueden obtenerse incluso peores resultados; y por último, que el ADSL2+ incorpora una serie de algoritmos para la recuperación de errores en los paquetes de datos, cosa que en el ADSL normal sencillamente se pierden.

Por tanto, concluimos con que lo ideal sería tener una atenuación lo más baja posible, un SNR lo más alto posible y, según la distancia, intentar utilizar G.992.5 (ADSL2+).

Volviendo al ejemplo de la vida real, mi ADSL, está justo al revés. La atenuación de 60 db se corresponde con una distancia de 4,5 Km con la central (hasta he tenido suerte); el SNR suele rondar valores entre 7 y 14 y la velocidad máxima obtenida era de 1024 Kbps con Telefónica (el límite contratado) y 1396 Kbps con Ya.com (usando el router Conceptronic, con el SMC no pasó nunca de 1208 Kbps). Utilizo normalmente ADSL normal ya que tengo contratado un plan de 10 Mb de los cuales apenas llega 1 Mb, asi que el límite máximo del ADSL de 8 Mb no es mucho problema, si utilizo ADSL2+ la velocidad de sincronismo cae entre 150 y 200 Kbps en relación con el ADSL normal. El hecho de tener contratado 10 Mb en lugar de 3 Mb, es porque la diferencia son 2 euros al mes y la velocidad de subida pasa de 256 a 512 Kbps (normalmente alcanzo velocidades de subida entre 480 y 512 Kbps, muy estable, lo que me deja un ADSL bastante simétrico).

El siguiente gráfico detalla los valores esperados segun la distancia a la central y el protocolo utilizado:

Segun vuestros valores de atenuación y SNR podeis saber si teneis una velocidad anormalmente baja, la correcta o incluso superior a la esperada. Tened en cuenta que incluso dos pisos del mismo edificio pueden tener diferentes velocidades, ya que cada uno tiene su par de cobre único y personal.

Como último dato, he montado una serie de servicios en mi red para guardar un histórico de todos los cambios de estado en la conexión a internet. Hay un script que se ejecuta automáticamente cada 5 minutos y guarda los valores de modo de sincronismo, velocidad, atenuación y SNR actuales. La razón para hacer esto es que la velocidad fluctua muchísimo, en ocasiones es muy estable y en otras tiene bajones importantes, el siguiente gráfico lo deja muy patente:

Algo que he implementado en este script (que es justo lo que el DSLAM no hace), es tratar de volver a subir la velocidad si el SNR lo permite. Si se detecta un SNR igual o superior a 13 db, intenta resincronizar para obtener una mejor velocidad. Es justo lo contratio a lo que hace el DSLAM cuando el SNR baja de 8 db. Aqui podeis ver una tabla con datos reales de la velocidad a la que sincronizó el ADSL, y vereis como en algunos casos mejora la velocidad porque el SNR tiene margen (en la gráfica superior son los escalones que suben progresivamente):

Se marca en texto rojo los SNR inferiores a 8 db, el resto de lineas tienen el color de fondo según la velocidad de descarga.

Poco más queda comentar sobre la configuración del ADSL propiamente dicho, a nivel interno de la red y siempre que el router lo permita, puede resultar interesante configurar un servicio QoS (Quality of Service, Gestión de Calidad del Servicio) para darle prioridad da determinados protocolos de red. Esto permitiría por ejemplo priorizar el tráfico web sobre el tráfico generado por programas P2P. No supone una mejora real en la velocidad a la que sincroniza el ADSL, pero permite gestionar el ancho de banda disponible según nuestras prioridades. El tema es muy extenso y existe mucha información en la red, si crees que necesitas implementarlo te recomiendo que empieces por la Wikipedia: QoS – Calidad del Servicio.

El último capítulo de esta entrega tratará sobre algunas optimizaciones que podemos hacer en la red para ahorrarnos consumir ancho de banda inútilmente y reducir la latencia. Probablemente la mayor parte de los usuarios que vivan en zonas urbanizadas no requieran llegar a este extremo, pero para muchos otros que tenemos un acceso a internet mucho más limitado, creo que puede resultar muy interesante.

Índice:

19/07/2009 – Capítulo I – Revisar y mejorar la instalación telefónica de nuestra casa
21/07/2009 – Capítulo II – Parámetros y configuraciones de ADSL, cómo configurar el router para sacar el mayor partido a tu ADSL
28/07/2009 – Capítulo III – Cuando no hay pan, buenas son migas. Si tu conexión es lenta, te interesará saber cómo cachear contenidos para acelerar la conexión a Internet

Como a la mayoría, si eres cliente de una línea de ADSL te habrás dado cuenta de que la velocidad real que alcanza la conexión muchas veces dista bastante de lo contratado con la operadora. Esto empezó a notarse cuando se popularizaron las ADSLs con velocidades superiores a los 3 Megas, especialmente con las famosas ofertas hasta 20 Megas…

Hay muchísimas causas que afectan a la velocidad final que se obtiene de una línea ADSL. Hay factores tanto internos a nuestra casa como externos; en esta primera entrega trataré de explicar cuales son las más comunes y cómo mejorar  la instalación telefónica de nuestra casa a fin de conseguir la mayor velocidad posible.

Factores externos que afectan a la velocidad:

• La distancia a la central o nodo auxiliar al que te conectas

Este es uno de los principales problemas, y además es insalvable. Cuanto más lejos estemos menos velocidad tendremos y más problemas de conexión, microcortes, oscilación de la velocidad de sincronismo, etc…

• La calidad del cableado de la red de telefonía

Existen líneas de teléfono aun en activo que tienen más de 60 años de antigüedad. El cobre de dichos cableados en muchas ocasiones está quemado o ha perdido gran parte de sus propiedades, lo que deteriora la calidad de la señal. También puede suceder que existan diferentes tramos de cableado con distintos grosores y calidades, estas variaciones también afectan al rendimiento del ADSL.

• Fallos en el aislamiento del cableado

No me refiero únicamente a cables que hayan sido dañados o hayan perdido parcial o totalmente su aislamiento. En muchos casos en plena ciudad a menos de 1 Km de la central hay grandes problemas de velocidad y en ocasiones se deben a obras en la calle que juntan cables eléctricos demasiado cerca de los telefónicos creando señales parásitas o incluso empalmes mal hechos, cajetines de telefónica sin aislante o abiertos, etc…

• El contrato que tengamos con nuestra operadora de telefonía

Sí, suena de perogrullo pero no será la primera ni la última vez que pase. No me refiero sólo a que si tenemos contratados 3 Mb no llegaremos a 10 Mb sino, a que en muchas ocasiones los contratos tienen letra pequeña acerca de lo que el cliente puede o no puede hacer (Ya.com por ejemplo no permite el uso de otro hardware que no esté homologado por ellos) aparte de las típicas clausulas mencionando el acceso a determinados contenidos penados por la ley etc… En algunos casos como por ejemplo en los famosisimos modem usb conectacte-donde-cuando-y-como-quieras que SIEMPRE tienen límites de descarga (entre 2 y 3 GB) a partir de los cuales o reducen la velocidad drásticamente o cobran una animalada por cada Mb adicional descargado.

• El protocolo de comunicaciones que se utilice

Entre nuestra operadora y nuestro router se utiliza un protocolo de comunicaciones, generalmente ATM, que tiene un cierto porcentaje de consumo de ancho de banda para gestion de la línea. En la mayoría de los casos, sobre dicho protocolo se encapsula otro: PPOA (IP over ATM), PPOE (PPP over ATM), etc… Es algo muy técnico y que no podemos cambiar, pero dependiendo del que se use nuestro operador, una parte se derrochará n el protocolo encapsulado o no (el más óptimo es PPOA).

También debemos tener en cuenta que para poder navegar por internet y descargar cosas tenemos que utilizar el protocolo TCP/IP (entre otros); llegando a ocupar hasta un 20% del ancho de banda disponible sólo en protocolos de red. Éstos son necesarios para gestionar el origen y destino de los paquetes, contadores de errores, reenvio de paquetes perdidos, etc…

Factores internos que afectan a la velocidad:

• La calidad del router que estemos utilizando

Comprobado personalmente: no es lo mismo un Zyxel, que un Conceptronic o un marca Nisu (Ni su padre lo conoce a la hora de comer…) que te entrega tu operador. En mi experiencia, tras un cambio de Telefónica a Ya.com, el router Zyxel que tenía con telefónica da unos mejores valores y velocidades que un Conceptronic (por poco, son bastante parecidos) y muchísimo mejores que el SMC que entrega Ya.com.

• Donde está conectado el router en nuestra casa

La posición ideal es justo al lado del PTR, con un cable lo más corto posible. Si lo tenemos conectado en otra habitación, hemos de tener en cuenta que al tener mucho cableado telefónico por la casa actúa como antena de radio y se ve influenciada por multitud de ondas electromagnéticas que inducen ruido en la señal.

• El uso de microfiltros o de splitter

El ADSL que tiene la línea telefónica multiplada con la de ADSL necesita separar en dos rangos de frecuencias la voz de los datos. Para lograr esto se utilizan unos microfiltros en los teléfonos o bien se sustituye el PTR por un Splitter. En cualquier caso, el Splitter proporciona una mejor calidad, pero puede suponer tener que instalar nuevo cableado. Mientras que los microfiltros se instalan en cada teléfono, el Splitter se instala en la entrada de la casa separando en dos líneas la línea de teléfono de la de datos; es decir, todos los teléfonos de la casa se conectan directamente sin microfiltro a las rosetas de la pared y el router tiene que conectarse a un conector específico que tiene el Splitter (en caso de querer tener el router en otra habitación, habría que cablear desde el Splitter hasta dicha habitación).

• El cableado telefónico de la casa

A parte de referirse a la antigüedad en años o al grosor y calidad del cable en sí, influye muchísimo si el cable pasa por el mismo tubo corrugado por donde pasen cables eléctricos (Esto va contra la normativa europea de instalaciones eléctricas de bajo voltaje, pero en muchos hogares está así). El cable eléctrico genera un campo electromagnético que induce ruido en la señal que va por el cable telefónico.

• El PCR, PTR ó Splitter

A efectos legales, el PCR es lo mismo que un PTR o un Splitter, sirve para dividir las responsabilidades en caso de haber un problema en la instalación. Desde la calle hasta el PTR es responsabilidad de la operadora, del PTR en adelante es responsabilidad del cliente. El PCR es una versión antigua del PTR, de hecho, son exactamente iguales sólo que éste último no trae un circuito para probar la línea de teléfono. Este circuito se eliminó porque generaba problemas con el ADSL. El Splitter sería una versión mejorada del PTR, pero que en muchos casos no se instala salvo que lo solicite el cliente, ya que supone una pequeña inversión, generalmente más que uno o dos microfiltros.

• El sistema operativo que estemos utilizando en nuestros equipos

Y no me refiero a que pueda estar infectado por virus o algo así, sino a que a bajo nivel, las pilas de red de diferentes sistemas operativos dan diferentes rendimientos. Por ejemplo, personalmente he verificado que la pila de Linux es mucho más efectiva que la de Windows. Una prueba sencilla, poned dos equipos en una misma red a descargar el mismo archivo de una red P2P, en muchos casos Linux deja sin ancho de banda a Windows.

Conclusión:

Para tener la instalación de nuestra casa optimizada al máximo, deberíamos tener instalado un Splitter en lugar de un PTR (siempre y cuando la línea telefónica vaya multiplada con la de ADSL; osea, el teléfono no funciona por VOIP) y el router directamente conectado a él. Cablearíamos un cable de red RJ45 hasta la habitación donde tengamos los equipos o bien hasta un sitio donde tengamos isntalado un switch de red con el que dar conectividad a todos los equipos de la red. Desde aquí recomendamos por lo menos probar una distribución de GNU/Linux (personalmente para usuarios poco experimentados recomiendo Ubuntu y para gente con más conocimientos debian) para obtener mejores resultados tanto de navegación como de descargas.

El resultado debería ser algo así:

Espero continuar en breve con el siguiente capítulo, que será algo más largo que este, me temo.