Exiger à la fois une connexion Squid et la bonne IP client

Un mot de passe correct ne représente que la moitié de cette politique : le compte doit aussi fonctionner depuis une adresse client approuvée. Dans Squid, placer les deux contrôles sur la même règle d'accès fait toute la différence entre cette exigence et deux voies d'entrée distinctes.

En supposant que l'authentification est déjà configurée, par exemple une configuration NCSA de Squid 6.13, la politique de base est la suivante :

acl approved_login proxy_auth alex
acl approved_source src 192.0.2.40/32
http_access allow approved_source approved_login
http_access deny all

Utilisez la source que Squid reçoit réellement ; l'exemple est une adresse de documentation. Conservez les protections antérieures pour les ports de destination non sûrs, les services locaux et le trafic CONNECT. Ce fragment montre la condition combinée, pas une configuration complète d'écoute.

Vérifiez les règles situées au-dessus

Une autorisation large antérieure peut accepter la requête avant qu'elle n'atteigne la nouvelle condition. La référence http_access décrit la correspondance ordonnée. Lisez toute la séquence, y compris les fichiers inclus.

Une autorisation pour le nom d'utilisateur et une autre pour la source n'exigent pas les deux. Chaque ligne peut réussir indépendamment. C'est une politique différente.

L'ACL proxy_auth dépend d'un assistant d'authentification. La définir ne crée pas l'utilisateur et ne valide pas le mot de passe. Cet exemple concerne un proxy explicite dont les clients peuvent répondre aux demandes d'authentification du proxy.

L'identité de la source a aussi ses limites. Derrière un même NAT, plusieurs personnes peuvent partager une adresse, et un ordinateur portable en déplacement peut changer d'adresse. La condition supplémentaire restreint l'emplacement réseau utilisable du compte ; elle n'identifie pas de manière fiable un ordinateur physique. Assurez-vous que cette limite correspond à la raison pour laquelle vous avez ajouté la condition.