Eu tenho uma coleção de servidores CentOS na minha rede corporativa. Por motivos de segurança, a maioria dos servidores não tem acesso geral à Internet de saída, a menos que seja um requisito funcional básico para o servidor.

Isso cria um desafio quando preciso atualizar pacotes. Para repositórios yum, atualmente espelho todos os repositórios necessários da Internet e disponibilizo os espelhos dentro da intranet. Eu mantenho cópias de cada repositório em cada um dos nossos cinco ambientes: desenvolvedor, controle de qualidade, preparo e dois datacenters de produção.

No momento, não resolvo para repositórios de pacotes específicos do idioma. Quando os servidores precisam de uma atualização de rubygems, PyPI, PECL, CPAN ou npm, eles precisam adquirir acesso temporário à Internet de saída para buscar os pacotes. Me pediram para começar a espelhar rubygems e PyPI, e o resto provavelmente se seguirá.

Tudo isso é desajeitado e não funciona bem. Gostaria de substituí-lo por um único proxy de cache em um ambiente e quatro proxies em cadeia nos meus outros ambientes, para eliminar a complexidade e a sobrecarga do disco de espelhos completos. Além disso:

• Pode ser um proxy direto ou reverso; cada gerenciador de pacotes suporta um servidor proxy ou um nó de extremidade do repositório customizado, que pode ser um espelho local ou um proxy reverso.
• Ele precisa de controle de acesso granular, para que eu possa limitar quais IPs de clientes podem se conectar a quais domínios de repo.
• Os clientes precisam seguir redirecionamentos para domínios desconhecidos. Sua solicitação original pode estar limitada ao rubygems.org, mas se esse servidor retornar 302 para uma CDN aleatória, você poderá segui-la.
• Ele deve suportar back-end HTTPS. Não preciso necessariamente representar outros servidores SSL, mas devo reexpor um site HTTPS por HTTP ou finalizar e criptografar novamente com um certificado diferente.

Inicialmente, eu estava procurando proxies reversos e o Varnish parece ser o único que me permitiria resolver internamente os redirecionamentos 302 dentro do proxy. No entanto, a versão gratuita do Varnish não suporta back-end HTTPS. Agora estou avaliando o Squid como uma opção de proxy de encaminhamento.

Isso parece ser algo que deveria ser um problema relativamente comum nas redes empresariais, mas estou tendo problemas para encontrar exemplos de como outras pessoas resolveram isso. Alguém implementou algo semelhante ou pensou em como fazer isso?

Obrigado!

Nós usamos o Squid para isso; o bom do squid é que você pode definir a expiração individual de objetos com base em uma correspondência de padrões com bastante facilidade, o que permite que os metadados do yum repo sejam eliminados rapidamente. A configuração que temos, que implementa isso:

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/

Esse é um caso de uso definitivo para um proxy . Um proxy normal, não um proxy reverso (também conhecido como balanceadores de carga).

O mais conhecido e gratuito e de código aberto é o squid . Felizmente, é um dos poucos bons softwares de código aberto que podem ser facilmente instalados com um único apt-get install squid3e configurados com um único arquivo /etc/squid3/squid.conf.

Analisaremos as boas práticas e as lições a serem conhecidas.

O arquivo de configuração oficial foi ligeiramente modificado (as 5000 linhas inúteis comentadas foram removidas).

#       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

Configuração do Cliente - Variáveis ​​de Ambiente

Configure essas duas variáveis ​​de ambiente em todos os sistemas.

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

A maioria das bibliotecas cliente http (libcurl, httpclient, ...) é auto configurável usando as variáveis ​​de ambiente. A maioria dos aplicativos está usando uma das bibliotecas comuns e, portanto, oferece suporte ao proxy imediato (sem que o desenvolvedor saiba necessariamente o que faz).

Observe que a sintaxe é estrita:

1. O nome da variável http_proxyDEVE estar em minúsculas na maioria dos Linux.
2. O valor da variável NÃO DEVE começar http(s)://(o protocolo de proxy não é http (s)).

Configuração do Cliente - Específica

Algumas aplicações estão ignorando variáveis ​​de ambiente e / ou são executadas como serviço antes que as variáveis ​​possam ser definidas (por exemplo, debian apt).

Esses aplicativos exigirão uma configuração especial (por exemplo /etc/apt.conf).

Proxy HTTPS - Conectar

A proxy HTTPS é totalmente suportada pelo design. Ele usa um método especial "CONNECT" que estabelece algum tipo de túnel entre o navegador e o proxy.

Não sei muito sobre isso, mas nunca tive problemas com isso há anos. Isso simplesmente funciona.

Caso especial HTTPS - Proxy transparente

Uma observação sobre proxy transparente. (ou seja, o proxy está oculto e intercepta solicitações de clientes ala. man-in-the-middle).

