Exiger une connexion sur les services HTTP et SOCKS de 3proxy

Définir un utilisateur ne constitue pas toute la configuration de connexion de 3proxy. Le service a aussi besoin d'une méthode d'authentification et d'une règle d'accès qui l'utilise. L'ordre compte, car les réglages du service s'appliquent pendant le traitement de la configuration.

Un exemple uniquement local pour deux services :

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

La référence de configuration explique users, auth strong et les commandes de service. CL stocke ce mot de passe d'exemple en clair. Protégez le fichier et choisissez une forme de stockage des identifiants prise en charge et adaptée au déploiement.

Le client a besoin du bon échange de connexion

Le service HTTP attend une authentification de proxy HTTP. Le service SOCKS a besoin d'un client prenant en charge l'authentification SOCKS5 par nom d'utilisateur et mot de passe. Un client SOCKS4 ne peut pas fournir cet échange simplement parce qu'il atteint le même port d'écoute.

Le mot strong est le nom d'un mode d'authentification, pas une garantie de transport chiffré. Protégez le trajet du client au proxy lorsque c'est nécessaire. HTTPS vers la destination et le chiffrement vers le proxy restent des décisions distinctes.

Les liaisons loopback limitent cet exemple à un accès local. Pour des clients distants, choisissez explicitement un écouteur et une politique réseau voulus. Un écouteur public avec joker ne remplace pas la vérification du comportement de connexion.

Si un service demande des identifiants et un autre non, examinez les réglages avant chaque commande de service, les règles après tout flush et le cache d'authentification. Changer un mot de passe ne peut pas réparer un service démarré sous une mauvaise politique. De même, changer le compte système du démon ne crée pas d'utilisateur proxy.