Concentrador e radios ou malla completa: que topoloxía VPN encaixa coas súas sedes

Dúas oficinas sucursais falan entre si todo o día, e o túnel entre elas desvía a ruta por un centro de datos doutra rexión. Cada petición paga ese desvío dúas veces, e ninguén o nota ata que a sincronización de ficheiros comeza a sentirse mal. Aquí é onde comeza de verdade a pregunta da topoloxía: non con que diagrama parece máis resistente, senón con que patrón de tráfico está a pagar. Ambos os deseños funcionan, e fallan de xeitos distintos con custos distintos.

Conte as relacións entre pares antes que nada

Con N sedes, unha malla completa necesita N por N menos un, dividido entre dous, túneles; un concentrador necesita N. Con cinco sedes son dez fronte a cinco, o que aínda soa manexable. Con quince son 105 fronte a quince, e a diferenza xa non é aritmética senón de persoal.

Cada unha desas relacións leva estado do que vostede debe ser dono. En IPsec iso significa unha asociación de seguridade, unha identidade, unha clave ou certificado, detección de par morto e polo menos unha ruta por cada prefixo remoto. En WireGuard significa unha clave pública e un AllowedIPs bloque por par, que sae máis barato por par pero chega sen ningún descubrimento: unha sede nova é un cambio de configuración en cada unha das existentes de todos os xeitos.

Deixe que decida a mestura de tráfico, non o debuxo

Se o tráfico das sucursais son sobre todo peticións a un ERP central ou a un clúster de ficheiros, un concentrador non é un compromiso, é a forma correcta: o tráfico xa quería ir alí, e un só punto de política é máis doado de auditar que unha malla de regras por pares. Unha malla gaña a súa complexidade cando as sucursais intercambian datos entre si — replicación entre dúas oficinas, voz entre sedes, un recurso CAD compartido que unha ducia de enxeñeiros abren todo o día.

Os casos incómodos están no medio, e son a maioría. Mida antes de discutir en lugar de adiviñar a partir dun organigrama.

Lea a táboa como un desempate, non como unha regra. Tres de cada catro filas nunha dirección adoitan resolver o deseño; unha división significa híbrido, que é co que acaban a maioría das redes maduras de todos os xeitos.

Hai que dicirlle ao concentrador que reenvíe

Dous túneles de radio a concentrador que funcionan non crean acceso de radio a radio. O concentrador necesita o reenvío IP activado, unha ruta a cada rede de radio, unha regra de cortafuegos que permita o tránsito e o camiño de volta resolto; cada radio necesita unha ruta para os prefixos da outra sede. Nun concentrador Linux iso é net.ipv4.ip_forward=1 máis FORWARD unha cadea que non descarte o par en silencio, e en IPsec baseado en políticas son selectores de tráfico que listan a subrede de radio remota nos dous extremos. En strongSwan, as notas de reenvío cobren a parte do núcleo e do cortafuegos cando é esa a capa que lle falta. Unha proba barata é enviar tráfico dunha radio a un servizo da outra mentres observa os contadores do concentrador; unha regra que nunca sobe significa que a orde está mal, non a ruta.

A política central tamén é a parte útil. Pódese permitir que as sucursais cheguen a servizos compartidos sen chegar entre elas, e esa matriz de acceso merece escribirse de forma explícita. As rutas que faltan son un mal substituto dunha regra que alguén poida ler.

Ollo coa versión a medias: a radio A encamiña cara á radio B polo concentrador, o concentrador encamiña en ambos os sentidos, e o cortafuegos do concentrador permite conexións novas desde A pero non desde B. A primeira dirección proba ben e a segunda colga, o que parece un fallo de encamiñamento e non o é.

Deseñe o fallo, despois o camiño normal

Un só concentrador é unha dependencia compartida e un colo de botella de tránsito, e a redundancia é onde os deseños con concentrador adoitan saír mal. Dous concentradores significan que cada radio mantén dous túneles, e o camiño de volta ten que concordar co de ida; cando non o fai, un cortafuegos con estado descarta as respostas e o síntoma é unha conexión que se abre e logo morre. Os despregamentos grandes resólveno cun protocolo de encamiñamento sobre os túneles en lugar de prefixos estáticos, que é máis maquinaria pero elimina as conxecturas. Escolla o que escolla, escriba o camiño de volta xunto ao de ida, porque a metade de volta é a que ninguén proba.

Unha malla reparte ese risco: que caia a ligazón dunha sede non illa as demais. Tamén multiplica os lugares onde a selección de camiño pode sorprendelo, e as sesións de aplicación seguen sen sobrevivir a un cambio de camiño sen axuda.

Ningún dos dous deseños mantén viva unha sesión TCP a través dunha conmutación por si só. Se a aplicación non pode reconectar, a topoloxía non é o seu problema.

Escolla por custo de cambio e logo verifique as rutas

Empece polo concentrador, porque é o máis barato no que equivocarse, e engada túneles directos para os pares cuxo tráfico o xustifique. Ese híbrido non é unha falta de decisión; é o deseño ao que a maioría das organizacións converxen nun ano. O importante é que cada enlace directo teña unha razón declarada e un responsable.

Logo verifique os dous debuxos en lugar dun. Para o camiño normal, traceroute desde cada sede ata cada prefixo de servizo e confirme que os saltos coinciden co diagrama. Para o camiño de fallo, apague un túnel e repítao, porque unha ruta que só funciona mentres todo está en marcha non se deseñou, só se configurou.

Garde ambos os debuxos coa matriz de acceso, e revíseos cando se engada unha sede; o custo que xestiona é o custo do próximo cambio, non a elegancia da imaxe actual.