Base de connaissances ProxyCompass
Authentification proxy : liste d’IP autorisées ou nom d’utilisateur et mot de passe ?
L’authentification proxy vérifie si votre application peut utiliser un service de proxys. Connaître l’adresse et le port du proxy ne suffit généralement pas : le service doit aussi distinguer les clients autorisés des autres systèmes capables de l’atteindre. Cela réserve l’utilisation des proxys achetés aux clients que vous autorisez.
Les deux méthodes courantes s’appuient sur des éléments différents. Avec l’authentification par IP, le proxy vérifie d’où vient la connexion. Avec l’authentification par nom d’utilisateur et mot de passe, l’application fournit des identifiants. La première méthode lie l’accès à une adresse réseau ; la seconde peut permettre à l’application de conserver son accès lorsqu’elle passe à un autre réseau. Un service peut aussi exiger les deux conditions à la fois.
Ce choix influe sur votre façon de vous connecter, les applications utilisables et les conséquences d’un changement d’environnement de travail. C’est un aspect distinct du choix d’une configuration proxy : l’authentification ne détermine pas si l’IP de sortie provient d’un centre de données ou d’un réseau résidentiel, ni si elle est statique ou rotative. Elle détermine qui peut utiliser le service qui fournit cette IP.
Fonctionnement des deux méthodes d’authentification
Authentification par IP : accès accordé à une source de connexion
Avec l’authentification par IP, vous ajoutez une adresse client à la liste des adresses autorisées du fournisseur, souvent appelée whitelist ou allowlist. Lorsqu’une connexion arrive, le proxy compare son IP source à cette liste. Si elle correspond et que les autres conditions d’accès du service sont remplies, l’application peut utiliser le proxy sans envoyer de nom d’utilisateur et de mot de passe proxy distincts.
Pour un proxy sur Internet, l’adresse concernée est normalement l’IP publique de sortie de votre réseau. C’est l’adresse depuis laquelle votre application atteint le proxy, et non l’IP de sortie que le proxy présente ensuite aux sites web. Acheter un proxy statique ne rend pas votre connexion domestique statique : ces adresses appartiennent à des parties différentes du trajet.
L’accès reste donc pratique tant que la source autorisée reste la même. Un programme peut redémarrer ou un autre appareil autorisé peut se connecter par ce réseau sans avoir besoin de son propre mot de passe proxy. Si l’IP de sortie change, l’autorisation existante ne couvre pas automatiquement la nouvelle adresse. Le guide de l’authentification par IP explique comment identifier la bonne adresse source et gérer sa liste d’adresses autorisées.
Nom d’utilisateur et mot de passe : accès accordé aux identifiants de l’application
Avec l’authentification par nom d’utilisateur et mot de passe, le fournisseur délivre des identifiants pour utiliser le proxy. L’application les envoie dans le cadre du protocole proxy pris en charge. Un navigateur peut demander à l’utilisateur de les saisir ; un script peut les fournir depuis sa configuration sans afficher de fenêtre de connexion.
Lorsque les identifiants constituent la seule exigence d’authentification, l’accès peut suivre l’application d’un réseau à l’autre. La même configuration fonctionnelle peut continuer à se connecter depuis une nouvelle IP source. Cela est utile lorsque le lieu d’exécution d’une tâche change plus souvent que ses paramètres proxy.
Les identifiants appartiennent à la connexion au proxy. Ils ne sont pas automatiquement le mot de passe du tableau de bord du fournisseur et ne vous connectent pas au site web de destination. Ce site continue d’appliquer ses propres règles de connexion et d’accès. Le guide de l’authentification par nom d’utilisateur et mot de passe traite des champs de connexion, des clients pris en charge et des formats d’identifiants.
Authentification par IP ou par nom d’utilisateur et mot de passe
La comparaison ci-dessous décrit les deux méthodes séparément. L’accès par mot de passe désigne ici un accès sans restriction IP supplémentaire ; l’accès combiné est expliqué plus bas.
| Ce qui change en pratique | Authentification par IP | Nom d’utilisateur et mot de passe |
|---|---|---|
| Condition d’accès | Une connexion doit arriver depuis une IP source autorisée. | L’application doit fournir des identifiants proxy valides. |
| Paramètres de l’application | Aucun identifiant proxy n’est nécessaire, mais le protocole, l’adresse et le port corrects restent indispensables. | L’application doit prendre en charge l’échange d’identifiants du proxy. |
| Passage à un autre réseau | La nouvelle source doit déjà être autorisée ou être ajoutée à la liste. | Les mêmes identifiants peuvent fonctionner depuis le nouveau réseau. |
| Plusieurs applications | Les applications utilisant la même sortie réseau autorisée partagent son autorisation par IP. | Chaque application doit envoyer des identifiants acceptés par le service ; plusieurs applications peuvent utiliser la même paire si cela est permis. |
| Conséquences de la divulgation d’une adresse proxy | L’adresse et le port seuls ne permettent pas de satisfaire la vérification de l’IP source depuis un réseau non autorisé. | Une configuration complète contenant des identifiants valides peut donner accès depuis un autre réseau. |
| Ce que vous devez gérer | Les adresses sources autorisées et les trajets réseau qui les utilisent. | Les identifiants et les applications configurées pour les envoyer. |
Aucune des deux méthodes ne détermine le nombre d’IP de sortie du service. Une IP client autorisée ou un jeu d’identifiants peut donner accès à de nombreux proxys. Aucune ne donne à ces proxys un nombre illimité de connexions et ne rend leurs adresses de sortie exclusives à un client.
Comment choisir pour votre application et votre réseau
Vérifiez d’abord si l’application peut utiliser la méthode proposée
Un programme peut prendre en charge un protocole proxy sans prendre en charge toutes ses options d’authentification. Des champs d’adresse et de port ne prouvent pas à eux seuls que le programme peut envoyer un nom d’utilisateur et un mot de passe. Par exemple, la prise en charge native de SOCKS5 dans Chrome n’inclut pas l’authentification SOCKS5 par nom d’utilisateur et mot de passe. Des identifiants corrects ne peuvent pas compenser cette fonction absente du client.
Si l’application requise prend en charge le protocole proposé mais ne peut pas envoyer les identifiants correspondants, l’authentification par IP peut fournir un accès utilisable. Cela exige toujours une adresse source autorisée. Lorsque cette adresse change fréquemment, passer à l’accès par IP résout le problème des identifiants, mais laisse celui de l’adresse source à gérer. Vous pouvez plutôt avoir besoin d’un client prenant en charge l’authentification requise ou d’une sortie réseau stable.
La vérification utile avant l’achat est donc précise : cette application peut-elle utiliser ce protocole proxy avec cette méthode d’authentification ? Une réussite dans un autre navigateur ou un outil en ligne de commande ne répond pas à cette question.
Examinez ensuite ce qui change habituellement dans votre configuration
L’authentification par IP convient à une tâche dont la sortie réseau est stable et contrôlée. Une fois cette sortie autorisée, changer le programme qui l’utilise n’exige pas de distribuer des identifiants proxy à chaque nouveau processus. Les paramètres d’accès du service restent attachés au réseau utilisé par la tâche.
Les identifiants conviennent à une tâche dont le lieu d’exécution change. Si une tâche est déplacée vers un autre serveur ou si de nouveaux processus de travail démarrent depuis des réseaux différents, l’accès ne nécessite pas une modification distincte de la liste pour chaque source, à condition que le service accepte les identifiants sans liaison à l’IP. La configuration proxy peut suivre l’application.
La distinction importante est la fréquence de changement de la source de sortie, et non le nom donné à la machine : ordinateur portable, VPS ou serveur cloud. Un ordinateur portable peut rester derrière une sortie fixe de bureau ; un déploiement serveur peut passer d’une adresse publique à l’autre. Choisissez selon le trajet de connexion réel et les changements attendus pendant le travail normal.
Si les deux méthodes fonctionnent, choisissez la configuration la plus simple à entretenir
Tenez compte de la personne qui gérera les paramètres. Un administrateur réseau contrôlant une sortie fixe partagée par plusieurs applications peut gérer l’accès au moyen d’une seule autorisation de source. Un développeur qui déplace des tâches entre des environnements sans pouvoir contrôler leurs IP publiques peut trouver les identifiants sans liaison à l’IP plus simples à gérer.
Incluez les ressources supplémentaires nécessaires à ce choix. Une IP publique fixe, des entrées supplémentaires dans la liste d’adresses autorisées ou une passerelle administrée peuvent avoir un coût. L’accès par mot de passe peut éviter ces coûts, mais seulement s’il fonctionne depuis les réseaux requis. Comparez les options réelles du service ; la présence d’un mot de passe ne rend pas, à elle seule, un proxy moins cher.
Authentification combinée : IP et mot de passe
Un fournisseur peut proposer l’accès par IP et l’accès par mot de passe comme deux solutions au choix, ou les exiger ensemble. Ce sont des configurations différentes. Dans un mode combiné, les identifiants valides ne sont acceptés que si la connexion provient aussi d’une adresse ou d’un réseau autorisé. Un mot de passe correct ne suffit pas à lui seul, et une source autorisée ne suffit pas non plus.
Cela peut convenir aux applications qui exigent des champs de nom d’utilisateur et de mot de passe tout en maintenant une restriction sur l’origine de l’accès. Cela peut aussi limiter l’utilisation d’identifiants copiés en dehors du réseau autorisé. Ce mode n’offre pas la même liberté de passage entre des réseaux quelconques que l’accès par mot de passe sans liaison à l’IP.
Dans les offres statiques de ProxyCompass, le mode combiné accepte des identifiants valides depuis des adresses IPv4 publiques client du même sous-réseau /24 qu’une IP ajoutée à la liste des adresses autorisées. Ces adresses ont les trois premiers nombres en commun. Plusieurs adresses client de ce sous-réseau peuvent donc utiliser les identifiants avec une seule entrée dans la liste. Cette règle concerne les clients qui se connectent au service, pas les IP de sortie achetées. Le guide du nom d’utilisateur et du mot de passe mentionné plus haut présente les exemples de connexion.
Quelle méthode offre le meilleur contrôle d’accès ?
L’authentification par IP place la décision d’accès au niveau de la sortie réseau. Une personne qui n’obtient que l’adresse du proxy ne peut pas l’utiliser depuis une autre source non autorisée. Mais le proxy ne peut pas identifier les personnes simplement parce qu’elles partagent une IP autorisée. Si plusieurs utilisateurs l’atteignent par la même adresse publique, cette vérification IP voit la même source pour tous. Cela compte pour les sorties de bureau partagées et les adresses publiques partagées entre abonnés Internet.
L’authentification par nom d’utilisateur et mot de passe place l’autorisation dans des identifiants que les applications peuvent présenter indépendamment de leur emplacement. Cela fonctionne bien sur des réseaux sans lien entre eux. Cela signifie aussi qu’une configuration copiée contenant des identifiants valides peut rester utilisable ailleurs. Lorsqu’un fournisseur propose des identifiants distincts pour différents utilisateurs ou tâches, ils peuvent permettre une gestion plus fine de l’accès ; un mot de passe partagé par tous ne crée pas cette séparation.
Le choix dépend donc de ce que vous contrôlez le plus sûrement : le groupe de systèmes derrière une sortie réseau autorisée ou les identifiants fournis aux applications. L’accès combiné exige les deux conditions et restreint donc les lieux depuis lesquels même des identifiants valides peuvent être utilisés.
Le contrôle d’accès et le chiffrement sont deux questions distinctes. L’authentification par IP ne chiffre pas le trafic, et un mot de passe ne crée pas automatiquement une connexion chiffrée. Protéger les identifiants en transit exige une protection sur la connexion entre client et proxy elle-même. Ouvrir un site HTTPS par un proxy ne protège pas, en soi, un échange d’authentification antérieur non chiffré avec ce proxy.
L’authentification par IP rend-elle un proxy plus rapide ?
L’accès par IP peut éviter un échange d’identifiants, mais l’établissement de la connexion diffère entre HTTP et SOCKS. En SOCKS5, l’authentification par nom d’utilisateur et mot de passe ajoute une requête et une réponse pendant l’établissement. Avec HTTP, un client peut attendre un défi d’authentification et répéter sa requête, ou envoyer les identifiants appropriés dès le départ. L’accès par mot de passe n’ajoute donc pas toujours un aller-retour réseau.
Cet écart compte surtout lorsqu’une tâche crée régulièrement de nouvelles connexions pour de petites quantités de travail. Il compte moins lorsque les connexions établies sont réutilisées. Par exemple, demander d’autres pages du même site par un tunnel HTTPS existant ne répète pas l’authentification proxy utilisée pour établir ce tunnel. C’est un coût d’établissement de connexion, pas une réduction constante de la vitesse de transfert des données du proxy.
Si les deux méthodes conviennent à votre configuration, comparez-les avec le même protocole, des ressources proxy similaires et votre schéma de connexion réel. Un test qui ouvre une nouvelle connexion pour chaque requête répond à une autre question qu’un test qui réutilise les connexions. Sans cette comparaison, affirmer qu’une méthode d’authentification est toujours plus rapide aide peu à choisir un service.
L’authentification peut-elle révéler qu’une adresse héberge un proxy ?
Oui. Un mot de passe peut empêcher une utilisation non autorisée tout en permettant à un système extérieur de reconnaître le service. Par exemple, un outil de vérification peut contacter l’adresse et le port d’un proxy HTTP sans identifiants valides. Une réponse 407 Proxy Authentication Required, avec l’en-tête Proxy-Authenticate, signale explicitement une exigence d’authentification proxy. L’outil n’a pas besoin de connaître le mot de passe pour obtenir cet indice.
Un service restreint par IP peut révéler moins d’informations s’il bloque une source non autorisée avant de renvoyer une réponse proxy reconnaissable. Mais une liste d’adresses autorisées ne garantit pas à elle seule ce comportement : le serveur peut renvoyer un refus caractéristique. Un point de connexion protégé par mot de passe peut aussi disposer d’un filtrage réseau. La différence pertinente est ce qu’une connexion extérieure peut atteindre et la réponse qu’elle reçoit.
L’adresse vérifiée compte aussi. Lorsque l’adresse d’entrée et l’IP de sortie du proxy sont les mêmes, une réponse reconnaissable peut identifier l’adresse vue par les sites web. Avec une passerelle utilisant des IP de sortie différentes, identifier la passerelle ne permet pas, à lui seul, d’identifier toutes les sorties de son pool.
Le site web de destination ne reçoit pas automatiquement le défi d’authentification du proxy pendant une navigation ordinaire : cet échange a lieu entre le client et le proxy. Un site ou son service de détection aurait besoin d’autres indices, qui pourraient inclure une vérification distincte de l’adresse. Changer uniquement l’authentification ne peut donc pas promettre de rendre une IP méconnaissable comme proxy ni de supprimer les informations déjà connues à son sujet.