Trois décisions d’adresse avant de placer des capteurs IoT derrière un VPN
Trois adresses remplissent trois rôles : le hub public, le pair de site authentifié et l’adresse privée du capteur. Planifiez chacune avant d’allouer quoi que ce soit de public.
Trois adresses s’emmêlent dans tout plan d’IoT sur VPN, et ce ne sont pas le même type de décision. L’une est la façon dont un opérateur distant trouve le point de terminaison du tunnel, une autre est la façon dont le site prouve qu’il est le site, et la dernière est l’endroit où le service du capteur écoute réellement. Répondez-y dans cet ordre et la conception sort presque toute seule. Répondez-y comme à une seule question et vous finirez par attribuer des adresses publiques à des appareils qui n’en ont jamais eu besoin. Un capteur derrière un tunnel de site sortant est joignable par un opérateur autorisé sans aucune règle entrante pointant vers le capteur.
Commencez par qui initie
Qui compose détermine presque tout le reste. Quand le site compose vers un hub, le site n’a besoin d’aucune joignabilité entrante, et le hub a besoin d’un nom ou d’une adresse que le site peut résoudre. Ce seul choix élimine la majeure partie du débat sur l’adressage public statique avant même qu’il commence.
Les trois rôles se séparent alors proprement, et le tableau ci-dessous est la forme la plus courte de la décision.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
Chaque ligne a un propriétaire différent, et c’est là le vrai point. Le hub appartient à qui exploite le service VPN, le pair de site à l’équipe réseau, et l’adresse du capteur à qui possède l’appareil.
L’adresse du hub est un amorçage, pas une destination
Un nom qui résout vers une adresse publique maintenue suffit pour le hub. Un enregistrement DNS peut suivre le point de terminaison quand il se déplace, sans modifier à la main chaque configuration de site. Ce que le DNS ne fait pas, c’est créer de la joignabilité ou rafraîchir un client qui met en cache l’ancienne réponse, et ce sont des problèmes distincts avec des correctifs distincts.
Si vous exploitez des tunnels de site à site sans hub, la même logique tient sous une autre forme : un côté a besoin d’un point de terminaison joignable, ou les deux côtés composent vers un tiers. Quelqu’un doit toujours posséder cette adresse et ses renouvellements.
Le pair de site est une identité avec un préfixe attaché
Le pair est d’abord une identité et ensuite un préfixe. En termes WireGuard, le pair détient une paire de clés et l’entrée AllowedIPs du hub lie cette clé au préfixe du site. En termes IKEv2, un certificat ou une clé pré-partagée identifie le site et ses sélecteurs de trafic disent ce qu’il peut transporter. Changer une seule moitié casse l’arrangement, et c’est pourquoi un changement d’adresse ne doit jamais être traité comme un changement d’identité.
Gardez la propriété de la clé ou du certificat côté site plutôt que côté opérateur du hub, afin qu’un changement de fournisseur ne devienne pas un changement d’identité.
Le préfixe est la partie que les gens oublient de planifier. Le hub doit associer le sous-réseau du capteur au bon pair, et le client de l’opérateur a besoin d’une route vers lui ; une route qui n’existe que sur le client envoie le trafic dans un tunnel qui le jette silencieusement. Écrivez le préfixe dans l’enregistrement du site à côté de l’empreinte de clé, pour qu’une passerelle de remplacement ne puisse pas apparaître avec une couverture différente sans que personne ne le remarque.
L’adresse du capteur appartient à l’application
Une adresse privée issue du plan du site suffit, et ce dont elle a besoin est la stabilité plutôt que la joignabilité publique : une réservation DHCP, une attribution statique ou un nom dans la zone propre du site. Si l’appareil ne peut pas être renuméroté, la traduction sur la passerelle du site est une réponse légitime tant que la traduction est documentée et que le trafic de retour la suit.
Une habitude de plus à conserver : ne collez jamais l’adresse publique du hub dans un champ de saut suivant sur l’hôte du capteur. Le VPN installe son propre chemin, et une adjacence Ethernet ordinaire vers un point de terminaison public est une fiction qui produit une configuration d’apparence convaincante.
Les réponses sont la moitié que l’on saute. L’appareil doit renvoyer sa réponse vers le tunnel, soit par une route vers le client de l’opérateur, soit par la même passerelle qui a traduit la requête. Un capteur dont la passerelle par défaut est erronée accepte la requête et répond dans le vide, et les notes de transfert expliquent pourquoi l’arrivée et le routage de la réponse sont deux exigences plutôt qu’une.
Décidez, puis écrivez la frontière
Écrivez la frontière d’accès avant que quiconque se connecte. Limitez la passerelle au segment IoT et aux services précis dont l’opérateur a besoin, car une route qui fonctionne tend à devenir un accès général par accident. Gardez la supervision en lecture seule et l’autorité de configuration comme des rôles distincts avec des identités distinctes, et nommez la personne qui retire l’accès à la fin du contrat.
L’approbation appartient au propriétaire du réseau, et être dans une DMZ n’est pas une politique d’accès.
Le test après déploiement est ennuyeux et concluant : une requête à l’intérieur du préfixe autorisé qui réussit, un compteur qui s’incrémente sur la passerelle, et une tentative délibérée hors du préfixe qui échoue.