Uno de los principales problemas con Windows es su popularidad y, por ende, el que se convierta en un blanco continuo de ataques y preocupaciones sobre seguridad y privacidad. Esto conlleva a que los administradores y organizaciones (lo quieran o no, tengan o no cierto nivel de paranoia, o en verdad se preocupen por ello) a que tengan que implementar ciertas políticas de seguridad (muchas vistas más como «buenas prácticas» que como una verdadera necesidad, otras definitivamente necesarias para el negocio, y otras más requeridas por la autoridad). Todo esto, para todos aquellos involucrados con el desarrollo de software, investigación y desarrollo científico y tecnológicos, de productos o servicios digitales, y operaciones o soporte técnico (es decir, todas las actividades no directamente relacionadas con el consumidor o la exposición pública) nos lleva a pasar «las de Caín» en las labores cotidianas.
Dentro de todo este universos de penalidades, nos encontramos con los «proxies«. Un proxy, o servidor proxy, es un equipo o programa que hace de intermediario en las peticiones de un cliente a otro servidor. El término viene, supongo, del término «procurador«. Usualmente es visto como un elemento de seguridad pero es en realidad un factor de enmascaramiento u ocultación. Por ejemplo, si una hipotética máquina A solicitara un recurso a otra máquina C, lo hará mediante una petición al proxy; C no sabrá que la petición procedió originalmente de A.
Aunque esto permite ofrecer funcionalidades de control de acceso, registro del tráfico, restricción a determinados tipos de tráfico, mejora de rendimiento, anonimato de la comunicación, caché web, etc., veremos que dependiendo del contexto, la intermediación que realiza el proxy puede ser considerada por los usuarios, administradores o proveedores como legítima o delictiva.
Hace tiempo escribí por mi regreso a ciertos entornos opresivos, como resultado de un cambio de empleo en el que fui asignado a un cliente grande (pero grande, no cositas como Citibanamex), debí nuevamente enfrentar el uso de un proxy para poder salir a la internet. Así, aunque en un inicio no lo consideré (pero entonces lo lamenté), esto impone ciertos problemas para actividades básicas de desarrollo informático.
Para el caso de Python, estas dificultades aparecen en el momento en el que uno quiere instalar paquetes (módulos) recibiendo un mensaje de time-out o que el sitio (repositorio del paquete) no puede ser encontrado. Una forma de solucionar esto es mediante el uso de un par de variables de ambiente:
http_proxy=http://[username:password@]proxyserver:port https_proxy=https://[username:password@]proxyserver:port
Dependiendo si se trata de un entorno Unix (BASH, KSH, C shell, etc.) o si es Windows (PowerShell o CMD batch commands) las variables deberán ser declaradas apropiadamente (e.g. si se requiere un comando SET o export para ello) y si estas deben ser colocadas en mayúsculas o si ello no importa. Una vez declaradas las variables, éstas sirven tanto para los administradores pip o conda.
Dos cosas importantes a recalcar. La dirección o nombre, y puerto del servidor proxy se puede obtener de la configuración del navegador o del script de configuración del que ésta haga uso (revisar la configuración del browser o del equipo sobre el acceso a la Internet para ello), y el protocolo para la variable https_proxy no necesariamente debe ser HTTPS. No he encontrado una justificación o regla al respecto pero si he atestiguado que el prefijo «http://» puede ser el único que funcione para «el puerto seguro», cuestión de probar (eso sí, el valor correcto para el puerto seguro es importante).
Alternativamente, algunos administradores de paquetes podrán permitir la declaración del proxy, por ejemplo para el caso del pip:
pip install --proxy=https://[username:password@]proxyserver:port somepackage
Dr. Edu 