J'ai une collection de serveurs CentOS dans mon réseau d'entreprise. Pour des raisons de sécurité, la plupart des serveurs ne disposent pas d'un accès Internet sortant général, sauf s'il s'agit d'une exigence fonctionnelle essentielle pour le serveur.

Cela crée un défi lorsque j'ai besoin de mettre à jour des packages. Pour les référentiels yum, je reflète actuellement tous les référentiels nécessaires à partir d'Internet, et rend les miroirs disponibles à l'intérieur de l'intranet. Je conserve des copies de chaque référentiel dans chacun de nos cinq environnements: dev, QA, staging et deux datacenters de production.

Je ne résout pas actuellement les dépôts de packages spécifiques à la langue. Lorsque les serveurs ont besoin d'une mise à jour depuis rubygems, PyPI, PECL, CPAN ou npm, ils doivent acquérir un accès Internet sortant temporaire pour récupérer les packages. On m'a demandé de commencer à mettre en miroir rubygems et PyPI, et le reste suivra probablement.

Tout cela est maladroit et ne fonctionne pas bien. Je voudrais le remplacer par un seul proxy de mise en cache dans un environnement et quatre proxys en chaîne dans mes autres environnements, pour éliminer la complexité et la surcharge disque des miroirs complets. Aditionellement:

• Il peut s'agir d'un proxy direct ou inverse; chaque gestionnaire de packages prend en charge un serveur proxy ou un point de terminaison de référentiel personnalisé, qui peut être un miroir local ou un proxy inverse.
• Il a besoin d'un contrôle d'accès granulaire, donc je peux limiter les adresses IP clientes qui peuvent se connecter à quels domaines repo.
• Les clients doivent pouvoir suivre les redirections vers des domaines inconnus. Votre demande d'origine peut être limitée à rubygems.org, mais si ce serveur renvoie un 302 à un CDN aléatoire, vous devriez pouvoir la suivre.
• Il devrait prendre en charge les backends HTTPS. Je n'ai pas nécessairement besoin d'emprunter l'identité d'autres serveurs SSL, mais je devrais être en mesure de réexposer un site HTTPS via HTTP, ou de terminer et de rechiffrer avec un certificat différent.

Au départ, je cherchais des proxy inverses, et Varnish semble être le seul qui me permettrait de résoudre en interne 302 redirections dans le proxy. Cependant, la version gratuite de Varnish ne prend pas en charge les backends HTTPS. J'évalue maintenant Squid comme une option de proxy direct.

Cela semble être quelque chose qui devrait être un problème relativement courant dans les réseaux d'entreprise, mais j'ai du mal à trouver des exemples de la façon dont d'autres personnes ont résolu ce problème. Quelqu'un a-t-il mis en œuvre quelque chose de similaire ou réfléchi à la meilleure façon de le faire?

Merci!

Nous utilisons Squid pour cela; la bonne chose à propos de calmar est que vous pouvez définir une expiration individuelle des objets basée sur une correspondance de modèle, assez facilement, ce qui permet de purger assez rapidement les métadonnées du référentiel yum. La configuration que nous avons qui implémente ceci:

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/

C'est un cas d'utilisation définitif pour un proxy . Un proxy normal, pas un proxy inverse (aka. Équilibreurs de charge).

Le calmar est le plus connu, le plus libre et le plus ouvert . Heureusement, c'est l'un des rares bons logiciels open source qui peut facilement être installé avec un seul apt-get install squid3et configuré avec un seul fichier /etc/squid3/squid.conf.

Nous passerons en revue les bonnes pratiques et les leçons à connaître.

Le fichier de configuration officiel a été légèrement modifié (les 5000 lignes commentées inutiles ont été supprimées).

#       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

Configuration du client - Variables d'environnement

Configurez ces deux variables d'environnement sur tous les systèmes.

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

La plupart des bibliothèques client http (libcurl, httpclient, ...) sont auto-configurables à l'aide des variables d'environnement. La plupart des applications utilisent l'une des bibliothèques communes et prennent donc en charge le proxy par défaut (sans que le développeur sache nécessairement qu'elles le font).

Notez que la syntaxe est stricte:

1. Le nom de la variable http_proxyDOIT être en minuscules sur la plupart des Linux.
2. La valeur de la variable NE DOIT PAS commencer par http(s)://(le protocole de proxy n'est PAS http (s)).

Configuration du client - spécifique

Certaines applications ignorent les variables d'environnement et / ou sont exécutées en tant que service avant de pouvoir définir des variables (par exemple debian apt).

Ces applications nécessiteront une configuration spéciale (par exemple /etc/apt.conf).

Proxy HTTPS - Se connecter

Le proxy HTTPS est entièrement pris en charge par la conception. Il utilise une méthode spéciale "CONNECT" qui établit une sorte de tunnel entre le navigateur et le proxy.

Je ne sais pas grand chose sur cette chose mais je n'ai jamais eu de problème avec ça depuis des années. Ça marche juste.

Cas spécial HTTPS - proxy transparent

Une note sur le proxy transparent. (c'est-à-dire que le proxy est caché et qu'il intercepte les demandes des clients, notamment man-in-the-middle).

