Não adivinhe o prefixo do escritório a partir de um único endereço de servidor

Comece pelo endereço que recebeu e depois resista à tentação de ampliá-lo para algo que pareça arrumado. Um servidor em 10.22.8.19 não diz nada sobre se o escritório possui 10.22.8.0/24, 10.22.0.0/16 ou um punhado de /28s dispersos. Escolher 10.0.0.0/8 porque o número começa por 10 captura redes domésticas, intervalos de contêineres e ligações de parceiros que não pretendia. O prefixo é uma fronteira a obter, não a deduzir.

O comprimento de um prefixo descreve quantos bits iniciais são significativos; não descreve quem possui o intervalo.

Um endereço de servidor não é uma rede

Servidor, sub-rede e local são três coisas diferentes. Um único serviço pode estar numa sub-rede pequena e dedicada enquanto o resto do escritório ocupa intervalos separados, e uma rota de host pode ser perfeitamente adequada para um serviço que tem deliberadamente um só endereço. Deixa de ser adequada quando o local redireciona para outro host, se autentica através de um servidor separado ou muda de endereço. Essas dependências são o requisito real, e vale a pena perguntar por elas antes de instalar qualquer prefixo.

Uma calculadora de sub-redes traduz um prefixo conhecido em máscara, intervalo ou lista de hosts. Não consegue inferir uma fronteira organizacional a partir de um único nome de host, e tratar a sua saída como autoridade é como redes sem relação acabam encaminhadas.

Peça os prefixos aprovados

Obtenha os intervalos de destino com quem opera a VPN ou a rede. Pode haver vários prefixos distintos e um servidor DNS privado noutra localização, que muitas vezes é esquecido até os nomes falharem. Registe-os como uma lista aprovada com um responsável e uma data, não como um intervalo reconstruído a partir de um exemplo. Se a lista é longa, isso é informação sobre a rede e não um convite para a resumir em algo mais amplo.

Uma consulta de rotas só de leitura no Mac, dirigida ao destino que lhe importa, mostra que caminho está a ser usado neste momento. Isso é comportamento atual, não uma autorização.

Verifique a sobreposição antes de aplicar seja o que for

Compare os prefixos aprovados com cada intervalo local antes de os aplicar: LAN doméstica, pontes de contêineres, redes de máquinas virtuais e qualquer outra VPN. Uma rota precisa para o escritório continua a não conseguir dizer-lhe que dispositivo naquele endereço queria quando o mesmo intervalo também existe localmente; a tabela não tem esse conceito. A sobreposição produz sintomas que parecem serviços avariados em vez de erros de encaminhamento, e são difíceis de diagnosticar depois.

Faça com que o responsável que dá suporte instale os prefixos, através da configuração do próprio cliente ou das rotas empurradas pelo servidor, para que uma reconexão os restabeleça em vez de depender de um comando que alguém escreveu uma vez.

Uma rota não é acesso

Encaminhar um prefixo para o túnel não concede acesso aos serviços lá dentro. A porta de ligação tem de permitir o tráfego, o destino tem de o aceitar e tem de existir um caminho de regresso, e cada um pode falhar independentemente da rota. Teste um serviço previsto depois de a rota estar no lugar e confirme então que um recurso não relacionado continua a ser recusado. Uma rota que chega a uma firewall não é o mesmo que uma ligação a funcionar.

Documente a lista de prefixos, a verificação de sobreposição e o responsável em conjunto. Quando um endereço mudar, são esses três que a pessoa seguinte precisa.

O prefixo é um acordo sobre fronteiras. Trate-o assim e a rota deixa de ser um palpite.