Instalar Squid forward proxy com SSL cache (SSL bump) em Rocky Linux 8.9 para cache de pacotes na infrestrutura

- dezembro 21, 2023

Objetivos:

O objetivo é acelerar a instalação de pacotes de atualização de sistema operacional e outros arquivos numa infraestrutura com várias máquinas virtuais / virtual machines.

É um acesso da infraestrutura interna para a internet aberta, até os repositórios de pacotes, com conexões SSL. Por isso o nome forward proxy.

Note a diferença para um reverse proxy que, por exemplo, acelera a entrega de conteúdo de um servidor web para a internet pública.

Utilizaremos Squid proxy, que é naturalmente um forward proxy.
O Nginx é naturalmente um reverse proxy. Somente com uso de patch consegue fazer forward proxy, com protocolo HTTP CONNECT.
E não conseguimos fazer cache de conteúdo https nele, nem com certificado auto-assinado, para descriptografar, armazenar, criptografar novamente.

Usaremos a ferramenta mais adequada para a necessidade, neste caso, o Squid.

Geralmente, os forward proxies apenas estabelecem a conexão SSL usando HTTP CONNECT, que cria um túnel entre o cliente local através do proxy até o servidor original sem fazer cache dos pacotes.

Para fazer cache local é necessário uma técnica de man-in-the-middle (MITM), descriptografando a conexão SSL, fazendo cache local, e recriptografando o conteúdo assinando com chave própria.

A chave própria pode ser válida por autoridade certificadora (CA) ou auto-assinada, já que o forward proxy será usado apenas na infraestrutura interna.

Se a chave for auto-assinada, terá de ser incluída no chaveiro / key-chain para aceitação em todas as máquinas da infraestrutura.

Considerações sobre Squid em container docker em ambientes de nuvem:

As primeiras implementações tentaram fazer um Squid, dentro de um container docker de Ubuntu, dentro de uma VM Rocky Linux como docker host, rodando sobre nuvem VmWare.

Depois alteramos para usar um IP estático próprio com driver ipvlan (macvlan precisa modo promíscuo de interface do docker host, o que nos seria inviável na infraestrutura VmWare por regras de segurança) em vez do IP do docker host com porta mapeada, nem o tipo host de rede. Isso para poder preservar o IP de origem de conexão.

Porém ainda não havíamos conseguido fazer o NAT no nossa nuvem VmWare fazer roteamento de retorno dos pacotes para o container quando configurado com IP estático próprio.

Os pacotes até saem da infraestrutura, mas a resposta não retorna para o container.

O container funciona bem num docker host em bare metal sobre Ubuntu. Futuramente, com mais tempo, faremos novas tentativas de configuração de NAT e de rede tipo host.

Devido a isso tudo fizemos uma nova implantação diretamente em uma VM Rocky Linux.

Desde 2016 constatam que iptables POSTROUTING inviabiliza drivers macvlan e ipvlan em ambientes de nuvem, que não deixam colocar interfaces em modo promíscuo nos NAT.
https://github.com/moby/moby/issues/21735

Talvez uma alternativa seja usar segunda interface física e tentar criar uma rede BRIDGE normal nova e atrelada a essa interface do docker host, com gateway e rotas próprias já na vm do docker host. Veremos.

/etc/squid/squid.conf

Leia com atenção e ADAPTE às suas necessidades, principalmente tamanhos e diretórios e RAM.

Reparar a configuração de SSL database do Squid e os requisitos para o diretório, usar caminhos absolutos, e posicionamento no arquivo de configuração, pois a ordem faz diferença para alguns parâmetros do Squid.

Você precisa inicializar a SSL database ANTES de começar a usar o Squid. Só precisará fazer uma vez.

Também que escolhemos aufs para o cache dir.

Um problema que persiste, nas novas versões de Squid, é como preferir conexões IPV4 sobre as IPV6. Antigamente, havia parâmetro para isso (comentado no arquivo), mas agora o Squid atende a quem responder primeiro.

Portanto, você terá de controlar isso por fora do Squid.

Nos procedimentos mais adiante, chamamos o arquivo de squid_rocky.conf

A porta para https será 4128 e a porta http 3128.

Repare que desabilitamos a verificação de certificados por estarmos usando um auto-assinado.

