Du choix du serveur et de la région à la sécurité de base, l’installation du proxy, l’authentification, les ports, la connexion du client, la vérification et le diagnostic des pannes.
Choisir le serveur et la région
Un proxy consomme très peu de CPU et de mémoire. Ces caractéristiques ne sont donc pas le point principal au moment de choisir la configuration.
Il n’est pas nécessaire de commencer avec une offre puissante. Les formules de type serveur applicatif léger, avec bande passante fixe et quota mensuel de trafic, suffisent généralement pour un proxy personnel utilisé par un ou quelques comptes et restent peu coûteuses. Il devient pertinent de passer à des instances généralistes aux ressources configurables séparément seulement si plusieurs instances sont nécessaires ou si les besoins en bande passante sont clairement définis.
La région mérite plus d’attention que les ressources, car l’IP de sortie est rattachée à l’emplacement où le nœud est déployé. La logique est simple : placez le nœud dans le marché visé par le compte. Beaucoup choisissent en fonction de la vitesse d’accès. Un nœud à Hong Kong peut être rapide depuis la Chine continentale, mais si le profil du compte indique les États-Unis alors que la sortie se trouve en Asie, cette incohérence compte davantage que la vitesse. La vitesse est secondaire ; la cohérence passe en premier.
Estimez la bande passante selon l’usage réel. Une faible bande passante suffit pour consulter des tableaux de bord et effectuer l’administration courante ; les opérations avec images ou vidéos en demandent davantage ; plus le nombre de comptes simultanément en ligne augmente, plus le besoin est élevé. En cas de doute, commencez par la plus petite offre, observez l’utilisation pendant un mois, puis ajustez.
Terminer ces étapes après le démarrage
Choisissez une image système Linux. Ces distributions incluent généralement SSH par défaut, il n’est donc pas nécessaire de configurer un service d’accès distant supplémentaire. Au moment de l’achat, définir un mot de passe personnalisé plutôt qu’un fichier de clé évite une étape de conversion plus tard lors de la configuration du proxy.
Une fois le serveur disponible, notez d’abord quatre éléments : IP publique, nom d’utilisateur (root par défaut sous Linux), mot de passe et port SSH (22 par défaut). Ce sont les informations à saisir dans le client.
Mettez ensuite en place la sécurité de base. Modifier le port 22 par défaut bloque une grande partie des tentatives de scan automatisées. Si le fournisseur prend en charge la connexion par clé, configurez-la puis désactivez l’authentification par mot de passe. Dans le groupe de sécurité et le pare-feu du système, n’autorisez que les ports réellement nécessaires et fermez les autres. Ces quelques minutes réduisent durablement le bruit des scans et des tentatives de réutilisation d’identifiants.
Deux façons de fournir le service proxy
La première consiste à utiliser directement un tunnel SSH. Rien n’est à installer sur le serveur : le client s’appuie sur le service SSH existant pour transférer le trafic, avec le port 22 et les identifiants du serveur. L’inconvénient est une performance moyenne ; un usage prolongé ou une forte concurrence peut devenir difficile, ce qui convient surtout à un usage temporaire ou à très peu de comptes.
La seconde consiste à installer un service proxy dédié sur le serveur. La méthode courante est de l’installer avec une seule commande, puis de configurer soi-même l’authentification et le port. Cette approche offre de meilleures performances et davantage de contrôle, et convient mieux à un usage durable. Après l’installation, activez le démarrage automatique, sinon un simple redémarrage du serveur arrêtera le proxy.
Authentification et ports
On peut distinguer trois niveaux d’authentification, avec une sécurité croissante : nom d’utilisateur et mot de passe est le plus simple, mais un mot de passe divulgué revient à donner l’accès au proxy ; mot de passe plus liste blanche d’IP source suffit généralement au quotidien ; l’authentification par clé ou certificat est la plus solide, mais demande davantage de configuration et vaut l’effort pour des comptes utilisés sur le long terme.
Pour les ports, configurer uniquement le port d’écoute du service ne suffit pas. Il faut également l’autoriser séparément dans le pare-feu du système et dans le groupe de sécurité du fournisseur. Ces deux contrôles sont indépendants et n’en ouvrir qu’un est une cause fréquente d’échec. Veillez aussi à ne pas lier l’adresse d’écoute uniquement à l’interface loopback locale. Si le test fonctionne sur le serveur mais échoue depuis l’extérieur, c’est souvent la raison.
Connecter le client et vérifier
Créez un nouvel environnement dans l’outil de gestion, ajoutez un nom et une note — intégrer l’usage du compte et la région cible dans le nom fait gagner du temps lorsque les comptes se multiplient — puis renseignez l’adresse du serveur, le port, le nom d’utilisateur et le mot de passe dans les paramètres du proxy selon le type choisi. Lancez le test. Un message de réussite indique que le chemin réseau est accessible. Les noms exacts des champs dépendent de l’interface de l’outil.
Réussir le test n’est que la première étape. Ouvrez ensuite l’environnement et vérifiez trois points.
Premièrement, l’IP de sortie doit être l’IP publique du serveur. Ouvrez une page affichant l’IP actuelle : le proxy est correctement utilisé seulement si l’adresse du serveur apparaît.
Deuxièmement, vérifiez que DNS passe également par le proxy. Si DNS continue d’être résolu localement, les informations géographiques exposées peuvent ne pas correspondre à l’IP de sortie, ce qui rend inutile la région définie dans le profil du compte.
Troisièmement, le fuseau horaire et la langue doivent correspondre à la région de sortie. Une IP américaine associée à un fuseau horaire et à une langue chinoise constitue une incohérence évidente.
L’environnement n’est prêt qu’une fois ces trois contrôles validés.
En cas d’échec, vérifier dans cet ordre
Si le test du proxy échoue immédiatement, commencez par la connectivité : confirmez que le port est autorisé dans le groupe de sécurité et dans le pare-feu du système. Vérifiez ensuite que le service proxy fonctionne, surtout après un redémarrage. Contrôlez enfin les identifiants et l’adresse du serveur. Confondre l’IP publique et l’IP privée est courant.
Si le test réussit mais que les pages ne s’ouvrent pas, le problème se trouve généralement côté environnement. Vérifiez que le bon proxy est associé et que DNS n’a pas été remis en résolution locale.
Si la connexion est lente, déterminez d’abord si la cause est la distance ou la bande passante. Accédez directement au site cible depuis le serveur. Si le serveur lui-même est lent, le problème vient de la région du nœud ou du routage ; si le serveur est rapide mais le client lent, la bande passante est probablement insuffisante ou trop de comptes sont connectés simultanément.
Évoluer quand le nombre de comptes augmente
Héberger plusieurs comptes sur un même serveur réduit les coûts, mais tous partagent la même IP de sortie. Si la plateforme identifie les relations par plage d’IP, des liens peuvent encore exister entre les comptes. Un serveur par compte coûte plus cher, mais isole complètement les environnements et constitue une option plus robuste pour les comptes de plus grande valeur.
Avec un outil de gestion d’environnements comme PurpleMark, attribuer une sortie distincte à chaque compte est plus fiable que maintenir manuellement un tableau de correspondance. Aux tarifs habituels des serveurs légers, une sortie par compte reste acceptable dans de nombreux cas et évite le travail de recréation ultérieure lié à des associations entre comptes. Gardez également un serveur réservé aux tests. Ne placez pas tous les comptes sur une seule machine, car un point de défaillance unique pourrait tous les affecter en même temps.
