Un préfixe public pour les clients VPN : ce que cela casse vraiment

Un pool de clients choisi parce que les nombres paraissent bien ordonnés est une route qui attend d'être installée. Le préfixe n'a pas besoin d'être privé pour que le VPN fonctionne, et l'utilisation d'un bloc qui appartient à quelqu'un d'autre n'expose pas non plus automatiquement vos utilisateurs à internet. Ce qu'il fait, c'est donner à ces adresses un sens différent tant que le tunnel est levé, puis un autre sens encore lorsqu'il tombe. Passez les cinq contrôles ci-dessous dans l'ordre et arrêtez-vous là où la réponse est « attribué ailleurs ».

Attribuer n'est pas annoncer

Placer une adresse sur une interface de tunnel ne l'annonce pas à internet. La joignabilité publique exige une route, un chemin autorisé et un fournisseur prêt à la porter, et rien de tout cela n'apparaît parce qu'un client a reçu l'adresse d'un pool. La politique du pare-feu et l'autorisation de l'hôte sont encore des décisions distinctes.

C'est pourquoi le risque n'est pas ce que la plupart des gens supposent. Le préfixe emprunté ne rend pas vos clients joignables ; il rend les destinations de quelqu'un d'autre injoignables depuis vos clients, ce qui est une défaillance différente avec un propriétaire différent. Personne n'est attaqué et aucune annonce ne s'échappe. Un utilisateur ne peut simplement pas ouvrir un site qui fonctionnait hier, et le support n'a aucune raison de soupçonner le pool VPN.

La distinction compte lorsqu'on choisit un pool. Si votre seule préoccupation était l'exposition à internet, un bloc public semblerait sûr parce que rien ne l'annonce. La préoccupation est la route locale que le client installe pour ce préfixe, et cette route est installée que quelqu'un d'autre puisse la voir ou non.

Ce que la route du client capture réellement

Lorsque le tunnel monte, le client reçoit une route pour le préfixe du pool, et cette route l'emporte sur la route par défaut pour chaque destination à l'intérieur. Une requête vers un hôte légitime de ce bloc va désormais au VPN au lieu d'internet. Qu'elle échoue, se bloque ou atteigne le mauvais serveur dépend de ce que votre côté en fait.

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

Exécutez la recherche tunnel levé, puis à nouveau tunnel baissé. L'adresse signifie une chose dans le premier cas et quelque chose de complètement différent dans le second, et toute application qui a mis en cache une connexion ou une résolution de nom pendant cette transition se comportera de manière incohérente. Cette incohérence est plus difficile à soutenir qu'une défaillance nette, car elle dépend du moment. Un utilisateur qui se reconnecte au mauvais moment a une expérience différente de celui qui ne le fait pas.

C'est aussi pourquoi une adresse IP familière n'est pas une preuve d'identité. Conservez la validation du certificat et du nom de serveur pour la destination réelle, car l'adresse numérique que vous avez atteinte il y a cinq minutes peut désormais appartenir à une autre conversation.

Comparez le pool à tous les réseaux que vous connaissez

RFC 1918 réserve trois blocs à l'usage privé : 192.168.0.0/16, 172.16.0.0/12 et 10.0.0.0/8. Des millions d'organisations distinctes les réutilisent, donc privé est une affirmation sur l'attribution et jamais une promesse que personne d'autre n'a choisi les mêmes numéros.

Comparez le pool candidat aux LAN de bureau, aux VPC du cloud, aux autres pools VPN, aux liaisons partenaires et aux plages que les télétravailleurs ont probablement chez eux. Le cas domestique n'est pas une raison d'inventer un préfixe étrange ; c'est une raison de garder le pool petit et documenté.

Coordonnez l'attribution avec celui qui possède le routage et enregistrez le chemin de retour au même endroit. Un pool vers lequel personne ne peut router en retour est un pool qui sera redécouvert lors d'une panne. Placez le pool dans le même document que les plages des sites, pas dans une configuration client qu'une seule personne a modifiée. Le document est ce qui rend la prochaine collision évitable.

Quand l'adressage public est la bonne réponse

Les organisations disposant d'un espace global correctement attribué peuvent tout à fait construire un pool VPN à adressage public, et certaines le font délibérément pour éviter la traduction. Cette conception a toujours besoin de routage, de validation de source, de règles d'accès et d'authentification client ; l'attribution n'en fournit aucun.

Ce qu'elle fournit, c'est l'unicité, la propriété qui manque au préfixe emprunté. Si vous détenez le bloc, la route que votre client installe pointe vers des adresses qui sont véritablement les vôtres, et le sens ne change pas lorsque le tunnel tombe.

N'ajoutez pas de NAT automatiquement pour compenser un choix de pool. Une conception privée routée avec des routes de retour explicites est plus propre qu'une traduction appliquée parce que l'adressage n'a jamais été planifié, et IPv6 a besoin de son propre plan délibéré plutôt que d'une copie des hypothèses d'IPv4.

Retirez un mauvais pool sans perdre l'accès

Si le pool est déjà déployé, faites un inventaire avant de le changer : réservations d'adresses, routes installées, enregistrements DNS qui résolvent dans le bloc, périmètres du pare-feu et les applications qui en dépendent. Planifiez ensuite le changement avec le même soin que toute autre bascule de routage. Annoncez-le aux personnes qui le remarqueront, car leurs sessions tomberont lorsque le pool bougera. Un changement silencieux de l'adressage des clients génère des tickets de support qui semblent sans rapport avec le travail.

Préservez un chemin de récupération qui ne dépend pas du pool que vous retirez, car le moment où vous le retirez est le moment où votre accès distant peut disparaître avec lui. Validez ensuite les deux sens : les destinations privées prévues fonctionnent toujours, et les destinations internet qui étaient capturées auparavant résolvent maintenant vers leurs véritables propriétaires.

Ce que vous voulez, c'est un pool que l'équipe réseau peut attribuer, router et retirer comme une seule chose cohérente. Un format d'adresse à lui seul n'établit ni la sécurité ni la connectivité.