Desde hace algunas semanas Telefonica™ ha implementado en su red de datos del servicio ADSL (tanto residencial como empresarial) un conjunto de proxys para el acceso a servicios web. La idea es que dichas máquinas hagan de intermediarios para el acceso a los servicios web desde los abonados ADSL sin que éstos deban modificar la configuración de sus equipos.

Este mecanismo se conoce como proxy transparente, y permite acelerar la descarga de contenidos desde Internet, almecenando en grandes cachés de datos los recursos accedidos con más frecuencia, evitando descargarlo desde el servidor real, posiblemente más lejano, saturado y con menor ancho de banda (y más costoso para el proveedor, al saturar sus caros enlaces de larga distancia).

Para que estos intermediarios funcionen de manera transparente al usuario, deben capturar el tráfico web, redirigirlo a una aplicación que implemente el servicio, y será esta aplicación la que haga la petición de la página. Todo esto consiste en la rescritura y reenvío de cabeceras del protocolo HTTP, que de no ser correctas o no enviarse en tiempo y forma, causará problemas de navegación.

Pues bien, los problemas de acceso a este sitio web es muy probable que vengan causados por alguno de estos mecanismos de proxy transparente que, por alguna razón, no funciona como debería. Lo más extraño de todo esto es que el acceso a páginas hospedadas en una determinada dirección IP de una máquina concreta funciona, pero falla el acceso a páginas hospedadas en el mismo servidor pero asociadas a otra dirección IP distinta.

En cualquier caso, los síntomas son retrasos de segundos o inclusos minutos antes de que nuestro navegador comience a descargar la página, el fallo del proceso (expira el plazo que el navegador se da para obtener una respuesta), etc. Estamos plenamente convencidos de que estos problemas son ajenos a nuestra responsabilidad, y rogamos disculpen las molestias causadas por estos errores por parte de su proveedor de acceso a Internet.

Puede verificar si su conexión está sujeta a los mecanismos descritos más arriba entrando en esta página, donde se le muestra información interesante sobre la petición HTTP, las direcciones IP real (la de su máquina, la identificada en letras grandes) y del servidor proxy intermedio, así como las cadenas User-Agent de su navegador y de la máquina intermedia.

Si en el informe aparecen los campos X-Forwarded-For y Via, entonces con casi total seguridad le sucede lo que a mi y otros muchos abonados al servicio ADSl de Telefonica™. Consulte esta conversación en el grupo de noticias es.comp.redes.adsl para saber algo más acerca de este asunto.

Otro posible inconveniente de estos mecanismos es que cuando acceda a páginas que cambian con mucha frecuencia (por ejemplo, sitios de noticias o periódicos) obtenga como respuesta una página en la caché del intermediario, y no el contenido real del servidor web remoto en ese momento. Esto puede evitarse en la mayoría de los navegadores pulsando CTRL+SHIFT+R para recargar la página actual evitando en lo posible el uso de cachés intermedias.

La solcuión de todos estos problemas pasa por la voluntad y responsabilidad del proveedor. Mientras tanto, para acceder a aquellos sitios que resultan inaccesibles, podemos hacer uso de alguno de los servicios de navegación anónima, como por ejemplo Anonymizer.com.

