Ho una collezione di server CentOS nella mia rete aziendale. Per motivi di sicurezza, la maggior parte dei server non ha un accesso generale a Internet in uscita a meno che non sia un requisito funzionale fondamentale per il server.

Questo crea una sfida quando devo aggiornare i pacchetti. Per i repository yum, attualmente eseguo il mirroring di tutti i repository necessari da Internet e rendo i mirror disponibili all'interno della rete Intranet. Conservo copie di ciascun repository in ciascuno dei nostri cinque ambienti: dev, QA, staging e due datacenter di produzione.

Al momento non risolvo per repository di pacchetti specifici della lingua. Quando i server necessitano di un aggiornamento da rubygems, PyPI, PECL, CPAN o npm, devono acquisire un accesso temporaneo a Internet in uscita per recuperare i pacchetti. Mi è stato chiesto di iniziare a rispecchiare rubygems e PyPI, e probabilmente il resto seguirà.

Tutto questo è goffo e non funziona bene. Vorrei sostituirlo con un singolo proxy di memorizzazione nella cache in un ambiente e quattro proxy concatenati negli altri miei ambienti, per eliminare la complessità e l'overhead del disco dei mirror completi. Inoltre:

• Può essere un proxy forward o reverse; ciascun gestore pacchetti supporta un server proxy o un endpoint di repository personalizzato, che può essere un mirror locale o un proxy inverso.
• Ha bisogno di un controllo granulare degli accessi, quindi posso limitare quali IP client possono connettersi a quali domini repo.
• I clienti devono essere in grado di seguire i reindirizzamenti verso domini sconosciuti. La tua richiesta originale potrebbe essere limitata a rubygems.org, ma se quel server restituisce un 302 a un CDN casuale, dovresti essere in grado di seguirlo.
• Dovrebbe supportare i backend HTTPS. Non devo necessariamente impersonare altri server SSL, ma dovrei essere in grado di ri-esporre un sito HTTPS su HTTP o terminare e ricrittografare con un certificato diverso.

Inizialmente stavo guardando i proxy inversi e Varnish sembra essere l'unico che mi avrebbe permesso di risolvere internamente 302 reindirizzamenti all'interno del proxy. Tuttavia, la versione gratuita di Varnish non supporta i backend HTTPS. Sto valutando Squid come un'opzione proxy diretta.

Sembra qualcosa che dovrebbe essere un problema relativamente comune all'interno delle reti aziendali, ma ho difficoltà a trovare esempi di come gli altri hanno risolto questo problema. Qualcuno ha implementato qualcosa di simile o ha pensato al modo migliore per farlo?

Grazie!

Usiamo Squid per questo; la cosa bella di calamari è che puoi impostare la scadenza individuale degli oggetti in base a una corrispondenza del modello, abbastanza facilmente, che consente di eliminare abbastanza rapidamente i metadati dal repo yum. La configurazione che abbiamo che implementa questo:

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/

Questo è un caso d'uso definitivo per un proxy . Un proxy normale, non un proxy inverso (ovvero bilanciamento del carico).

Il calamaro più conosciuto, gratuito e open source . Fortunatamente è uno dei pochi buoni software open source che può essere facilmente installato con un singolo apt-get install squid3e configurato con un singolo file /etc/squid3/squid.conf.

Esamineremo le buone pratiche e le lezioni da conoscere.

Il file di configurazione ufficiale è stato leggermente modificato (sono state rimosse le 5000 righe commentate inutili).

#       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

Configurazione client - Variabili d'ambiente

Configurare queste due variabili di ambiente su tutti i sistemi.

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

La maggior parte delle librerie client http (libcurl, httpclient, ...) si auto-configurano usando le variabili d'ambiente. La maggior parte delle applicazioni utilizza una delle librerie comuni e quindi supporta il proxy out-of-the-box (senza che lo sviluppatore necessariamente sappia che lo fanno).

Si noti che la sintassi è rigorosa:

1. Il nome della variabile http_proxyDEVE essere in minuscolo sulla maggior parte di Linux.
2. Il valore della variabile NON DEVE iniziare con http(s)://(il protocollo di proxy NON è http (s)).

Configurazione client: specifica

Alcune applicazioni ignorano le variabili di ambiente e / o vengono eseguite come servizio prima che le variabili possano essere impostate (ad es. Debian apt).

Queste applicazioni richiedono una configurazione speciale (ad es /etc/apt.conf.).

Proxy HTTPS - Connetti

Il proxy HTTPS è completamente supportato dalla progettazione. Utilizza uno speciale metodo "CONNECT" che stabilisce una sorta di tunnel tra il browser e il proxy.

Non so molto di quella cosa, ma non ho mai avuto problemi con esso da anni. Funziona e basta.

Caso speciale HTTPS - Proxy trasparente

Una nota sul proxy trasparente. (ovvero il proxy è nascosto e intercetta le richieste dei client ala. man-in-the-middle).

I proxy trasparenti stanno rompendo HTTPS. Il client non sa che esiste un proxy e non ha motivo di utilizzare lo speciale metodo Connect.

