Ce service SOCKS de RouterOS prend-il en charge votre connexion par mot de passe ?
Vérifiez la version de RouterOS installée et la prise en charge de l'authentification SOCKS5 par le client, puis gardez les comptes SOCKS séparés des réglages du proxy web et de l'administration du routeur.
Le manuel SOCKS de RouterOS documente l'authentification par mot de passe SOCKS5 et une liste d'utilisateurs SOCKS dédiée. Cela répond à une question de fonctionnalité pour les versions qui disposent de ces contrôles, sans garantir qu'un routeur plus ancien les possède.
Dans la configuration documentée, les deux côtés doivent s'accorder :
- Le routeur choisit SOCKS5 et une méthode d'authentification exigeant une négociation de mot de passe, avec un utilisateur SOCKS dédié et activé.
- Le client met en œuvre la négociation de nom d'utilisateur et de mot de passe SOCKS5. Une fenêtre de connexion de proxy HTTP ou une implémentation SOCKS fonctionnant uniquement sans authentification ne suffisent pas.
Utilisez les champs pris en charge par la version installée. Si une version ne les propose pas, choisissez sa conception prise en charge ou une alternative approuvée plutôt que de recopier les champs d'un manuel plus récent.
Il s'agit de comptes SOCKS. Ils n'établissent pas que le proxy web HTTP distinct de RouterOS expose la même interface et n'imposent pas d'accorder l'accès à l'administration du routeur. Maintenez aussi restreintes la politique d'accès source/destination et le pare-feu du routeur.
La méthode par mot de passe ne chiffre pas elle-même les identifiants : la négociation RFC 1929 précède toute session HTTPS ultérieure avec un site. Utilisez un chemin client-routeur correctement protégé ; le TLS de destination ne peut pas protéger rétroactivement cet échange antérieur.