Ports bloqués
Un fournisseur de proxys peut interdire les connexions à certains ports réseau. Il peut autoriser la navigation web tout en refusant les connexions aux ports utilisés pour envoyer des courriels. Le proxy accepte toujours la connexion du client, mais n’établit pas la connexion demandée au serveur de messagerie.
Les restrictions de ports font partie des limites d’utilisation des proxys qui déterminent les tâches qu’un service peut prendre en charge. Pour comprendre leur effet, il faut distinguer la connexion au proxy de celle que le proxy établit pour vous.
Quel port est bloqué ?
Un port réseau est un numéro qui permet de distinguer les services à une adresse réseau. Le même serveur peut accepter des connexions web sur un port et celles d’une autre application sur un port différent. Une application a besoin de l’adresse du serveur, du port approprié et du transport utilisé : TCP ou UDP.
Une connexion proxy comporte deux destinations distinctes. Votre application se connecte d’abord au proxy à l’adresse et au port fournis par le prestataire. Elle demande ensuite au proxy d’atteindre le serveur cible à l’adresse et au port de ce serveur. Le port indiqué dans vos paramètres proxy appartient à la première étape ; une restriction de port de destination s’applique à la seconde.
Par exemple, un programme peut se connecter à proxy.example:1080 et demander portal.example:443. Le même point d’entrée proxy peut aussi recevoir une demande pour mail.example:587. Si le fournisseur autorise le premier port de destination et bloque le second, la connexion web peut réussir tandis que la connexion de messagerie est refusée.
Ces restrictions concernent les connexions sortantes du proxy vers des services externes. Autoriser une telle connexion ne donne pas à une application de votre ordinateur un port entrant joignable par les autres internautes. La redirection de ports entrants est une fonctionnalité distincte.
Pourquoi les fournisseurs restreignent les ports
La raison la plus évidente est de prévenir les abus d’un service particulier. L’accès direct aux serveurs de messagerie peut servir à des campagnes de spam. Les plaintes et les listes de blocage d’expéditeurs touchent les adresses IP qui transportent le trafic ; les conséquences peuvent donc dépasser le client qui a envoyé les messages. Un fournisseur peut réduire ce risque en refusant les connexions aux ports d’envoi de courriels avant toute transmission de messages.
Des considérations similaires peuvent s’appliquer aux services d’administration à distance, de partage de fichiers ou de bases de données. Un fournisseur peut restreindre l’accès aux ports associés à ces services pour réduire les tentatives de connexion non autorisée et les autres attaques. La restriction s’applique à la connexion elle-même : un administrateur légitime peut aussi être incapable d’atteindre son propre serveur par ce produit.
La règle ne vient pas toujours du vendeur de proxys. Un hébergeur ou un opérateur réseau peut filtrer les connexions sortantes de l’infrastructure utilisée par le proxy. Une autorisation dans le logiciel proxy ne peut pas annuler une restriction imposée plus loin sur le trajet.
Un filtre de ports est une mesure large. Il peut arrêter du trafic indésirable sans examiner chaque message ni décider si chaque opération est légitime, mais il limite aussi les applications utiles qui ont besoin du même port. Ce compromis explique pourquoi un fournisseur peut garder un port fermé même pour un client payant ayant un besoin raisonnable.
Comment fonctionnent les règles d’accès aux ports
Il existe deux approches de base. Une liste de blocage nomme les ports que les clients ne peuvent pas utiliser ; les autres connexions sont évaluées selon les règles restantes du service. Une liste d’autorisation fonctionne à l’inverse : le fournisseur autorise un ensemble précis de ports et refuse les autres. Dans ce second modèle, une application web ordinaire sur un port non standard peut être indisponible simplement parce que son port ne figure pas dans l’ensemble autorisé.
Une règle peut couvrir un port à toutes les adresses externes ou combiner ce port avec une destination précise. Les fournisseurs peuvent aussi appliquer des règles différentes selon les produits ou les usages approuvés. L’accès par un réseau ne permet donc pas de déduire les autorisations d’un autre produit vendu par la même entreprise.
Le proxy n’a pas besoin de déchiffrer le trafic de l’application pour appliquer une règle de port de destination. Dans une requête HTTP CONNECT, le client fournit l’hôte et le port cibles. SOCKS5 transmet aussi la destination demandée dans sa requête de connexion. Le proxy peut rejeter cette requête avant le début d’une session protégée avec le serveur cible.
Les trafics TCP et UDP utilisant le même numéro de port peuvent être autorisés ou bloqués séparément. Une connexion réussie au port TCP 443 ne prouve pas que le port UDP 443 est disponible. Une autre possibilité existe : le produit proxy choisi peut ne pas transporter du tout l’UDP. Dans ce cas, la limite concerne le transport plutôt qu’un port UDP particulier.
Un numéro de port ne prouve pas non plus, à lui seul, ce que fait une application. Des services peuvent fonctionner sur des ports non standard, et un numéro autorisé ne rend pas tous ses usages acceptables. Les fournisseurs peuvent combiner les filtres de ports avec des restrictions de destinations et des règles encadrant l’activité elle-même.
Ce que cela change pour les applications
Les applications utilisent des connexions pour des fonctions précises. Un test dans un navigateur vérifie la connexion web qu’il établit ; il ne teste pas toutes les connexions dont un autre programme pourrait avoir besoin. Les exemples suivants montrent comment une restriction de port peut affecter un service qui fonctionne par ailleurs.
| Connexion | Ports utilisés dans cet exemple | Effet d’une restriction |
|---|---|---|
| Accès web par TCP | 443 | La page ne peut pas être récupérée par cette connexion. |
| Envoi de courriels | TCP 25 pour la livraison entre serveurs ; TCP 465 ou 587 pour la soumission par une application de messagerie | L’envoi direct de courriels par la connexion concernée est indisponible. |
| FTP passif | TCP 21 pour les commandes et un port distinct annoncé par le serveur pour les données | La connexion au compte peut réussir tandis que l’affichage du répertoire ou le transfert de fichiers échoue. |
| Application web sur un port personnalisé | Par exemple, TCP 8443 | L’application peut être inaccessible alors que les sites sur TCP 443 fonctionnent. |
La messagerie illustre particulièrement bien cette distinction. Une application de messagerie soumet les messages sortants à un serveur, généralement sur le port 587 ou 465. Le port 465 commence par le chiffrement TLS ; le port 587 utilise couramment STARTTLS pour établir le chiffrement. Une restriction de port peut empêcher l’une ou l’autre connexion avant l’envoi du message. Le chiffrement protège l’échange, mais ne supprime pas la règle d’accès du fournisseur.
Dans une interface de webmail, le navigateur communique avec un site par HTTPS, et le service de messagerie assure la livraison. Le navigateur ne demande pas au proxy d’établir cette même connexion SMTP. Une boîte mail web peut donc rester utilisable tandis que l’accès SMTP est bloqué. La réception des courriels dans une application distincte constitue encore une autre connexion : l’accès IMAP ou POP doit être examiné séparément de l’envoi.
FTP montre pourquoi un simple test de connexion au compte peut manquer un problème. En mode passif, le client envoie d’abord les commandes sur une connexion, puis se connecte à un port indiqué par le serveur pour transférer les données. Si la seconde connexion est restreinte, l’authentification peut fonctionner tandis que la liste des fichiers ou le téléchargement échoue. Les applications qui utilisent des connexions distinctes pour l’authentification, la voix ou l’échange de fichiers peuvent présenter des échecs partiels similaires.
Pourquoi modifier les paramètres proxy peut ne pas aider
Modifier le port d’entrée dans vos paramètres proxy change l’endroit où votre application contacte le proxy. Cela ne change pas le port de destination demandé pour le service externe. Si le fournisseur propose un point d’entrée sur le port 443, s’y connecter laisse toujours une demande pour le port 587 du serveur de messagerie soumise à la restriction des ports de messagerie.
Passer d’un proxy HTTP à SOCKS5 peut résoudre un problème de compatibilité lorsque l’application a besoin d’une fonctionnalité prise en charge par la nouvelle méthode de connexion. Cela n’annule pas, en soi, les règles du fournisseur. SOCKS5 définit comment demander des connexions TCP et le transfert UDP ; le service décide lesquelles de ces demandes il accepte.
Remplacer une IP de sortie laisse aussi en place une restriction applicable à tout le produit. Un trajet différent peut se comporter autrement lorsqu’un réseau externe précis cause la défaillance, mais la rotation ne supprime pas une règle applicable au produit entier. Davantage d’IP ou un quota de trafic plus élevé ne changent pas non plus cette autorisation.
Comment identifier une restriction de port
L’élément le plus utile est une réponse explicite du fournisseur indiquant que le port de destination demandé n’est pas autorisé. Un message générique de refus d’accès est moins précis. Par exemple, la réponse SOCKS5 à une requête rejetée par les règles indique un refus fondé sur la politique d’accès, mais ne précise pas la règle en cause. Un dépassement de délai ou une réinitialisation seuls sont des indices encore plus faibles.
Le serveur cible peut n’avoir aucun service à l’écoute sur ce port, n’accepter que certaines adresses sources ou être temporairement indisponible. L’application peut aussi utiliser le mauvais protocole ou envoyer une partie du trafic en dehors du proxy configuré. Vérifier une requête web réussie ne permet pas de distinguer ces causes d’une restriction qui touche une autre connexion.
Pour une demande d’assistance utile, indiquez le produit proxy, le nom d’hôte ou l’IP cible, son port, TCP ou UDP, l’application et l’erreur exacte avec l’heure de la tentative. Ces détails permettent à l’assistance de vérifier la connexion concernée plutôt que de simplement confirmer que le proxy est en ligne. Avant un achat, les mêmes informations aident à établir si le produit prend en charge la tâche.
Lorsque le fournisseur autorise des exceptions, l’approbation doit préciser la destination et l’usage requis. Certaines restrictions restent permanentes ou proviennent d’une infrastructure que le fournisseur ne contrôle pas. La question utile est de savoir si la connexion précise peut être prise en charge selon les règles du service ; demander « d’ouvrir tous les ports » laisse le besoin et les limites indéterminés.