Si vous avez déjà utilisé des proxys, la liste blanche d’IP vous est probablement familière : vous enregistrez l’adresse de votre serveur auprès du fournisseur, et toute connexion depuis cette adresse est autorisée sans identifiants. C’est un modèle courant, et les personnes venant d’autres produits cherchent souvent ce paramètre.
La réponse directe pour la passerelle résidentielle est qu’il n’existe pas de liste blanche d’IP. L’authentification se fait par nom d’utilisateur et mot de passe à chaque requête, et les identifiants sont le seul mécanisme d’authentification. C’est un choix de conception délibéré plutôt qu’une fonctionnalité manquante, et il vaut la peine de comprendre pourquoi, car cela change la façon de sécuriser l’accès. La liste blanche existe ailleurs dans la gamme de produits, sur les proxys ISP et sur les anciens plans basés sur des ports, et ce texte explique comment la configurer dans ces cas.
Pourquoi la passerelle résidentielle utilise des identifiants plutôt que la liste blanche
Le produit résidentiel est un point d’accès unique, p.shifter.io:443, où tout le ciblage se trouve dans le nom d’utilisateur. Une requête pour une sortie aux États-Unis avec une session persistante utilise le même hôte et le même port qu’une requête pour une sortie allemande rotative ; seule la chaîne du nom d’utilisateur change. Cette conception a une conséquence sur l’authentification : l’identifiant porte déjà des informations propres à chaque requête, il doit donc de toute façon être présent à chaque requête.
L’authentification par identifiants est également nettement plus portable, ce qui compte plus qu’il n’y paraît de prime abord. La liste blanche lie l’accès à une adresse de sortie fixe, et une grande partie de l’infrastructure moderne n’en possède pas. Les conteneurs obtiennent de nouvelles adresses lors de leur replanification, les groupes d’auto-scaling ajoutent et retirent des nœuds, les fonctions serverless sortent via un espace d’adresses partagé qui change sans préavis, les exécuteurs CI sont éphémères, et un développeur sur un ordinateur portable ou une connexion domestique a une adresse dynamique qui peut changer du jour au lendemain. Avec la liste blanche, chacun de ces cas devient un ticket de support. Avec des identifiants stockés dans un gestionnaire de secrets, la même configuration fonctionne depuis un ordinateur portable, un conteneur, un job CI et un cluster de production sans que personne n’ait besoin d’enregistrer quoi que ce soit.
Donc si vous cherchiez le paramètre de liste blanche sur les proxys résidentiels, ce qu’il faut configurer à la place est la gestion des identifiants, décrite ci-dessous.
Où la liste blanche s’applique
Deux produits utilisent l’authentification par IP source, et si la liste blanche est une exigence stricte pour vous, ce sont ceux-là qu’il faut regarder.
Les proxys ISP prennent en charge deux modes d’authentification, et vous en choisissez un par plan dans le panneau. En mode IP source autorisée, vous enregistrez l’adresse de votre serveur puis vous vous connectez à vos IP fixes sur le port 1337 sans aucun identifiant. En mode nom d’utilisateur et mot de passe, vous vous connectez depuis n’importe où avec des identifiants, une ligne par IP. Le compromis est exactement celui décrit plus haut : la liste blanche évite complètement les identifiants dans votre code, au prix de ne fonctionner que depuis des adresses enregistrées. Les proxys ISP sont un produit différent du résidentiel rotatif, avec des adresses statiques fixes plutôt qu’un pool rotatif, donc si vous hésitez entre les deux, la comparaison se trouve dans ISP versus proxys résidentiels et ce que sont les proxys résidentiels statiques.
Les anciens plans à liste de ports s’authentifient uniquement par IP source. Chaque port de votre allocation possède son propre sous-domaine, et vous mettez en liste blanche l’adresse de votre serveur dans le panneau, ou vous gérez la liste via l’ancienne API de gestion, puis vous vous connectez à n’importe quel port de votre liste. Si vous êtes sur l’un de ces plans, la liste blanche n’est pas optionnelle, c’est le seul mécanisme d’authentification. Le contexte expliquant pourquoi le secteur s’est éloigné de ce modèle se trouve dans pourquoi l’ère du port par port est révolue.
Configurer une liste blanche sur les proxys ISP
Le mécanisme est simple, mais deux détails causent la plupart des échecs.
D’abord, enregistrez votre adresse de sortie, pas une adresse locale. L’adresse qui compte est l’adresse publique depuis laquelle votre trafic arrive, ce qui n’est pas votre adresse LAN, ni l’adresse interne de votre conteneur, ni ce que ifconfig affiche sur la machine. Déterminez-la depuis la machine qui effectuera réellement les requêtes :
# run this ON the server that will connect to the proxies
curl -s https://ipinfo.io/ipSi votre infrastructure sort via une passerelle NAT ou un load balancer, c’est cette adresse partagée qu’il faut enregistrer, et il vaut la peine de vérifier qu’elle est stable plutôt qu’attribuée dynamiquement.
Ensuite, choisissez délibérément le mode d’authentification dans le panneau sous ISP Proxies, car les deux modes sont des alternatives et non un système superposé. Une fois en mode IP source autorisée, vous vous connectez sans aucun identifiant :
# authorized source IP mode: no username or password
curl -x 185.199.108.153:1337 https://ipinfo.io/jsonSi cela renvoie une erreur et que vous êtes sûr que l’adresse est enregistrée, les causes habituelles sont que votre adresse de sortie a changé, que vous avez enregistré une adresse IPv4 alors que votre trafic sort en IPv6 ou l’inverse, ou que les requêtes proviennent d’un nœud différent de celui depuis lequel vous avez testé.
Le compromis, dit simplement
La liste blanche supprime les secrets de votre code et de votre configuration, ce qui a une réelle valeur : rien à divulguer dans un dépôt, rien à faire tourner, rien qui finisse dans un journal. Sa faiblesse est qu’elle échoue dès que votre adresse de sortie change, et qu’elle ne peut pas prendre en charge un accès depuis un endroit qui n’a pas d’adresse stable.
L’authentification par identifiants est portable et fonctionne depuis n’importe quel environnement, mais les identifiants sont un secret dont vous avez désormais la responsabilité, ce qui signifie qu’ils doivent se trouver dans un gestionnaire de secrets plutôt que dans le code source, et qu’ils ont besoin d’un plan de rotation.
Aucune des deux méthodes n’est intrinsèquement plus sûre. Elles échouent différemment, et le bon choix dépend du fait que votre infrastructure ait ou non une sortie stable.
Sécuriser les identifiants résidentiels, puisqu’il n’y a pas de liste blanche
Si vous êtes sur la passerelle résidentielle, cette section remplace la liste blanche pour vous.
Gardez les identifiants hors du contrôle de version et hors des images de conteneur, et chargez-les depuis des variables d’environnement adossées à un gestionnaire de secrets. Utilisez des identifiants séparés par environnement quand c’est possible, afin qu’une valeur de développement divulguée n’expose pas la production. Traitez la rotation comme un déploiement plutôt qu’un clic dans le panneau : mettez d’abord à jour le gestionnaire de secrets, déployez les clients, puis faites pivoter l’ancienne valeur, car chaque client qui détient encore le mot de passe précédent commencera à recevoir des 407 dès que celui-ci changera, ce qui est la version la plus courante et auto-infligée du problème traité dans corriger les erreurs 407 et d’identifiants.
Contrôlez ensuite l’autre côté. Même sans liste blanche côté fournisseur, vous pouvez restreindre lesquels de vos propres systèmes atteignent la passerelle à l’aide de règles de sortie ordinaires, d’une politique réseau ou d’un groupe de sécurité, de sorte qu’un identifiant divulgué soit moins utile depuis l’extérieur de votre infrastructure. Et surveillez l’utilisation de la bande passante, car une consommation inexpliquée est le signal qu’un identifiant a fuité, ce qui est plus facile à repérer lorsque vous disposez d’une référence issue de votre propre surveillance de pipeline.
Erreurs courantes
Enregistrer une adresse privée telle qu’une valeur 10.x ou 192.168.x, qui ne pourra jamais correspondre, puisque seule l’adresse de sortie publique est visible par le fournisseur. Mettre en liste blanche un ordinateur portable ou une connexion domestique et être surpris que cela cesse de fonctionner après qu’un redémarrage du routeur a réattribué l’adresse. Oublier que l’auto-scaling ajoute des nœuds derrière des adresses différentes. Enregistrer une IPv4 alors que le trafic sort réellement en IPv6. Et supposer qu’une entrée de liste blanche sur un produit couvre un autre produit : une liste blanche de proxy ISP n’a aucun effet sur la passerelle résidentielle, qui exigera toujours des identifiants.
En résumé
Il n’y a pas de liste blanche d’IP sur la passerelle résidentielle, et c’est voulu : le ciblage se trouve dans le nom d’utilisateur, donc les identifiants sont de toute façon présents à chaque requête, et l’authentification par identifiants continue de fonctionner à travers les conteneurs, l’auto-scaling, la CI et les connexions dynamiques, là où une liste blanche échouerait. Si vous avez spécifiquement besoin d’une authentification par IP source, les proxys ISP l’offrent comme l’un des deux modes sélectionnables et les anciens plans à liste de ports l’utilisent exclusivement, et dans les deux cas, ce qu’il faut enregistrer est votre adresse de sortie publique plutôt qu’une adresse locale. Sur le résidentiel, remplacez la liste blanche par une gestion disciplinée des identifiants : gestionnaire de secrets, valeurs par environnement, procédure de rotation qui met à jour les clients avant d’invalider l’ancien mot de passe, ainsi que des contrôles de sortie et une surveillance d’utilisation de votre côté.
La référence complète sur l’authentification pour chaque produit se trouve dans la documentation d’authentification, et les spécificités de la passerelle sont dans passerelle et authentification. Le produit lui-même est proxys résidentiels, un point d’accès unique et une seule paire d’identifiants pour tous les pays et modes de session, avec une tarification par Go.