Question Meilleur choix d'adresses privées pour un «réseau local d'appareils»


Je construis une appliance composée de plusieurs sous-périphériques connectés par Ethernet à l'intérieur de l'appliance. L'appliance se connectera au réseau du client. Le réseau client peut utiliser des adresses IP privées. Un conflit d'adresse avec le réseau interne poserait un problème (le sous-périphérique connecté aux deux réseaux serait confondu). IPv6 n'est pas une option.

Devrais-je acheter des adresses IPv4? Ou peut-être que je peux me permettre d'utiliser TEST-NET-3 (203.0.113.0/24) ou quelque chose du genre? Quelle est la meilleure pratique?


8
2018-01-22 16:02


origine


Le réseau client aura-t-il besoin d'accéder directement aux sous-périphériques ou se connectera-t-il à l'appliance uniquement via un port LAN de type "gestion" sur l'appliance? Je pose la question car EMC et d’autres utilisent des communications IP en fibre privée sur leurs réseaux SAN pour leurs contrôleurs / etc. avec une carte réseau de gestion dédiée connectée au réseau du client. Le NIC de la société de gestion obtient une adresse DHCP du réseau local du client ou est statiquement affecté à résider sur le réseau du client. - TheCleaner
Devez-vous utiliser la pile TCP / IP pour la communication entre vos «sous-périphériques»? Si vous restez sur la couche deux, vous ne rencontrerez aucun problème de conflit IP. - jlehtinen
Le réseau client n'est que le moyen de se connecter au service cloud. Ainsi, la passerelle par défaut du client ne doit pas chevaucher le réseau interne, sinon le sous-périphérique tourné vers l’extérieur risquerait de détourner les paquets. L'un des sous-périphériques est uniquement IPv4, aucun autre moyen de le contrôler. - proski
"IPv6 n'est pas une option." Nous avons 2014 maintenant. Cela devrait être une option. "Dois-je acheter des adresses IPv4?" Eh bien, si vous le pouvez - en Asie, ils sont épuisés, en Europe également ... - glglgl
Si les appareils ne pas soutenir IPv6, je ne vais même pas considérer de les acheter, car je devrais alors les remplacer bien avant la durée de vie prévue de l'appareil, par quelque chose qui Est-ce que supporte IPv6. (Eh bien, pour les clients en tout cas. Sur mes réseaux, qui sont déjà à double pile, un périphérique qui ne prend pas en charge IPv6 est considéré comme inadapté.) - Michael Hampton♦


Réponses:


@ yoonix a envoyé un lien qui pourrait avoir une solution.

Link-local, également connu sous le nom de APIPA.

   169.254.0.0/16 - Il s'agit du bloc "link local". Comme décrit dans la RFC3927, il est alloué pour la communication entre hôtes sur une seule liaison. Les hôtes obtiennent ces adresses par configuration automatique, par exemple lorsqu'un serveur DHCP est introuvable.

Si j’étais votre client, j’aimerais vraiment avoir la possibilité de le configurer moi-même et / ou d’utiliser DHCP (ce qui est, je ne sais pas, peut-être une norme établie de longue date?), Mais en l’absence de ceux-ci, c’est exactement ce que l’APIPA est censé utiliser.

Modifier - Étant donné que vous indiquez maintenant que les adresses IP doivent être statiques pour des hôtes individuels dans votre solution, car celles-ci correspondent aux règles de pare-feu de votre périphérique de passerelle, je suppose que cela demanderait un peu d'effort pour que cela fonctionne avec link adressage IPv4 local; effort vous dites que vous ne dépenserez pas. Donc, vous essentiellement avoir pour rendre cela configurable. Vous pouvez l'envoyer avec un paramètre par défaut, moins susceptible d'être utilisé par un client, mais vous devez disposer d'un mécanisme lui permettant de le modifier en cas de conflit. Soit par le client, soit par vous dans le cadre de la mise en œuvre / UAT.


10
2018-01-22 19:31



