Calculadora de sub-redes IPv4 e IPv6

Cenário

O espaço de endereçamento da empresa será definido do zero. Há 150 sites e 16 fábricas, e as redes virtuais na nuvem também ficam no mesmo espaço. As unidades de negócio são reorganizadas a cada poucos anos, e as regiões a que os sites pertencem também mudam. Esta é a etapa de decidir, antes de tudo, o que vai onde em 10/8.

Premissas

Poder dividir 10/8 livremente dentro da própria empresa. Não precisar considerar, por ora, que uma integração futura misture este espaço com o de outra empresa. Poder acrescentar outras finalidades depois. Poder contar as linhas de filtro que fazem referência aos limites.

Alocação

Justificativa

A primeira decisão em 10/8 é que significado dar ao segundo octeto. Há três candidatos: dividir por finalidade, por organização ou por geografia.

Em resumo, divide-se por finalidade. Organização e geografia mudam; a finalidade, não. As unidades de negócio são reorganizadas a cada poucos anos, e as regiões mudam de responsável. Já uma fábrica nunca vira um site de escritório, e um ambiente de testes nunca vira produção.

Ao dividir por organização, cada reorganização obriga a escolher entre mover os limites ou manter nomes que não correspondem mais à realidade. Quase sempre se escolhe a segunda opção, e alguns anos depois há outro departamento ocupando o bloco de vendas. Nesse ponto, a divisão registrada no documento de projeto e o que realmente está nos equipamentos deixam de coincidir.

Os limites do nível superior não podem ser movidos, porque os filtros foram escritos supondo que 10.16.0.0/12 são as fábricas. Se um limite se move, é preciso revisar todas as linhas que o referenciam. Com 150 sites, 16 fábricas e a nuvem, são centenas de linhas e, se nem todas forem trocadas ao mesmo tempo, haverá um período em que o tráfego passa em um só sentido.

Por isso, decide-se o mínimo possível no início. Dividindo 10/8 em /12, obtêm-se 16 blocos para entregar às finalidades. Começa-se com quatro finalidades e acrescenta-se um bloco quando faltar espaço. Blocos só são acrescentados, então os limites existentes não se movem. Usar apenas 4 de 16 blocos parece desperdício, mas não precisar mover nada vale mais.

Margem para crescer

Há 16 blocos /12 no total. As quatro finalidades (comum à empresa, sites, fábricas e nuvem) usam quatro blocos, e doze ficam livres. Para acrescentar uma finalidade, entrega-se a ela um bloco livre como 10.64.0.0/12, sem mexer nos limites existentes. Finalidades que surgirem depois, como testes ou IoT, também recebem um bloco novo em vez de dividir um existente. Qual bloco entregar em seguida é decidido quando for necessário.

Armadilhas

• Dividir o segundo octeto por organização. A organização é reorganizada a cada poucos anos, mas os limites não podem ser movidos, e nomes e realidade ficam descasados de vez. Divide-se por finalidade.
• Criar desde o início muitas finalidades detalhadas. Além de acumular blocos sem uso, cada nova solicitação exige decidir a qual finalidade pertence. Começa-se com cerca de quatro e acrescenta-se quando necessário.
• Tomar emprestada parte do bloco vizinho para uma finalidade que ficou sem espaço. Surge um limite no meio do bloco, e daí em diante só esse bloco mistura duas finalidades. Se faltar espaço, entrega-se um bloco inteiro.
• Registrar só o resultado da divisão, sem os motivos. O próximo responsável consegue ler para que serve cada bloco, mas não por que a divisão foi por finalidade, e a proposta de redividir por organização volta periodicamente.
• Pegar por último a faixa comum à empresa. Os blocos convenientes são entregues primeiro, e o que é comum à empresa acaba espalhado por blocos distantes. O que é comum à empresa fica com o primeiro bloco.

Cenário

Uma empresa de cerca de 100 pessoas mantém seus equipamentos de campo e de teste na faixa 192.168. Sempre que surge a conexão entre sites com um parceiro de negócios ou um terceirizado, os endereços entram em conflito com os das instalações da outra parte e é preciso coordenar. As conexões de trabalho remoto também às vezes entram em conflito com os roteadores sem fio pessoais dos funcionários.

Premissas

Os endereços usados nas instalações da outra parte nem sempre podem ser conhecidos de antemão. Os equipamentos com rotas para fora podem ser separados dos que não têm. Mudar depois o endereço de um equipamento exige visita técnica e reconfiguração. 10/8 também está disponível.

Alocação

Justificativa

192.168.0.0/16 não é só da empresa. Equipamentos domésticos, roteadores sem fio pessoais e as instalações de parceiros e terceirizados usam o mesmo espaço. É bem conhecido que os valores padrão se concentram em 192.168.0 e 192.168.1, mas o problema não para aí. Os valores padrão de equipamentos pequenos também se espalham por 192.168.10, 192.168.100 e outros, e normalmente não é possível saber de antemão o que a outra parte usa.

Se cada bloco em conflito é evitado caso a caso, o registro de blocos evitados não para de crescer. Em dez anos de operação, chega a dezenas de blocos, e cada novo parceiro exige uma conferência com a lista. Quem confere são pessoas, então casos escapam.

Por isso, faz-se o contrário. A faixa usada é fixada pelo bit de ordem superior, e só a metade em que o terceiro octeto é 128 ou maior é considerada da empresa. Abre-se mão de metade do espaço, mas a decisão é tomada uma única vez. Uma empresa de cerca de 100 pessoas precisa de menos de 10 blocos, então 128 sobram.

Também se limita o que é colocado ali. Neste espaço só podem ficar equipamentos sem rotas para outras empresas ou outros sites. Se já se sabe que os conflitos neste espaço são inevitáveis, basta colocar ali apenas o que não é prejudicado por um conflito. Tudo o que for visível do outro lado de uma conexão entre sites, ou que sair para uma interconexão, recebe endereços de 10.0.0.0/8.

Margem para crescer

A empresa usa só a metade em que o terceiro octeto é 128 ou maior, e ocupa 4 desses 128 blocos. A outra metade, 192.168.0.0/17, fica livre, e não se faz conferência bloco a bloco mesmo que os parceiros aumentem. A decisão é uma única verificação: o terceiro octeto é 128 ou maior? Quando algo precisar de rotas para fora, não é colocado neste espaço e recebe endereços de 10.0.0.0/8. Mesmo que os equipamentos aumentem, a metade em uso basta.

