A melhor escolha de endereços privados para uma “rede de área de dispositivos”

Question

Estou criando um appliance que consiste em vários subdevices conectados por ethernet dentro do appliance. O appliance se conectará à rede do cliente. A rede do cliente pode estar usando endereços IP privados. Um conflito de endereços com a rede interna seria um problema (o subdispositivo conectado a ambas as redes seria confuso). O IPv6 não é uma opção.

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

    

Answer 1

@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 por configuração automática, como quando um servidor DHCP não pode ser encontrado.

Se eu fosse seu cliente, eu certamente gostaria de ter a opção de configurá-lo sozinho e / ou usar o DHCP (que eu não sei, talvez um padrão já estabelecido?), mas em a ausência desses, é exatamente para isso que o APIPA deve ser usado.

Editar - Considerando que 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 em seu dispositivo de gateway, suponho que seria necessário um pouco de esforço de sua parte para fazer isso. trabalhar com endereçamento IPv4 local de link; esforço que você diz que não vai gastar. Então, você essencialmente tem para tornar isso configurável. Você poderia enviá-lo com um padrão, que é menos provável de ser usado por um cliente, mas você deve ter um mecanismo pelo qual ele pode ser alterado em caso de conflito. Seja pelo cliente ou por você como parte da implementação / UAT.

    

Answer 2

Tornar configurável.

Should I buy IPv4 addresses?

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

Or maybe I can get away with using TEST-NET-3 (203.0.113.0/24)

Possivelmente. Até o dia em que alguém pedir oy pelo custo de consertar as coisas por causa da negligência grosseira.

What is the best practice?

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

    

Answer 3

1. 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.

2. Uma coisa que você parece estar ignorando: Como você supõe que será capaz de 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 - Them: 10.0.0.0/8), como você supõe que a comunicação de rede funcionará? É por isso que você deve configurar o dispositivo para usar o DHCP pronto para uso e permitir que o cliente o configure estaticamente posteriormente.

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

    

Answer 4

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

Se isso não for uma opção, acho que quase ninguém usa a metade superior do 172.16.0.0/12 , e é isso que eu uso. (Eu acho que estou correndo em 172.25.0.0/16 , para ser preciso.) Eu ainda tenho que ter uma colisão de endereços, e eu VPN em um monte de redes privadas.

Se você tiver que usar um endereço privado IPv4, acho que é o melhor que você poderá fazer, com o bloco 10.0.0.0/8 sendo amplamente usado e o bloco 192.168.0.0/16 sendo o padrão para quase tudo, o único um restante seria 172.16.0.0/12 . É claro que este bloco é frequentemente usado para VPNs, para evitar colisões de endereços, devido ao uso difundido de outros blocos de redes privadas, então use os endereços superiores, já que (na minha experiência) são as sub-redes menos utilizadas nesse bloco. .

    

Answer 5

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

    

Answer 6

Supondo que nenhum desses subdiscos 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

    

Answer 7

O seu "controlador principal" pode executar um servidor DHCP / fornecer concessões de 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 delas 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 como um todo.

A lógica deste dispositivo era configurar dinamicamente um servidor DHCP ("udhcpc", via opções de linha de comando) na porta LAN "direta" (eth1) com base em sua própria configuração IP em sua porta LAN "pública" (eth0 ). Independentemente de o dispositivo ter obtido seu próprio endereço IP por meio de DHCP ou por meio de 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 (na eth0), ele configuraria seu próprio servidor DHCP (na eth1) para a próxima rede disponível 192.168.1.0/255.255.255.0.

Ele escolheria de 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 isso ajude.