L’appliance utilise DHCP sur le réseau interne pour l’un des sous-périphériques (c’est très difficile à configurer sans DHCP). Je ne me sens pas à l'aise lorsque le serveur DHCP distribue des adresses IP dans la plage de liens locaux, car cela est explicitement interdit: tools.ietf.org/html/rfc3927#section-1.6 Si nous n'avions pas besoin d'utiliser DHCP en interne, cela aurait été mon premier choix. - proski
Non non non, comme je l'ai explicitement cité, les adresses APIPA (link-local) sont celles que les périphériques assigneront à eux-mêmes si un serveur DHCP ne peut pas être trouvé. Je n'ai pas suggéré d'utiliser DHCP pour attribuer des adresses APIPA. - mfinni
Les sous-périphériques ont des rôles spécifiques et le routeur doit configurer iptables en fonction de ces rôles. Je ne veux pas que le routeur découvre les adresses et modifie iptables en conséquence. De plus, l'attribution d'adresses IP aléatoires signifie qu'il y aura des conflits d'adresses et je ne suis pas sûr que le matériel soit suffisamment intelligent pour les résoudre. - proski
Lis ça : tools.ietf.org/html/rfc3927 - tout ce qui utilise link local doit implémenter la détection de conflit. - mfinni
Je le sais. Il est impossible que cela soit implémenté dans le produit. Les sous-périphériques ont leurs rôles et il existe des configurations iptables spécifiques. - proski


Rendez-le configurable.

Devrais-je acheter des adresses IPv4?

Ouais. ESSAYEZ CELA. Premièrement, vous ne les achetez pas, vous les "louez" par adhésion. Deuxièmement, cela nécessite un AS et 2 liaisons montantes. Troisièmement, cela nécessite une raison et "nous ne voulons pas supposer une infrastructure de réseau appropriée" est une raison qui engendre le rire (et un rejet) et non l'obtention d'adresses IP allouées.

Ou peut-être que je peux m'en sortir en utilisant TEST-NET-3 (203.0.113.0/24)

Peut-être. Jusqu'au jour où quelqu'un demande à oyu le coût de la réparation en raison d'une négligence grave.

Quelle est la meilleure pratique?

Rendez-le configurable. Ou utilisez IPV6 - vous pouvez vous en tirer avec quelques réserves.


5
2018-01-22 16:12



Obtenir des adresses IPv4 pour une utilisation interne (afin de ne pas les acheminer vers Internet) est un cas d'utilisation parfaitement valable. Malheureusement, dans les régions APNIC et RIPE, il ne reste plus aucune adresse IPv4. Le passage à IPv6 est donc la seule solution à l'épreuve du temps. Les adresses ULA semblent être une bonne option. - Sander Steffann
Ce n'est pas un cas d'utilisation valide. Pas avec un espace d'adressage IPv4 limité. C'est à quoi servent les adresses privées. Et ils ne le gaspilleront pas pour les entreprises "qui ne sont pas capables ou désireuses de suivre les procédures de conservation établies". - TomTom
Ce n'est certainement pas un cas d'utilisation valable aujourd'hui, je ne sais pas si cela a déjà été le cas. Avez-vous de la documentation pour sauvegarder votre assertion, @SanderSteffann? - mfinni
@proski ah, non. Voir - Les adresses de TEST-NET-3 sont destinées aux tests. Un client qui les utilise pour tester a un cas valable. Les appareils d’expédition SOoneone sont soit ignorants, soit délibérément ignorants des règles relatives à ces adresses, ce qui constitue une négligence grave. Dans les deux cas. - TomTom
@SanderSteffann Je ne connais pas APNIC, mais RIPE a certainement des adresses IPv4 - environ 14 millions d’entre elles (0,85 sur 8) selon la dernière mise à jour de statut sur leur site Web. - Jules


  1. De Wikipedia: Assigned as "TEST-NET-3" in RFC 5737 for use solely in documentation and example source code and should not be used publicly. - Cela me dit que vous ne devriez pas utiliser TEST-NET-3.

  2. Une chose que vous semblez négliger: comment pensez-vous que vous pourrez communiquer avec le périphérique ou que le périphérique pourra communiquer avec d'autres périphériques, et inversement, si vous ne configurez pas l'adresse IP du périphérique POUR le réseau client? Si vous attribuez une adresse IP à un réseau qui n'est pas utilisé sur le réseau client (You: 192.168.1.0/24 - Them: 10.0.0.0/8), comment supposez-vous que la communication réseau va fonctionner? C'est pourquoi vous devez configurer le périphérique pour qu'il utilise le protocole DHCP prêt à l'emploi et permettre au client de le configurer de manière statique par la suite.