Armadilhas

• Dividir o espaço supondo que todo o 192.168 é da empresa. Cada interconexão traz um conflito, cada um é resolvido evitando um bloco, e os registros de blocos evitados ficam espalhados. A faixa usada é fixada pelo bit de ordem superior.
• Manter uma lista de blocos em conflito para evitá-los. Cada novo parceiro exige uma conferência e, como são pessoas que a fazem, casos escapam. A decisão se reduz a uma única verificação do bit de ordem superior.
• Colocar neste espaço equipamentos visíveis de fora. Quando entram em conflito com as instalações da outra parte, só o próprio lado pode mudar, e é preciso trocar os endereços dos equipamentos. O que sai para fora recebe endereços de 10.0.0.0/8.
• Começar a usar a metade não utilizada porque deixá-la vazia parece desperdício. Blocos que entram em uso não podem ser recuperados; não se ganha nada e perde-se a simplicidade da decisão. Para cerca de 100 pessoas, 128 blocos sobram.

Cenário

Matriz ou filial com cerca de 100 funcionários, em um ou dois andares. Usa rede cabeada e sem fio, com servidor de arquivos e NAS instalados no próprio local. É a configuração mais típica.

Premissas

Há pelo menos um switch de camada 3 ou um roteador com suporte a VLAN. O DHCP pode ficar tanto em um equipamento de rede quanto em um servidor. Prevê-se que o quadro de pessoal possa chegar a 1,5 vez o atual nos próximos três anos.

Alocação

Justificativa

Com cerca de 100 pessoas, a primeira dúvida é se um único /24 basta. A resposta: só para o cabeado, basta, mas não se deve usar um único /24 para o site inteiro. Um /24 basta sozinho para os clientes cabeados. Porém, ao contar os smartphones corporativos e as conexões sem fio dos notebooks, cada pessoa tem na prática dois ou três dispositivos, e os 254 endereços de um /24 se esgotam rapidamente.

Por isso, reserva-se um /22 e divide-se em /24 e /26 por dentro. Os clientes cabeados e os sem fio recebem cada um seu próprio /24, para que o esgotamento de um pool DHCP não se estenda ao outro. Servidores e gerenciamento ficam em /26 porque, nessa escala, raramente passam de 60 equipamentos, e reservar mais faria perder a legibilidade do terceiro octeto.

Dar significado ao terceiro octeto também é intencional. Com 0 = cabeado, 1 = equipamentos com IP fixo, 2 = sem fio e 3 = fase 2, basta olhar uma captura de pacotes ou um log para saber de qual segmento se trata. Essa legibilidade se traduz diretamente em rapidez na resposta a falhas.

Margem para crescer

Como 10.20.3.0/24 fica totalmente livre, mesmo que o quadro de pessoal cresça 1,5 vez é possível ampliar a rede sem fio para /23 ou acrescentar um segmento por departamento. Se o /26 dos servidores ficar apertado, movem-se as impressoras de 10.20.1.128/27 para 10.20.1.192/27 e o gerenciamento de equipamentos para o 10.20.1.128/26 que ficou livre; assim os servidores podem dobrar como 10.20.1.0/25. Para acrescentar outro site, segue-se com 10.21.0.0/22, 10.22.0.0/22 e assim por diante, agregando-os como 10.20.0.0/14.

Armadilhas

• Usar 192.168.1.0/24 ou 192.168.0.0/24 na rede corporativa. Eles entram em conflito com os valores padrão dos roteadores domésticos, e o roteamento quebra nas conexões VPN do trabalho remoto. O mais seguro é recortar de 10/8.
• Juntar clientes sem fio e cabeados no mesmo segmento. Quando mais tarde se quiser adicionar um SSID para visitantes, será preciso refazer o plano de endereçamento. Separá-los desde o início não custa quase nada.
• Misturar os endereços de gerenciamento dos equipamentos de rede em um segmento de clientes. As ACLs deixam de conseguir restringir à parte o acesso de gerenciamento, e as auditorias sempre apontam isso.
• Usar o /24 de reserva para uma necessidade imediata “porque está livre”. A reserva vale justamente por não ser usada; chamá-la de “fase 2” em vez de “reserva” faz com que seja mais respeitada.

Cenário

Site com cerca de 100 lugares sem mesas fixas. Para um quadro de 120 pessoas, a taxa de presença no escritório varia entre 40% e 80% conforme o dia. Todos andam com notebook, e as portas cabeadas só restam nas salas de reunião e em algumas mesas fixas. Há sempre cerca de 10 pessoas de pessoal temporário, entre contratados por agência e terceirizados alocados.

Premissas

A rede sem fio cobre todo o site, e os funcionários conseguem trabalhar em seus dispositivos apenas pela rede sem fio. O tempo de concessão do DHCP pode ser definido por segmento. A presença real de cada dia pode ser obtida depois, por exemplo a partir dos registros de entrada e saída. Parte-se do princípio de que não há sistema de reserva de mesas.

Alocação

Justificativa

Ao dimensionar o pool, os primeiros números que aparecem são os 100 lugares e o quadro de 120 pessoas. Primeiro, descarta-se o número de lugares. Em seguida, considera-se o número de dispositivos no pico de presença: com 80% de presença são 96 pessoas e, como cada uma leva um notebook e um smartphone corporativo, 192 dispositivos. Até aqui, os 254 endereços de um /24 bastam.

O erro vem depois. Com mesas compartilhadas, não se sabe quem virá hoje. Com um tempo de concessão de 24 horas, os endereços dos dispositivos de quem veio ontem e não veio hoje continuam ativos. Uma presença que varia entre 40% e 80% significa que há dias em que poucas pessoas vêm dois dias seguidos. Se um dia de 40% (48 pessoas) for seguido por um dia de 80% (96 pessoas) quase sem rostos em comum, o número de pessoas que vieram nos dois dias se aproxima do quadro de 120, e as concessões ativas chegam a até 240 dispositivos. São 94% dos 254 endereços de um /24, e restam apenas 14. O esgotamento não acontece no dia mais cheio, e sim no dia em que os rostos mudam. O que se deve contar não é o pico de presença, mas quantas pessoas podem vir dentro de um tempo de concessão, ou seja, um número próximo ao quadro de pessoal.