Les proxys transparents cassent HTTPS. Le client ne sait pas qu'il existe un proxy et n'a aucune raison d'utiliser la méthode spéciale Connect.

Le client essaie une connexion HTTPS directe ... qui est interceptée. L'interception est détectée et des erreurs sont lancées partout. (HTTPS est destiné à détecter les attaques d'homme au milieu).

Liste blanche de domaine et CDN

La liste blanche de domaine et de sous-domaine est entièrement prise en charge par Squid. Néanmoins, il échouera de manière inattendue de temps en temps.

Les sites Web modernes peuvent avoir toutes sortes de redirections de domaine et CDN. Cela cassera l'ACL lorsque les gens ne font pas tout leur possible pour tout mettre proprement dans un seul domaine.

Parfois, il y aura un programme d'installation ou un package qui souhaite appeler le vaisseau ou récupérer des dépendances externes avant de s'exécuter. Il échouera à chaque fois et vous ne pourrez rien y faire.

Mise en cache

Le fichier de configuration fourni désactive toutes les formes de mise en cache. Mieux vaut prévenir que guérir.

Personnellement, j'exécute des choses dans le cloud pour le moment, toutes les instances ont au moins 100 Mbps de connectivité et le fournisseur exécute ses propres dépôts pour les choses populaires (par exemple Debian) qui sont découvertes automatiquement. Cela fait de la bande passante un produit dont je ne me soucie pas.

Je préfère désactiver totalement la mise en cache plutôt que de rencontrer un seul bogue de mise en cache qui fera fondre mon cerveau lors du dépannage. Chaque personne sur Internet NE PEUT PAS obtenir ses en-têtes de mise en cache correctement.

Cependant, tous les environnements n'ont pas les mêmes exigences. Vous pouvez aller plus loin et configurer la mise en cache.

JAMAIS JAMAIS exiger d'authentification sur le proxy

Il existe une option pour exiger l'authentification par mot de passe des clients, généralement avec leurs comptes LDAP. Il cassera tous les navigateurs et tous les outils de ligne de commande de l'univers.

Si vous voulez faire une authentification sur le proxy, ne le faites pas.

Si la direction souhaite une authentification, expliquez que ce n'est pas possible.

Si vous êtes un développeur et que vous venez de rejoindre une entreprise qui bloque Internet direct ET force l'authentification par proxy, RUN AWAY WHILE YOU CAN.

Conclusion

Nous sommes passés par la configuration commune, les erreurs courantes et les choses à savoir sur le proxy.

Leçon apprise:

• Il existe un bon logiciel open source pour le proxy (calmar)
• C'est simple et facile à configurer (un seul fichier court)
• Toutes les mesures de sécurité (facultatives) ont des compromis
• Les options les plus avancées casseront des trucs et reviendront vous hanter
• Les proxys transparents cassent le HTTPS
• L'authentification proxy est mauvaise

Comme d'habitude dans la programmation et la conception du système, il est essentiel de gérer les exigences et les attentes.

Je recommande de s'en tenir aux bases lors de la configuration d'un proxy. De manière générale, un simple proxy sans aucun filtrage particulier fonctionnera bien et ne posera aucun problème. N'oubliez pas de configurer (automatiquement) les clients.

Cela ne résoudra pas toutes vos tâches, mais c'est peut-être toujours utile. Malgré son nom, apt-cacher-ng ne fonctionne pas seulement avec Debian et ses dérivés, et est

un proxy de mise en cache. Spécialisé pour les fichiers de paquets des distributeurs Linux, principalement pour les distributions Debian (et basées sur Debian) mais sans s'y limiter.

J'utilise ceci en production dans un environnement similaire (basé sur Debian) comme le vôtre.

Cependant, AFAIK, cela ne prend pas en charge rubygems, PyPI, PECL, CPAN ou npm et ne fournit pas de listes de contrôle d'accès granulaires.

Personnellement, je pense que l'enquête sur Squid est une bonne idée. Si vous implémentez une configuration à la fin, pourriez-vous s'il vous plaît partager vos expériences? Je suis assez intéressé par la façon dont ça se passe.

nous avons eu un défi similaire et nous l'avons résolu en utilisant des dépôts locaux et un système de stockage basé sur des instantanés. Nous mettons essentiellement à jour le référentiel de développement, le clonons pour le tester, le clonons pour le staging et enfin pour la production. La quantité de disque utilisée est limitée de cette façon, en plus c'est un stockage sata lent et c'est correct.

Les clients obtiennent les informations du référentiel de notre gestion de la configuration, ce qui facilite le changement si nécessaire.

Vous pouvez obtenir ce que vous voulez en utilisant ace sur le serveur proxy en utilisant des chaînes d'agent utilisateur ou des combinaisons ips / masque source et en restreignant leur accès à certains domaines, mais si vous faites cela, un problème que je vois est celui de différentes versions de packages / bibliothèques. Donc, si l'un des hôtes peut accéder à cpan et demande le module xxx :: yyy à moins que le client ne demande d'utiliser une version spécifique, tirera la dernière de cpan (ou pypy ou rubygems), qui peut ou non être celle qui était déjà mis en cache dans le proxy. Vous pourriez donc vous retrouver avec différentes versions sur le même environnement. Vous n'aurez pas ce problème si vous utilisez des référentiels locaux.