Si vous ne pouvez pas utiliser DHCP, utilisez APIPA.


5
2018-01-22 19:42



Il n'y aura pas Publique utilisation. Les adresses internes ne seraient jamais exposées à l'extérieur. La communication utilise NAT. Mais je ne peux pas faire de NAT lorsque les deux réseaux utilisent des adresses qui se chevauchent. - proski
OK, mais ma réponse ne concerne pas le NAT. Comment votre appareil communiquera-t-il avec d'autres appareils du même réseau interne s'il utilise une adresse IP qui ne se trouve pas dans le même sous-réseau que le réseau interne? - joeqwerty
De toute évidence, l'appliance comprend un routeur qui possède des adresses sur les deux réseaux. Le routeur fait NAT. Le client ne communique avec l'appliance que via un service cloud. - proski
Je n'essaie pas d'être sournois, mais comment est-ce évident? Nous savons seulement ce que vous nous dites dans votre question et vous ne l'avez jamais mentionné. - joeqwerty
Peut-être que c'est moi Je ne veux certainement pas parler d'infraction et peut-être que cela va paraître grossier, mais comment l'affirmation "le sous-périphérique connecté aux deux réseaux serait-il confus" implique-t-elle que le périphérique est doté d'un routeur intégré ou d'une fonctionnalité de routage? Mon ordinateur a deux interfaces réseau, chacune connectée à un réseau différent, mais mon ordinateur n'est pas un routeur. Peut-être que je suis juste stupide. Je ne lis rien dans votre question qui me porte à croire que votre appareil a un routeur intégré ou a une capacité de routage. En tout cas, ce coup de gueule ne sert pas à vous aider alors je vais laisser tomber pour le moment. - joeqwerty


En théorie, toute plage IP privée pourrait être utilisée par n'importe quel réseau privé. Je doute donc que vous trouviez une meilleure pratique ou tout ce qui sera universellement applicable si vous codez en dur l'adresse. La meilleure pratique serait de le rendre configurable et de permettre au réseau client d'attribuer une adresse privée au périphérique (via DHCP, par exemple).

Si ce n'est pas une option, je trouve que presque personne n'utilise la moitié supérieure de la 172.16.0.0/12, c'est ce que j'utilise. (Je pense que je cours sur 172.25.0.0/16, pour être précis.) Je n’ai pas encore eu de conflit d’adresses, et j’ai VPN dans beaucoup de réseaux privés.

Si vous devez utiliser une adresse privée IPv4, je pense que c’est le mieux que vous puissiez faire, avec le 10.0.0.0/8 bloc étant largement utilisé et la 192.168.0.0/16 block étant la valeur par défaut pour presque tout, le seul qui reste serait 172.16.0.0/12. Bien sûr, ce bloc est souvent utilisé pour les VPN, afin d'éviter les conflits d'adresses, en raison de l'utilisation généralisée des autres blocs de réseau privé. Utilisez donc les adresses supérieures, car (selon mon expérience), ce sont les sous-réseaux les moins utilisés de ce bloc. .


4
2018-01-22 16:16