Proxies transparentes estão quebrando o HTTPS. O cliente não sabe que existe um proxy e não tem motivos para usar o método Connect especial.

O cliente tenta uma conexão HTTPS direta ... que é interceptada. A interceptação é detectada e erros são lançados em todo o lugar. (HTTPS destina-se a detectar ataques man-in-he-middle).

Lista de permissões de domínio e CDN

A lista de permissões de domínio e subdomínio é totalmente suportada pelo squid. No entanto, é provável que falhe de maneiras inesperadas de tempos em tempos.

Os sites modernos podem ter todos os tipos de redirecionamentos de domínio e CDN. Isso quebrará a ACL quando as pessoas não se esforçassem para colocar tudo em um único domínio.

Às vezes, haverá um instalador ou um pacote que deseja ligar para a casa ou recuperar dependências externas antes de executar. Ele falhará toda vez e não há nada que você possa fazer.

Armazenamento em cache

O arquivo de configuração fornecido está desativando todas as formas de cache. Melhor prevenir do que remediar.

Pessoalmente, estou executando coisas na nuvem no momento, todas as instâncias têm conectividade de pelo menos 100 Mbps e o provedor executa seus próprios repositórios para coisas populares (por exemplo, Debian) que são descobertas automaticamente. Isso faz da largura de banda uma mercadoria que eu não poderia me importar menos.

Prefiro desativar totalmente o cache do que experimentar um único bug de cache que derreterá meu cérebro na solução de problemas. Todas as pessoas na Internet NÃO PODEM acertar seus cabeçalhos de cache.

Porém, nem todos os ambientes têm os mesmos requisitos. Você pode ir além e configurar o cache.

NUNCA exija autenticação no proxy

Há uma opção para exigir autenticação de senha dos clientes, geralmente com suas contas LDAP. Ele quebrará todos os navegadores e todas as ferramentas de linha de comando do universo.

Se você deseja fazer autenticação no proxy, não faça.

Se o gerenciamento quiser autenticação, explique que não é possível.

Se você é desenvolvedor e acaba de ingressar em uma empresa que está bloqueando a Internet direta e forçando a autenticação por proxy, EXECUTE ONDE POSSO.

Conclusão

Passamos pela configuração comum, erros comuns e coisas que se deve saber sobre proxy.

Lição aprendida:

• Existe um bom software de código aberto para proxy (squid)
• É simples e fácil de configurar (um único arquivo curto)
• Todas as medidas de segurança (opcionais) têm vantagens e desvantagens
• As opções mais avançadas quebram coisas e voltam para assombrá-lo
• Proxies transparentes estão quebrando o HTTPS
• A autenticação de proxy é ruim

Como de costume na programação e no design do sistema, é fundamental gerenciar requisitos e expectativas.

Eu recomendo manter o básico ao configurar um proxy. De um modo geral, um proxy simples, sem nenhuma filtragem específica, funcionará bem e não causará nenhum problema. Só tenho que lembrar de (auto) configurar os clientes.

Isso não resolverá todas as suas tarefas, mas talvez isso ainda seja útil. Apesar do nome, o apt-cacher-ng não funciona apenas com o Debian e derivados, e é

um proxy de armazenamento em cache. Especializado para arquivos de pacote de distribuidores Linux, principalmente para distribuições Debian (e baseadas em Debian), mas não limitado a elas.

Estou usando isso na produção em um ambiente semelhante (baseado no Debian) como o seu.

No entanto, AFAIK, isso não suporta rubygems, PyPI, PECL, CPAN ou npm e não fornece ACLs granulares.

Pessoalmente, acho que investigar o Squid é uma boa ideia. Se você implementar uma configuração no final, poderia compartilhar suas experiências? Estou bastante interessado em como vai.

tivemos um desafio semelhante e o resolvemos usando repositórios locais e um sistema de armazenamento baseado em instantâneo. Basicamente, atualizamos o repositório de desenvolvimento, clonamos para teste, clonamos para teste e, finalmente, para produção. A quantidade de disco usado é limitada dessa maneira, além de todo o armazenamento sata lento e tudo bem.

Os clientes obtêm as informações do repositório em nosso gerenciamento de configurações, para que a troca seja fácil, se necessário.

Você pode conseguir o que deseja usando ás no servidor proxy usando cadeias de agente do usuário ou combinações de ips / máscara de origem e restringindo o acesso a determinados domínios, mas se você fizer esse problema, eu vejo é o de diferentes versões de pacotes / bibliotecas. Portanto, se um dos hosts puder acessar o cpan e solicitar o módulo xxx :: yyy, a menos que o cliente instrua a usar uma versão específica, obterá as últimas do cpan (ou pypy ou rubygems), que podem ou não ser as que já eram armazenado em cache no proxy. Portanto, você pode acabar com versões diferentes no mesmo ambiente. Você não terá esse problema se usar repositórios locais.