Rutas estáticas ou un protocolo de encamiñamento sobre unha VPN de sitio a sitio?

As dúas opcións transportan paquetes entre sitios, así que a decisión non vai de que protocolo é máis novo, e o tamaño do túnel tampouco a resolve. Resólvena tres condicións: cantos prefixos cambian e con que frecuencia, se o deseño necesita conmutación automática entre camiños, e canta maquinaria de plano de control pode operar o equipo ás tres da mañá. Responda con sinceridade e a elección adoita facerse soa. O resto deste artigo é o que custa cada resposta.

Tres condicións decídeno

A primeira condición é a volatilidade. Un puñado de subredes estables cunha propiedade clara pódese manter a man durante anos, e cada ruta segue sendo unha liña que alguén pode ler e comprobar. Decenas de prefixos que se moven segundo chegan e van os proxectos son outro problema, porque cada movemento ten que chegar a cada dispositivo que aínda lembra o camiño antigo.

A segunda é o comportamento ante fallos. Cando unha ruta de reserva debe activarse sen que ninguén o note, algo ten que detectar o fallo e retirar a ruta. O encamiñamento estático só pode facelo mediante seguimento ou instalación condicional, e só para os fallos que previse.

A terceira é o apetito por un segundo plano de control. Un protocolo de encamiñamento engade sesións, autenticación, filtros e política de selección, e cada un deses elementos necesita monitorización e un proceso de cambio. É un custo operativo permanente, non unha tarefa de configuración puntual.

A táboa baixo o terceiro parágrafo é a versión curta, e as tres seccións que a seguen explican por que cada fila está onde está. Lea as filas contra o seu propio reconto de sitios antes de escoller, porque unha decisión que ignora o custo operativo só é media decisión.

O que custa de verdade o encamiñamento estático

Unha ruta estática ten que ser correcta nos dous lados do túnel. Engadir unha subrede implica editar a pasarela remota, a local e normalmente o camiño de volta, e esquecer calquera delas produce un fallo unidireccional que parece un erro da aplicación. O equipo de aplicacións ve tempos de espera mentres o de rede ve unha ruta que está presente e aparentemente san. Ningún dos dous se equivoca, e por iso este fallo tarda tanto en situarse.

Unha entrada estática tamén segue instalada despois de que desapareza o camiño que ten debaixo. Salvo que a plataforma proporcione seguimento, a ruta segue apuntando a un seguinte salto que xa non reenvía, e o tráfico desaparece en lugar de conmutar. Ese silencio é o gasto que acepta ao escoller a opción simple.

Escriba o método de seguimento xunto a cada ruta, anote que fallos cobre e garde a lista coa configuración do túnel. Doutro xeito, a próxima interrupción descóbrea un usuario e non a rede, que sempre é o descubrimento máis caro.

O que custa de verdade o encamiñamento dinámico

Un protocolo anuncia prefixos novos, retira os inalcanzables e expresa preferencia entre camiños. Iso é realmente útil cando varios sitios ou túneles redundantes necesitarían doutro xeito edicións coordinadas en cada cambio. Tamén é a razón pola que o protocolo pode sorprendelo no peor momento. Cada unha desas accións é un cambio de estado que vostede non fixo persoalmente.

Crea dous estados que poden discrepar. O túnel pode estar arriba mentres a sesión de encamiñamento está abaixo, e a sesión pode estar arriba mentres os seus anuncios omiten a subrede que necesita a aplicación. Ambos parecen unha rede que funciona a medias, e ningún é visible desde unha páxina de estado do túnel.

Por iso os filtros e a política pasan a formar parte do deseño en vez de ser un engadido. Un protocolo que anuncia todo acabará anunciando algo incorrecto, e o prefixo incorrecto viaxa máis rápido que a persoa que pode corrixilo. Escriba os filtros antes de habilitar a primeira sesión, para que o primeiro anuncio xa sexa deliberado.

Controle que pode dicir a sesión de encamiñamento

Decida a lista de prefixos permitidos por par e aplíquea na entrada, porque un filtro de saída non pode impedir que un par lle envíe unha ruta por defecto. As rutas por defecto e os agregados son os erros caros aquí: poden substituír en silencio rutas non relacionadas por unha soa entrada aprendida que parece lexítima. Rexeíteos de forma explícita salvo que o deseño os queira de verdade.

Escriba o sitio propietario xunto a cada rede antes de que suba a primeira sesión, porque ese mapa é a fonte da lista de filtros e non un adorno de documentación. Sen el, quen edita un filtro ten que adiviñar que sitio debería anunciar o prefixo.

A redistribución entre dous protocolos é onde comezan os bucles e onde o mesmo prefixo chega dúas veces con atributos que non se comparan limpiamente. Manteña a redistribución fóra do deseño ata que un requisito concreto a obrigue, e se ten que existir, marque e filtre as rutas na fronteira.

As interfaces de túnel baseadas en rutas facilitan representar o encamiñamento dinámico, porque o túnel pasa a ser unha interface con rutas en lugar dunha política que casa selectores. Iso non elimina a cuestión do alcance do par: os selectores de IPsec aínda teñen que permitir o tráfico que pretende encamiñar.

Probe o camiño do fallo, non o camiño feliz

Escolla o que escolla, baixe unha ligazón ascendente e confirme que o tráfico se move, ou que falla tal como o documentou. Un deseño probado só con ambos camiños sans é un deseño que non se probou en absoluto. Mida a detección mentres está alí, porque o número que mediu é o número que vivirán os usuarios.

Despois confirme o camiño de volta de forma independente, porque o encamiñamento asimétrico sobre unha VPN é habitual e invisible ata que un dispositivo con estado descarta as respostas. Un fluxo que funciona nunha dirección só demostra a metade do camiño.

Orde de traballo: conte os prefixos, decida como deben detectarse os fallos, comprobe quen pode operar o protocolo, controle que se anuncia e logo probe unha interrupción de extremo a extremo. Cada paso produce un feito que o seguinte necesita.