Basta, então, encurtar a concessão? Há um limite inferior. Notebooks fechados no almoço e em reuniões à tarde ficam de três a quatro horas sem comunicação, e com uma concessão de 2 horas alguns dispositivos pegam outro endereço ao voltar. O limite superior é dado pelo tamanho do pool, e o inferior, pela forma de trabalhar. Para atender aos dois, a única saída é um /23 para o pool. Com 510 endereços, mesmo com 240 dispositivos sobram 53%.

Ao adotar um /23, perde-se a correspondência entre o terceiro octeto e o segmento, mas neste site evitar o esgotamento tem prioridade sobre a legibilidade. Se dispositivos que se comunicam enquanto se movem o tempo todo forem colocados no mesmo pool, é preciso uma decisão à parte.

Margem para crescer

O 10.16.10.0/23 vizinho não fica livre pensando no futuro, mas para que o pool possa crescer como uma única sub-rede. Um pool não pode ser ampliado somando pedaços separados; para transformar o /23 em /22, o /23 adjacente precisa estar totalmente livre. O ponto de decisão fica em um quadro de 210 pessoas porque, se quase todos vierem em dois dias, serão 420 dispositivos, 82% dos 510 endereços do /23 atual. Nesse momento, o bloco adjacente é incorporado para formar 10.16.8.0/22, mantendo o tempo de concessão. Por essa restrição, tanto o cabeado quanto os servidores foram empurrados para 10.16.12.0/24. Se as condições para liberar esse espaço não forem definidas antes, ele sempre acabará tomado por outro uso.

Armadilhas

• Dimensionar o pool pelo número de lugares. Se for recortado um /25 porque há 100 lugares, ele não basta assim que se contam dois dispositivos por pessoa e o pessoal temporário, e se esgota na primeira semana de operação. Contam-se dispositivos, não lugares.
• Encurtar o tempo de concessão para aumentar a rotatividade e evitar o esgotamento. Os dispositivos que voltam depois do almoço ou de uma reunião pegam outro endereço e perdem a conexão, mas como a queda só ocorre no momento da volta, não se reproduz e ninguém a relata.
• Colocar os dispositivos do pessoal temporário no mesmo pool dos funcionários. A quantidade estimada a partir do quadro de pessoal se afasta continuamente da real, e a cada aumento de pessoal já não é possível explicar quantos endereços faltaram. Separa-se o que é previsível do que não é.
• Manter a prática de atribuir IPs fixos às portas cabeadas. Com mesas compartilhadas, a cada dia uma pessoa diferente usa a mesma porta, então a correspondência entre endereços e usuários logo se desfaz e só resta o registro de endereços. O cabeado também é atendido por DHCP.

Cenário

150 sites no total: 1 matriz, 8 hubs regionais e 141 escritórios de vendas e depósitos. Cada site se conecta à matriz por um hub regional, e as rotas são agregadas nos hubs regionais e repassadas ao nível superior. Os números de site já são usados na gestão de ativos e em formulários e relatórios, e foram atribuídos na ordem de abertura. Todo ano alguns sites abrem e alguns fecham.

Premissas

Cada hub regional consegue anunciar os sites sob ele como uma única rota. Já existe um esquema de números de site, e os sites não podem ser renumerados por conveniência do plano de endereçamento. Nenhum site passa de 1.000 dispositivos. A região a que cada site pertence não muda por anos.

Alocação

Justificativa

Agrega-se para que 150 sites não subam ao nível superior como 150 rotas. Mas o que a agregação exige é que os blocos de endereços sejam contíguos, não que os números de site o sejam. Confundir isso desperdiça o projeto inteiro.

Os números de site já existem. São usados na gestão de ativos e em formulários e relatórios, foram atribuídos na ordem de abertura e não têm relação com as regiões. Se forem copiados diretamente para o segundo octeto, o hub da região 3 fica com um conjunto espalhado, como os sites 3, 17, 42 e 88. Blocos espalhados não se juntam em uma rota só, então continuam subindo 150 rotas. Renumerar para agregar não é possível: os números estão gravados em formulários, relatórios e na forma como cada site é chamado.

Por isso, inverte-se a ordem. Primeiro atribuem-se blocos à unidade de agregação, ou seja, ao hub regional, e os números de site são distribuídos como identificadores dentro desse bloco. Cada uma das 8 regiões recebe um segundo octeto, e cada site um bloco /22 próprio. Uma região comporta até 64 sites. Com 150 sites, mesmo a maior região tem só 24, então tudo cabe e sobem 8 rotas. Mesmo que os sites dobrem para 300, continuam sendo 8.

O custo é que o número do site deixa de ser legível no endereço. Torná-lo legível significa abrir mão da contiguidade dentro das regiões. O que o atendimento a incidentes precisa não é de uma regra de numeração, e sim de uma tabela de correspondência entre números de site e blocos.

Margem para crescer

Os blocos regionais usam os segundos octetos de 1 a 8, e o 0 fica para usos comuns à empresa. Os sete blocos de 9 a 15 ficam livres, para novas regiões e para o segundo bloco regional dado a uma região que passe de 64 sites. Esses números não são contíguos, então são consultados na tabela de correspondência. De 10.16.0.0/12 para cima nada é mexido, e o espaço fica reservado para aquisições e para receber outros negócios.

Armadilhas

• Fazer os números de site corresponderem diretamente aos endereços. Os números seguem a ordem de abertura e não têm relação com as regiões, então os sites de um mesmo hub ficam espalhados e continuam subindo tantas rotas quanto há sites. Distribuem-se os números dentro do bloco regional.
• Tirar os endereços dos links entre sites do bloco do próprio site. Se a outra ponta for um site de outra região, endereços do bloco desta região acabam naquela região, e rotas mais específicas sobem por causa deles. Os links são tirados de um bloco comum fora dos blocos de site.
• Acrescentar segmentos dentro de um site atravessando o limite do bloco do site. A parte que transborda não entra na agregação, e sobe uma rota mais específica só para aquele site. Acrescenta-se apenas dentro do bloco e, ao ultrapassá-lo, entrega-se um segundo bloco.
• Exigir que o número do site seja legível no endereço. Torná-lo legível significa abrir mão da contiguidade dentro das regiões, e a agregação deixa de funcionar. O necessário não é uma regra de numeração, e sim uma tabela de correspondência.
• Ligar um único site a outro hub regional por conveniência geográfica. Os endereços continuam no bloco da região original, então no nível superior aparecem lado a lado o bloco regional e uma rota só daquele site. Se o hub de um site mudar, mudam-se também os endereços.

