L’IP de sortie d’un VPN ne prouve pas un tunnel : ce que voient les serveurs

Quelqu’un demande un service que seuls les utilisateurs d’un VPN peuvent atteindre, et l’implémentation évidente consiste à autoriser une liste d’adresses de sortie. La liste fait quelque chose de réel : elle restreint qui peut se connecter. Elle n’établit pas qu’un tunnel a été utilisé, car l’adresse appartient à celui qui exploite la sortie et cet opérateur peut relayer le trafic de n’importe qui. L’écart entre ces affirmations constitue tout le problème de conception.

Le serveur voit une seule adresse par connexion

Une connexion arrive avec une adresse source et un port de destination, et c’est tout ce que le réseau signale. Quand un client utilise un tunnel, les paquets qui atteignent votre écouteur viennent de la sortie ou de la traduction devant elle. L’adresse propre du client, généralement privée, n’apparaît jamais. Une règle de pare-feu écrite pour la plage du réseau local du client ne fait donc absolument rien.

Tout ce qui suit cette adresse source est une donnée d’application, et l’application ne peut lui faire confiance que dans la mesure où elle l’authentifie.

Vérifiez à quoi ressemble votre sortie

Examinez le chemin des deux côtés avant d’écrire une règle. La vision qu’a le client de sa sortie et celle qu’a le serveur de la connexion sont les deux faits qui comptent.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

La première commande indique l’adresse publique sous laquelle le client apparaît, et c’est la valeur que toute liste d’autorisation doit contenir. La seconde montre les connexions établies sur le serveur avec les adresses de leurs pairs, et c’est à cela que la règle correspondra réellement. Si les deux ne concordent pas avec votre modèle mental, corrigez le modèle avant de modifier la politique. Un pare-feu de base de données cloud, une liste d’autorisation applicative et un répartiteur de charge peuvent chacun voir une couche de traduction différente.

Un seul des deux ensembles de sorties peut être répertorié

Un cas est vérifiable au moment de la requête et l’autre non, ce qui produit des garanties très différentes.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

La liste publique des sorties Tor peut être récupérée et comparée, sous réserve de l’âge de la liste et de la politique propre à chaque sortie, si bien qu’une règle de refus visant des sorties connues est applicable et vérifiable. Il n’existe pas de registre équivalent pour les VPN commerciaux. Les adresses tournent, de nombreux fournisseurs ne publient rien, et un tunnel peut fonctionner sur une adresse cloud louée qui n’a jamais appartenu à un VPN. La liste que vous composez est un instantané d’adresses observées, et l’élargir à des plages d’hébergement ajoute des charges sans rapport sans ajouter de preuve.

Utilisez les adresses comme entrée de politique, pas comme preuve

Décidez à quoi sert la règle. Une restriction réseau doit rester étroite, consigner l’adresse observée avec sa date et son motif, et offrir aux utilisateurs légitimes un chemin de récupération lorsque leur sortie change. Le contrôle d’accès exige un compte authentifié ou un jeton signé, car seuls ceux-ci lient une requête à une identité. La notation de risque peut utiliser l’adresse comme un signal unique et peu fiable, en acceptant ses faux positifs et ses angles morts. Écrire la règle comme une décision produit est honnête ; l’écrire comme une vérification qu’un tunnel existe ne l’est pas.

La requête en miroir, retrouver l’adresse réelle de l’utilisateur derrière un VPN, échoue pour la même raison : une connexion porte une adresse, et un changement entre sessions est compatible avec plusieurs explications. Traitez la valeur antérieure comme un historique, non comme une vérité.