Limitez un écouteur VPN aux interfaces que vous visiez

Un service VPN est joignable partout où sa socket est liée et où son pare-feu l'autorise. Ce sont deux décisions distinctes, et les gens n'en prennent généralement qu'une. Lire l'écouteur réel prend dix secondes et tranche une question que les suppositions ne peuvent pas trancher. Commencez par là, puis changez un contrôle à la fois.

Tout ce qui suit suppose que vous pouvez exécuter des commandes sur l'hôte avec root ou sudo.

Lisez les sockets avant de changer quoi que ce soit

Sous Linux, ss -lunp liste les écouteurs UDP avec leur adresse locale, leur port et leur processus, et ss -ltnp fait de même pour TCP. Cherchez le port du VPN et lisez attentivement la colonne d'adresse. 0.0.0.0:51820 et [::]:51820 signifient toutes les interfaces, tandis que 10.0.0.5:51820 signifie une adresse sur une interface. Le manuel de ss documente les colonnes si la sortie ne vous est pas familière. Si le nom du processus manque, exécutez la même commande avec sudo, car la colonne du propriétaire exige un privilège.

Notez l'adresse. C'est le fait dont dépend le reste de ce guide.

Liez-vous à une adresse, pas à un souhait

OpenVPN lie l'écouteur à une adresse précise avec sa directive local, et c'est la manière prise en charge de le circonscrire au niveau du processus. Toutes les implémentations n'offrent pas d'équivalent, et un protocole sans option de liaison ne peut pas être restreint ainsi. Si la vôtre n'en a aucune, le pare-feu est votre seul contrôle, et les notes de déploiement devraient le dire clairement. Sur un hôte à plusieurs adresses, liez-vous à celle qui fait face au tunnel ; se lier à une adresse flottante est généralement une erreur.

Un service qui doit survivre à un changement d'adresse a besoin d'un plan pour la liaison obsolète, pas seulement d'une ligne de configuration.

Vérifiez la famille d'adresses séparément

IPv4 et IPv6 sont des sockets distinctes. Un processus lié à 0.0.0.0 peut encore accepter IPv6 via une socket double pile, ou pas, selon l'option de socket et la valeur par défaut de la plateforme. Lire uniquement la ligne IPv4 a trompé plus d'une revue de déploiement. Listez les deux familles avant de conclure que l'écouteur est étroit.

Si IPv6 ne fait pas partie de la conception, le désactiver au niveau de la socket est plus propre que d'espérer que le pare-feu le couvre. C'est une décision de politique, alors consignez-la avec le reste des choix d'interface.

Superposez le pare-feu à la liaison

Une liaison étroite ne remplace pas une règle de pare-feu, et une règle de pare-feu ne restreint pas une liaison générique. Utilisez les deux : liez-vous là où l'implémentation le permet, puis n'autorisez le port que depuis les sources qui doivent l'atteindre. Les groupes de sécurité cloud se placent devant le pare-feu de l'hôte, alors vérifiez les deux lorsque le chemin traverse une frontière de VPC. La règle effective est l'intersection des deux, et chaque couche ne peut que retirer de l'accessibilité.

Testez depuis une source autorisée et depuis une source délibérément exclue. Une connexion depuis localhost ne prouve rien sur la frontière publique.

Consignez ce que vous avez choisi

Notez l'adresse liée, l'interface qui la possède, la règle de pare-feu et son but. Une carte réseau de remplacement ou une adresse cloud réattribuée peut modifier l'exposition sans que personne n'édite le profil. Datez la note, car les adresses cloud bougent entre les revues plus souvent qu'on ne l'attend.

Cette note est ce qui fait de la prochaine revue une comparaison plutôt qu'un projet d'archéologie.