Cenário

Em uma rede com 300 ou mais links ponto a ponto, é preciso definir o comprimento do prefixo dos links. Os equipamentos são de gerações misturadas: convivem equipamentos antigos, equipamentos de uso específico e equipamentos virtuais. Foi proposto padronizar em /31 com o argumento de economizar endereços.

Premissas

É possível listar o modelo e a geração dos equipamentos nas duas pontas de cada link. É possível verificar com antecedência se um equipamento suporta /31 ou não. A alocação é feita em um único lugar. Mudar depois os endereços de um link exige reescrever a configuração e o monitoramento.

Alocação

Justificativa

Um /30 tem quatro endereços, dos quais só dois são utilizáveis; um /31 aproveita os dois. A quantidade de endereços necessários cai pela metade.

Mas, como economia, isso não significa nada. Com 352 links, o /30 ocupa 1.408 endereços e o /31 ocupa 704. A diferença de 704 é só cerca de 1 por cento do bloco /16 reservado para links. Uma diferença tão pequena não é motivo para mudar a decisão.

O fator decisivo é se todos os equipamentos acompanham. Nem todo equipamento suporta /31. Algum equipamento antigo, de uso específico ou virtual pode não suportar. Cada link tem um equipamento em cada ponta, então basta um deles não suportar para que esse link tenha de ser um /30 de qualquer forma.

Misturar muda o procedimento de alocação. Passam a conviver dois tamanhos no pool, e a cada alocação é preciso verificar o suporte dos equipamentos das duas pontas. A 10 links por mês, são 120 verificações por ano. Economizar 704 endereços não vale 120 verificações por ano.

Por isso se padroniza. Se todos os equipamentos suportam, /31; se sobra ao menos um sem suporte, /30 em todos os links. Se for inevitável misturar, separam-se as faixas para não ser preciso verificar a cada alocação.

Mais uma coisa. Um link cortado uma vez como /30 não passa para /31, mesmo quando seus equipamentos são trocados. Passá-lo significa mudar seus endereços, o que reescreve a configuração e os nomes no monitoramento. Não se parte da premissa de migrar mais tarde.

Margem para crescer

O padrão é /30, e só os trechos com suporte confirmado são cortados da faixa /31 dedicada. As faixas são separadas para que a alocação não exija verificar o suporte dos equipamentos. Um trecho só entra na faixa /31 quando os equipamentos das duas pontas foram trocados e o suporte foi confirmado. O crescimento sai de 10.161.16.0/21. Mesmo depois que todos os equipamentos forem trocados, os links /30 existentes não são convertidos; só os links criados daí em diante são cortados como /31 desde o início.

Armadilhas

• Escolher /31 para economizar endereços. A economia é de cerca de 1 por cento do bloco de links e não é motivo para mudar a decisão. O fator decisivo é se todos os equipamentos acompanham.
• Misturar os dois tamanhos na mesma faixa. A cada alocação é preciso verificar o suporte dos equipamentos das duas pontas, e a 10 links por mês são 120 verificações a mais por ano. Se for para misturar, separam-se as faixas.
• Adotar /31 como padrão mesmo restando um equipamento sem suporte, deixando só esse trecho como exceção /30 à parte. Cada troca de equipamento exige verificar o suporte, e basta esquecer uma vez para esse link ficar inutilizável. Adota-se /30 como padrão, e os /31 são cortados da faixa dos trechos com suporte confirmado.
• Escolher /30 contando com migrar para /31 mais tarde. Migrar significa mudar endereços, o que reescreve a configuração e os nomes no monitoramento. Decide-se partindo do princípio de que não haverá migração.

Cenário

Uma empresa de cerca de 100 pessoas prepara uma rede sem fio para visitantes. Em dias normais há uns 20 dispositivos de visitantes, mas em dias de apresentações ou exposições chegam 400 de uma vez. O tráfego para a rede corporativa é bloqueado por filtros, mas a resolução de nomes e a atribuição de endereços usam os mesmos equipamentos da rede corporativa.

Premissas

A rede sem fio para visitantes pode ser oferecida como uma faixa separada da rede sem fio corporativa. É possível disponibilizar uma única saída para o exterior para os visitantes. Equipamentos de resolução de nomes e de atribuição de endereços podem ser instalados à parte para os visitantes. Há uma posição utilizável dentro de 172.16/12.

Alocação

Justificativa

Costuma-se pensar que basta isolar a rede sem fio para visitantes da rede corporativa: bloqueia-se com filtros o tráfego para a rede corporativa e o assunto está resolvido. Isso não basta.

A faixa de visitantes também compartilha coisas com a rede corporativa fora dos filtros. Se os visitantes resolvem nomes com equipamentos corporativos, seus dispositivos conseguem consultar os nomes dos servidores internos. Mesmo sem resposta, a reação à consulta revela quais nomes existem. Se os endereços são atribuídos pelos mesmos equipamentos da rede corporativa, no dia de um evento em que chegam 400 dispositivos a uma empresa de 100 pessoas, a atribuição de endereços corporativa também trava. Se os visitantes sincronizam o horário com a rede corporativa, é preciso abrir uma rota até o servidor de horário interno.

Por isso a faixa de visitantes não compartilha nada com a rede corporativa. Ela não tem rota para nenhum segmento corporativo, e sua única saída é uma só, para o exterior. A resolução de nomes e a atribuição de endereços ficam à parte, só para os visitantes. Em vez de bloquear com filtros, faz-se com que as rotas que precisariam ser bloqueadas nem existam. Uma rota bloqueada se abre com uma linha; uma rota que não existe não tem como ser aberta.

A escolha dos endereços também tem um motivo. A maioria dos dispositivos de visitantes abre conexões com a própria empresa. Se essa empresa usa 10/8 internamente e a faixa de visitantes também está em 10/8, os endereços colidem do outro lado e o visitante não consegue chegar à própria empresa. A faixa é tirada de uma posição pouco usada dentro de 172.16/12.

