Meilleur choix d'adresses privées pour un «réseau de zone d'appareil»

8

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

Dois-je acheter des adresses IPv4? Ou peut-être puis-je m'en tirer avec TEST-NET-3 (203.0.113.0/24) ou quelque chose comme ça? Quelle est la meilleure pratique?

networking local-area-network ip-address ipv4 rfc proski
la source
1
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 fibre optique privées 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 client. La carte réseau mgmt obtient une adresse DHCP du LAN du client ou est statiquement affectée pour résider sur le réseau du client.
TheCleaner
1
Devez-vous utiliser la pile TCP / IP pour la communication entre vos «sous-appareils»? Si vous restez sur la couche deux, vous n'aurez aucun problème avec les conflits 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 se chevaucher avec le réseau interne, sinon le sous-périphérique vers l'extérieur dérouterait les paquets. L'un des sous-appareils est IPv4 uniquement, aucun autre moyen de le contrôler.
proski
3
"IPv6 n'est pas une option." Nous avons maintenant 2014. Ce devrait être une option. "Dois-je acheter des adresses IPv4?" Eh bien, si vous le pouvez - en Asie, ils sont épuisés, en Europe aussi, ...
glglgl
1
Si les appareils ne prennent pas en charge IPv6, je n'envisagerai même pas de les acheter, car je devrais alors les remplacer bien avant la durée de vie prévue de l'appareil, avec quelque chose qui prend en charge IPv6. (Eh bien, pour les clients de toute façon. Sur mes réseaux, qui sont déjà à double pile, un appareil qui ne prend pas en charge IPv6 est considéré comme non adapté à l'usage prévu.)
Michael Hampton

Réponses:

10

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

Link-local, également appelé 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 les 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, je voudrais certainement avoir la possibilité de le configurer moi-même et / ou d'utiliser DHCP (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 à quoi APIPA est censé être utilisé.

Modifier - Étant donné que vous déclarez maintenant que les adresses IP doivent être statiques pour les hôtes individuels dans votre solution, car celles-ci correspondent aux règles de pare-feu dans votre périphérique de passerelle, je suppose que cela prendrait un peu d'effort de votre part pour que cela fonctionne avec le lien adressage IPv4 local; l'effort que vous dites que vous ne dépenserez pas. Donc, vous essentiellement avez à faire ce configurable. Vous pouvez l'envoyer avec une valeur par défaut, qui est moins susceptible d'être utilisée par un client, mais vous devez disposer d'un mécanisme permettant de la modifier en cas de conflit. Soit par le client, soit par vous dans le cadre de l'implémentation / UAT.

mfinni
la source
L'appliance utilise DHCP sur le réseau interne pour l'un des sous-périphériques (il est très difficile à configurer sans DHCP). Je ne me sens pas à l'aise pour que le serveur DHCP distribue des adresses IP dans la plage locale de liens, car c'est explicitement interdit: tools.ietf.org/html/rfc3927#section-1.6 Si nous n'avions pas à utiliser DHCP en interne, cela aurait été mon premier choix.
proski
Non non non, comme je l' ai cité explicitement, les adresses APIPA (lien local) sont les périphériques attribueront à eux - mêmes si un serveur DHCP ne peut pas être trouvé. Je n'ai pas suggéré que vous utilisiez 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. En outre, 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
Lisez ceci: tools.ietf.org/html/rfc3927 - tout ce qui utilise le lien local doit implémenter la détection des conflits.
mfinni
Je le sais. Il n'y a aucun moyen que cela soit implémenté dans le produit. Les sous-périphériques ont leurs rôles et il existe pour eux des configurations iptables spécifiques.
proski
5

Rendez-le configurable.

Dois-je acheter des adresses IPv4?

Ouais. ESSAYEZ CELA. D'abord, 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 réseau appropriée" est une raison qui se traduit par des rires (et un rejet), et non par l'attribution d'adresses IP.

Ou peut-être que je peux m'en tirer 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 des choses à cause d'une négligence grave.

Quelle est la meilleure pratique?

Rendez-le configurable. Ou utilisez IPV6 - vous pouvez y échapper avec quelques réservations.

TomTom
la source
Obtenir des adresses IPv4 pour un usage interne (donc ne pas les acheminer vers Internet) est un cas d'utilisation parfaitement valide. Malheureusement, dans les régions APNIC et RIPE, il n'y a plus d'adresses IPv4, donc passer à IPv6 est vraiment la seule solution évolutive ... Les adresses ULA semblent être une bonne option là-bas.
Sander Steffann
3
Ce n'est pas un cas d'utilisation valide. Pas avec un espace d'adressage IPv4 limité. C'est à cela que servent les adresses privées. Et ils ne le gaspilleront pas pour les entreprises "incapables 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 s'il l'a jamais été. Avez-vous des documents pour sauvegarder votre affirmation, @SanderSteffann?
mfinni
3
@proski ah, non. Voir - Les adresses TEST-NET-3 sont destinées aux tests. Un client qui les utilise pour les tests a un cas valide. Les appareils d'expédition SOmeone ignorent OU ignorent volontairement les politiques autour de ces adresses, ce qui est une négligence grave. Dans les deux cas.
TomTom
1
@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
5

  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 devez pas utiliser TEST-NET-3.

  2. Une chose que vous semblez ignorer: comment pensez-vous que vous pourrez communiquer avec l'appareil ou que l'appareil pourra communiquer avec d'autres appareils et vice versa si vous ne configurez pas l'adresse IP de l'appareil POUR le réseau client? Si vous attribuez une adresse IP dans un réseau qui n'est pas utilisé dans le réseau client (vous: 192.168.1.0/24 - Them: 10.0.0.0/8), alors comment pensez-vous que la communication réseau va fonctionner? C'est pourquoi vous devez configurer le périphérique pour utiliser DHCP hors de la boîte et permettre au client de le configurer statiquement par la suite.

Si vous ne pouvez pas utiliser DHCP, utilisez APIPA.

joeqwerty
la source
Il n'y aura pas d' utilisation publique . 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
1
D'accord, mais ma réponse ne concerne pas le NAT. Comment votre appareil communiquera-t-il avec d'autres appareils sur le même réseau interne s'il utilise une adresse IP qui n'est pas dans le même sous-réseau que le réseau interne?
joeqwerty
De toute évidence, l'appliance comprend un routeur qui a des adresses sur les deux réseaux. Le routeur fait NAT. Le client ne parle à l'appliance que via un service cloud.
proski
Je n'essaie pas d'être sarcastique, mais comment est-ce évident? Nous ne savons que ce que vous nous dites dans votre question et vous n'avez jamais mentionné ce fait.
joeqwerty
1
C'est peut-être moi. Je ne veux certainement pas dire une infraction et peut-être que cela va paraître impoli, mais comment la déclaration "le sous-périphérique connecté aux deux réseaux serait-il confondu" implique-t-elle que l'appareil a un routeur intégré ou dispose d'une fonctionnalité de routage? Mon ordinateur possède 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 dispose d'un routeur intégré ou d'une capacité de routage. En tout cas, cette diatribe ne sert pas à vous aider donc je vais le laisser tomber à ce stade.
joeqwerty
4

En théorie, n'importe quelle plage IP privée pourrait être utilisée par n'importe quel réseau privé, donc je doute que vous trouverez 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 au périphérique une adresse privée (via DHCP, par exemple).

Si ce n'est pas une option, je trouve que presque personne n'utilise la moitié supérieure du 172.16.0.0/12, c'est donc ce que j'utilise. (Je pense que je suis en cours d'exécution 172.25.0.0/16, pour être précis.) Je n'ai pas encore rencontré de collision d'adresse, et je VPN sur de nombreux réseaux privés.

Si vous devez utiliser une adresse privée IPv4, je pense que c'est le mieux que vous puissiez faire, le 10.0.0.0/8bloc étant largement utilisé et le 192.168.0.0/16bloc é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, pour éviter les collisions d'adresses, en raison de l'utilisation généralisée des autres blocs de réseau privé, alors utilisez les adresses supérieures, car (selon mon expérience), ce sont les sous-réseaux les moins utilisés dans ce bloc .

HopelessN00b
la source
1
Si vous choisissez un / 24 aléatoire dans la plage 10.0.0.0/8, et en supposant une utilisation raisonnable des adresses par les appareils existants (c'est-à-dire au plus une poignée de / 24 sous-réseaux sont utilisés - j'ai tendance à penser à ma configuration réseau comme assez complexe, étant donné qu'il dispose de 4 sous-réseaux de ce type [3 emplacements différents et un vpn à acheminer entre eux]), les chances d'un conflit sont <0,01%. Je serais généralement disposé à prendre ce risque dans la plupart des circonstances.
Jules
1
@Jules, sauf pour les réseaux (malheureusement courants) qui utilisent l'intégralité du sous-réseau / 8 simplement parce que c'est la valeur par défaut.
Grant
La route vers un réseau plus petit a la priorité, cela devrait fonctionner. Je pourrais en fait avoir / 29 en interne pour réduire encore plus le risque. Mais ne pas éliminer ce risque, aussi petit soit-il, serait mauvais. Le support client devrait en être informé et vérifier la configuration réseau du client.
proski
2

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

Michael
la source
1
Mauvais. Obtenez un bloc ULA.
TomTom
1

En supposant qu'aucun de ces sous-périphériques n'a 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 Wikipédia

yoonix
la source
3
Comment cela pourrait-il fonctionner? Ses "sous-dispositifs" sont des hôtes individuels. Le bouclage permet à un hôte de communiquer avec lui-même.
mfinni
1
Bon point, je jure que je l'ai vu utilisé comme ça avant .. mais je ne me souviens pas où. Je vais retirer ma réponse sous peu.
yoonix
Mais, ce document a une autre suggestion que j'aime!
mfinni
En fait, je pense à utiliser 127.0.1.0/255 pour le réseau interne. Je ne sais pas si ce serait mieux que TEST-NET-3.
proski
1
QUE WON "T travail qui réalimentation Une foule de communication à une adresse de réalimentation ne sera PARLER LUI - MÊME L'adresse de réalimentation se trouve être la taille d'un sous - réseau entier, il est toujours seul hôte local....
mfinni
1

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

J'ai fait quelque chose dans le passé pour l'un des produits commerciaux de notre entreprise qui pourrait être utile. L'appareil avait deux ports Ethernet, dont l'un était destiné à une connectivité "directe" à partir d'un PC. Le problème était similaire; nous voulions éviter les conflits d'adresses IP avec le LAN interne d'un client (éventuellement sur un réseau IP privé) ainsi qu'avec le monde en général.

La logique de ce périphérique était de configurer dynamiquement un serveur DHCP ("udhcpc", via les 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 a appliqué le paramètre modifierait également la configuration du serveur DHCP pour éviter les conflits.

Par exemple, si le périphérique a obtenu l'adresse 192.168.0.100/netmask 255.255.255.0 (sur eth0), il configurerait 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.

user1722483
la source
Que faire si j'utilise 192.168.0.0/16comme préfixe de site, mais que vous n'êtes connecté au VLAN qu'à l'aide de 192.168.0.0/24? Vous venez de détourner 192.168.1.0/24même si je l'utilise sur un autre VLAN sur le même site.
fukawi2
C'est une bonne idée en théorie. En pratique, l'un des sous-appareils utilise une adresse IP statique et un autre utilise un client DHCP. Aucun n'est configurable dans un produit expédié. Ainsi, les adresses doivent être préconfigurées, mais les adresses lien-local ne fonctionneront pas.
proski