El proxy de $peedy

Hace ya varios meses que los sufridos usuarios de $peedy tenemos problemas de navegación. No solo por culpa de el mal estado de las lineas telefónicas, que impiden en una gran proporción de casos que la velocidad que uno contrata no puede ser cumplida, sino también por un artilugio utilizado por la monopólica Telefónica de Argentina para reducir el consumo de ancho de banda de los enlaces de datos que unen a esta empresa con el resto de la Internet.
Este ahorrador tiene nombre y apellido. Se llama proxy y se identifica como NetCache. Este software tiene los días contados. La empresa que originalmente lo programó, NetApp lo ha vendido a Blue Coat, quienes han dejado de venderlo desde enero de este año y le puso fecha de defunción para el 12/11/2009. Asi que aun nos quedan unos dos años de sufrimiento.

¿Que hace el NetCache y en que nos perjudica?

En términos sencillos, NetCache es un programa que se mete en el medio de nuestras comunicaciones en la web, va almacenando las páginas que vemos y cuando otro usuario (o nosotros mismos) quiere ver la misma página, nos muestra la copia que guardó en vez de la página tal y como está en el servidor web remoto.
Si funcionara bien, no nos perjudicaría en casi nada. Pero como ocurre lo contrario, lo mas habitual es encontrarse con problemas para ver las páginas en sus versiones mas recientes, o, como viene ocurriendo muy seguido, directamente nos muestra páginas en blanco o nos da errores de página no econtrada.
Y un problema grave para los que cada tanto nos bajamos algúna que otra imágen de DVD de distribuciones de GNU/Linux, no nos deja transferir por http archivos de tamaños mayores a los 2 Gb.

¿Por qué se producen estos problemas?

Si ud., estimado lector, no entiende nada de servidores web, paquetes tcp/ip, headers y requests, la respuesta es: porque $peedy no sabe configurar el NetCache y sus propios servidores DNS funcionan para la mierda.
Dese por contento con esta explicación y evítese una larga lectura que no va a entender.

¿Como saber si nuestra conexión tiene al NetCache metido en el medio?
Abriendo una consola de comandos y escribiendo telnet dirección_IP 80, siendo dirección_IP una IP que no pertenezca a nuestro rango privado, si estamos tras un NAT. Si se conecta con “algo”, ese algo es el NetCache. Si no lo tenemos en el medio, nos dirá que no puede conectarse al servidor remoto.
A efectos mas prácticos, la IP que utilizaremos será 1.1.1.1 y el comando quedaría telnet 1.1.1.1 80
Si estamos afectados por el proxy, veremos esto:

Connected to 1.1.1.1.
Escape character is ‘^]’.

Caso contrario, dirá “Unable to connect to remote host”

A partir de aquí, las explicaciones para los que conocen un poco de estos temas.
Agradezco enormemente a Hernán “LocoDelAssembly” Pereira, quien aún no tiene un blog para linkear pero que está en proyecto, por el trabajo que se tomó para resumirme en estas lineas algo tan complejo como esto. Asi que los aplausos para el y los palos, si algo está mal, para mi.

El NetCache funciona escencialmente como un server HTTP con la salvedad de que tiene capacidad de hacer “relay” de tu request HTTP. Este relay tiene algunas diferencias con respecto a mandar el request al server destino directamente. La primera es que si el cache del proxy puede satisfacer el request entonces utiliza este para enviar la respuesta y segundo, si el cache no pudo satisfacer el request, el proxy inicia entonces una conexión al server destino y realiza el request solicitado. Este request es armado por el proxy y por lo tanto no tiene necesariamente una equivalencia bit a bit con el original (pero mantiene la semántica del mismo).

¿Como determina NetCache donde está el server destino?

Un request HTTP es un mensaje compuesto por (entre otras cosas) headers de control y cada uno de estos sirve para un propósito específico. El header interesante para este caso es el header Host ya que este es el que determina a que server va dirigido el request. Entonces supongamos que tenemos una conexión TCP puerto 80 establecida con la IP 1.1.1.1 y nuestro navegador envía el siguiente mensaje:

