Planifique os rangos privados de enderezos VPN antes de que os sitios colisionen

Dous sitios que ambos usan 192.168.1.0/24 poden chegar a internet e, aínda así, non chegar un ao outro. A pasarela non xera ningún erro; instala unha ruta para ese prefixo e envía cada paquete ao par que o reclamou primeiro. Nada no handshake, na lista de cifrados nin na métrica da interface di que par está equivocado. A planificación de enderezos é a parte do deseño que resolve isto antes de que ninguén se conecte.

Inventarie cada espazo que deba ser accesible

Anote os rangos que deben encamiñarse, non só os que está a configurar. Iso significa as LAN dos sitios, os grupos de clientes VPN, as subredes na nube, as redes de xestión e fóra de banda, os segmentos de laboratorio e as redes desde as que os usuarios adoitan conectarse na casa. Un router de consumo que se entrega como 192.168.1.0/24 non é hipotético, e o mesmo prefixo aparece en hoteis e recintos de congresos. O inventario é unha táboa de prefixo, propietario e propósito, e é o único artefacto que evita que o mesmo rango se entregue dúas veces.

Engada os prefixos que espera durante o próximo ano, porque un plan que só cobre hoxe falla no primeiro sitio novo. Marque cada fila con quen pode cambiala, non só con quen a posúe.

A reutilización é o que o fai difícil: o espazo privado é finito e cada organización considera 10.0.0.0/8 como seu. Un plan non pode prometer que ningunha LAN de invitados futura caia nun dos seus prefixos, así que o deseño ten que dicir que ocorre cando o fai. Dúas regras fan a maior parte do traballo. Poña os grupos de clientes nun bloque contiguo que poida resumir, e non asigne nunca un rango que outro equipo xa encamiña. Todo o demais é un rexistro que alguén mantén ao día.

Por que unha superposición derrota a táboa de encamiñamento

Unha ruta é un prefixo máis un seguinte salto, e o reenvío elixe o prefixo coincidente máis longo. Cando dous pares reclaman ambos 192.168.1.0/24, a táboa garda unha soa entrada para el, así que o tráfico de ambos os sitios sae polo mesmo túnel. O segundo sitio non está mal configurado; é inalcanzable porque o primeiro responde polos mesmos enderezos. Ningunha métrica pode separalos, porque a coincidencia ocorre antes de consultar as métricas.

O fallo é asimétrico e fácil de malinterpretar. Os hosts do sitio A chegan á pasarela e a algúns servizos, mentres que os do sitio B non responden nada, e o rexistro mostra un túnel san en ambas as direccións. Ese patrón é unha colisión de enderezos e non unha falla de autenticación ou da devasa, e confirmalo require un volcado da táboa comparado co inventario.

Dimensione deliberadamente o grupo de clientes e os rangos dos sitios

Un grupo de clientes VPN é un rango que a pasarela entrega un enderezo á vez, así que o seu tamaño limita a concorrencia. Un /24 alberga 254 enderezos utilizables, o que é xeneroso para un equipo pequeno e axustado para unha sucursal que executa contedores; un /22 non custa nada extra dentro do espazo privado e elimina a discusión. Manteña o grupo contiguo e afastado de cada LAN de sitio, para que a ruta resumida cara aos clientes nunca trabe un sitio. Reserve o rango mesmo mentres o grupo está valeiro, porque un rango sen escribir é o que asignará o seguinte enxeñeiro.

Os sitios reciben rangos dimensionados para os hosts esperados máis o crecemento, aliñados nun límite que se resume limpiamente. Os ocos deliberados entre asignacións non custan nada e compran espazo para agregar máis adiante.

Despois comprobe a dirección que a xente esquece: o camiño de volta. Cada router de sitio necesita unha ruta cara ao grupo de clientes, e o concentrador necesita unha ruta cara a cada prefixo de sitio que serve. Unha táboa de prefixos ordenada sen camiño de volta ao grupo segue sendo un deseño roto, e o síntoma é unha conexión unidireccional que non responde nada. Manteña ambas as direccións na mesma táboa e revísea cada vez que se engada un sitio.

A tradución e a renumeración resolven problemas distintos

Cando xa existe unha superposición, hai dúas opcións honestas e unha deshonesta. A renumeración elimina a colisión de forma permanente e custa unha ventá de mantemento máis cada enderezo codificado que esquecera. A tradución de enderezos asigna o rango privado dun lado a outro rango no bordo do túnel, o que deixa ambos os sitios intactos pero engade estado, rompe protocolos que incrustan enderezos e fai os rexistros máis difíciles de ler. A opción deshonesta é unha ruta de host cara a un só servidor, que pasa unha proba e falla todo o demais.

Elixa por control e vida útil. Un sitio que posúe e pode programar pertence ao camiño da renumeración; unha rede de socio que non pode tocar, usada para unha soa aplicación, é candidata a tradución cunha correspondencia documentada. Escriba esa correspondencia, porque unha tradución que só existe dentro dun ficheiro de configuración desaparece no momento en que o ficheiro se substitúe.

Probe desde o lado remoto antes de despregar

Probe desde unha rede que non aloxe a pasarela, porque a LAN propia da pasarela oculta a maioría dos erros de encamiñamento. Conecte un cliente detrás dun router doméstico corrente e despois chegue a un servizo en cada sitio e a un dentro do grupo de clientes. Probe tamén a dirección inversa, desde un host de sitio ata o cliente, porque os camiños de volta fallan de forma independente. Unha proba que só fai ping á pasarela demostra que o túnel está levantado e nada máis.

Manteña rangos, propietarios e correspondencias de tradución nun único rexistro compartido que o seguinte sitio lea antes de asignar nada. Revíseo cando se engade un sitio e trate un rango non documentado como un defecto e non como unha sorpresa.

O rexistro é a entrega. Un plan que vive na memoria de tres persoas falla a primeira vez que unha delas está de vacacións, e unha superposición atopada en produción custa máis do que tería custado a táboa.