#
# Recommended minimum configuration:
#

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8    # RFC1918 possible internal network
acl localnet src 172.16.0.0/12    # RFC1918 possible internal network
acl localnet src 192.168.0.0/16    # RFC1918 possible internal network
acl localnet src fc00::/7       # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines

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 70        # gopher
acl Safe_ports port 210        # wais
acl Safe_ports port 1025-65535    # unregistered ports
acl Safe_ports port 280        # http-mgmt
acl Safe_ports port 488        # gss-http
acl Safe_ports port 591        # filemaker
acl Safe_ports port 777        # multiling http
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

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost

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

# Squid normally listens to port 3128
http_port 3128

# Squid normally listens to port 4128 for ssl bump
http_port 4128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/ssl/certs/selfsigned.pem key=/etc/ssl/certs/selfsigned.key

#AFM For squid >= 4.x initialize cert db on debian/ubuntu at dockerfile. here only run cert db on the fly generator. It MUST be outside cache_dir.
sslcrtd_program /usr/lib64/squid/security_file_certgen -s /data/squidssldatabase/ssl_db -M 4MB
acl step1 at_step SslBump1 #there are 3 hardcoded sslbump step names.
ssl_bump peek step1
ssl_bump bump all
ssl_bump server-first all

always_direct allow all

#AFM should be placed above cache_dir
range_offset_limit 10 GB
maximum_object_size 10 GB
quick_abort_min -1

# Uncomment and adjust the following to add a disk cache directory. disk space in MB
#AFM
cache_dir aufs /data/squid 10000 16 256

# Leave coredumps in the first cache dir
coredump_dir /data/squid

#
# Add any of your own refresh_pattern entries above these.
#
refresh_pattern ^ftp:        1440    20%    10080
refresh_pattern ^gopher:    1440    0%    1440
refresh_pattern -i (/cgi-bin/|\?) 0    0%    0
refresh_pattern .        30    20%    4320 reload-into-ims

#AFM prefer ipv4 over ipv6
dns_v4_first on #obsolete?
#AFM dangerous, disabling verification
sslproxy_cert_error allow all
#sslproxy_flags DONT_VERIFY_PEER #obsolete
tls_outgoing_options options=ALL flags=DONT_VERIFY_PEER

Procedimentos:

Comandos a executar no Rocky Linux ANTES de executar Squid

Copiar o squid_rocky.conf para /etc/squid/squid.conf, fazendo antes um backup do arquivo original.

dnf update

dnf install squid

mv /etc/squid/squid.conf /etc/squid/squid.conf.original

Copiar o squid_rocky.conf da estação local para /etc/squid/squid.conf e os certificados (jump através de entreposto, neste exemplo)

scp -r -J andre@entreposto -o ServerAliveInterval=60 ./squid_rocky.conf root@squidhost:/etc/squid/squid.conf

scp -r -J andre@entreposto -o ServerAliveInterval=60 ./selfsigned.* root@squidhost:/etc/ssl/certs/

Executar no squidhost:

ls -lah /etc/ssl/certs/

Habilitar o serviço squid:

systemctl status squid.service
systemctl enable squid
systemctl status squid.service

Crie um diretório para Squid SSL database, ajuste permissões e inicialize o database.

mkdir -p /data/squidssldatabase &&\
chown -R squid:squid /data/squidssldatabase &&\
/usr/lib64/squid/security_file_certgen -c -s /data/squidssldatabase/ssl_db -M 4MB &&\
chown -R squid:squid /data/squidssldatabase/ssl_db
mkdir -p /data/squid &&\
chown -R squid:squid /data/squid

Inclua o certificado auto-assinado para ser reconhecido no servidor e nas máquinas que vão utilizar o ssl forward proxy:

less /etc/pki/ca-trust/source/README
cp /etc/ssl/certs/selfsigned.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust --extract

Inicie o serviço Squid:

systemctl start squid
journalctl -xe

Testando o funcionamento:

export ftp_proxy='http://squidhost:4128'; export https_proxy='http://squidhost:4128'; export http_proxy='http://squidhost:4128'

time wget -v --no-check-certificate https://dl.rockylinux.org/pub/rocky/8/BaseOS/x86_64/os/Packages/g/glibc-all-langpacks-2.28-225.el8_8.6.x86_64.rpm

tail /var/log/squid/cache.log

tail /var/log/squid/access.log

Verifique a saída dos logs.

Liste o conteúdo do cache_dir .

Execute outra vez o wget e os comandos tail, avaliando se houve HIT e a diferença de velocidades.

Liste o conteúdo do cache_dir outra vez e examine. Os arquivos são guardados numa árvore de diretórios e não preservam os nomes, apenas o conteúdo e tamanho.

Bibliografia

Pesquisar este blog

Tech Force - blog sobre tecnologia