Planifique as subredes antes dunha VPN entre sedes: renumere ou traduza

Dúas oficinas usan ambas 192.168.1.0/24 porque ninguén planificou outra cousa, e espérase que o túnel o resolva. Non pode: un enrutador non pode facer que o mesmo enderezo privado signifique dous lugares distintos. O traballo que o evita ocorre antes de que se escriba o primeiro parámetro do túnel.

Inventaríe cada rango, incluídos os que esqueceu

Reúna as LAN, os segmentos de servidores, os grupos de clientes de acceso remoto, os rangos de VPC na nube e calquera rede de contedores ou superposta á que os equipos deban chegar. Os grupos de clientes son os que a xente esquece, e solápanse cun rango de oficina sorprendentemente a miúdo porque ambos se escolleron do mesmo valor predeterminado. Inclúa a rede de xestión e calquera segmento fóra de banda.

Anote o propietario, a pasarela, o propósito e se o prefixo debe ser alcanzable desde a outra sede. Un prefixo que nunca necesita cruzar o túnel non ten que ser único, e sabelo reduce o traballo de renumeración.

Faga IPv6 por separado, porque o seu plan e os seus solapamentos son independentes.

Compare prefixos, non enderezos familiares

Dúas redes con enderezos de host distintos poden solaparse igualmente, porque o solapamento é unha propiedade das máscaras e non dos números que a xente lembra. 10.20.0.0/16 contén 10.20.30.0/24 o diga alguén en voz alta ou non. Compare pares de prefixos completos e comprobe os agregados contra as redes máis pequenas que hai dentro. Por iso a comprobación pertence a unha folla de cálculo e non á cabeza de ninguén.

A mesma comprobación aplícase ao grupo de clientes da propia VPN e a calquera rango traducido que pense introducir, xa que un rango traducido que colisiona é peor que o solapamento orixinal.

Basta unha táboa de prefixos con máscaras; un diagrama sen máscaras non.

Decida que ten que cruzar de verdade

Unha sede pode conter trinta subredes mentres que unha rede de servizo necesita acceso remoto. Parta dese requisito e anuncie só o que necesita, porque os anuncios máis pequenos e as regras de acceso correspondentes son máis fáciles de revisar e máis difíciles de ampliar por accidente. Anunciar todos os rangos privados en uso é un costume que converte un túnel nunha ponte. Canto máis estreito o anuncio, menor o raio de impacto dun erro futuro.

O DNS privado ten que devolver enderezos que os clientes previstos poidan alcanzar, así que un nome que apunta a un rango non anunciado ou solapado segue roto aínda que a consulta teña éxito.

Escriba a lista de acceso antes da configuración do túnel, non despois de que falla.

Renumere ou traduza, e coñeza o custo

Renumerar unha rede adoita ser o remedio máis claro a longo prazo, e toca reservas, dispositivos, DNS, regras de devasas e todo o que teña un enderezo incrustado nunha configuración. Traducir un rango de acceso é a alternativa cando renumerar non é práctico, e custa a identidade de orixe máis unha clase de protocolos que incrustan enderezos na carga útil. Escolla unha e termínea, porque unha rede a medio renumerar é peor que calquera das dúas opcións.

Escolla o que escolla, documente tanto o enderezo orixinal como o presentado, porque cada conversa posterior de resolución de problemas os necesita.

Unha solución sen camiño de volta non é unha solución.

Use unha matriz de rutas como proba de aceptación

Termine cunha matriz: prefixo local, prefixo remoto, servizo permitido e pasarela de retorno. Esa táboa é a proba de aceptación cando o túnel levanta, e tamén é o documento que lerá o seguinte enxeñeiro. Probe desde equipos reais nas subredes elixidas e non desde as pasarelas.

Un ping entre enderezos do túnel demostra que o túnel existe e nada sobre o plan de enderezos que hai detrás.

Garde a matriz coa configuración do túnel, e a seguinte adición de sede comezará a partir de datos e non de memoria. A guía de reenvío de strongSwan cobre o lado da pasarela unha vez que o plan existe.