Ordre recommandé côté serveur pour un proxy IP autohébergé : valider d'abord l'accès SSH, changer le port et passer à l'authentification par clé, effectuer le durcissement de base, installer le service proxy et ouvrir le port, puis connecter et vérifier le client.
Lorsqu'on achète un serveur cloud pour l'utiliser comme proxy, le blocage vient rarement de la connectivité elle-même. Le problème tient plus souvent à l'ordre de préparation côté serveur. Avec le bon ordre, la connexion du client fonctionne généralement du premier coup ; avec un ordre confus, il faut revenir sans cesse au terminal pour modifier la configuration.
Ici, on se concentre uniquement sur le serveur : première connexion, sécurisation de l'accès, démarrage du service proxy, ouverture des ports, connexion du client et diagnostic par couches en cas d'échec.
Première connexion : valider d'abord l'accès
Une fois l'instance créée, connectez-vous d'abord avec le terminal web fourni dans la console du prestataire, sans dépendre immédiatement d'un outil local. Cette étape sert uniquement à vérifier que la machine fonctionne et que le réseau est accessible.
Une fois connecté, passez en root avec sudo -i puis appuyez sur Enter. Lorsque l'invite passe de $ à #, l'élévation de privilèges a réussi. Effectuez les opérations suivantes sous cette identité.
Notez quatre informations : l'IP publique, le nom d'utilisateur de connexion (root par défaut sous Linux), le mot de passe et le port SSH (22 par défaut). Le client a besoin de ces quatre valeurs ; s'il en manque une, la connexion échouera.
Changer le port par défaut, puis passer à l'authentification par clé
Le port 22 est scanné d'innombrables fois chaque jour et les tentatives automatisées d'identification sont courantes. Changer le port ne rend pas le serveur intrinsèquement plus robuste, mais élimine une grande partie du bruit automatisé.
La modification se fait dans /etc/ssh/sshd_config. Ouvrez le fichier avec vi, appuyez sur i pour passer en mode édition, mettez les lignes PermitRootLogin et PasswordAuthentication à yes, puis appuyez sur Esc et saisissez :wq pour enregistrer et quitter. Si le prestataire prend en charge la connexion par clé, une solution plus sûre consiste à ajouter votre clé publique locale dans authorized_keys sur le serveur, puis à mettre PasswordAuthentication à no afin de n'accepter que les clés.
Ne fermez pas la session en cours immédiatement après la modification. Ouvrez d'abord une deuxième fenêtre de terminal, connectez-vous une fois avec le nouveau port et la nouvelle méthode, vérifiez que l'accès fonctionne, puis fermez l'ancienne fenêtre. Sinon, une erreur de configuration peut vous bloquer à l'extérieur et vous obliger à repasser par la console du prestataire.
Le port SSH se règle sur la ligne Port. Après modification, redémarrez le service SSH pour appliquer la configuration. Sur Debian et Ubuntu, vous pouvez exécuter /etc/init.d/ssh restart.
Effectuer le durcissement de base dès le premier jour
En plus du changement de port et des clés, deux petites tâches méritent d'être terminées dès le premier jour. D'abord, attribuez à root un mot de passe aléatoire suffisamment long avec passwd root, plutôt qu'une combinaison facile à deviner. Ensuite, désactivez les services et ports inutiles. Moins la machine expose de composants, plus la surface d'attaque est réduite ; le pare-feu système ne doit autoriser que les ports réellement nécessaires.
Si le serveur sera utilisé à long terme depuis quelques sources fixes, limitez les adresses source à ces emplacements dans le groupe de sécurité. C'est bien plus sûr que d'ouvrir l'accès à tout Internet.
Installer le service proxy et configurer l'authentification
Une fois l'initialisation du serveur terminée, passez au proxy lui-même.
Une première possibilité consiste à utiliser directement un tunnel SSH. Rien d'autre n'a besoin d'être installé sur le serveur : le client s'appuie sur le service SSH intégré au système pour le transfert, avec les mêmes identifiants que le serveur. C'est simple, mais les performances sont moyennes et la forte concurrence devient vite difficile ; cette solution convient donc à un usage temporaire ou à peu de comptes.
L'autre possibilité est d'installer un service proxy dédié. En général, une seule commande suffit pour l'installation, puis vous configurez vous-même le mode d'authentification et le port d'écoute. Pensez à activer le démarrage automatique ; sinon, un simple redémarrage du serveur arrêtera le proxy.
On peut distinguer trois niveaux d'authentification, par sécurité croissante : identifiant et mot de passe sont les plus simples, mais une fuite revient à donner le proxy ; mot de passe plus liste blanche d'IP source suffit souvent au quotidien ; l'authentification par clé ou certificat est la plus robuste, avec une configuration un peu plus complexe mais pertinente pour des comptes utilisés sur la durée.
Ouvrir le port à deux endroits distincts
C'est l'un des points qui bloquent le plus souvent. Le port d'écoute du service proxy doit être autorisé à la fois dans le pare-feu système et dans le groupe de sécurité du prestataire. Ces deux contrôles sont indépendants : n'en ouvrir qu'un ne suffit pas.
Un autre réglage est facilement oublié : l'adresse d'écoute du service. Certains services ne se lient par défaut qu'à 127.0.0.1. Si le test fonctionne sur le serveur lui-même mais pas depuis l'extérieur, c'est souvent la cause. Modifiez l'adresse d'écoute pour utiliser l'adresse privée du serveur ou 0.0.0.0.
Se connecter depuis le client local
Créez un nouvel environnement dans votre outil de gestion et sélectionnez le type de proxy réellement utilisé. Avec un tunnel SSH, l'adresse est l'IP publique du serveur, le port est le port SSH et le nom d'utilisateur ainsi que le mot de passe sont ceux du serveur. Lancez ensuite le test de connexion.
Un test réussi indique seulement que le chemin réseau fonctionne. Ouvrez ensuite l'environnement et vérifiez trois points : l'IP de sortie doit correspondre à l'IP publique du serveur ; DNS doit également passer par le proxy, car une résolution locale peut révéler une région qui ne correspond pas à l'IP de sortie ; enfin, le fuseau horaire et la langue doivent être cohérents avec la région de sortie. L'environnement n'est réellement prêt que lorsque ces trois vérifications sont validées.
Quand le nombre de comptes augmente, gardez une correspondance fixe entre chaque environnement et sa sortie afin d'éviter que plusieurs comptes partagent le même environnement. Des outils comme PurpleMark peuvent attribuer une sortie distincte à chaque compte, ce qui est plus fiable qu'un tableau de correspondance géré à la main.
En cas d'échec, diagnostiquer de l'extérieur vers l'intérieur
Commencez par la couche la plus externe : le groupe de sécurité autorise-t-il le port ? Le pare-feu système l'autorise-t-il ? Vérifiez ces deux points avant d'aller plus loin.
Contrôlez ensuite le service lui-même : le processus tourne-t-il encore, surtout après un redémarrage du serveur ? L'adresse d'écoute est-elle limitée à l'hôte local ?
Passez ensuite à l'authentification : le nom d'utilisateur ou le mot de passe est-il incorrect ? Les permissions du fichier de clé sont-elles trop larges ? SSHD refuse directement une clé lorsque les permissions sont incorrectes. Ce n'est qu'après cela qu'il faut examiner le client : avez-vous saisi l'IP publique ou, par erreur, l'IP privée ? Cette confusion est particulièrement fréquente.
En suivant cet ordre, deux ou trois passages suffisent généralement à identifier la couche en cause, au lieu de réinstaller le service à répétition.
Conclusion
La préparation côté serveur prend moins d'une demi-heure, mais elle détermine la tranquillité d'utilisation de la machine pendant les mois suivants. Sécurisez l'accès, ouvrez correctement les ports et configurez clairement l'authentification ; le reste ne sera plus que de la maintenance courante.
