Ne devinez pas le préfixe du bureau à partir d’une seule adresse de serveur

Partez de l’adresse qu’on vous a donnée, puis résistez à l’envie de l’élargir en quelque chose qui paraît bien rangé. Un serveur à 10.22.8.19 ne dit rien sur le fait que le bureau possède 10.22.8.0/24, 10.22.0.0/16 ou une poignée de /28s dispersés. Choisir 10.0.0.0/8 parce que le nombre commence par 10 attrape des réseaux domestiques, des plages de conteneurs et des liens partenaires que vous ne visiez pas. Le préfixe est une frontière à obtenir, non à déduire.

Une longueur de préfixe décrit combien de bits de tête sont significatifs ; elle ne décrit pas qui possède la plage.

Une adresse de serveur n’est pas un réseau

Un serveur, un sous-réseau et un site sont trois choses différentes. Un seul service peut se trouver dans un petit sous-réseau dédié tandis que le reste du bureau occupe des plages séparées, et une route d’hôte peut être parfaitement adaptée à un service qui a délibérément une seule adresse. Elle cesse de l’être lorsque le site redirige vers un autre hôte, s’authentifie via un serveur distinct ou change d’adresse. Ces dépendances sont l’exigence réelle, et elles valent la peine d’être demandées avant qu’un préfixe soit installé.

Un calculateur de sous-réseaux traduit un préfixe connu en masque, en plage ou en liste d’hôtes. Il ne peut pas déduire une frontière organisationnelle à partir d’un seul nom d’hôte, et traiter sa sortie comme une autorité est la façon dont des réseaux sans rapport finissent routés.

Demandez les préfixes approuvés

Obtenez les plages de destination auprès de qui exploite le VPN ou le réseau. Il peut y avoir plusieurs préfixes distincts et un serveur DNS privé situé ailleurs, que l’on oublie souvent jusqu’à ce que les noms échouent. Consignez-les comme une liste approuvée avec un propriétaire et une date, pas comme une plage reconstruite à partir d’un exemple. Si la liste est longue, c’est une information sur le réseau et non une invitation à la résumer en quelque chose de plus large.

Une consultation d’itinéraires en lecture seule sur le Mac, visant la destination qui vous intéresse, montre quel chemin est utilisé en ce moment. C’est le comportement actuel, pas une autorisation.

Vérifiez le chevauchement avant d’appliquer quoi que ce soit

Comparez les préfixes approuvés à chaque plage locale avant de les appliquer : réseau domestique, ponts de conteneurs, réseaux de machines virtuelles et tout autre VPN. Une route précise vers le bureau ne peut toujours pas vous dire quel appareil à cette adresse vous visiez lorsque la même plage existe aussi localement ; la table n’a pas ce concept. Le chevauchement produit des symptômes qui ressemblent à des services cassés plutôt qu’à des erreurs de routage, et ils sont difficiles à diagnostiquer après coup.

Faites installer les préfixes par le propriétaire qui en assure le support, via la configuration du client lui-même ou les routes poussées par le serveur, afin qu’une reconnexion les rétablisse au lieu de dépendre d’une commande que quelqu’un a tapée une fois.

Une route n’est pas un accès

Router un préfixe dans le tunnel ne donne pas accès aux services qu’il contient. La passerelle doit autoriser le trafic, la destination doit l’accepter et un chemin de retour doit exister, et chacun peut échouer indépendamment de la route. Testez un service prévu une fois la route en place, puis confirmez qu’une ressource sans rapport est toujours refusée. Une route qui atteint un pare-feu n’est pas la même chose qu’une connexion qui fonctionne.

Documentez ensemble la liste des préfixes, la vérification des chevauchements et le propriétaire. Lorsqu’une adresse change, ce sont ces trois éléments dont la personne suivante a besoin.

Le préfixe est un accord sur des frontières. Traitez-le ainsi et la route cesse d’être une supposition.