GET / HTTP/1.1\r\n
Host: www.google.com\r\n

\r\n
(Nótese que \r\n es retorno de carro y avance de línea como en el lenguaje C)

¿Entonces a dónde se conectará el proxy? La IP a la que nos conectamos (1.1.1.1) es inválida y no pertenece a nadie, sin embargo obtenemos una respuesta exitosa de algún server de Google al hacer eso. ¿Qué es lo que hizo el proxy entonces? Utilizó sus propios DNSs consultándolos con el valor con el que fue enviado el header Host. Nótese que esto ocurre SIEMPRE, no importa si la IP a la que nos conectamos ya pertenecía a Google, el proxy aunque experto el en el arte del IP spoofing, resulta completamente ignorante de las capas inferiores a la hora de trabajar con HTTP y para él el método utilizado para alcanzar el server destino es utilizando la información de control HTTP y resolviendo con DNSs en caso de que en vez de venir una IP (muy poco usual), venga un nombre de host (casi 100% de los casos).

Se habló del header Host como el header utilizado por el proxy para determinar el server destino pero en realidad no es aplicable en las siguientes 2 situaciones:

1) Cuando en la primer línea del mensaje HTTP viene una URL completa. En este caso toma prioridad esta y se ignora el header host (nótese que entonces el header host enviado por nosotros nunca es visto por el server destino sino que es armado por el proxy a partir de la URL)
Si hacemos:

GET http://www.speedyapesta.com.ar/ HTTP/1.1\r\n
Host: www.google.com\r\n
\r\n

Recibimos respuesta desde SpeedyApesta en vez de Google. Nótese que en realidad utilizando HTTP/1.0 o HTTP/0.9 (el cual consiste en GET seguido de la path o URL completa seguido de \r\n y nada más), también se utiliza el host indicado en la URL sobre cualquier otra cosa.

2) Cuando se utiliza HTTP/1.0 o HTTP/0.9 y es omitido el header Host aprovechando que el primero no lo pone como obligación, no como HTTP/1.1 que si lo hace y en el segundo no existen los headers directamente. Cuando se da esta situación y la primera línea del mensaje no contiene una URL completa tampoco, entonces ahí si se utiliza la IP provista por capa de red (la IP de destino de nuestros paquetes).
Desafortunadamente no solo los navegadores no omiten este header sino que encima resulta impráctico ya que muchísimos hostings
(escencialmente los que utilizan virtual hosting o VHOST) dependen de este header. El hosting de SpeedyApesta mismo requiere este header, de lo contrario vamos a parar a una página por default del proveedor de hosting.

Este comportamiento del NetCache agrega los siguientes efectos secundarios indeseados:

1) Ante la falla de los servers de DNS utilizados por el proxy nosotros pagamos el precio ya que no es utilizada la información de
capa de red como último recurso y por lo tanto el proxy gentilmente corta la conexión dando la apariencia involuntaria de ser una
respuesta HTTP/0.9 válida de 0 bytes.

2) Servicios como “Typo Correction” de OpenDNS no funcionan. La razón es que aunque los servers de DNS de OpenDNS nos dirigen a sus webservers cuando tipeamos mal, luego los proxies NO utilizarán los DNSs de OpenDNS sino que los suyos propios como siempre y como estos no hacen lo mismo la conexión será cortada y nuevamente navegadores como Mozilla Firefox u Opera identificarán esto como una respuesta HTTP/0.9 válida (Internet Explorer no los considera válidos y por lo tanto muestra página de error). Nótese que la razón por la cual welcome.opendns.com da siempre “oops” por más correcta sea nuestra configuración es por esta misma razón.

Resumiendo, el NetCache, para determinar el server destino, lo hace de igual manera que lo haría un proxy opaco, con la salvedad de que se valdrá de la capa de red cuando el mensaje HTTP no ofrezca información acerca del host (server HTTP) destino.