Margem para crescer

A faixa de visitantes não tem rota para nenhuma parte da rede corporativa, e sua única saída é uma só, para o exterior. A resolução de nomes e a atribuição de endereços também ficam à parte para os visitantes. Quando os eventos trazem mais dispositivos, acrescenta-se 172.30.4.0/22 para recebê-los, e o acréscimo sai pela mesma saída. Não se acrescentam rotas para a rede corporativa. A faixa é tirada dentro de 172.16/12 e não se sobrepõe a 10/8, que as empresas dos visitantes provavelmente usam.

Armadilhas

• Contentar-se em bloquear por filtros o tráfego para a rede corporativa. Se a resolução de nomes ou a atribuição de endereços são compartilhadas com a rede corporativa, informações internas vazam fora dos filtros e a carga também se propaga. Não se compartilha nada.
• Fazer os dispositivos de visitantes usarem a resolução de nomes corporativa. Mesmo sem resposta, a reação às consultas revela quais nomes existem. Mantém-se uma à parte para os visitantes.
• Atribuir os endereços dos visitantes com os mesmos equipamentos da rede corporativa. Quando o número de visitantes dispara no dia de um evento, a atribuição de endereços corporativa também trava. Separa-se a atribuição para os visitantes.
• Tirar a faixa de visitantes de 10/8. Quando um visitante se conecta à própria empresa, os endereços colidem com a rede interna dessa empresa e a conexão falha. Tira-se de uma posição pouco usada dentro de 172.16/12.

Cenário

Em uma empresa de cerca de 500 pessoas, os equipamentos na DMZ aumentam ano a ano. Um servidor web exposto à internet, um servidor para trocar arquivos com parceiros de negócios, equipamentos que recebem e-mail do exterior, um servidor que só chama serviços externos e equipamentos que enviam alertas de monitoramento para fora convivem em uma mesma faixa.

Premissas

É possível distinguir os equipamentos que recebem conexões iniciadas de fora daqueles que só enviam tráfego para fora. A contraparte de cada conexão com parceiros de negócios pode ser identificada. As faixas da DMZ podem ser oferecidas separadamente por contraparte. O tráfego entre faixas pode ser barrado no limite.

Alocação

Justificativa

O critério do que vai na DMZ é um só: equipamentos que recebem conexões iniciadas de fora.

Sem critério, entra tudo o que conversa com o exterior: equipamentos que só enviam tráfego de dentro para fora, servidores que só chamam serviços externos, equipamentos que enviam alertas de monitoramento para fora. Nenhum deles recebe conexões iniciadas de fora, então não há motivo para colocá-los na DMZ. Se forem colocados lá, a DMZ incha, e quando qualquer um deles é comprometido, tudo o que está ao lado fica ao alcance.

Decidido o que entra, divide-se em seguida conforme de quem se recebe. O que é exposto à internet e o que é para parceiros de negócios não ficam na mesma faixa. Qualquer um chega ao que é exposto à internet, então ele é projetado partindo do pressuposto de que será comprometido. O que é para parceiros tem contrapartes conhecidas, então suas permissões são bem mais estreitas. Se estiverem na mesma faixa, quando um servidor exposto à internet é comprometido, os arquivos trocados com os parceiros ficam ao alcance a partir do servidor vizinho. Restringir as contrapartes perde o sentido.

O tráfego entre as faixas separadas não é permitido. Não há um único motivo de negócio para ir do que é exposto à internet ao que é para parceiros.

Quando surge um equipamento novo que recebe de fora e não está claro de quem recebe, ele vai para a faixa exposta à internet. Colocar na faixa de parceiros um equipamento cujas contrapartes não podem ser restringidas derruba a premissa dessa faixa.

Margem para crescer

A DMZ é dividida conforme de quem cada faixa recebe, e o que é exposto à internet e o que é para parceiros de negócios ficam em faixas distintas. O tráfego entre faixas não é permitido. Quando surge um equipamento novo que recebe de fora, sua faixa é decidida conforme de quem ele recebe, e, se não for possível decidir, ele vai para a faixa exposta à internet. Quando faltarem faixas, elas são cortadas de 10.170.1.0/24. Equipamentos que só enviam tráfego para fora não entram na DMZ, mesmo que aumentem.

Armadilhas

• Colocar na DMZ tudo o que se comunica com o exterior. Se entram também equipamentos que só enviam tráfego para fora, a DMZ incha e um único comprometimento alcança tudo o que está ao lado. Só se colocam os equipamentos que recebem conexões iniciadas de fora.
• Colocar o que é exposto à internet e o que é para parceiros de negócios na mesma faixa. Quando o lado exposto é comprometido, os arquivos trocados com os parceiros ficam ao alcance a partir do vizinho. Dividem-se as faixas conforme de quem se recebe.
• Permitir por precaução o tráfego entre as faixas separadas. Uma permissão sem motivo de negócio só serve de caminho para um invasor. Entre faixas não se permite nada.
• Colocar na faixa de parceiros um equipamento cuja contraparte não está clara. Essa faixa mantém as permissões estreitas partindo da premissa de que as contrapartes são conhecidas, e essa premissa cai. Na dúvida, coloca-se na faixa exposta à internet.

Cenário

Em uma rede virtual na nuvem, cria-se em cada zona de falha uma sub-rede pequena para 10 equipamentos. Como na rede corporativa, espera-se que um /28 comporte 14 equipamentos. Na mesma rede virtual também está prevista uma sub-rede de aplicações com cerca de 200 equipamentos.

Premissas

Sabe-se que o provedor utilizado toma antecipadamente alguns endereços de cada sub-rede. É possível verificar quantos ele toma e qual é o tamanho mínimo permitido. O tamanho de uma sub-rede não pode ser alterado depois de criada. Há espaço livre na rede virtual.

Alocação

Justificativa

Ao criar uma sub-rede na nuvem, o provedor toma antecipadamente alguns dos seus endereços. Depende do provedor, mas é comum tomar os quatro primeiros e o último, cinco no total. Na rede corporativa, só o primeiro e o último endereço não podem ser usados; por isso, quem corta sub-redes sem conhecer essa diferença acaba com endereços de menos.

