Melhor escolha de endereços privados para uma "rede de área de dispositivos"

8

Estou construindo um dispositivo que consiste em vários subdispositivos conectados por Ethernet dentro do dispositivo. O dispositivo se conectará à rede do cliente. A rede do cliente pode estar usando endereços IP privados. Um conflito de endereço com a rede interna seria um problema (o subdispositivo conectado às duas redes ficaria confuso). IPv6 não é uma opção.

Devo comprar endereços IPv4? Ou talvez eu possa me safar usando o TEST-NET-3 (203.0.113.0/24) ou algo assim? Qual é a melhor prática?

— proski
fonte

1

A rede do cliente precisará acessar os subdispositivos diretamente ou eles se conectarão ao dispositivo apenas por uma porta LAN do tipo "gerenciamento" no dispositivo? Eu pergunto porque a EMC e outros usam comunicações IP de fibra privada em suas SANs para seus controladores / etc com uma NIC de gerenciamento dedicada que está conectada à rede do cliente. A placa de rede mgmt obtém um endereço DHCP da LAN do cliente ou é atribuída estaticamente para residir na rede do cliente.

— TheCleaner

1

Você precisa usar a pilha TCP / IP para a comunicação entre seus 'subdevices'? Se você permanecer na camada dois, não terá problemas com conflitos de IP.

— jlehtinen

A rede do cliente é apenas o meio de conexão com o serviço em nuvem. Portanto, o gateway padrão do cliente não deve se sobrepor à rede interna, ou o subdispositivo de aparência externa usurpará os pacotes. Um dos subdispositivos é apenas IPv4, não há outra maneira de controlá-lo.

— proski

3

"IPv6 não é uma opção." Temos 2014 agora. Deve ser uma opção. "Devo comprar endereços IPv4?" Bem, se você puder - na Ásia, eles também estão exaustos, na Europa ...

— glglgl

1

Se os dispositivos não suportam IPv6, eu não vou nem considerar comprá-los, porque eu teria, então, para substituí-los bem antes da vida útil esperada do dispositivo, com algo que faz suporte IPv6. (. Bem, para os clientes de qualquer maneira Em minhas redes, que já são dual stack, um dispositivo que não suporta IPv6 é considerado não apto para o efeito.)

— Michael Hampton

10

@yoonix enviou um link que pode ter uma solução.

Link-local, também conhecido como APIPA.

169.254.0.0/16 - este é o bloco "link local". Conforme descrito no RFC3927, ele é alocado para comunicação entre hosts em um único link. Os hosts obtêm esses endereços pela configuração automática, como quando um servidor DHCP não pode ser encontrado.

Se eu fosse seu cliente, com certeza gostaria de ter a opção de configurar isso sozinho e / ou usar o DHCP (que é, eu não sei, talvez um padrão estabelecido há muito tempo?), Mas na ausência de é exatamente para isso que o APIPA deve ser usado.

Editar - Como você agora declara que os endereços IP devem ser estáticos para hosts individuais em sua solução, porque eles corresponderão às regras de firewall no seu dispositivo de gateway, suponho que seria necessário um pouco de esforço de sua parte para fazer com que o link funcionasse. endereçamento IPv4 local; esforço que você diz que não vai gastar. Então, você basicamente precisa tornar isso configurável. Você pode enviá-lo com um padrão, menos provável de ser usado por um cliente, mas você deve ter um mecanismo pelo qual ele possa ser alterado em caso de conflito. Pelo cliente ou por você como parte da implementação / UAT.

— mfinni
fonte

O dispositivo está usando o DHCP na rede interna para um dos subdispositivos (é muito difícil de configurar sem o DHCP). Não me sinto à vontade para o servidor DHCP distribuir endereços IP no intervalo local do link, pois é explicitamente proibido: tools.ietf.org/html/rfc3927#section-1.6 Se não precisarmos usar o DHCP internamente, teria sido minha primeira escolha.

— proski

Não, não, como citei explicitamente, os endereços APIPA (link-local) são os dispositivos que os dispositivos atribuirão a si mesmos se um servidor DHCP não puder ser encontrado. Não sugeri que você usasse o DHCP para atribuir endereços APIPA.

— mfinni

Os subdispositivos têm funções específicas e o roteador deve configurar as tabelas de ip de acordo com essas funções. Não quero que o roteador descubra os endereços e mude o iptables de acordo. Além disso, atribuir endereços IP aleatórios significa que haverá conflitos de endereços e não tenho certeza de que o hardware seja inteligente o suficiente para resolvê-los.

— proski

Leia isto: tools.ietf.org/html/rfc3927 - qualquer coisa que esteja usando o link local precisa implementar a detecção de conflitos.

— mfinni

Eu sei disso. Não há como isso ser implementado no produto. Os subdispositivos têm suas funções e há configurações específicas de tabelas de ip para eles.

— proski

5

