Dous túneles IPsec activos seguen a necesitar un plan de camiño de volta

Abre un terminal nunha estación de traballo dun sitio e conéctate a un servidor do outro. Esa única conversa TCP agora ten que cruzar catro pasarelas en lugar de dúas, e o interesante non é se funciona nun bo día. O interesante é que par de pasarelas escolleu a dirección de ida, que par escolle a resposta e quen mantén o estado do fluxo mentres ocorre. Nada na táboa de rutas decide iso por ti.

Debuxa catro pasarelas antes de debuxar unha ruta

Un deseño dobremente activo con dous cortafuegos VPN independentes por sitio, un par por provedor, dache dous camiños utilizables e tres formas de rompelos. Anota os enderezos antes de configurar nada: o cliente tal como se ve antes e despois de cada pasarela, o servidor igual, o seguinte salto de ida e o seguinte salto de volta.

Esa táboa é o deseño. Todo o que vén despois é unha cuestión de se os dispositivos están de acordo coa táboa.

Como se escolle o camiño de ida

Unha capa de encamiñamento multipath de igual custo distribúe os fluxos entre os seguintes saltos mediante hash de campos da cabeceira, o que RFC 2992 describe en detalle. Esa selección pode ser totalmente sen estado: non necesita ningunha entrada de seguimento de conexións, só un hash estable sobre campos sen cambios. Mantén constantes o conxunto de camiños e as entradas do hash, e cada paquete do fluxo escollerá o mesmo seguinte salto.

A selección por fluxo evita a reordenación que causaría o balanceo paquete a paquete entre enlaces con atrasos distintos. Non promete que un custo de encamiñamento igual signifique unha latencia medida igual, porque non é así. E cando cambia a composición dos camiños, os fluxos remápanse, así que a supervivencia da conexión durante un fallo é un requisito aparte da selección de camiño.

Que necesita de verdade o camiño de volta

Aquí o percorrido deixa de ser simétrico. Un hash de ida estable non che di nada sobre o que fará o sitio remoto coa resposta. Se un cortafuegos independente debe ver as dúas direccións da conexión para manter un estado útil, unha ruta de volta que o evita deixa o tráfico sen coincidir con nada. Dúas caixas con conxuntos de regras parecidos non son estado compartido.

Confirma o comportamento bidireccional implementado ou escribe unha política explícita que manteña coherentes os límites necesarios. Unha suposición aquí descóbrese durante unha caída, por xente que non o está a gozar.

Onde a tradución decide por ti

NAT é a outra panca, e é opcional en vez de obrigatoria. As identidades traducidas específicas do camiño poden dirixir as respostas de volta á pasarela que mantén o estado, o cal é un deseño lexítimo. Tamén engaden mapas, rutas de volta e un propietario dese estado, así que acepta a carga só por un requisito que poidas dicir en voz alta.

Se o requisito é simplemente que ambos camiños leven tráfico e que calquera sobreviva á perda dun provedor, o multipath por fluxo con encamiñamento de volta coherente adoita ser o deseño máis pequeno.

Percorre a aceptación en orde

Proba nesta secuencia e rexistra os enderezos en cada paso: unha conexión nova no camiño A e o seu camiño de resposta, o mesmo no camiño B, despois a perda dun provedor e despois a restauración. Para cada resultado, anota que fluxos establecidos se moveron, cales tiveron que reconectarse e onde foron os fluxos novos despois. Escribe primeiro o valor esperado e logo compárao coa captura. Dous túneles establecidos non demostran nada diso.

O deseño está rematado cando a táboa que escribiches coincide co que mostra a captura, non cando ambos túneles están levantados.