La mejor opción de direcciones privadas para una "red de área de dispositivo"

8

Estoy construyendo un dispositivo que consta de varios subdispositivos conectados por ethernet dentro del dispositivo. El dispositivo se conectará a la red del cliente. La red del cliente puede estar utilizando direcciones IP privadas. Un conflicto de direcciones con la red interna sería un problema (el subdispositivo conectado a ambas redes se confundiría). IPv6 no es una opción.

¿Debo comprar direcciones IPv4? ¿O tal vez pueda salirse con la suya usando TEST-NET-3 (203.0.113.0/24) o algo así? cual es la mejor practica?

networking local-area-network ip-address ipv4 rfc proski
fuente
1
¿La red del cliente necesitará acceso a los subdispositivos directamente o se conectarán al dispositivo solo a través de un puerto LAN tipo "administración" en el dispositivo? Pregunto porque EMC y otros utilizan comunicaciones IP privadas de fibra en sus SAN para sus controladores / etc. con una NIC de administración dedicada que está conectada a la red del cliente. La NIC de gestión obtiene una dirección DHCP de la LAN del cliente o está asignada estáticamente para residir en la red del cliente.
TheCleaner
1
¿Tiene que usar la pila TCP / IP para la comunicación entre sus 'subdispositivos'? Si permanece en la capa dos, no tendrá problemas con los conflictos de IP.
jlehtinen
La red del cliente es solo el medio para conectarse al servicio en la nube. Por lo tanto, la puerta de enlace predeterminada del cliente no debe superponerse con la red interna, o el subdispositivo que mira hacia afuera enrutará erróneamente los paquetes. Uno de los subdispositivos es solo IPv4, no hay otra forma de controlarlo.
proski
3
"IPv6 no es una opción". Tenemos 2014 ahora. Debería ser una opción. "¿Debo comprar direcciones IPv4?" Pues bien, si se puede - en Asia, se han agotado, también en Europa, ...
glglgl
1
Si los dispositivos no son compatibles con IPv6, ni siquiera consideraré comprarlos, porque luego tendría que reemplazarlos mucho antes de la vida útil esperada del dispositivo, con algo que sí sea compatible con IPv6. (Bueno, para los clientes de todos modos. En mis redes, que ya son de doble pila, un dispositivo que no es compatible con IPv6 no se considera adecuado para su propósito)
Michael Hampton

Respuestas:

10

@yoonix ha enviado un enlace que podría tener una solución.

Link-local, también conocido como APIPA.

169.254.0.0/16 - Este es el bloque "enlace local". Como se describe en RFC3927, se asigna para la comunicación entre hosts en un solo enlace. Los hosts obtienen estas direcciones mediante la configuración automática, como cuando no se puede encontrar un servidor DHCP.

Si fuera su cliente, me gustaría tener la opción de configurar esto yo mismo y / o usar DHCP (que es, ¿no sé, tal vez un estándar establecido hace mucho tiempo?), Pero en ausencia de esos, esto es exactamente para lo que APIPA se supone que debe usarse.

Editar: dado que ahora declara que las direcciones IP deben ser estáticas para los hosts individuales en su solución porque corresponderán a las reglas de firewall en su dispositivo de puerta de enlace, supongo que tomará un poco de esfuerzo de su parte para que eso funcione con el enlace direccionamiento IPv4 local; esfuerzo que dices que no gastarás. Entonces, esencialmente tienes que hacer esto configurable. Puede enviarlo con un valor predeterminado, uno que sea menos probable que sea utilizado por un cliente, pero debe tener un mecanismo por el cual pueda cambiarse en caso de conflicto. Ya sea por el cliente o por usted como parte de la implementación / UAT.

mfinni
fuente
El dispositivo está utilizando DHCP en la red interna para uno de los subdispositivos (es muy difícil de configurar sin DHCP). No me siento cómodo si el servidor DHCP entrega direcciones IP en el rango local del enlace, ya que está explícitamente prohibido: tools.ietf.org/html/rfc3927#section-1.6 Si no tuviéramos que usar DHCP internamente, Habría sido mi primera opción.
proski
No no no, como cité explícitamente, las direcciones APIPA (link-local) son lo que los dispositivos se asignarán a sí mismos si no se puede encontrar un servidor DHCP. No sugerí que usaras DHCP para asignar direcciones APIPA.
mfinni
Los subdispositivos tienen roles específicos y el enrutador tiene que configurar iptables de acuerdo con esos roles. No quiero que el enrutador descubra las direcciones y cambie iptables en consecuencia. Además, la asignación de direcciones IP aleatorias significa que habrá conflictos de direcciones, y no estoy seguro de que el hardware sea lo suficientemente inteligente como para resolverlos.
proski
Lea esto: tools.ietf.org/html/rfc3927 : todo lo que utiliza enlaces locales necesita implementar la detección de conflictos.
mfinni
Yo sé eso. No hay forma de que esto se implemente en el producto. Los subdispositivos tienen sus roles y hay configuraciones específicas de iptables para ellos.
proski el
5

