Como manter lexible un plan de enderezos IPv6 para VPN un ano despois
Un plan lexible di que prefixo pertence a que sitio e como volven as respostas. Anota os roles, a notación, a delegación e as rutas de retorno xunto a cada entrada.
Dúas preguntas deciden se un plan de enderezos merece o seu sitio: que prefixo pertence a que sitio e como unha resposta sae dese sitio. Responde a ambas dunha vez e un mantedor pode cambiar un par sen interrogar a ninguén. Todo o demais no documento existe para soster esas dúas respostas. O que non sostiña ningunha das dúas é decoración.
O que un lector ten que responder antes de tocar un par
A compresión fai que os enderezos parezan ordenados, e a orde non é estrutura. Estrutura é saber que rango delegou o provedor, cal escolliches, cal é unha bolsa de clientes e cal está detrás dun sitio.
Escribe para o colega que se incorpora o próximo trimestre e ten que engadir un segundo sitio. Nada na páxina dille de onde vén un prefixo a non ser que a entrada o faga. Omíteo e o primeiro cambio convértese en arqueoloxía.
O que cada liña do plan ten que levar
Catro campos fan que unha entrada sexa revisable: a lonxitude do prefixo, quen o posúe, a onde vai o tráfico despois e que compoñente reparte o valor. Contrastaos coa configuración en execución e calquera desacordo xorde por si mesmo. Un próximo salto dirixido a un túnel retirado o mes pasado parece incorrecto de inmediato en vez de fundirse co resto.
Mantén os roles en filas separadas aínda que dous deles compartan un prefixo hoxe. Fusionalos converte unha separación posterior en algo que se le como unha asignación nova en lugar dunha corrección.
| 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 divergen o texto canónico e a sintaxe de configuración
RFC 5952 fixa unha única forma textual para un enderezo: minúsculas, sen ceros iniciais e a serie máis longa de grupos cero comprimida exactamente unha vez. Úsaa en notas, tíckets e rexistros de cambios para que dous documentos se comparen sen conversión. Os lectores que atopan dúas grafías dun mesmo enderezo comezan a buscar unha diferenza que non existe. A coherencia aquí é barata e elimina toda unha clase de falsas alarmas.
Os ficheiros de configuración obedecen as súas propias regras, e non son as regras de lexibilidade. Un enderezo emparellado cun porto necesita corchetes aínda que o enderezo espido non os necesite, e unha copia dunha nota a un ficheiro de configuración perde esa distinción sen aviso. Nomea a forma que usa cada campo, ou o plan causa o erro de transcrición que debía evitar.
Dúas notacións están ben sempre que cada unha estea etiquetada. É a mestura sen etiquetar a que convida ao erro.
Onde aparecen os rangos solapados e as rutas de retorno ausentes
O solapamento sobrevive a outros erros porque nada parece mal ata que dous sitios responden polo mesmo rango. Etiqueta o sitio e xera prefixos únicos locais mediante o procedemento documentado en vez de copiar un exemplo.
Unha lista de clientes nunca explica en que dirección viaxa a resposta. Anota o camiño de volta da pasarela da LAN xunto ao rango de pares que transporta o túnel, e o rexistro explica unha subrede remota que recibe peticións e queda en silencio. Executa as comprobacións de abaixo na máquina e compáraas coa entrada. Un plan que non concorda con ip -6 route é un plan que a xente deixa de ler.
ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0A alcanzabilidade non é autorización, e un prefixo nunca implica unha política. Escribe o acceso previsto xunto á ruta á que se aplica. Se non, o seguinte lector trata un enderezo do plan como permiso para chegar a todos os servizos que están detrás.
Como sobrevive o plan ao terceiro sitio
Marca cada prefixo como delegado, asignado localmente ou encamiñado doutro xeito. Para todo o que poida moverse, nomea o proceso que o move. Despois lista os rexistros DNS e as regras de devasas que deben cambiar na mesma ventá, porque unha actualización de prefixo que se detén no router está a medias.
Despois dun cambio, chega a un recurso detrás de cada fronteira que o cambio tocou antes de editar o documento. Un plan que describe a rede do mes pasado é peor que ningún, xa que a xente confía nel. Mantén as asignacións retiradas listadas coa data na que desapareceron para que ninguén as volva emitir por accidente. Os segredos quedan fóra do ficheiro; un plan explica a rede, non a abre.
Garda o plan onde se revisan os cambios, xunto á configuración que describe. Un documento que ninguén volve ler podrece máis rápido ca a rede que mapea.