Cue the angry nerd jokes.
Esto va a ser un thread bastante técnico, que nadie va a leer, pero me va a dejar descargar mi ira contra estos conchudos.
Todo esto comenzó hace mucho tiempo en una galaxia muy lejana, cuando Speedy implementó su novedoso servicio de "Ayuda en la búsqueda", para hacerse unos pesitos en una relación carnal con Yahoo. Hete aquí, que para mantener de rehenes a los usuarios, agarraron y empezaron a repartir proxy (del cual venía zafando) a diestra y siniestra. El proxy resolvía los DNS y por más que le pusieras el puto DNS a mano (onda OpenDNS), se cagaba en vos y te hacía pasar por donde a el se le cantaba el culo.
No es cuestión de demonizar a los proxy-caché, que en la teoría pueden llegar a ser beneficiosos, sino que en una infraestructura tan grande como la de uno de los ISP más grande del país, es IMPOSIBLE mantenerlo y que funcione bien. Más teniendo en cuenta la intachable calidad del Grupo Telefónica (?) en la calidad del servicio.
El primer problema que empecé a notar, era que no me cargaban bien algunas imágenes de Flickr. En particular, las fotos del blog de Uncubed, hosteadas en la farm4 de Flickr.
Googlié un toque, y en seguida saltó que el proxy andaba mal. Me quejé (sabiendo que es al pedo) e instalé Access Flickr una extensíon diseñada para acceder a Flickr en países con filtros de contenido y censura (ej., Iran, China, etc.). Todo empezó a funcionar correctamente, se me bajó la mostaza de la capocha (?), y seguí mirando Gundam como si nada (?).
Hasta hace un par de semanas. Usualmente uso Deviantart, para chusmear galerías de usuarios muy grosos, gente que labura para Marvel, DC, etc. Pero al entrar, me encuentro con esto:
- ¡OH DIOS MIO! ¡MATARON AL CSS! O_o
- ¡HIJOSDEPUTA! >__<
Epic Fail. Pruebo entrar via Anonymouse, rogando que no sea el puto proxy de Telefornica... y entro perfectamente. Me estaban cagando.
Leyendo un poquito el código, veo que el CSS para los usuarios logueados es http://st.deviantart.com/css/v6loggedin.css. Entro a esa URL con Anonymouse, anda joya. Entro con mi navegador/es: FAIL. HTTP 400 Solicitud incorrecta.
A todo esto, llamo a Speedy y me quejo. Al pedo, sigo coleccionando números de reclamo. Pero mientras, voy buscando el nombre del culpable.
Haciendo con PUTTY una conexión RAW a 10.0.0.150, conecta y le pregunto:
TRACE http://www.google.com.ar/ HTTP/1.1
Host: www.google.com.ar
Max-Forwards: 0
Responde:
HTTP/1.1 200 OK
Date: Fri, 15 May 2009 01:57:12 GMT
Content-Length: 86
Content-Type: message/http
Server: NetCache appliance (NetApp/6.0.7)
YAYNESS!! ¡BIENVENIDO AL MUNDO DE MI PROXY CONFIGURADO POR UN PRIMATE CON ALGUN PARASITO ALIEN EN EL CEREBRO!
Vamos a hacer unas pruebas.
Tracert, es un comando que muestra el camino que hacen nuestras peticiones para llegar a destino, en este caso GMAIL.COM:
C:\Documents and Settings\Ukyo>tracert gmail.com -w 500
Traza a la dirección gmail.com [74.125.79.83]
sobre un máximo de 30 saltos:
1 * * * Tiempo de espera agotado para esta solicitud.
2 * 8 ms * RBFLR02-Gi5-6-3920.mrse.com.ar [200.51.234.42]
3 * 8 ms * RBFLR02-Po11.mrse.com.ar [200.51.234.205]
4 * * * Tiempo de espera agotado para esta solicitud.
5 129 ms 64 ms 63 ms Xe7-3-0-0-grtlurem4.red.telefonica-wholesale.net
[213.140.49.18]
6 126 ms 125 ms 125 ms xe3-0-0-0-grtmiabr6.red.telefonica-wholesale.net
[84.16.15.90]
7 169 ms 168 ms 170 ms Xe2-3-0-0-grtnycpt3.red.telefonica-wholesale.net
[84.16.15.129]
8 236 ms 235 ms 237 ms So5-1-0-0-grtlontl1.red.telefonica-wholesale.net
[213.140.38.222]
9 252 ms 253 ms 253 ms 72.14.198.9
10 253 ms 263 ms 263 ms 209.85.252.40
11 256 ms 264 ms 254 ms 72.14.233.63
12 264 ms 256 ms 263 ms 64.233.175.246
13 263 ms 262 ms 266 ms 209.85.255.166
14 258 ms 256 ms 259 ms 209.85.255.118
15 257 ms 265 ms 256 ms ey-in-f83.google.com [74.125.79.83]
Básicamente lo que nos dice, es que estamos a 15 "pasos" del servidor que responde por GMAIL.COM. Tracert utiliza paquetes UDP, por lo cual no pasa a través del proxy.
Para romper las pelotas, intento un TRACETCP a GMAIL. Con este comando, puedo hacer un traceroute, pero usando paquetes comunes, para simular como si estuviera navegando:
C:\Documents and Settings\Ukyo>tracetcp gmail.com -t 500
Tracing route to 209.85.171.83 [cg-in-f83.google.com] on port 80
Over a maximum of 30 hops.
1 * * * Request timed out.
2 * * * Request timed out.
3 Destination Reached in 10 ms. Connection established to 209.85.171.83
Trace Complete.
Oia. ¿3 pasos? ¿No será como muy poco?
Ahora intento por el puerto de SSL. Los proxy no pueden cachear SSL, porque está encriptado y lo que hacen es dejarlo pasar de largo:
C:\Documents and Settings\Ukyo>tracetcp gmail.com:443 -t 500
Tracing route to 74.125.79.83 [ey-in-f83.google.com] on port 443
Over a maximum of 30 hops.
1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 Destination Reached in 263 ms. Connection established to 74.125.79.83
Oh casualidad, me da igual cantidad de saltos que en el traceroute UDP. Eso significa que en la primera petición, contestó el amigo NetCache.
Lo que más me molesta de esto, es que te sacan herramientas para solucionarte problemas. A Speedy se le viven cayendo los servidores DNS, y antes ponías uno de Arnet, o los OpenDNS mismos. Hoy por hoy, con el proxy transparente, te cabe por gil. Lo único que queda es utilizar un proxy diferente, que no pase por el puerto 80 y que sea confiable. Lo cual es muuuuy difícil de conseguir, no podés saber si el que maneja el proxy en Tagarraninpán se está quedando con tus contraseñas...
En pocas palabras, una pija ¬¬
PD: Y encima en España
lo habían sacado en 2006, porque andaba como el culo.