Hazlo configurable.

¿Debo comprar direcciones IPv4?

Si. TRATA ESO. Primero, no los compra, los "alquila" por membresía. Segundo, esto requiere un AS y 2 enlaces ascendentes. Tercero, esto requiere una razón y "no queremos suponer que una infraestructura de red adecuada" sea una razón que provoque risas (y un rechazo), no que se le asignen direcciones IP.

O tal vez pueda salirse con la suya utilizando TEST-NET-3 (203.0.113.0/24)

Posiblemente. Hasta el día en que alguien le pregunta a oyu por el costo de arreglar las cosas por negligencia grave.

cual es la mejor practica?

Hazlo configurable. O use IPV6: allí puede escapar con algunas reservas.

TomTom
fuente
Obtener direcciones IPv4 para uso interno (para no enrutarlas a Internet) es un caso de uso perfectamente válido. Desafortunadamente, en las regiones APNIC y RIPE no quedan más direcciones IPv4, por lo que pasar a IPv6 es realmente la única solución a prueba de futuro ... Las direcciones ULA parecen una buena opción allí.
Sander Steffann
3
No es un caso de uso válido. No con espacio limitado de direcciones IPv4. Para eso están las direcciones privadas. Y no lo desperdiciarán en compañías que "no pueden o no quieren seguir los procedimientos de conservación establecidos".
TomTom
Ciertamente no es un caso de uso válido hoy, no sé si alguna vez lo fue. ¿Tiene alguna documentación que respalde su afirmación, @SanderSteffann?
mfinni
3
@proski ah, no. Ver - Las direcciones TEST-NET-3 son para pruebas. Un cliente que los usa para probar tiene un caso válido. Algunas aplicaciones de envío ignoran o ignoran intencionalmente las políticas en torno a estas direcciones, lo cual es una negligencia grave. En ambos casos.
TomTom
1
@SanderSteffann No sé sobre APNIC, pero RIPE ciertamente tiene direcciones IPv4, alrededor de 14 millones de ellas (0,85 de a / 8) según la última actualización de estado en su sitio 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.- Esto me dice que no debes usar TEST-NET-3.

  2. Algo que parece pasar por alto: ¿cómo supone que podrá comunicarse con el dispositivo o que el dispositivo podrá comunicarse con otros dispositivos y viceversa si no configura la dirección IP del dispositivo? ¿PARA la red del cliente? Si asigna una dirección IP en una red que no está en uso en la red del cliente (Usted: 192.168.1.0/24 - Ellos: 10.0.0.0/8), ¿cómo supone que funcionará la comunicación de red? Esta es la razón por la que debe configurar el dispositivo para usar DHCP de forma inmediata y permitir que el cliente lo configure estáticamente después.

Si no puede usar DHCP, use APIPA.

joeqwerty
fuente
No habrá uso público . Las direcciones internas nunca estarían expuestas al exterior. La comunicación utiliza NAT. Pero no puedo hacer NAT cuando ambas redes usan direcciones superpuestas.
proski
1
OK, pero mi respuesta no es sobre NAT. ¿Cómo se comunicará su dispositivo con otros dispositivos en la misma red interna si está utilizando una dirección IP que no está en la misma subred que la red interna?
joeqwerty
Obviamente, el dispositivo incluye un enrutador que tiene direcciones en ambas redes. El enrutador hace NAT. El cliente solo habla con el dispositivo a través de un servicio en la nube.
proski
No estoy tratando de ser sarcástico, pero ¿cómo es eso obvio? Solo sabemos tanto como usted nos dice en su pregunta y nunca mencionó ese hecho.
joeqwerty
1
Quizás soy yo. Ciertamente no me refiero a ninguna ofensa y tal vez esto resulte grosero, pero ¿cómo la afirmación "se confundiría el subdispositivo conectado a ambas redes" implica que el dispositivo tiene un enrutador incorporado o tiene funcionalidad de enrutamiento? Mi computadora tiene dos interfaces de red, cada una conectada a una red diferente, pero mi computadora no es un enrutador. Tal vez solo soy estúpido. No leo nada en su pregunta que me haga creer que su dispositivo tiene un enrutador incorporado o tiene capacidad de enrutamiento. En cualquier caso, este discurso no sirve para ayudarte, así que lo dejaré en este punto.
joeqwerty
4

En teoría, cualquier rango de IP privado podría estar en uso por cualquier red privada, por lo que dudo que encuentre una mejor práctica, o cualquier cosa que sea de aplicación universal si está codificando la dirección. La mejor práctica sería hacerlo configurable y permitir que la red del cliente asigne al dispositivo una dirección privada (a través de DHCP, por ejemplo).

Si esa no es una opción, encuentro que casi nadie usa la mitad superior de la 172.16.0.0/12, así que eso es lo que yo uso. (Creo que estoy funcionando 172.25.0.0/16, para ser precisos). Todavía tengo que tener una colisión de direcciones y VPN en muchas redes privadas.