A diferença pesa mais nas sub-redes pequenas. Em um /24 são 5 de 256, menos de 2 por cento. Em um /26 são 5 de 64, ou 8 por cento. Em um /28, o menor tamanho que se pode criar, somem 5 de 16, cerca de 30 por cento. Sobram apenas 11 utilizáveis.

Quando se corta um /28 como na rede corporativa, preveem-se 14 equipamentos, mas cabem só 11. Com 10 equipamentos, a margem é de um único endereço, e no dia em que entram mais dois, a sub-rede transborda. Como o tamanho não pode ser alterado depois da criação, um transbordamento obriga a refazer a sub-rede.

Por isso, ao cortar sub-redes pequenas, compara-se o número de equipamentos com o que sobra depois das reservas. Para 10 equipamentos, um /28 não basta e usa-se um /27 no lugar. Um /27 deixa 27 endereços utilizáveis ao descontar 5 de 32. Quanto menor a sub-rede, maior a proporção perdida; por isso, como regra, as sub-redes pequenas são cortadas um tamanho acima do que se usaria na rede corporativa.

O número de endereços reservados varia conforme o provedor, assim como o tamanho mínimo. Ao escolher um perfil de reserva na aba Calcular, o número de endereços utilizáveis aparece na hora. É ali que as estimativas são conferidas.

Margem para crescer

Nas sub-redes pequenas, descontam-se os 5 endereços reservados antes de comparar com o número de equipamentos. Para 10 equipamentos, um /28 não basta e usa-se um /27 no lugar. As sub-redes são alinhadas com o mesmo tamanho, uma por zona de falha. Quando forem necessárias mais sub-redes, elas são cortadas de 10.216.2.0/24. Em caso de dúvida sobre uma estimativa, escolhe-se o perfil de reserva na aba Calcular e confere-se o número de endereços utilizáveis.

Armadilhas

• Calcular os endereços utilizáveis como na rede corporativa. Quando se descontam só o primeiro e o último, esquecem-se os outros três que o provedor toma, e o número de equipamentos previsto não cabe. Compara-se com o que sobra depois das reservas.
• Adotar o /28, o menor tamanho, como padrão. Somem 5 de 16, sobram só 11 utilizáveis, e basta acrescentar poucos equipamentos para a sub-rede transbordar. Para cerca de 10 equipamentos, usa-se um /27 no lugar.
• Supor que a sub-rede poderá ser ampliada depois. O tamanho não muda depois da criação, e um transbordamento obriga a refazer a sub-rede. Estima-se desde o início com as reservas incluídas.
• Supor que todos os provedores reservam o mesmo número de endereços. Os provedores diferem tanto na quantidade que tomam quanto no tamanho mínimo permitido. Confere-se com o perfil do provedor utilizado.

Cenário

Conecta-se a rede de uma empresa adquirida à rede própria. As duas usam 10/8, e muitas faixas se sobrepõem. Por necessidade do negócio, as redes precisam estar conectadas no mês que vem, e não há tempo para renumerar nenhum dos lados. Há uma proposta de conectá-las traduzindo os endereços no limite.

Premissas

É possível colocar, entre as redes das duas empresas, um único limite capaz de traduzir endereços. Os endereços traduzidos podem ser tirados de um espaço que não pertence a nenhuma das duas. É possível escrever um prazo nas regras de tradução. O lado a renumerar pode ser decidido sem esperar uma decisão da diretoria.

Alocação

Justificativa

Há duas maneiras de conectar duas redes sobrepostas: renumerar uma delas ou traduzir os endereços no limite. A tradução entra em uma noite; a renumeração leva meses. Escolher a tradução no início de uma integração é correto.

O problema é que a tradução se torna permanente. Como o tráfego passa com a tradução, o motivo para renumerar desaparece. Três anos depois, as regras de tradução se acumularam e ninguém consegue explicar o conjunto. A cada falha, é preciso verificar se um endereço que aparece nos logs é de antes ou de depois da tradução.

Por isso, no dia em que a tradução entra, decidem-se duas coisas ao mesmo tempo: o prazo e o lado que será renumerado. O prazo é definido como uma data e escrito nas próprias regras de tradução. O lado a renumerar é decidido no mesmo dia, e o período da tradução é tratado como tempo de preparação da renumeração. Uma tradução sem decisão sobre qual lado renumerar só pode ser prorrogada quando o prazo chega.

Os endereços traduzidos são tirados de um espaço que não pertence a nenhum dos dois lados. Se as duas empresas usam 10/8 e é ali que se sobrepõem, os endereços traduzidos são tirados de 172.16/12. Se for usado espaço livre do 10/8 de qualquer um dos lados, a próxima empresa incorporada vai se sobrepor de novo.

Há traduções que podem ser permanentes. Quando o projeto pressupõe que os mesmos endereços se repetem lado a lado, como em linhas de produção montadas copiando a mesma configuração, a tradução permanente é correta. A sobreposição em uma integração não é um pressuposto, e sim um acidente, e o remédio de um acidente não deve se tornar permanente.

Margem para crescer

As faixas traduzidas são tiradas de dentro de 172.16/12, e separa-se a faixa para ver a rede da outra empresa da faixa que apresenta a rede própria à outra empresa. O prazo é escrito nas regras de tradução e, até o prazo, renumera-se o lado decidido no dia em que a tradução entrou. O crescimento até o prazo é recortado de 172.18.24.0/22. Uma tradução vencida não é prorrogada; se for preciso prorrogar, recomeça-se pela decisão de qual lado renumerar.

Armadilhas

• Não definir um prazo ao colocar a tradução. O tráfego passa, então o motivo para renumerar desaparece, e as regras de tradução se acumulam até que ninguém consiga explicá-las.
• Colocar a tradução sem decidir qual lado renumerar. Quando o prazo chega, a discussão recomeça pela questão de qual lado mover, e só resta prorrogar. Decide-se no mesmo dia da tradução.
• Tirar os endereços traduzidos do espaço livre do próprio 10/8. Na próxima vez que outra empresa for incorporada, eles vão se sobrepor de novo. Eles são tirados de um espaço que não pertence a nenhum dos dois lados.
• Escrever as regras de tradução host por host. Os prazos também precisam ser gerenciados host por host, e ninguém sabe quais regras restam. Elas são escritas por faixa.