Torne-o configurável.

Devo comprar endereços IPv4?

Sim. TENTE ISSO. Primeiro, você não os compra, os "aluga" por associação. Segundo, isso requer um AS e 2 uplinks. Terceiro, isso requer uma razão e "não queremos supor que uma infra-estrutura de rede adequada" seja uma razão que resulte em risadas (e rejeição), não na obtenção de endereços IP alocados.

Ou talvez eu possa me safar usando o TEST-NET-3 (203.0.113.0/24)

Possivelmente. Até o dia em que alguém pede a oyu o custo de consertar as coisas por causa de negligência grosseira.

Qual é a melhor prática?

Torne-o configurável. Ou use o IPV6 - lá você pode se safar com algumas reservas.

— TomTom
fonte

Obter endereços IPv4 para uso interno (para não rotear para a Internet) é um caso de uso perfeitamente válido. Infelizmente, nas regiões APNIC e RIPE, não existem mais endereços IPv4, portanto, mudar para IPv6 é realmente a única solução à prova de futuro ... Os endereços ULA são uma boa opção.

— Sander Steffann

3

Não é um caso de uso válido. Não com espaço de endereço IPv4 limitado. É para isso que servem os endereços privados. E eles não o desperdiçam com empresas "incapazes ou dispostas a seguir procedimentos de conservação estabelecidos".

— TomTom

Certamente não é um caso de uso válido hoje, não sei se já foi. Você tem alguma documentação para fazer backup de sua afirmação, @SanderSteffann?

— mfinni

3

@proski ah, não. Consulte - Os endereços TEST-NET-3 são para teste. Um cliente que os utiliza para teste tem um caso válido. Alguns aparelhos de remessa ignoram ou deliberadamente ignoram as políticas em torno desses endereços, o que é uma negligência grave. Em ambos os casos.

— TomTom

1

@SanderSteffann Não conheço o APNIC, mas o RIPE certamente tem endereços IPv4 - cerca de 14 milhões deles (0,85 de a / 8), de acordo com a atualização de status mais recente em seu site.

— Jules

5

Da Wikipedia: Assigned as "TEST-NET-3" in RFC 5737 for use solely in documentation and example source code and should not be used publicly.- Isso me diz que você não deve usar o TEST-NET-3.
Uma coisa que você parece ignorar: como você supõe que poderá se comunicar com o dispositivo ou que o dispositivo poderá se comunicar com outros dispositivos e vice-versa se você não configurar o endereço IP do dispositivo PARA a rede do cliente? Se você atribuir um endereço IP em uma rede que não esteja em uso na rede do cliente (Você: 192.168.1.0/24 - Eles: 10.0.0.0/8), como você acha que a comunicação de rede funcionará? É por isso que você deve configurar o dispositivo para usar o DHCP imediatamente e permitir que o cliente o configure estaticamente posteriormente.

Se você não pode usar o DHCP, use o APIPA.

— joeqwerty
fonte

Não haverá uso público . Os endereços internos nunca seriam expostos ao exterior. A comunicação usa NAT. Mas não posso fazer o NAT quando as duas redes usam endereços sobrepostos.

— proski

1

OK, mas minha resposta não é sobre NAT. Como o seu dispositivo se comunicará com outros dispositivos na mesma rede interna se estiver usando um endereço IP que não esteja na mesma sub-rede que a rede interna?

— precisa saber é o seguinte

Obviamente, o dispositivo inclui um roteador que possui endereços nas duas redes. O roteador faz NAT. O cliente só conversa com o dispositivo por meio de um serviço em nuvem.

— proski

Não estou tentando ser esquisito, mas como isso é óbvio? Sabemos apenas o que você nos diz na sua pergunta e você nunca mencionou esse fato.

— precisa saber é o seguinte

1

Talvez seja eu. Certamente não me refiro a nenhuma ofensa e talvez isso pareça rude, mas como a declaração "o subdispositivo conectado às duas redes ficaria confusa" implica que o dispositivo possui um roteador embutido ou possui funcionalidade de roteamento? Meu computador possui duas interfaces de rede, cada uma conectada a uma rede diferente, mas meu computador não é um roteador. Talvez eu seja apenas estúpido. Não li nada na sua pergunta que me leve a acreditar que seu dispositivo possui um roteador embutido ou possui capacidade de roteamento. De qualquer forma, esse discurso retórico não serve para ajudá-lo;

— joeqwerty

4

Em teoria, qualquer intervalo de IP privado poderia estar em uso por qualquer rede privada, então duvido que você encontre uma prática recomendada ou qualquer coisa que seja universalmente aplicável se você codificar o endereço. A melhor prática seria torná-lo configurável e permitir que a rede do cliente atribua ao dispositivo um endereço privado (via DHCP, por exemplo).

