Tengo una colección de servidores CentOS en mi red corporativa. Por razones de seguridad, la mayoría de los servidores no tienen acceso general a Internet saliente a menos que sea un requisito funcional central para el servidor.

Esto crea un desafío cuando necesito actualizar paquetes. Para los repositorios de yum, actualmente reflejo todos los repositorios necesarios de Internet y hago que los espejos estén disponibles dentro de la intranet. Guardo copias de cada repositorio en cada uno de nuestros cinco entornos: desarrollo, control de calidad, puesta en escena y dos centros de datos de producción.

Actualmente no resuelvo los repositorios de paquetes específicos del idioma. Cuando los servidores necesitan una actualización de rubygems, PyPI, PECL, CPAN o npm, tienen que adquirir acceso temporal a Internet saliente para obtener los paquetes. Me han pedido que empiece a duplicar rubygems y PyPI, y el resto probablemente seguirá.

Todo esto es torpe y no funciona bien. Me gustaría reemplazarlo con un solo proxy de almacenamiento en caché en un entorno y cuatro servidores proxy en cadena en mis otros entornos, para eliminar la complejidad y la sobrecarga de disco de los espejos completos. Adicionalmente:

• Puede ser un proxy directo o inverso; cada administrador de paquetes admite un servidor proxy o un punto final de repositorio personalizado, que podría ser un espejo local o un proxy inverso.
• Necesita control de acceso granular, por lo que puedo limitar qué IP de cliente pueden conectarse a qué dominios de repositorio.
• Los clientes deben poder seguir los redireccionamientos a dominios desconocidos. Su solicitud original podría estar limitada a rubygems.org, pero si ese servidor devuelve un 302 a un CDN aleatorio, debería poder seguirlo.
• Debería admitir backends HTTPS. No necesariamente necesito suplantar a otros servidores SSL, pero debería poder volver a exponer un sitio HTTPS a través de HTTP, o terminar y volver a cifrar con un certificado diferente.

Inicialmente estaba mirando proxies inversos, y Varnish parece ser el único que me permitiría resolver internamente las redirecciones 302 dentro del proxy. Sin embargo, la versión gratuita de Varnish no admite backends HTTPS. Ahora estoy evaluando Squid como una opción de proxy hacia adelante.

Esto parece algo que debería ser un problema relativamente común dentro de las redes empresariales, pero tengo problemas para encontrar ejemplos de cómo otras personas han resuelto esto. ¿Alguien ha implementado algo similar o tiene ideas sobre la mejor manera de hacerlo?

¡Gracias!

Usamos Squid para esto; Lo bueno de los calamares es que puede establecer la expiración individual de los objetos en función de una coincidencia de patrones, con bastante facilidad, lo que permite que los metadatos del repositorio de yum se eliminen con bastante rapidez. La configuración que tenemos que implementa esto:

refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern (\.xml|xml\.gz)$      0       20%     2880
refresh_pattern ((sqlite.bz2)*)$      0       20%     2880
refresh_pattern (\.deb|\.udeb)$   1296000 100% 1296000
refresh_pattern (\.rpm|\.srpm)$   1296000 100% 1296000
refresh_pattern .        0    20%    4320

http://www.squid-cache.org/Doc/config/refresh_pattern/

Ese es un caso de uso definitivo para un proxy . Un proxy normal, no un proxy inverso (también conocido como equilibradores de carga).

El calamar más conocido, libre y de código abierto es el calamar . Afortunadamente, es uno de los pocos buenos software de código abierto que puede instalarse fácilmente apt-get install squid3con un solo archivo y configurarse con un solo archivo /etc/squid3/squid.conf.

Repasaremos las buenas prácticas y las lecciones a conocer.

El archivo de configuración oficial se modificó ligeramente (se eliminaron las 5000 líneas inútiles comentadas).

#       WELCOME TO SQUID 3.4.8
#       ----------------------------
#
#       This is the documentation for the Squid configuration file.
#       This documentation can also be found online at:
#               http://www.squid-cache.org/Doc/config/
#
#       You may wish to look at the Squid home page and wiki for the
#       FAQ and other documentation:
#               http://www.squid-cache.org/
#               http://wiki.squid-cache.org/SquidFaq
#               http://wiki.squid-cache.org/ConfigExamples
#

