Adresse VPN ajoutée à la liste blanche et toujours bloquée ? Remontez la piste

Autoriser l’adresse qu’affiche une application VPN corrige rarement un port bloqué, et le paquet explique pourquoi. Le pare-feu n’ignore pas votre règle ; il évalue une adresse source que rien à l’écran du client n’affiche. Tant que la destination ne rapporte pas cette valeur, chaque modification de règle est une supposition.

Partez de la requête qui arrive au service. L’adresse du tunnel, l’adresse de sortie et toute traduction entre les deux restent des hypothèses jusqu’à ce que la destination en confirme une.

L’adresse affichée dans l’application n’est pas celle qui arrive

Une connexion VPN transporte au moins quatre adresses qu’il vaut la peine de nommer séparément : le point de terminaison du serveur, l’adresse interne du tunnel attribuée à votre client, l’adresse locale Wi-Fi ou Ethernet, et l’adresse publique qu’un site voit une fois le trafic sorti du fournisseur. La fenêtre du client peut n’afficher que la deuxième. Nommez les quatre avant de nommer une règle. Avec un tunnel divisé, les requêtes vers une destination publique peuvent contourner entièrement le tunnel, si bien que la session qui échoue n’est pas celle que l’utilisateur croit avoir lancée.

Déterminez laquelle de ces quatre la règle est censée autoriser, puis vérifiez-la depuis l’autre côté. Si l’exigence est réellement une adresse de bureau, la condition est la route plus l’organisation de sortie de ce site, et une connexion étiquetée Office VPN ne fournit ni l’une ni l’autre à elle seule.

Suivez une requête jusqu’à sa frontière de filtrage

Confirmez l’adresse de destination et le port utilisés par le client, puis vérifiez que cette destination suit le chemin que vous supposez. Un port de conteneur publié, un proxy inverse ou une redirection de port peuvent déplacer la décision vers un hôte que vous n’avez jamais modifié. Chacun de ces sauts peut porter sa propre politique. Établir d’abord le chemin vous évite de corriger une règle qu’aucun paquet n’atteint.

Sur un hôte Linux autorisé, lisez les règles actives dans l’ordre avant de les modifier. Les services redirigés et les services de conteneurs sautent souvent dans leur propre chaîne, examinez donc la cible du saut ainsi que le verdict final.

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

Citez le numéro de règle correspondant dans le ticket. Sans lui, le lecteur suivant ne peut pas savoir quelle modification a changé le résultat. Un numéro de règle sans horodatage reste ambigu.

Vérifiez le chemin avec une capture ciblée

Une requête inoffensive et une capture étroite tranchent la question qui revient sans cesse. Filtrez sur le port de destination et l’hôte étudié, limitez le nombre de paquets et arrêtez la capture dès que la requête est terminée.

tcpdump -ni any 'tcp dst port 9443' -c 20

Comparez trois valeurs côte à côte : la source dans la capture, la source que nomme la règle correspondante et le rejet que l’application a journalisé. Elles peuvent toutes différer, et seule la première explique une chute décidée par une règle IP. Un en-tête HTTP transféré appartient à la couche proxy, donc un journal qui cite cet en-tête ne décrit pas la source que le pare-feu a évaluée.

Lisez l’ordre de la chaîne, pas seulement la règle

La référence iptables documente le parcours ordonné, c’est pourquoi une autorisation située sous un rejet terminal correspondant ne sauve jamais le paquet. Une connexion acceptée plus tôt peut aussi se comporter différemment d’une nouvelle, donc un ancien succès ne dit rien de la nouvelle règle. Trouvez le rejet ou la chute au-dessus de votre autorisation avant de supposer que l’autorisation est fausse. Les compteurs par règle indiquent aussi quelle règle a vu le paquet.

Supprimer une règle pour voir ce qui se passe est un changement, pas une observation. Lisez les compteurs, notez le numéro de règle et conservez la politique d’origine dans le journal des modifications. Si un test est inévitable, exécutez-le sur une copie de la chaîne.

Modifiez la règle que contrôle son propriétaire

Ne mettez à jour que la politique de source et de service visée, par l’intermédiaire de celui qui la possède. Une sortie traduite partagée peut représenter de nombreux utilisateurs à la fois, donc autoriser cette adresse n’authentifie personne, et les permissions applicatives derrière restent où elles sont.

Lorsque l’adresse continue de bouger, la réponse durable est une sortie stable ou un canal authentifié, pas une liste d’exceptions plus longue. Notez la source observée, le port de destination et le numéro de règle.