Después de llevar a cabo diversas pruebas para identificar el origen de los problemas, con la inestimable ayuda y colaboración de algunos amigos, parece que hemos dado con la causa de los mismos. Aunque para entender la razón de los problemas de acceso, y la solución adoptada, es necesario disponer de unos conceptos básicos de funcionamiento de la web (es decir, de qué sucede desde que tecleamos una URL en nuestro navegador hasta que aparece la página en pantalla. Consulte este artículo para saber más al respecto, y luego siga leyendo.

El problema sucede por una desafortunada combinación de factores, entre los que se incluyen el proxy situado por Telefonica™ en el camino del tráfico HTTP saliente, el funcionamiento del propio protocolo y posibles problemas con los servidores DNS que contienen la información asociada al dominio 24x7linux.com. Sucede que habitualmente los navegadores usan la versión 1.1 del protocolo HTTP, que especifica la obligatoriedad de enviar junto con el resto de cabeceras de la petición, una de nombre Host, donde se indique el nombre o dirección IP (y en caso necesario, el puerto) del servidor remoto a cuyas páginas queremos acceder. Baste decir que esta cabecera es la que permite configurar virtual hosts distinguidos por nombre, compartiendo una misma IP.

En situaciones normales (en ausencia de proxys, el navegador conecta al puerto correspondiente de la máquina remota, y le remite las cabeceras de la petición HTTP (incluyendo la cabecera Host). El servidor web remoto analizará las cabeceras, y devolverá la respuesta (página) que corresponda. Sin embargo, con un proxy intermedio (aunque sea transparente de cara al usuario) la petición del cliente (el navegador) es atendida por la máquina proxy, que por su parte realiza una nueva consulta al servidor en nombre del cliente, hecho del que deja constancia añadiendo alguna cabecera adicional, como por ejemplo X-Forwarded-For (IP de la máquina donde está el navegador que hizo la petición original) y Via (donde el proxy se identifica como tal).

Pues bien, por razones que no alcanzo a comprender parece como si el proxy intentara averiguar la dirección IP de la máquina indicada en la cabecera Host. Esto, que en circunstancias normales no tendría mayor problema, se convierte en un grave inconveniente si, como parece, el proxy es incapaz de encontrar la dirección IP asociada a www.24x7linux.com la mayor parte del tiempo, reteniendo la petición HTTP, que nunca llega al servidor. Parece que eventualmente consigue averiguar la dirección IP asociada, dando acceso al sitio web durante el tiempo que dicha equivalencia entre nombre y dirección IP permanece en su caché DNS.

La razón por la que el proxy es incapaz de averigüar la dirección IP del sitio web me resulta desconocida. Porque habiendo consultado a varios servidores DNS la equivalencia entre el nombre www.24x7linux.com y su dirección IP siempre he obtenido respuesta, y de manera rápida en todos los casos. Lo que sí es cierto es que desde hace unas semanas la web de Gandi, donde se registró el nombre de dominio y donde se encuentran los servidores DNS primario y secundario para el mismo, ha experimentado graves problemas de acceso, que bien pudieran afectar también al servicio de nombres.

Así que para descartar esta posibilidad, y solucionar de una vez los problemas de acceso que están teniendo lugar, me decidí a migrar los servidores DNS primario y secundario para el dominio a la máquinas de la empresa ZoneEdit. Dicha empresa se dedica exclusivamente a prestar servicios de hospedaje de servidores DNS, proporcionando una sencilla interfaz web para la gestión de toda la información asociada al dominio o dominios cuyos servidores de nombres albergue. Además, este servicio es completamente gratuito para los primeros cinco dominios cuyos servidores DNS hospedemos, así que todo son ventajas.

El único problema es que la propagación de los cambios en los servidores de nombres asociados a dominios .com suele tardar entre dos y tres días, de manera que hasta aproximadamente el Martes día 12 de Noviembre de 2002 no sabremos si el cambio ha solucionado los problemas de acceso (confirmándonos que la causa de los mismos radicaba en la combinación de circunstancias indicadas más arriba). Seguiremos informando de todo cuando vayamos averigüando.

Se ha confirmado desde varias líneas de acceso (tanto de la red ADSL de Telefonica™, como de otros proveedores y con otras tecnologías) que la información actualizada de los servidores de nombres primario y secundario para el dominio 24x7linux.com ya se ha propagado por Internet. Desde estas mismas conexiones se ha probado a acceder a la página web www.24x7linux.com, funcionando correctamente y a gran velocidad en todos los casos.

Es decir, se confirma nuestra hipótesis principal, que consistía en problemas de funcionamiento de los servidores DNS hospedados en las máquinas de Gandi, aunque bien es cierto que dichos problemas sólo parecían suceder en las supuestas resoluciones de nombres que parecían llevar a cabo los proxys instalados por Telefonica™ en la red de datos ADSL.

Desde el cambio de los servidores DNS primario y secundario del dominio a ZoneEdit no hemos tenido ningún tipo de problema. De hecho, personalmente opino que he salido ganando con este cambio, que si bien me había planteado en alguna ocasión, nunca había llevado a cabo, por la simple premisa de "si funciona, no lo toques". Aprovecho estas últimas líneas para agradecer la colaboración, apoyo y paciencia de todos aquellos que han colaborado en averiguar y solucionar el problema acaecido. Muchas gracias a todos.

Según parece, Telefonica™ ha dado marcha atrás en su despliegue de proxys para las conexiones ADSL, en las que todo el tráfico de red con destino a puertos 80 remotos se asumía de tipo HTTP. Esto impedía prestar servicios distintos de web en citado puerto (algo nada habitual), desvirtuaba la información contenida en los archivos de log de los ervidores, causaba que ciertas aplicaciones y formularios web no funcionaran correctamente, o que se manifestaran otro tipo de problemas como el sucedido con este sitio, y que se describe más arriba.

Si bien parece que los proxys ya no están presentes (como se puede comprobar en esta página), bien pudiera ser una medida temporal o simplemente una configuración más furtiva de los mismos. Hasta ahora las únicas noticias al respecto de esta posible retirada de los proxys en las líneas ADSL provienen de un hilarante (por las estupideces técnicas y la creencia de sus autores de haber sido ellos, entre otros, lo que han hecho dar marcha atrás a la operadora) artículo en el foro de nombre Asociación para la Información de Hackers (A.I.H.).

De momento la operadora no ha dicho nada al respecto (tampoco veo yo la necesidad de que una operadora haga públicos cada uno de los cientos de cambios que acomete al mes en su red), y no hay mucha más informacuón al respecto. El hecho es que parece que el hecho se confirma a lo largo de toda la red ADSL de Telefonica™, y la situación vuelve a la situación previa a principios de Noviembre.

Parece que lo que parecía lógico se ha hecho realidad: Telefonica™ parece haber "reactivado" sus proxys en los accesos ADSL. Como ya hemos comentado previamente esto no es malo de por sí, de hecho si funcionan correctamente es beneficioso tanto para el operador de la red como para el usuario, pero conviene tener este hecho en cuenta por si experimentamos problemas de navegación inusuales. Por lo demás, consulte el resto de este artículo para los (pocos) detalles concretos al respecto de este tema.

Por fin parece haber información fiable al respecto del asunto de los proxys de boca del proveedor. Según se recoge en esta página de ADSL4Ever, Telefonica está informando a sus clientes que en breve (a partir del día 10 de Enero de 2003) activará los proxys de los que hemos venido hablando ya durante varias semanas, y que hasta la fecha tan sólo estaban en pruebas.

Si bien los argumentos del proveedor son correctos y justificados, el uso de estos sistemas abren algunas cuestiones que no tienen de momento respuesta, así como algunos inconvenientes que pueden aparecer. Si bien es cierto que el uso de los proxys proporcionan "Mayor seguridad y anonimato de los usuarios ya que, para estos contenidos, se accede a los servidores con la dirección IP del proxy-caché y no con la del usuario", también es cierto que esto impide a los servidores web generar estadísticas de uso correctas con la configuración actual. Además del posible inconveniente de un punto central de fallo, que en caso de fallar (físicamente, o por problemas de configuración) puede dejar sin servicio a un elevado número de abonados.

Además, el uso de estos proxys quizás (no lo sé con seguridad) no aplique a otros tipos de tráfico posiblemente más masivo y "dañino" para la calidad del servicio de sus clientes, como es el generado por los programas peer-to-peer y de streaming de vídeo y audio. Sin olvidar que dependiendo del funcionamiento de estos ingenios es posible que las páginas cuyos contenidos varían con frecuencia (como los periódicos en Internet y los weblogs) se nos muestren anticuadas con respecto a los contenidos actuales de las mismas.

Telefonica muestra en las páginas de www.telefonicaonline.com información acerca del despliegue de los sistemas de proxy cache para los abonados del servicio ADSL. En concreto, a partir de esta página se encuentran varios documentos en formato PDF, donde se explican los detalles del sistema tanto para los usuarios finales, como para las empresas y proveedores.

Lo mejor para formarse una opinión acerca de este tema es leer la documentación enlazada en el párrafo anterior, aunque conviene señalar un par de detalles:

• Los únicos servicios a los que afectará la presencia de estos proxy son a los prestados en los puertos 80 (protocolo HTTP), streaming de Microsoft™ Windows Media© (puerto 1755 tanto TCP como UDP), streaming de Real Networks™ (protocolo RTSP en el puerto 554), así como streaming de Quicktime©, en el mismo puerto que el anterior.
• No existe previsto un mecanismo para evitar el uso de los proxy, salvo reconfigurar los servidores web bajo nuestra responsabilidad y forzar a que los navegadores pidan contenido "fresco" a los servidores.
• Algunos sitios y aplicaciones que usan la dirección IP de las peticiones HTTP como medio de identificar a los usuarios o restringir el acceso es muy posible que dejen de funcionar correctamente. Esto incluye también a los programas analizadores de log y de generación de estadísticas de acceso.

Al margen de los detalles objetivos existen bastantes detalles en los documentos publicados por Telefonica que bien no son ciertos, o son contradictorios con otras cosas dichas en los mismos documentos tan solo unos párrafos antes, como por ejemplo:

• Si bien se dice que el uso de cookies en los servicios web se desaconseja, puesto que dichas páginas no son cacheadas por los proxy, un par de párrafos más adelante se indica el uso de este mecanismo para ofrecer al usuario el contenido real actualizado del sitio.
• Se recomiendan barbaridades como renombrar todos los archivos de nuestro sitio web para asegurarnos de que los cambios se propagan de manera inmediata a los visitantes de nuestras páginas.
• Se explica cómo modificar la configuración de los servidores web más importantes del mercado para generar archivos de log que tengan en cuenta la presencia de los proxy, pero los cambios suponen que las peticiones que vengan directamente de los navegadores de los usuarios sin pasar por estos dispositivos no se registrarán correctamente, siendo no contabilizables con las aplicaciones de generación de estadísticas.
• Los cambios necesarios en los servidores web para "adecuarlos" a los proxy, en los casos donde realmente sirven para algo, requieren siempre privilegios de superusuario sobre la máquina que hospeda las páginas, lo que impide llevar estos cambios a la práctica cuando las páginas están alojadas en un servicio de hosting.
• Otras muchas incorrecciones, contradicciones y recomendaciones al margen de la realidad que podrá encontrar si lee con detenimiento los documentos en cuestión.

Ya para finalizar, mi opinión personal después de leer la información proporcionada por el propio proveedor es que la presencia de estos dispositivos en la red de acceso para los usuarios de ADSL posiblemente sí que mejore los tiempos de carga de las páginas web más visitadas, pero dudo que en la mayor parte de los casos la mejora sea tan importante como para justificar el despliegue masivo de esta infraestructura de proxy.

Además, puede que el porcentaje de tráfico que estos proxy ahorren al proveedor sea muy bajo, puesto que tráfico tan masivo como el FTP, los programas de peer to peer, el streaming de MP3, etc. no son cacheados por estos dispositivos.

Por cierto, si desea reconfigurar su servidor web Apache para que sus archivos de log contengan entradas correctas aún cuando las peticiones provengan de usuarios ADSL de Telefonica, consulte este artículo.

Última modificación: 11-January-2003 13:52:37 -0500