Le serveur proxy certifié en interne n'est qu'un obstacle au développement logiciel. Les applications qui ne prennent pas en charge le proxy avec authentification, la configuration des changements à chaque fois en changeant les mots de passe, la définition des différences entre les membres du développement ... J'ai toujours été troublée par ces problèmes. Quand je l'ai regardé là-haut, j'ai découvert que les ancêtres utilisaient Squid pour configurer un serveur proxy d'authentification [^ 1], et j'ai également installé Squid sur le Mac et je l'ai utilisé. (Très pratique!)
Cependant, les membres du développement en sont venus à dire des choses comme "La sécurité est-elle d'accord avec ça?" Et "Ce n'est pas bon parce que l'environnement change avec les autres membres."
Puisqu'il n'y a aucune aide pour cela, j'ai déployé le script de construction de proxy d'authentification pour Mac auprès des membres et j'ai réussi à unifier l'environnement pour le moment. Cependant, le mécanisme du contenu (en particulier Squid) n'a pas été tellement développé, donc s'il y a un problème, je dois le considérer, et je n'ai pas été en mesure de l'étendre beaucoup à d'autres projets.
Cette fois, nous avons rendu possible la construction d'un serveur proxy d'authentification aussi simplement que possible avec uniquement Docker, nous allons donc introduire le mécanisme en se concentrant sur les paramètres de Squid.
[^ 1]: Conteneur Docker avec proxy authentifié sans authentification ou [Réduire le stress causé par le proxy authentifié avec squid](https: / /qiita.com/scalper/items/e945dd103d356db6eae6), Ignorer l'authentification du proxy d'authentification en configurant le proxy HTTP sur mac, etc. Il y en a aussi beaucoup.
Cette fois, nous présenterons les référentiels suivants. Veuillez consulter ici pour les dernières informations.
https://github.com/k-ishigaki/proxy-docker
Cela devrait fonctionner si Docker (Docker Compose) est installé. La version de Docker que j'ai utilisée était:
$ docker version
(Omis)
Server: Docker Engine - Community
Engine:
Version: 19.03.12
API version: 1.40 (minimum version 1.12)
(Omis)
$ docker --version
Docker version 19.03.9, build 9d988398e7
$ docker-compose --version
docker-compose version 1.26.2, build eefe0d31
Configurez un serveur proxy d'authentification (Squid) sur le conteneur Docker et ajoutez des informations d'authentification (en-tête d'autorisation). En faisant cela, les applications qui utilisent le proxy pourront se connecter à Internet sans authentification.
Je vais expliquer les paramètres de squid.conf.template un par un.
Réglez le port de veille sur 8080.
Si vous ne définissez pas visible_hostname
, une erreur sera affichée disant" Il n'est pas défini ", alors réglez-le sur aucun
[^ visible_hostname].
Activez DNS. Si cela est défini, vous pourrez spécifier le serveur proxy pour le nom de domaine. (Il semble que certains environnements ne fonctionnent pas, mais je n'en connais pas la cause.)
http_port 8080
visible_hostname none
dns_defnames on
[^ visible_hostname]: Définissez visible_hostname, ce qui provoque une erreur en essayant de démarrer squid après un long moment!
Définissez l'ACL (Contrôle d'Accès) de Squid.
localnet
définit l'accès depuis le réseau local, to_localnet_fast
définit l'accès au réseau local, to_localhost_fast
définit l'accès à l'hôte local et to_direct_access_domains
définit l'accès au domaine spécifié.
Dans l'ACL dst
(destination), l'indicateur -n
est spécifié pour désactiver la recherche DNS. S'il est activé, l'accès au réseau sera extrêmement lent.
De plus, to_direct_access_domains
spécifie d'inclure les domaines spécifiés dans .direct_access_domains
[^ direct_access_domains].
[^ direct_access_domains]: j'essaie d'importer à partir d'un autre fichier afin de pouvoir définir facilement le domaine d'exclusion de proxy tel que le site portail interne.
acl localnet src 0.0.0.1-0.255.255.255
acl localnet src 10.0.0.0/8
(Omis)
acl to_localnet_fast dst -n 0.0.0.1-0.255.255.255
acl to_localnet_fast dst -n 10.0.0.0/8
(Omis)
acl to_localhost_fast dst -n 127.0.0.0/8
acl to_direct_access_domains dstdomain -n "/.direct_access_domains"
Spécifie le réseau qui autorise l'accès à Squid. Seul l'accès depuis le réseau interne est autorisé [^ http_access].
[^ http_access]: Afin d'autoriser l'accès à partir d'environnements virtuels tels que VirtualBox, l'accès depuis non seulement localhost mais aussi localnet est autorisé.
http_access allow localhost
http_access allow localnet
Spécifiez la demande de transfert vers le serveur proxy avec authentification.
Par défaut, Squid opère "essayez de transférer vers le proxy spécifié par cache_peer
, et si cela est impossible, essayez de vous connecter directement", doncnever_direct autorise <destination de connexion autre que la destination de connexion qui permet une connexion directe>
Spécifiez la destination de connexion qui interdit [^ always_direct].
[^ always_direct]: always_direct allow <destination de connexion qui permet la connexion directe>
n'est pas défini car lors de la connexion au réseau d'entreprise via VPN, il se connecte via le proxy.
Spécifiez le proxy parent (proxy avec authentification) avec cache_peer
.
Remplacez les variables telles que «$ proxy_port» par «envsubst» lors du démarrage du conteneur Docker.
never_direct allow !to_localhost_fast !to_localnet_fast !to_direct_access_domains
cache_peer $proxy_host parent $proxy_port 0 proxy-only no-digest no-netdb-exchange login=$proxy_auth
Par défaut, les serveurs proxy tels que Squid transportent des informations telles que PROXY_VIA
qui dit" Je passe par un proxy ".
Selon l'environnement, si l'en-tête de communication est différent, la communication peut ne pas être possible, supprimez donc les informations que Squid met tout seul.
De plus, pour ne fonctionner que pour le transfert, le cache de Squid est désactivé avec cache deny all
.
forwarded_for delete
via off
cache deny all
request_header_access Cache-Control deny all
request_header_access Connection deny all
request_header_add Proxy-Connection "Keep-Alive" all
L'image Docker est créée et démarrée via Docker Compose.
Puisqu'il est nécessaire de définir le proxy à construire, définissez HTTP_PROXY_FOR_PROXY
dans la variable d'environnement pour générer et démarrer.
Pour extraire l'image de base (Alpine), il est nécessaire de définir le proxy côté Docker Daemon, mais comme la méthode de paramétrage diffère selon l'environnement d'exécution Docker, chargez l'image locale avec load au lieu de télécharger avec pull. Je le fais.
Si «<proxy_user>» et «<proxy_password>» contiennent des symboles, vous devez entrer la valeur encodée en URL.
cd proxy-docker
docker load ./alpine.tar
HTTP_PROXY_FOR_PROXY=http://<proxy_user>:<proxy_password>@<proxy_host>:<proxy_port> HOST_PORT=8080 docker-compose up -d
Les paramètres de construction et de démarrage sont définis dans docker-compose.yml
.
J'essaye de mettre «HTTP_PROXY» et «HTTPS_PROXY» dans «args» (variable d'environnement au moment de la construction) et «environnement» (variable d'environnement au démarrage).
De plus, le port côté hôte peut être défini avec HOST_PORT
.
Si le port 8080 est déjà rempli, vous pouvez spécifier un autre port.
version: "3.4"
x-proxy_settings: &proxy_settings
HTTP_PROXY: "${HTTP_PROXY_FOR_PROXY:?HTTP_PROXY_FOR_PROXY must be set. Prease read README}"
HTTPS_PROXY: "${HTTP_PROXY_FOR_PROXY}"
services:
proxy:
build:
context: .
args:
<<: *proxy_settings
environment:
<<: *proxy_settings
ports:
- "${HOST_PORT:-8080}:8080"
Comme il est long, je vais omettre le contenu, mais je fais ce qui suit.
HTTP_PROXY
et installez SquidHTTP_PROXY
et lancez SquidJ'ai brièvement présenté comment configurer un serveur proxy d'authentification à l'aide de Squid et comment le lancer avec Docker. Nous espérons que le plus grand nombre de personnes possible pourra utiliser ces informations pour se débarrasser des inconvénients du proxy authentifié.
Recommended Posts