Si tiene que usar una dirección privada IPv4, creo que es lo mejor que podrá hacer, ya que el 10.0.0.0/8bloque se usa ampliamente y el 192.168.0.0/16bloque es el predeterminado para casi todo, el único que quedaría sería 172.16.0.0/12. Por supuesto, este bloque a menudo se usa para VPN, para evitar colisiones de direcciones, debido al uso generalizado de los otros bloques de redes privadas, así que use las direcciones superiores, ya que (en mi experiencia) son las subredes menos utilizadas en ese bloque .

HopelessN00b
fuente
1
Si elige un / 24 aleatorio en el rango 10.0.0.0/8, y suponiendo un uso razonable de las direcciones por parte de los dispositivos existentes (es decir, como máximo se utilizan un puñado de subredes / 24, tiendo a pensar en la configuración de mi red como bastante complejo, dado que tiene 4 de esas subredes [3 ubicaciones diferentes y una VPN para enrutar entre ellas]), las posibilidades de un conflicto son <0.01%. Generalmente estaría dispuesto a correr este riesgo en la mayoría de las circunstancias.
Jules
1
@Jules, excepto las redes (desafortunadamente comunes) que usan la subred completa / 8 solo porque es la predeterminada.
Grant
La ruta a una red más pequeña tiene prioridad, por lo que debería funcionar. De hecho, podría tener / 29 internamente para reducir aún más el riesgo. Pero no eliminar ese riesgo, por pequeño que sea, sería malo. El servicio de atención al cliente necesitaría saberlo y verificar la configuración de red del cliente.
proski
2

Estamos diseñando exactamente lo mismo y hemos decidido utilizar las direcciones locales del sitio IPv6 con un prefijo aleatorio fc00: nnnn.

Miguel
fuente
1
Malo. Consigue un bloqueo ULA.
TomTom
1

Suponiendo que ninguno de estos subdispositivos necesite conectividad directa fuera del dispositivo, debe usar la red de bucle invertido para esto (127.0.0.0/8).

RFC 5735 / Sección 3

Loopback en Wikipedia

yoonix
fuente
3
¿Cómo funcionaría esto? Sus "subdispositivos" son hosts individuales. El bucle invertido es para que un host se comunique consigo mismo.
mfinni
1
Buen punto, juro que lo he visto usado así antes ... pero no recuerdo dónde. Eliminaré mi respuesta en breve.
Yoonix
¡Pero ese documento tiene otra sugerencia que me gusta!
mfinni
En realidad, estoy pensando en usar 127.0.1.0/255 para la red interna. No estoy seguro de si sería mejor que TEST-NET-3.
proski
1
Que ganaron "t trabajo que de bucle invertido Un anfitrión se comunica a una dirección de bucle de retorno sólo será HABLA CON EL MISMO La dirección de bucle pasa a ser el tamaño de toda una subred, es todavía sólo host local....
mfinni
1

¿Puede su "controlador principal" ejecutar un servidor DHCP / proporcionar arrendamientos DHCP en su interfaz "interna"?

He hecho algo en el pasado para uno de los productos comerciales de nuestra compañía que podría ser útil. El dispositivo tenía dos puertos ethernet, uno de los cuales estaba destinado a la conectividad "directa" desde una PC. El problema era similar; Queríamos evitar conflictos de direcciones IP con la LAN interna de un cliente (posiblemente en una red IP privada), así como con el mundo en general.

La lógica en este dispositivo era configurar dinámicamente un servidor DHCP ("udhcpc", a través de opciones de línea de comando) en el puerto LAN "directo" (eth1) basado en su propia configuración IP en su puerto LAN "público" (eth0). Si el dispositivo obtuvo su propia dirección IP a través de DHCP o mediante una configuración estática, el módulo que aplicó la configuración también cambiaría la configuración del servidor DHCP para evitar conflictos.

Por ejemplo, si el dispositivo obtuvo la dirección 192.168.0.100/netmask 255.255.255.0 (en eth0), configuraría su propio servidor DHCP (en eth1) para la siguiente red disponible 192.168.1.0/255.255.255.0.

Elegiría de una de estas redes (en orden de prioridad): 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

Espero que esto ayude.

usuario1722483
fuente
¿Qué sucede si estoy usando 192.168.0.0/16como prefijo de mi sitio, pero solo está conectado a la VLAN 192.168.0.0/24? Te acabas de conectar 192.168.1.0/24a pesar de que lo estoy usando en otra VLAN en el mismo sitio.
fukawi2
Esa es una buena idea en teoría. En la práctica, uno de los subdispositivos usa una dirección IP estática y otro usa un cliente DHCP. Tampoco es configurable en un producto enviado. Por lo tanto, las direcciones deben estar preconfiguradas, pero las direcciones locales de enlace no funcionarán.
proski