Un réseau peut-il bloquer votre VPN sans casser le chiffrement ?

Aucun opérateur n’a besoin d’une clé de session pour arrêter un tunnel : jetez les paquets sur le chemin et il échoue, tandis que la cryptographie reste exactement aussi solide que sa conception l’a promis. Le chiffrement protège ce qu’une conversation transporte, pas la volonté d’un réseau de le transporter. Séparer ces deux propriétés transforme un débat sur l’impossibilité de bloquer en une question sur la politique en vigueur et sur sa portée. La comparaison ci-dessous tient disponibilité et confidentialité séparées, car la plupart des affirmations assurées sur le blocage des VPN les fusionnent sans le dire.

La joignabilité est une décision prise par le chemin

Chaque transport dépend d’un chemin qui achemine les paquets, et toute question de politique ici se ramène à cette décision d’acheminement. Une règle qui abandonne des paquets change la disponibilité sans toucher à la confidentialité, et c’est ainsi qu’un tunnel peut être parfaitement chiffré et totalement inutilisable au même instant. Rien dans ce résultat n’exige de casser un chiffrement ni de récupérer une clé. Il exige seulement la maîtrise du chemin.

La confusion commence souvent parce que deux propriétés partagent un mot. Une cryptographie forte dit qui peut lire un flux ; elle ne dit rien sur le fait qu’un équipement intermédiaire le laissera passer. L’affirmation qu’un VPN ne peut pas être bloqué a donc besoin d’une seconde affirmation en dessous, à savoir que personne sur le chemin n’est prêt à abandonner les paquets.

Styles d’application et prix de chacun

Trois styles couvrent la plupart des politiques réelles, et ils diffèrent par ce qu’ils doivent savoir, ce que coûte leur exploitation et qui d’autre en souffre. Chacun peut refuser un tunnel sans rien déchiffrer. Les différences comptent parce que le même mot, blocage, sert pour les trois.

Ce tableau est une carte des coûts, pas un classement. Une liste de blocage est peu coûteuse à démarrer et coûteuse à garder exacte ; une liste d’autorisation échange la découverte contre la maintenance de l’ensemble autorisé, et une coupure n’a besoin d’aucune classification. Ce qui les sépare n’est pas la sophistication technique mais l’endroit où chacune place l’effort continu. Une politique qui paraît simple sur le papier cache généralement une ligne de maintenance ailleurs.

Une liste de blocage est limitée par la façon dont une adresse nomme un service

Une liste de blocage refuse des destinations déjà identifiées et laisse le reste généralement disponible. Pour l’appliquer, il faut des adresses et des ports, pas du texte en clair, et c’est ce qui la rend peu coûteuse à exploiter au début. Le coût vient plus tard, car une plage qui désignait autrefois un fournisseur peut ensuite héberger une douzaine de locataires sans rapport. Chaque changement d’adresse impose de modifier la liste, et chaque entrée périmée emporte du trafic innocent.

La précision de ce modèle est limitée par la façon dont une destination identifie un service, et un point de terminaison partagé et très sollicité est un mauvais identifiant. C’est une limite structurelle et non un défaut d’implémentation, si bien que de meilleurs outils ne la suppriment pas. Cela explique aussi pourquoi les listes de blocage tendent à grossir : chaque nouveau point de terminaison ressemble à un petit ajout, et les dégâts collatéraux croissent avec la liste.

Une liste d’autorisation déplace la charge de maintenance

Une liste d’autorisation inverse la valeur par défaut pour que seules les destinations ou les types de trafic choisis à l’avance passent. Elle n’a pas à énumérer chaque point de terminaison interdit, ce qui aide quand l’ensemble interdit est grand ou change vite. Il lui faut plutôt une définition maintenue de ce qui est permis, plus une application qui correspond à cette définition.

Les numéros de port sont le point faible habituel d’une telle définition. Autoriser un port n’est pas la même chose qu’identifier chaque application qui peut l’utiliser, si bien qu’une liste d’autorisation fondée sur les ports admet souvent plus que son auteur ne le voulait. Les empreintes de protocole posent le même problème sous un autre angle, car elles identifient une forme de trafic plutôt qu’une intention. Une liste d’autorisation n’est donc pas automatiquement plus précise qu’une liste de blocage ; elle est précise sur autre chose.

Ce qu’une observation peut étayer et ce qu’elle ne peut pas

Toute affirmation sur le blocage devrait se lire avec quatre questions en main : quels réseaux d’accès, quelles destinations, quels protocoles et quelle période d’observation. Une défaillance vue aujourd’hui sur un réseau mobile ne dit rien du même point de terminaison demain depuis un autre réseau. Un tunnel qui a fonctionné une fois ne dit rien non plus d’une disponibilité durable.

La forme d’une défaillance s’observe avant de théoriser sur sa cause. Un blocage silencieux, un refus immédiat et une réinitialisation après connexion renvoient à des styles d’application différents, et deux commandes les distinguent :

curl -sS -m 8 https://vpn.example.com/ -o /dev/null -w "%{http_code}\n"
traceroute -n -m 8 vpn.example.com

Un blocage qui finit en délai dépassé suggère un abandon silencieux, un refus rapide un équipement qui rejette sur le chemin, et une réinitialisation après connexion une interférence avec état plutôt qu’une route absente. L’enquête RFC 9505 sur les techniques de censure décrit les points de contrôle et les schémas d’interférence derrière ces formes. Aucune ne dit pourtant jusqu’où s’applique la politique. La permanence est une affirmation plus forte que la joignabilité : points de terminaison, logiciels, politiques et services autorisés changent tous, si bien qu’une efficacité indéfinie exige des hypothèses sur la poursuite de l’application, et non une liste d’adresses observées à un instant donné.