###########################################################
# ACL
###########################################################

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 1025-65535  # unregistered ports

acl CONNECT method CONNECT

#####################################################
# Recommended minimum Access Permission configuration
#####################################################
# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

#####################################################
# ACL
#####################################################

# access is limited to our subnets
acl mycompany_net   src 10.0.0.0/8

# access is limited to whitelisted domains
# ".example.com" includes all subdomains of example.com
acl repo_domain dstdomain .keyserver.ubuntu.com
acl repo_domain dstdomain .debian.org
acl repo_domain dstdomain .python.org

# clients come from a known subnet AND go to a known domain
http_access allow repo_domain mycompany_net

# And finally deny all other access to this proxy
http_access deny all

#####################################################
# Other
#####################################################

# default proxy port is 3128
http_port 0.0.0.0:3128

# don't forward internal private IP addresses
forwarded_for off

# disable ALL caching
# bandwidth is cheap. debugging cache related bugs is expensive.
cache deny all

# logs
# Note: not sure if squid configures logrotate or not
access_log daemon:/var/log/squid3/access.log squid
access_log syslog:squid.INFO squid


# leave coredumps in the first cache dir
coredump_dir /var/spool/squid3

# force immediaty expiry of items in the cache.
# caching is disabled. This setting is set as an additional precaution.
refresh_pattern .               0       0%      0

Configuración del cliente - Variables de entorno

Configure estas dos variables de entorno en todos los sistemas.

http_proxy=squid.internal.mycompany.com:3128
https_proxy=squid.internal.mycompany.com:3128

La mayoría de las bibliotecas de cliente http (libcurl, httpclient, ...) se autoconfiguran utilizando las variables de entorno. La mayoría de las aplicaciones están utilizando una de las bibliotecas comunes y, por lo tanto, admiten el proxy listo para usar (sin que el desarrollador sepa necesariamente que lo hacen).

Tenga en cuenta que la sintaxis es estricta:

1. El nombre de la variable http_proxyDEBE estar en minúsculas en la mayoría de Linux.
2. El valor de la variable NO DEBE comenzar con http(s)://(el protocolo proxy NO es http (s)).

Configuración del cliente: específica

Algunas aplicaciones ignoran las variables de entorno y / o se ejecutan como servicio antes de que se puedan establecer variables (por ejemplo, debian apt).

Estas aplicaciones requerirán una configuración especial (p /etc/apt.conf. Ej .).

HTTPS Proxying - Conectar

El proxy HTTPS es totalmente compatible con el diseño. Utiliza un método especial de "CONEXIÓN" que establece algún tipo de túnel entre el navegador y el proxy.

No sé mucho sobre eso, pero nunca he tenido problemas con él en años. Simplemente funciona

Estuche especial HTTPS - Proxy transparente

Una nota sobre proxy transparente. (es decir, el proxy está oculto e intercepta las solicitudes de los clientes ala. man-in-the-middle).

Proxies transparentes están rompiendo HTTPS. El cliente no sabe que hay un proxy y no tiene ninguna razón para usar el método especial Connect.

El cliente intenta una conexión HTTPS directa ... que es interceptada. Se detecta la intercepción y se lanzan errores por todo el lugar. (HTTPS está destinado a detectar ataques de hombre en medio).

Lista blanca de dominio y CDN

La lista blanca de dominios y subdominios es totalmente compatible con squid. Sin embargo, es inevitable que falle de manera inesperada de vez en cuando.

Los sitios web modernos pueden tener todo tipo de redirecciones de dominio y CDN. Eso romperá ACL cuando las personas no hicieron un esfuerzo adicional para poner todo en un solo dominio.

A veces habrá un instalador o un paquete que quiera llamar a la nave o recuperar dependencias externas antes de ejecutar. Fallará cada vez y no hay nada que pueda hacer al respecto.

Almacenamiento en caché

