Cando IPsec cae, unha ruta de reserva non é unha política de reserva

Un sitio perde o seu túnel, e a táboa de rutas segue mostrando un camiño perfectamente utilizable cara ao destino por internet. Alguén propón conmutar por fallo a ela e chama ao cambio unha corrección de enrutamento. O paquete podería percorrer ese camiño; a pregunta que ninguén fixo é se se lle permite chegar sen protección. Son respostas distintas de táboas distintas, e confundilas é a forma en que unha interrupción se converte en incidente.

Dous resultados que parecen idénticos nunha táboa de rutas

A alcanzabilidade di que un paquete ten onde ir. Unha política de seguridade di que debe ocorrerlle a ese paquete polo camiño, e ambas se aplican con maquinaria distinta. Unha ruta pode existir para un fluxo que a política está obrigada a descartar, e esa combinación non é unha configuración errónea. Separar as dúas preguntas é o que fai que un plan de interrupción sexa revisable.

Así que un camiño de interrupción só é un deseño despois de que alguén decida cal dos resultados permitidos se aplica. Mentres esa decisión non exista, a ruta de reserva é unha tentación e non un plan.

O modelo de política ten tres veredictos, non dous

A arquitectura IPsec separa o tráfico que debe descartarse, o tráfico ao que se permite saltar a protección e o tráfico que debe protexerse. Son tres instrucións distintas, e a do medio é unha exención deliberada, non un modo de fallo. Leelas como unha parella é o que produce a falsa elección entre un túnel e unha estrada aberta.

Unha asociación ausente non promove en silencio unha regra de protexer a unha de evitar. A política segue dicindo protexe, así que o paquete espera ou morre, e ese comportamento é o control funcionando tal como está escrito, non proba de que a política estea rota.

Escriba o requisito do seu fluxo como unha de tres frases: detéñase ata que exista un camiño protexido, cambie a outro camiño protexido, ou use un camiño autorizado por separado para funcionar sen IPsec. Só a terceira cambia o contrato de seguridade, e necesita un propietario que poida asinalo. Esa frase vai no rexistro de cambios, non na memoria de ninguén. Os revisores aproban a segunda frase e rexeitan a terceira, e ambas decisións son razoables cando son visibles.

Unha exención é un contrato que asinan ambos extremos

Un camiño alternativo necesita enderezos encamiñables, admisión explícita onde chega e un camiño de resposta que funcione en ambos sentidos. Os enderezos privados do sitio non se volven alcanzables porque unha ruta por defecto apunte a algún sitio.

A autenticación importa tanto como o enderezamento. O tráfico que salta o túnel e chega a un límite que espera protección é rexeitado mesmo cando aterra na interface correcta, así que a política de recepción ten que aceptar esa forma a propósito. Unha exención coa que o extremo remoto nunca estivo de acordo é unha interrupción con pasos extra.

Quitar un selector ou afrouxar un mapa para que funcione a reserva non é unha exención controlada. Amplía o que está exento, deixa ao extremo remoto aplicando algo distinto e pode cambiar que regra de tradución coincide co fluxo.

A tradución e a admisión cambian a aritmética

A tradución pode presentar outra vista de enderezos, pero os mapas directo e inverso teñen que concordar co camiño alternativo. Un mapa unidireccional produce unha conexión que se abre e despois se colga. Medio mapa é peor que ningún, porque parece progreso.

A admisión é a segunda metade. O lado receptor debe ter unha regra explícita para este tráfico, o seu propio rexistro e unha forma de distinguir ás tres da madrugada unha exención aprobada dun erro.

A restauración forma parte do deseño

Rexiste como se detecta o fallo, que política escolle o substituto e que ocorre coas sesións que estaban en curso cando sucedeu. Unha conexión nova pode ter éxito tras a conmutación mentres unha máis antiga conserva estado atado a un enderezo que xa non se aplica.

Prefera outro camiño protexido sempre que o requisito sexa protección continua. Onde unha excepción sen protección sexa realmente necesaria, acótea con orixes, destinos, servizos e unha duración, e anota como se retira.

Probe ambos estados, non só a interrupción

A aceptación cobre o caso do túnel fallido e o restaurado, cunha comprobación de aplicación en cada un. O resultado interesante non é que os paquetes seguisen movéndose, senón que se moveron só baixo o contrato que a organización escolleu.

Engada tamén a proba de retirada. Unha excepción que ninguén pode desactivar converteuse en silencio en política permanente, que é exactamente contra o que protexía a regra orixinal. Póñalle unha data de caducidade e un revisor nomeado, ou a exención sobrevivirá a todos os que a entenderon.