Se isso não é uma opção, acho que quase ninguém usa a metade superior da 172.16.0.0/12, então é isso que eu uso. (Acho que estou executando 172.25.0.0/16, para ser mais preciso.) Eu ainda tenho uma colisão de endereços e faço VPN em muitas redes privadas.

Se você precisar usar um endereço privado IPv4, acho que é o melhor que você poderá fazer, com o 10.0.0.0/8bloco sendo amplamente usado e o 192.168.0.0/16bloco sendo o padrão para quase tudo, o único que resta 172.16.0.0/12. Obviamente, esse bloco é frequentemente usado para VPNs, para evitar colisões de endereços, devido ao uso generalizado de outros blocos de rede privada, portanto, use os endereços superiores, pois (na minha experiência) são as sub-redes menos utilizadas nesse bloco .

— HopelessN00b
fonte

1

Se você escolher um / 24 aleatório no intervalo 10.0.0.0/8 e assumir um uso razoável de endereços pelos dispositivos existentes (por exemplo, no máximo, algumas sub-redes / 24 estão em uso - eu costumo pensar na configuração da minha rede como bastante complexo, uma vez que possui 4 sub-redes [3 locais diferentes e uma VPN para rotear entre eles]), as chances de um conflito são <0,01%. Geralmente, eu estaria disposto a correr esse risco na maioria das circunstâncias.

— Jules

1

@Jules, exceto naquelas redes (infelizmente comuns) que usam a sub-rede / 8 inteira apenas porque é o padrão.

— Grant

A rota para uma rede menor tem prioridade, pois deve funcionar. Na verdade, eu poderia ter / 29 internamente para reduzir ainda mais o risco. Mas não eliminar esse risco, por menor que seja, seria ruim. O suporte ao cliente precisaria saber sobre isso e verificar a configuração de rede do cliente.

— proski

2

Estamos projetando exatamente a mesma coisa e decidimos usar os endereços locais do site IPv6 com um prefixo fc00: nnnn aleatório.

— Michael
fonte

1

Ruim. Obtenha um bloco ULA.

— TomTom

1

Supondo que nenhum desses subdispositivos precise de conectividade direta fora do dispositivo, você deve usar a rede de loopback para isso (127.0.0.0/8).

RFC 5735 / Seção 3

Loopback na Wikipedia

— yoonix
fonte

3

Como isso possivelmente funcionaria? Seus "subdevices" são hosts individuais. O loopback é para um host se comunicar consigo mesmo.

— mfinni

1

Bom ponto, juro que já o vi usado assim antes ... mas não me lembro onde. Retirei minha resposta em breve.

— Yoonix

Mas, esse documento tem outra sugestão que eu gosto!

— mfinni

Na verdade, estou pensando em usar 127.0.1.0/255 para a rede interna. Não tenho certeza se seria melhor que TEST-NET-3.

— proski

1

Que ganharam "T trabalho que é auto-retorno Um anfitrião comunicando para um endereço de auto-retorno será apenas falar com ele mesmo o endereço de auto-retorno passa a ser do tamanho de uma sub-rede inteira; ainda é único hospedeiro-local....

— mfinni

1

Seu "controlador principal" pode executar um servidor DHCP / fornecer concessões DHCP em sua interface "interna"?

Eu fiz algo no passado para um dos produtos comerciais da nossa empresa que pode ser útil. O dispositivo tinha duas portas Ethernet, uma das quais destinada à conectividade "direta" de um PC. A questão era semelhante; queríamos evitar conflitos de endereço IP com a LAN interna do cliente (possivelmente em uma rede IP privada) e com o mundo em geral.

A lógica deste dispositivo era configurar dinamicamente um servidor DHCP ("udhcpc", por meio de opções de linha de comando) na porta LAN "direta" (eth1) com base em sua própria configuração de IP na porta LAN "pública" (eth0). Se o dispositivo obteve seu próprio endereço IP através do DHCP ou via configuração estática, o módulo que aplicou a configuração também alteraria a configuração do servidor DHCP para evitar conflitos.

Por exemplo, se o dispositivo obtivesse o endereço 192.168.0.100/netmask 255.255.255.0 (em eth0), ele configuraria seu próprio servidor DHCP (em eth1) para a próxima rede disponível 192.168.1.0/255.255.255.0.

Ele escolheria uma dessas redes (em ordem de prioridade): 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 isto ajude.

— user1722483
fonte

E se eu estiver usando 192.168.0.0/16como prefixo do meu site, mas você estiver conectado apenas à VLAN 192.168.0.0/24? Você acabou de fazer o hi-jacked 192.168.1.0/24, embora eu esteja usando em outra VLAN no mesmo site.

— Fkawi2

Essa é uma boa ideia em teoria. Na prática, um dos subdispositivos usa endereço IP estático e outro usa um cliente DHCP. Nem é configurável em um produto enviado. Portanto, os endereços devem ser pré-configurados, mas os endereços locais do link não funcionarão.

— proski