Si vous choisissez un nombre aléatoire / 24 dans la plage 10.0.0.0/8, et en supposant que les périphériques existants utilisent raisonnablement les adresses (c.-à-d. Tout au plus une poignée de / 24 sous-réseaux sont utilisés - j'ai tendance à penser que la configuration de mon réseau est la suivante: assez complexe, étant donné qu'il comporte 4 sous-réseaux de ce type [3 emplacements différents et un vpn pour les acheminer entre eux]), les risques de conflit sont <0,01%. Je serais généralement prêt à prendre ce risque dans la plupart des circonstances. - Jules
@Jules sauf pour les réseaux (malheureusement communs) qui utilisent le sous-réseau entier / 8 simplement parce que c'est le réseau par défaut. - Grant
L’acheminement vers un réseau plus petit est prioritaire, il devrait fonctionner. Je pourrais effectivement avoir / 29 en interne pour réduire encore plus le risque. Mais ne pas éliminer ce risque, si petit soit-il, serait mauvais. Le support client doit en être informé et vérifier la configuration réseau du client. - proski


Nous concevons exactement la même chose et avons décidé d’utiliser les adresses locales des sites IPv6 avec un préfixe aléatoire fc00: nnnn.


2
2018-01-23 03:10



Mal. Obtenez un bloc ULA. - TomTom


En supposant qu'aucun de ces sous-périphériques n'ait besoin d'une connectivité directe en dehors de l'appliance, vous devez utiliser le réseau de bouclage pour cela (127.0.0.0/8).

RFC 5735 / Section 3

Loopback sur Wikipedia


1
2018-01-22 19:24



Comment cela fonctionnerait-il? Ses "sous-périphériques" sont des hôtes individuels. Le bouclage consiste pour un hôte à communiquer avec lui-même. - mfinni
Bon point, je jure que je l’ai déjà utilisé comme ça auparavant… mais je ne me souviens plus où. Je vais retirer ma réponse sous peu. - yoonix
Mais, ce document a une autre suggestion que j'aime bien! - mfinni
En fait, je pense utiliser 127.0.1.0/255 pour le réseau interne. Pas sûr que ce soit mieux que TEST-NET-3. - proski
Cela va fonctionner. C'est du bouclage. Un hôte qui communique avec une adresse de bouclage parlera UNIQUEMENT À LUI-MÊME. L'adresse de bouclage se trouve être la taille d'un sous-réseau entier; elle n'est toujours que l'hôte local. - mfinni


Votre "contrôleur principal" peut-il exécuter un serveur DHCP / fournir des baux DHCP sur son interface "interne"?

J'ai déjà fait quelque chose par le passé pour l'un des produits commerciaux de notre société qui pourrait être utile. L'appareil disposait de deux ports Ethernet, dont l'un était destiné à la connectivité "directe" à partir d'un PC. Le problème était similaire. nous voulions éviter les conflits d'adresses IP avec le réseau local interne d'un client (éventuellement sur un réseau IP privé) ainsi qu'avec le monde entier.

La logique de ce périphérique consistait à configurer de manière dynamique un serveur DHCP ("udhcpc" via des options de ligne de commande) sur le port LAN "direct" (eth1) en fonction de sa propre configuration IP sur son port LAN "public" (eth0). Que le périphérique obtienne sa propre adresse IP via DHCP ou via un paramètre statique, le module qui applique le paramètre modifiera également la configuration du serveur DHCP pour éviter les conflits.

Par exemple, si le périphérique obtient l'adresse 192.168.0.100/netmask 255.255.255.0 (sur eth0), il configurera son propre serveur DHCP (sur eth1) pour le prochain réseau disponible 192.168.1.0/255.255.255.0.

Il choisirait l'un de ces réseaux (par ordre de priorité):     192.168.0.0/24 ... 192.168.254.0/24     172.16.0.0/16 ... 172.31.0.0/16     10.0.0.0/8

J'espère que cela t'aides.


1
2018-01-23 00:49



Et si j'utilise 192.168.0.0/16 comme préfixe de mon site, mais vous êtes uniquement connecté au VLAN à l'aide de 192.168.0.0/24? Vous venez de salir 192.168.1.0/24 même si je l’utilise sur un autre réseau local virtuel sur le même site. - fukawi2
C'est une bonne idée en théorie. En pratique, l’un des sous-périphériques utilise une adresse IP statique et un autre utilise un client DHCP. Ni est configurable dans un produit expédié. Ainsi, les adresses doivent être préconfigurées, mais les adresses de liens locaux ne fonctionneront pas. - proski