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:
- Le nom de la variable
http_proxyDOIT être en minuscules sur la plupart des Linux.
- 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
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.
la source
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.
la source