El archivo de configuración proporcionado está deshabilitando toda forma de almacenamiento en caché. Más vale prevenir que lamentar.

Personalmente, estoy ejecutando cosas en la nube en este momento, todas las instancias tienen al menos una conectividad de 100 Mbps y el proveedor ejecuta sus propios repositorios para cosas populares (por ejemplo, Debian) que se descubren automáticamente. Eso hace que el ancho de banda sea una mercancía que no podría importarme menos.

Prefiero deshabilitar totalmente el almacenamiento en caché que experimentar un solo error de almacenamiento en caché que derretirá mi cerebro al resolver problemas. Cada persona en Internet NO PUEDE obtener sus encabezados de almacenamiento en caché correctamente.

Sin embargo, no todos los entornos tienen los mismos requisitos. Puede hacer un esfuerzo adicional y configurar el almacenamiento en caché.

NUNCA NECESITA autenticación en el proxy

Hay una opción para solicitar la autenticación de contraseña de los clientes, generalmente con sus cuentas LDAP. Romperá todos los navegadores y todas las herramientas de línea de comandos del universo.

Si desea autenticar en el proxy, no lo haga.

Si la gerencia quiere autenticación, explique que no es posible.

Si eres un desarrollador y te acabas de unir a una empresa que está bloqueando Internet directo Y forzando la autenticación de proxy, EJECÚTATE MIENTRAS PUEDES.

Conclusión

Revisamos la configuración común, los errores comunes y las cosas que uno debe saber sobre la representación.

Lección aprendida:

• Existe un buen software de código abierto para proxy (calamar)
• Es simple y fácil de configurar (un solo archivo corto)
• Todas las medidas de seguridad (opcionales) tienen compensaciones
• Las opciones más avanzadas romperán cosas y volverán a atormentarte
• Proxies transparentes están rompiendo HTTPS
• La autenticación de proxy es malvada

Como es habitual en la programación y el diseño del sistema, es fundamental gestionar los requisitos y las expectativas.

Recomiendo atenerse a lo básico al configurar un proxy. En términos generales, un proxy simple sin ningún filtro en particular funcionará bien y no dará ningún problema. Solo tengo que recordar configurar (auto) los clientes.

Esto no resolverá todas sus tareas, pero tal vez esto sea útil. A pesar del nombre, apt-cacher-ng no solo funciona con Debian y derivados, y es

un proxy de almacenamiento en caché. Especializado para archivos de paquetes de distribuidores de Linux, principalmente para distribuciones Debian (y basadas en Debian), pero no limitado a esos.

Estoy usando esto en producción en un entorno similar (basado en Debian) como el suyo.

Sin embargo, AFAIK, esto no admitirá rubygems, PyPI, PECL, CPAN o npm y no proporciona ACL granulares.

Personalmente, creo que investigar Squid es una buena idea. Si implementa una configuración al final, ¿podría compartir sus experiencias? Estoy bastante interesado en cómo va.

Tuvimos un desafío similar y lo resolvimos utilizando repositorios locales y un sistema de almacenamiento basado en instantáneas. Básicamente, actualizamos el repositorio de desarrollo, lo clonamos para pruebas, lo clonamos para la puesta en escena y finalmente para la producción. La cantidad de disco utilizada está limitada de esa manera, además de que todo es un almacenamiento lento de sata y eso está bien.

Los clientes obtienen la información del repositorio de nuestra gestión de configuración, por lo que cambiar es fácil si es necesario.

Puede lograr lo que desea usando ace en el servidor proxy usando cadenas de agente de usuario o combinaciones de ips / máscara de origen y restringiendo su acceso a ciertos dominios, pero si lo hace, veo un problema que es el de diferentes versiones de paquetes / bibliotecas. Entonces, si uno de los hosts puede acceder a cpan y solicita el módulo xxx :: aaa, a menos que el cliente le indique que use una versión específica, extraerá lo último de cpan (o pypy o rubygems), que puede o no ser el que ya era almacenado en caché en el proxy. Por lo tanto, puede terminar con diferentes versiones en el mismo entorno. No tendrá ese problema si utiliza repositorios locales.