Resta poder determinar exactamente cuales son todos los motivos por los que los proxys devuelven páginas vacias. Sabemos que muchas de estas fallas son culpa de resoluciones DNS fallidas de los propios DNS de $peedy, pero no estamos del todo seguros que sea únicamente por eso. Sabemos que cuando no existe el dominio o cuando ocurre un time out (más de 2) o server failure (este caso es altamente sospechado de generar páginas en blanco en el acto), obtenemos página en blanco y que hasta llega a quedar cacheado el error, pero por el momento no sabemos con certeza si las páginas en blanco y el cacheo de las mismas se deben SOLO a problemas de DNS.
Por ejemplo, ¿que ocurrirá si el webserver rechaza la conexión del proxy una sola vez? ¿Quedará cacheado por unos minutos o volverá a probar suerte en nuestro próximo reintento o tal vez reintente solo como parece hacerlo cuando ocurren time outs de TCP?
Dicho sea de paso, en este momento que estoy escribiendo este párrafo, estoy haciendo la prueba de mandar como header
Host el mismo que fue utilizado en el thread de “Pool de DNSs de los proxies” y NO me está cacheando el error (pero la versión de NetCache sigue siendo la misma que desde entonces).

Al principio hablamos de que el proxy arma su propio request para ser enviado al server pero no se comentó que ocurre en el camino
opuesto. Nuevamente, el proxy arma su propio mensaje tratando de mantener la semántica del server origen.
Por ejemplo, el proxy ante un header Expires con valor inválido o con una fecha estrictamente menor a la del header Date lo que hace es modificar el header Expires llenándolo con el valor encontrado en Date. Este cambio no afecta la semántica. Desafortunadamente, entre estos “toqueteos” hay otros, el más importante es el header Content-Length.
Lo que sucede con este header es el equivalente a C de “length = (long int) strtoint64(str_content_length_value)” (aproximadamente ocurre esto). Gracias a este bug, no es posible bajar archivos mayores a 2 GB. (Ver posts en SpeedyApesta.com.ar para obtener detalles del comportamiento del proxy ante cualquier valor).

Para terminar, pongamos una cosa en claro. Usar proxys cache no es malo, lo malo es que quienes los mantienen no sean duchos en esa tarea, o, en el mejor de los casos, desconozcan algunos detalles importantes de la configuración.
Es casi innegable que sea cual fuere la razón, el motivo es el mismo. Ahorrar, por parte de los ISPs, hasta el último centavo posible tanto en ancho de banda utilizado como en sueldos del personal a cargo de estos proxys.
Algún día tendremos un gobierno al que le preocuparán estos temas. Lamentablemente, hoy ni siquiera saben de que estamos hablando. Sin embargo, calidad de servicio no es una frase tan difícil de entender. Significa, nada mas y nada menos, que quienes están en una posición de inferioridad por desconocimiento, deben ser protegidos por el Estado fijando normas de cumplimiento mínimos. Las cuales hoy no tenemos y por eso mismo es que tenemos problemas con nuestras conexiones y los ISPs ocultan los motivos por los que se producen, ya que no tienen ninguna intención de solucionarlos.

Otro links para leer:
¿Como se determinó que los proxys son varios y con diferentes configuraciones?
WC MRSE implementa método CONNECT

Para los usuarios de Fibertel (también aplica para $peedy aunque en esta última solo para el puerto 80), vean lo que va descubriendo Buanzo:
“Soy Fibertel y te cago” – Juaz, te cago el doble!
Fibertel: Continúa la Batalla 😛
Investigando Fiberte1!
Confirmado: Fibertel tiene NetCache
Mas Pruebas a Fibertel – Post recomendado por los datos que contiene.
Mas Pruebas e Ideas (fibertel)
Informe de Puertos Proxeados – Fibertel

Compartir via ...

Facebook

Twitter

Email