Il client tenta una connessione HTTPS diretta ... che viene intercettata. L'intercettazione viene rilevata e gli errori vengono generati ovunque. (HTTPS ha lo scopo di rilevare attacchi man-in-he-middle).

Lista bianca domini e CDN

La whitelisting di domini e sottodomini è completamente supportata da squid. Tuttavia, è tenuto a fallire in modi inaspettati di volta in volta.

I siti Web moderni possono avere tutti i tipi di reindirizzamenti di dominio e CDN. Ciò interromperà l'ACL quando la gente non ha fatto il possibile per mettere tutto in un unico dominio.

A volte ci sarà un programma di installazione o un pacchetto che vuole chiamare l'homeship o recuperare dipendenze esterne prima di eseguirlo. Fallirà ogni volta e non c'è niente che tu possa fare al riguardo.

caching

Il file di configurazione fornito disabilita tutte le forme di memorizzazione nella cache. Meglio prevenire che curare.

Personalmente, sto eseguendo cose nel cloud al momento, tutte le istanze hanno una connettività di almeno 100 Mbps e il provider esegue i propri repository per cose popolari (ad esempio Debian) che vengono scoperte automaticamente. Ciò rende la larghezza di banda un prodotto di cui non me ne può fregare di meno.

Preferirei disabilitare totalmente la cache piuttosto che sperimentare un singolo bug di cache che mi scioglierà il cervello nella risoluzione dei problemi. Ogni singola persona su Internet NON PU get ottenere le intestazioni della cache correttamente.

Tuttavia, non tutti gli ambienti hanno gli stessi requisiti. Puoi fare il possibile e configurare la memorizzazione nella cache.

MAI MAI richiesto l'autenticazione sul proxy

C'è un'opzione per richiedere l'autenticazione della password dai client, in genere con i loro account LDAP. Romperà ogni browser e ogni strumento da riga di comando nell'universo.

Se si desidera eseguire l'autenticazione sul proxy, non farlo.

Se la direzione desidera l'autenticazione, spiegare che non è possibile.

Se sei uno sviluppatore e sei appena entrato in una società che sta bloccando Internet diretto e costringendo l'autenticazione proxy, CORRI LONTANO MENTRE PUOI.

Conclusione

Abbiamo esaminato la configurazione comune, gli errori comuni e le cose che uno deve sapere sul proxy.

Lezione imparata:

• Esiste un buon software open source per il proxy (calamari)
• È semplice e facile da configurare (un singolo file breve)
• Tutte le misure di sicurezza (facoltative) presentano compromessi
• Le opzioni più avanzate romperanno le cose e torneranno a perseguitarti
• I proxy trasparenti stanno rompendo HTTPS
• L'autenticazione proxy è malvagia

Come al solito nella programmazione e nella progettazione del sistema, è fondamentale gestire requisiti e aspettative.

Consiglio di attenersi alle basi quando si configura un proxy. In generale, un proxy semplice senza alcun filtro particolare funzionerà bene e non darà alcun problema. Devo solo ricordare di (auto) configurare i client.

Questo non risolverà tutti i tuoi compiti, ma forse è ancora utile. Nonostante il nome, apt-cacher-ng non funziona solo con Debian e derivati, ed è

un proxy di memorizzazione nella cache. Specializzato per i file dei pacchetti dai distributori Linux, principalmente per le distribuzioni Debian (e basate su Debian) ma non limitati a quelli.

Sto usando questo in produzione in un ambiente simile (basato su Debian) come il tuo.

Tuttavia, AFAIK, questo non supporta rubygem, PyPI, PECL, CPAN o npm e non fornisce ACL granulari.

Personalmente, penso che indagare su Squid sia una buona idea. Se alla fine implementi una configurazione, potresti condividere le tue esperienze? Sono abbastanza interessato a come va.

abbiamo avuto una sfida simile e l'abbiamo risolta utilizzando repository locali e un sistema di archiviazione basato su snapshot. Fondamentalmente aggiorniamo il repository di sviluppo, lo cloniamo per i test, lo cloniamo per lo staging e infine per la produzione. La quantità di disco utilizzata è limitata in questo modo, inoltre è tutto archiviazione sata lenta e va bene.

I client ottengono le informazioni sul repository dalla nostra gestione della configurazione, quindi il passaggio è semplice se necessario.

È possibile ottenere ciò che si desidera utilizzando gli assi sul server proxy utilizzando stringhe agente utente o combinazioni ips / maschera di origine e limitando il loro accesso a determinati domini, ma se si verifica quell'unico problema che vedo è quello di diverse versioni di pacchetti / librerie. Quindi, se uno degli host può accedere a cpan e richiede il modulo xxx :: yyy a meno che il client non indichi di utilizzare una versione specifica, estrarrà l'ultimo da cpan (o pypy o rubygems), che potrebbe essere o meno quello che era già memorizzato nella cache del proxy. Quindi potresti finire con versioni diverse nello stesso ambiente. Non avrai questo problema se usi i repository locali.