Cenário

Uma fábrica com várias linhas de produção de mesma configuração de equipamentos, que pretende acrescentar outras. Os controladores entregues pelo fornecedor de equipamentos têm IPs fixos gravados de fábrica, e parte-se de uma situação em que os mesmos endereços se repetem em várias linhas.

Premissas

Os endereços dos controladores de cada linha não podem ser alterados, ou alterá-los exige um novo aceite com o fornecedor de equipamentos. As linhas não precisam se comunicar diretamente entre si; basta que se comuniquem com os sistemas de coleta do nível superior. É possível colocar, no limite de cada linha, um equipamento de camada 3 ou um equipamento capaz de fazer NAT.

Alocação

Justificativa

O que separa de forma decisiva uma rede OT da TI é que os endereços não podem ser escolhidos livremente. Os fornecedores de equipamentos entregam a mesma configuração a muitos clientes, por isso os endereços dos controladores vêm fixados de fábrica, e o mesmo 192.168.0.10 existe tanto na linha 2 quanto na linha 3. Se for aplicado o reflexo habitual de TI, "está sobreposto, então renumera", a conversa passa para a garantia dos equipamentos e para refazer o aceite, e o chão de fábrica fica parado.

Por isso não se renumera. Os endereços dentro da linha ficam como o fornecedor de equipamentos os configurou; no equipamento do limite da linha aplica-se uma tradução de endereços 1:1, e apenas os endereços vistos de fora são diferenciados pelo número da linha. Um controlador da linha 1 aparece de fora como 172.20.1.x, e o mesmo equipamento da linha 2 como 172.20.2.x. Com a regra de que o terceiro octeto é o número da linha, quem lê os logs do sistema de coleta identifica a linha na hora, sem conhecer o nome do equipamento.

O essencial deste projeto é separar as condições do fornecedor de equipamentos e a facilidade de gestão da TI com uma única camada: a tradução. Dentro da linha vale o mundo do fornecedor de equipamentos; do limite para cima, o mundo da área de TI. A maior vantagem é que acrescentar uma linha não obriga a refazer o projeto: basta somar um ao número e copiar a mesma configuração.

Margem para crescer

Para as próximas ampliações está reservado 172.20.4.0/22 (linhas 4 a 7). Como o bloco base é um /16, a regra de usar o terceiro octeto como número da linha alcança a linha 255 (o 0 não é usado como número de linha e fica para a coleta e a manutenção comuns), e a partir da linha 8 segue-se naturalmente com 172.20.8.0/21 e 172.20.16.0/20. Se houver mais fábricas, o segundo octeto passa a ser o número da fábrica: 172.21.0.0/16 vai para a fábrica seguinte, e as duas são agregadas em 172.20.0.0/15. Uma linha só fica pequena para o seu /24 quando passa de 250 controladores, e nessa escala é mais fácil operar a linha dividindo-a logicamente.

Armadilhas

• Liberar o tráfego entre linhas "por precaução". Quando uma linha é infectada por malware, todas as linhas de mesma configuração param ao mesmo tempo. O tráfego entre linhas é bloqueado por padrão, e o tráfego necessário passa pelos sistemas de coleta.
• Não prever um segmento para notebooks de manutenção e ligar os PCs trazidos de fora direto no segmento de controle. É a porta de entrada mais comum dos incidentes de OT, e ainda não deixa registro. Cria-se um segmento dedicado, e só a partir dele se entra no lado de controle.
• Manter a tabela de correspondência da tradução de endereços apenas na configuração do equipamento. Quando a pessoa que a configurou muda de função, ninguém mais consegue explicar qual endereço externo corresponde a qual equipamento. A tabela de correspondência é mantida nos documentos de projeto como fonte principal.
• Usar a faixa 192.168 nos endereços da fábrica. Ela entra facilmente em conflito com os roteadores e roteadores móveis que os prestadores de manutenção trazem, e o conflito só aparece no próprio local. Os endereços são tirados de 172.16/12 ou de 10/8.
• Definir a correspondência entre número de linha e endereços ocupando, a cada ampliação, o número que estiver livre. Quando a linha 7 é desmontada e depois outros equipamentos ocupam o seu lugar, número e linha real deixam de bater, e ninguém mais confia neles. Os números não são reutilizados.

Cenário

Uma fábrica de cerca de 300 funcionários, com um prédio de escritórios e um prédio de produção no mesmo terreno, operados até agora como uma única rede. Continuará sendo necessário enviar instruções da gestão da produção aos equipamentos e coletar os resultados deles, mas quer-se acabar com a situação em que os PCs do escritório alcançam os controladores diretamente. Nesta etapa não se mexe no projeto interno das linhas; primeiro se redesenham apenas os limites acima e abaixo delas.

Premissas

É possível colocar ao menos um equipamento de camada 3 entre o lado do escritório e o lado da fábrica. O tráfego que atravessa os dois lados pode ser levantado, no mínimo por servidor de interconexão, com a contraparte e o sentido. Os endereços dos controladores não mudam desta vez; o reprojeto interno das linhas é feito à parte. Entre os requisitos está que a produção possa continuar enquanto os equipamentos do limite estiverem fora do ar.

Alocação

Justificativa

Ninguém se opõe à separação. O que não se consegue decidir é o tamanho da zona colocada no limite.

Tomar um /24 para o limite sempre dá errado. Nesta escala, o que realmente precisa se comunicar com os dois lados são apenas os servidores de interconexão, pouco mais de uma dúzia. Os mais de 240 endereços restantes viram terrenos baldios, e terrenos baldios sempre acabam ocupados. Seis meses depois entra um servidor de arquivos da TI corporativa; no ano seguinte, um servidor de salto ingressado na infraestrutura de autenticação do escritório. Nesse ponto o limite deixa de ser limite, mas na tabela de endereços nada muda, então ninguém percebe.

Por isso a interconexão fica em um /28 e nada mais. Com apenas 14 endereços, quem tentar colocar a décima quinta máquina terá de consultar alguém antes. A ideia é fazer o tamanho funcionar como regra de operação. A margem de crescimento fica ao lado, com outro nome, para a fase 2, e a própria zona de interconexão não é ampliada.

