Como manter um plano de endereços IPv6 para VPN legível um ano depois
Um plano legível diz qual prefixo pertence a qual site e como as respostas voltam. Anote papéis, notação, delegação e rotas de retorno ao lado de cada entrada.
Duas perguntas decidem se um plano de endereços merece seu lugar: qual prefixo pertence a qual site, e como uma resposta sai desse site. Responda às duas de uma vez e um mantenedor consegue mudar um par sem interrogar ninguém. Todo o resto do documento existe para sustentar essas duas respostas. O que não sustenta nenhuma delas é decoração.
O que um leitor precisa responder antes de tocar em um par
A compressão faz os endereços parecerem arrumados, e a arrumação não é estrutura. Estrutura é saber qual faixa o provedor delegou, qual você escolheu, qual é um pool de clientes e qual fica atrás de um site.
Escreva para o colega que entra no próximo trimestre e precisa adicionar um segundo site. Nada na página diz de onde veio um prefixo, a menos que a entrada faça isso. Pule essa parte e a primeira mudança vira arqueologia.
O que cada linha do plano precisa carregar
Quatro campos tornam uma entrada verificável: o comprimento do prefixo, quem o possui, para onde o tráfego vai em seguida e qual componente distribui o valor. Confronte-os com a configuração em execução e qualquer divergência aparece sozinha. Um próximo salto apontado para um túnel removido no mês passado parece errado na hora, em vez de se misturar ao conjunto.
Mantenha os papéis em linhas separadas mesmo quando dois deles compartilham um prefixo hoje. Juntá-los transforma uma separação posterior em algo que se lê como uma alocação nova, e não como uma correção.
| Entry | Fields to record | Why a reviewer needs it |
|---|---|---|
| Endpoint addresses | Prefix, owning side, session initiator | Firewall rules and peer config both read it |
| Tunnel interfaces | Prefix and length, next hop, interface name | Shows the path a packet actually takes |
| Client allocations | Pool range, size, distributing component | Shows room left before a redesign |
| Downstream networks | Prefix, site label, return route | Explains a reply that never arrives |
Onde o texto canônico e a sintaxe de configuração divergem
RFC 5952 fixa uma única forma textual para um endereço: minúsculas, sem zeros à esquerda e a maior sequência de grupos zero comprimida exatamente uma vez. Use-a em notas, tickets e registros de mudança para que dois documentos se comparem sem conversão. Leitores que encontram duas grafias do mesmo endereço começam a procurar uma diferença que não existe. A consistência aqui é barata e elimina toda uma classe de alarmes falsos.
Os arquivos de configuração obedecem às próprias regras, e não são as regras de legibilidade. Um endereço emparelhado com uma porta exige colchetes mesmo quando o endereço nu não exige, e uma cópia de uma nota para um arquivo de configuração perde essa distinção sem aviso. Nomeie a forma que cada campo usa, ou o plano causa exatamente o erro de transcrição que deveria evitar.
Duas notações estão bem desde que cada uma esteja rotulada. É a mistura sem rótulo que convida ao erro.
Onde faixas sobrepostas e caminhos de retorno ausentes aparecem
A sobreposição sobrevive a outros erros porque nada parece errado até dois sites responderem pela mesma faixa. Rotule o site e gere prefixos únicos locais pelo procedimento documentado em vez de copiar um exemplo.
Uma lista de clientes nunca explica em que direção a resposta viaja. Anote o caminho de volta do gateway da LAN ao lado da faixa de pares que o túnel transporta, e o registro explica uma sub-rede remota que recebe requisições e fica em silêncio. Execute as verificações abaixo na máquina e compare-as com a entrada. Um plano que discorda de ip -6 route é um plano que as pessoas param de ler.
ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0
Alcançabilidade não é autorização, e um prefixo nunca implica uma política. Escreva o acesso pretendido ao lado da rota a que se aplica. Caso contrário, o próximo leitor trata um endereço do plano como permissão para alcançar todos os serviços atrás dele.
Como o plano sobrevive ao terceiro site
Marque cada prefixo como delegado, atribuído localmente ou roteado de outra forma. Para tudo o que pode se mover, nomeie o processo que o move. Depois liste os registros DNS e as regras de firewall que precisam mudar na mesma janela, porque uma atualização de prefixo que para no roteador está pela metade.
Depois de uma mudança, alcance um recurso atrás de cada fronteira que a mudança tocou antes de editar o documento. Um plano que descreve a rede do mês passado é pior do que nenhum, já que as pessoas confiam nele. Mantenha as alocações retiradas na lista com a data em que sumiram para que ninguém as emita de novo por acidente. Segredos ficam fora do arquivo; um plano explica a rede, não a abre.
Guarde o plano onde as mudanças são revisadas, ao lado da configuração que ele descreve. Um documento que ninguém relê apodrece mais rápido do que a rede que ele mapeia.