Le protocole SSH fonctionne souvent avec votre connexion habituelle, mais échoue lorsqu'un VPN est activé. Cet article explique les causes et les solutions pratiques, notamment la gestion des cas où les serveurs n'autorisent que des adresses IP spécifiques et où les VPN utilisent des adresses tournantes ou des protocoles différents.
Le symptôme
SSH fonctionne lorsque vous n'utilisez pas de VPN :
utilisateur [email protected]Lorsque vous vous connectez à un VPN, la même commande expire, se bloque ou se déconnecte :
ssh : connexion à l'hôte myserver.com port 22 : délai de connexion expiréPourquoi cela arrive-t-il ?
Lorsque vous vous connectez à un VPN, votre configuration réseau change : les routes sont modifiées, les serveurs DNS peuvent changer et le VPN ou son opérateur peut imposer des règles de pare-feu. Causes courantes :
- Le VPN force tout le trafic à travers le tunnel (VPN à tunnel complet) — SSH est acheminé via le VPN et peut être bloqué ou mal acheminé.
- Le pare-feu VPN bloque les SSH sortants (port 22) — certains opérateurs ou VPN d’entreprise bloquent intentionnellement SSH pour réduire les risques.
- Modifications de la résolution DNS — les serveurs DNS du VPN peuvent ne pas résoudre votre nom d'hôte de la même manière que votre réseau habituel.
- Conflits de table de routage — le trafic vers le serveur SSH va vers la mauvaise interface ou est acheminé vers le tunnel mais ne peut pas sortir vers le serveur public.
- Liste blanche IP côté serveur — le serveur SSH n'autorise que certaines IP client ; lorsque votre IP change à cause du VPN, vous êtes bloqué.
Diagnostiquer rapidement
- Pouvez-vous envoyer un ping au serveur lorsque vous êtes sur le VPN ?
ping myserver.com - Exécutez un traceroute pour voir où le trafic s'arrête :
traceroute monserveur.com(outracertsous Windows). - Essayez de vous connecter par IP au lieu du nom d'hôte :
utilisateur ssh@. - Essayez un autre port si votre serveur le prend en charge :
ssh -p 2222 [email protected]. - Vérifiez votre table de routage :
route IP(Linux/macOS) ouimpression d'itinéraire(Fenêtres).
Vous pouvez également vérifier si un autre VPN fonctionne. Par exemple : ProtonVPN propose un forfait gratuit que vous pouvez tester.
Corrections courantes
1. Utiliser le tunneling fractionné
Si votre client VPN le prend en charge, configurez le tunneling fractionné afin que le trafic vers le serveur SSH transite directement par votre passerelle habituelle plutôt que par le tunnel VPN. Pour OpenVPN, vous pouvez ajouter une route dans la configuration du client pour contourner le tunnel pour une adresse IP spécifique :
itinéraire 255.255.255.255 passerelle_netCela indique au système d'atteindre le serveur SSH en utilisant la passerelle par défaut (non VPN).
2. Utilisez un port SSH alternatif
Si le VPN bloque le port 22, configurez votre serveur pour écouter sur un autre port (par exemple 2222 ou 443) et connectez-vous en utilisant ssh -p utilisateur@hôteLe port 443 (HTTPS) est souvent autorisé là où d'autres ports sont bloqués.
3. Contourner les problèmes DNS
Essayez de vous connecter directement par IP ou définissez un résolveur DNS de confiance (pour le dépannage uniquement) comme 8.8.8.8 pour voir si DNS est le coupable.
4. Ajouter une route statique
Si le trafic est acheminé de manière incorrecte après la connexion VPN, ajoutez une route spécifique qui envoie votre destination SSH via votre passerelle locale :
sudo ip route ajouter /32 via5. Vérifiez les règles IP côté serveur
Si le serveur utilise la liste blanche d'adresses IP, des pare-feu ou des outils comme fail2ban peuvent bloquer les adresses IP VPN. Vérifiez les journaux sur le serveur et ajoutez les adresses IP correctes à la liste blanche (voir la section sur la rotation des adresses IP ci-dessous).
Cas particulier : le serveur met les adresses IP sur liste blanche et la mise sur liste blanche ne semble pas fonctionner
Lorsqu'un serveur n'autorise que des adresses IP client spécifiques, ajouter une mauvaise adresse (ou une seule) à la liste blanche peut entraîner un blocage si le VPN modifie les adresses IP, les protocoles ou fournit plusieurs points de sortie. Voici quelques nuances et recommandations importantes :
Rotation des IP et des protocoles VPN
De nombreux services VPN commerciaux (et certains VPN d'entreprise) proposent plusieurs protocoles et serveurs de sortie. Certains fournisseurs utilisent des tunnels UDP (par exemple, OpenVPN sur UDP) ou des protocoles plus récents comme WireGuard, qui peuvent modifier fréquemment votre adresse IP publique. Si votre VPN attribue une nouvelle adresse IP publique à chaque session, l'ajout d'une seule adresse IP à la liste blanche échouera.
Plages de listes blanches par rapport aux adresses IP uniques
Pour que SSH fonctionne sur un tel VPN, les administrateurs mettent parfois une adresse IP sur liste blanche. gamme appartenant au fournisseur VPN. La liste blanche augmente les chances que votre nœud de sortie VPN actuel soit couvert, mais elle élargit également l'accès et augmente les risques de sécurité.
Déroulement pratique du travail
- Identifiez les IP de sortie VPN pendant la connexion (par exemple, visitez un service « quelle est mon IP » à partir de la connexion VPN ou vérifiez votre IP publique à partir de la machine cliente).
- Ajoutez à la liste blanche l'adresse IP ou la plus petite plage CIDR pratique sur le pare-feu du serveur pour autoriser votre connexion SSH.
- Exécutez la session SSH dont vous avez besoin.
- Une fois l'opération terminée, supprimez l'entrée temporaire de la liste blanche élargie afin de réduire la surface d'attaque et revenez à la politique stricte. L'automatisation des ajouts/suppressions avec une fenêtre de modification de courte durée réduit les risques.
Remarque : si vous contrôlez les deux extrémités, envisagez d’autres options sécurisées telles que l’utilisation d’un hôte de saut avec TLS mutuel, des proxys d’accès compatibles VPN ou une authentification SSH basée sur un certificat éphémère qui réduit la dépendance aux listes blanches IP.
Exemple : les protocoles UDP et leur importance
Certains pare-feu ou appliances réseau différencient le trafic par protocole à un niveau plus profond ; les tunnels VPN UDP peuvent être gérés par des règles NAT/pare-feu différentes de celles du protocole TCP. Cela peut affecter l'adresse de sortie utilisée ou le comportement identique de la redirection de port/NAT. Si vous constatez des incohérences entre les protocoles, testez le VPN en utilisant les modes UDP et TCP (si le client le prend en charge) afin de trouver l'option la plus stable pour votre environnement.
Notes spécifiques au fournisseur (expérience utilisateur)
Les fournisseurs de VPN se comportent différemment. Par exemple, certains utilisateurs constatent qu'un fournisseur disposant d'adresses IP de sortie tournantes (ou de nombreux nœuds de sortie) nécessite une liste blanche de plages, tandis que d'autres fournisseurs disposant d'adresses IP de sortie plus stables n'en ont pas besoin. Un utilisateur a rapporté que ExpressVPN les nœuds de sortie rotatifs/variés nécessitaient des plages de liste blanche, tandis que ProtonVPN Les résultats ont été cohérents pour les mêmes flux de travail. Votre expérience peut varier ; vérifiez toujours les adresses IP de sortie et le comportement du fournisseur avant de modifier définitivement les politiques de pare-feu.
Considérations de sécurité
L'ajout de larges plages d'adresses IP à la liste blanche expose votre serveur à davantage d'attaquants potentiels. Si vous devez ajouter temporairement des plages à la liste blanche, suivez ces bonnes pratiques :
- Créez une liste blanche avec une plage aussi petite que possible.
- Limitez le temps de modification de la liste blanche et supprimez-la immédiatement une fois la tâche terminée.
- Utilisez une authentification forte sur le serveur SSH (clé publique uniquement, aucune authentification par mot de passe) et envisagez une authentification à deux facteurs pour SSH lorsque cela est possible.
- Utilisez la journalisation, les alertes et l'automatisation des accès temporaires afin que les ajouts/suppressions de listes blanches soient vérifiables.
Liste de contrôle récapitulative
| Problème | Symptôme | Réparer |
|---|---|---|
| Le VPN achemine tout le trafic | SSH expire | Activer le tunneling fractionné ou ajouter une route d'exception |
| Pare-feu VPN | Port 22 bloqué | Utiliser un port alternatif (par exemple, 443) ou modifier le port d'écoute du serveur |
| Modifications DNS | Hôte non trouvé ou résolu de manière incorrecte | Connectez-vous par IP ou modifiez temporairement le DNS pour le dépannage |
| Conflit de routage | Trafic envoyé vers la mauvaise interface | Ajouter une route statique au serveur via une passerelle locale |
| Liste blanche d'adresses IP / rotation des adresses IP VPN | La mise sur liste blanche d'une seule adresse IP échoue | Ajoutez temporairement des plages minimales de fournisseurs à la liste blanche, puis supprimez-les ; ou utilisez des méthodes d'authentification éphémères |
Exemples de commandes
Commandes utiles référencées dans cet article :
- Se connecter via le nom d'hôte :
utilisateur [email protected] - Se connecter via IP :
utilisateur ssh@ - Se connecter sur un port alternatif :
ssh -p 2222 [email protected] - Vérifier le routage (Linux/macOS) :
route IP - Ajouter une route pour contourner le VPN (Linux) :
sudo ip route ajouter /32 via - Exemple de route client OpenVPN :
itinéraire 255.255.255.255 passerelle_net
Réflexions finales
L'échec de SSH uniquement lorsqu'un VPN est activé est généralement dû au routage, au DNS ou au comportement du pare-feu/liste blanche, et parfois à l'utilisation par le fournisseur VPN d'adresses IP tournantes ou de protocoles de transport différents. Identifiez la couche interférente, appliquez la solution la moins permissive possible (tunneling fractionné, plages de liste blanche minimales ou ports alternatifs) et supprimez tout accès temporaire et étendu une fois l'opération terminée.
Si vous le souhaitez, je peux adapter cet article pour inclure des exemples étape par étape d'OpenVPN / WireGuard / AnyConnect pour un système d'exploitation spécifique (Windows, macOS, Linux) ou une configuration de client VPN spécifique.
Dernière mise à jour le 17 octobre 2025