Dividir o /20 em três áreas, 0 a 3 (TI), 4 a 7 (limite) e 8 a 15 (controle), também é proposital. Os filtros do equipamento do limite são escritos em três linhas, 10.60.0.0/22, 10.60.4.0/22 e 10.60.8.0/21, e essas três linhas não mudam quando se acrescentam segmentos. Num projeto que obriga a mexer nos filtros a cada acréscimo, um dia alguém mexe errado e interrompe a produção.

A zona dos serviços compartilhados da rede de controle, um /25, fica no lado de controle por disponibilidade. A produção continua enquanto os equipamentos do limite estão fora do ar. Se a sincronização de horário e a resolução de nomes dependerem do lado do escritório, uma parada do limite vira uma parada do lado de controle.

Margem para crescer

No limite, 10.60.4.64/26 fica livre para a fase 2. Não serve para ampliar a interconexão, e sim para acrescentar depois as integrações de dados com o exterior e os intermediários de manutenção remota. No lado de controle, 10.60.12.0/22 fica livre para as zonas por linha, e é ali que entra o projeto de cada linha. Se a rede sem fio ficar pequena para o seu /24, acrescenta-se 10.60.10.0/23. Se houver mais fábricas, 10.60.16.0/20 vai para a fábrica seguinte, e o conjunto é agregado em 10.60.0.0/16. Como as divisas das três áreas estão alinhadas em limites de /22, as três linhas de filtro têm a mesma forma em todas as fábricas.

Armadilhas

• Colocar um servidor de salto no limite e ingressá-lo na infraestrutura de autenticação do escritório. Abre-se um caminho pelo qual as credenciais entram vindas do lado do escritório, e o limite perde o sentido. Se for colocado um servidor de salto, sua autenticação fica restrita ao interior do limite.
• Manter os controladores sincronizando o horário com um servidor do lado do escritório. No instante em que o equipamento do limite é parado, o horário do lado de controle começa a se desviar, e ao investigar uma falha depois não é possível confrontar os logs. A sincronização de horário é colocada no lado de controle.
• Definir o requisito de separação apenas como "não entrar do escritório na rede de controle". O tráfego do lado de controle para o escritório fica sem controle, e um dispositivo infiltrado entre os equipamentos mantém um caminho de saída. As regras são definidas nos dois sentidos.
• Fazer os servidores de interconexão acumularem também a coleta e o armazenamento de arquivos. As exigências do lado que não pode parar impedem as atualizações, e em poucos anos ninguém mais ousa mexer neles. Separam-se os servidores por função, e a quantidade é mantida dentro do /28 atribuído.

Cenário

Uma empresa com 10 sites recebeu da operadora um /48 de IPv6. Até agora, no IPv4, ajustava o tamanho de cada sub-rede ao número de dispositivos e cuidava de onde deixar reserva e de como evitar a fragmentação. Está prestes a começar a alocação de IPv6 com a mesma mentalidade.

Premissas

Um /48 foi recebido da operadora. Os equipamentos da empresa podem usar a configuração automática de endereços do IPv6. Prevê-se que o número de sites e o de finalidades fiquem, cada um, em 15 ou menos. Os endereços são feitos para que pessoas os leiam e entendam seu significado.

Alocação

Justificativa

Um /48 contém 65.536 sub-redes /64 no total. Boa parte do que se acumulou em anos de IPv4 se inverte aqui.

No IPv4, o tamanho da sub-rede era decidido pelo número de dispositivos: um /28 para 10, um /24 para 200. No IPv6 isso não se faz. Toda sub-rede é sempre um /64, independentemente do número de dispositivos. O mecanismo pelo qual os dispositivos escolhem o próprio endereço foi construído pressupondo um prefixo /64 na sub-rede. Se o corte for menor que um /64, esse mecanismo deixa de funcionar.

Também não é preciso economizar. Praticamente nenhuma organização esgota as 65.536 sub-redes /64 disponíveis. Os problemas que deram tanto trabalho no IPv4, como onde deixar reserva e como evitar a fragmentação, quase desaparecem.

Resta uma única decisão: como dividir os 16 bits do quarto grupo de 16 bits. Aqui se atribuem 4 bits ao site, 4 à finalidade e 8 a um número sequencial. Quando as divisões de significado coincidem com as divisas entre dígitos hexadecimais, um endereço se lê só de olhar. 2001:db8:100:1200::/64, por exemplo, é a primeira sub-rede de servidores do site 1.

As divisões se alinham aos dígitos hexadecimais. Se a divisão cair no meio de um dígito, cada leitura de um endereço obriga a convertê-lo para binário, e a vantagem da legibilidade se perde. Se o número de sites puder passar de 15, atribuem-se desde o início 8 bits ao site e 4 bits cada à finalidade e ao número sequencial.

Margem para crescer

O primeiro dígito hexadecimal do quarto grupo de 16 bits é o site, numerado a partir de 1, e o 0 fica reservado para o que é comum à empresa toda. O segundo dígito é a finalidade e os dois últimos são o número sequencial. As sub-redes são sempre /64 e não aumentam quando os dispositivos aumentam. As sub-redes /64 da tabela de segmentos parecem grandes para o número de dispositivos porque o protocolo exige um prefixo /64, e não porque se deixou folga. Se os sites passarem de 15, mantêm-se as divisões e obtém-se um segundo /48 da operadora.

Armadilhas

• Dimensionar as sub-redes pelo número de dispositivos e cortá-las menores que um /64 completo. O mecanismo pelo qual os dispositivos escolhem o próprio endereço pressupõe um prefixo /64 e deixa de funcionar. As sub-redes são sempre /64 completas.
• Cortar as sub-redes bem justas por preocupação com reserva e fragmentação, como no IPv4. Esgotar 65.536 sub-redes /64 praticamente não acontece, e apertar não traz ganho algum. A legibilidade vem primeiro.
• Dividir o quarto grupo de 16 bits no meio de um dígito hexadecimal. Cada leitura de um endereço obriga a convertê-lo para binário, e não dá mais para ler o significado no endereço. A divisão é feita nas divisas entre dígitos hexadecimais.
• Numerar o dígito do site a partir de 0. Não sobra lugar para o que é comum à empresa toda, e depois é preciso encaixá-lo à força. O 0 fica reservado para o que é comum à empresa toda.