VPN IPsec dual-WAN no Junos: associar o caminho de origem ao gateway

Dois links WAN por local parecem redundância até você tentar provar qual par de endereços um determinado fluxo realmente usou. Num SRX, um gateway IKE carrega uma interface externa e um endereço local; uma lista de candidatos remotos não cria uma segunda origem local. Por isso este percurso começa pela matriz de pares e não pela configuração, porque o Junos valida sem hesitar um desenho que cobre apenas metade das combinações pretendidas. Aconteceu-me em dois SRX345s: o túnel de backup subiu limpo e mesmo assim derrubou a sessão no retorno.

Percorra os passos por ordem: enumere os pares que precisa de suportar, construa um gateway por origem local, confirme qual associação transportou o tráfego e só depois decida o que cada tipo de falha pode alterar.

Mapear os pares antes de tocar na CLI

Se o local A consegue originar a partir de A1 ou A2 e o local B consegue receber em B1 ou B2, tem quatro pares de endereços externos. A maioria dos desenhos precisa de dois deles de forma contínua e trata os outros dois como opcionais. Anote a matriz e marque cada linha, porque cada linha prometida custa depois um gateway, uma interface de túnel e uma decisão de encaminhamento.

Cada par necessário precisa de três coisas ao mesmo tempo: um underlay alcançável entre esses endereços exatos, aceitação mútua da identidade do par e do endereço de origem nas duas pontas, e um caminho de retorno protegido. Um par que só funciona num sentido continua a mostrar um túnel, e a falha aparece mais tarde como tráfego de aplicação unidirecional.

Um gateway por origem local, não por local remoto

A lista de endereços remotos pertence a um gateway, e a origem local também. A referência de gateways IKE mantém os endereços remotos, a interface externa, o endereço local e a deteção de par morto como definições separadas, e é exatamente esse o ponto: duas origens locais significam dois gateways sobre duas unidades st0. Partilhar a política IKE entre eles é aceitável; manter um único gateway e esperar que ele escolha outra origem sozinho, não.

set security ike policy IKE-P1 mode main
set security ike gateway GW-A1 ike-policy IKE-P1
set security ike gateway GW-A1 address 198.51.100.20
set security ike gateway GW-A1 address 198.51.100.21
set security ike gateway GW-A1 external-interface ge-0/0/0
set security ike gateway GW-A1 local-address 203.0.113.10
set security ike gateway GW-A1 version v2-only
set security ike gateway GW-A2 ike-policy IKE-P1
set security ike gateway GW-A2 address 198.51.100.20
set security ike gateway GW-A2 external-interface ge-0/0/3
set security ike gateway GW-A2 local-address 192.0.2.10
set security ike gateway GW-A2 version v2-only

Depois ligue os túneis e dê ao prefixo remoto dois next hops, um por túnel:

set interfaces st0 unit 1 family inet
set interfaces st0 unit 2 family inet
set security ipsec policy IPSEC-P1 perfect-forward-secrecy keys group14
set security ipsec vpn VPN-A1 bind-interface st0.1
set security ipsec vpn VPN-A1 ike gateway GW-A1 ipsec-policy IPSEC-P1
set security ipsec vpn VPN-A2 bind-interface st0.2
set security ipsec vpn VPN-A2 ike gateway GW-A2 ipsec-policy IPSEC-P1
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.1 preference 10
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.2 preference 20

Se um gateway pode ou não manter duas instruções do tipo address depende da versão e do processo IKE que a máquina executa. Junos mais antigos baseados em kmd aceitam um único endereço remoto por gateway; as compilações recentes lidam com vários candidatos mas acrescentam restrições próprias, e os clusters de alta disponibilidade são um local comum onde esse suporte se estreita. Verifique as notas de versão da sua compilação exata antes de copiar isto de um chassis mais antigo.

Confirmar qual associação transportou o pacote

Duas SAs e dois túneis não dizem qual deles encaminhou a sessão. Pergunte à máquina diretamente e compare os campos com o par que pretendia:

show security ike sa detail
show security ipsec sa detail
show security flow session destination-prefix 10.20.1.0/24
show interfaces st0.1 | match packets

A saída de detalhe indica o gateway local e o remoto de cada associação, o que é a forma mais rápida de detetar um túnel negociado a partir de uma origem que não esperava. Depois observe os contadores de pacotes por unidade em st0.1 e st0.2 enquanto envia tráfego; um túnel que não transporta nada mantém a sua SA e parece saudável numa vista de resumo.

Dar a cada falha o seu próprio detetor

Vivacidade do par, perda do uplink local, retirada da rota protegida e quebra da aplicação são quatro eventos diferentes. O DPD responde apenas ao primeiro, por isso configure-o com um intervalo e um limiar que consiga defender em vez de deixar o valor predefinido e assumir que cobre o resto:

set security ike gateway GW-A1 dead-peer-detection interval 10
set security ike gateway GW-A1 dead-peer-detection threshold 3
set security ipsec vpn VPN-A1 vpn-monitor source-interface st0.1
set security ipsec vpn VPN-A1 vpn-monitor destination-ip 10.20.0.1

A monitorização de túnel que sonda um destino dentro da sub-rede remota cobre o caso que o DPD não vê: o IKE está vivo, o gateway responde e o prefixo protegido continua inalcançável. Escolha qual dos dois deve atrair a preferência, porque se ambos dispararem ao mesmo tempo produz-se uma tempestade de alterações em vez de um failover limpo.

Não se esqueça da ponta remota. Uma rota preferida que fica instalada no local remoto continua a apontar para um túnel que já abandonou, e nenhum temporizador local corrige isso. Publique a mesma lógica de preferência nos dois pares e registe se um link recuperado pode retomar o tráfego automaticamente ou tem de ser comutado à mão.

Readereçar um link sem tocar no outro

Quando um ISP lhe entrega um bloco novo, altere uma relação de cada vez. Atualize address ou local-address nos dois pares para esse par, faça commit, e apague apenas as associações afetadas por índice em vez de apagar todas as SAs da máquina. Um apagamento global leva também o túnel saudável e transforma uma janela de manutenção numa queda.

Guarde um fluxo falhado e o detalhe da sua sessão como prova antes de limpar o que quer que seja, e depois repita as verificações acima contra o novo par de endereços. Restaurar um link é uma decisão de encaminhamento, por isso trate o regresso como um passo testado à parte em vez de assumir que a preferência antiga volta sozinha.

Fechar a alteração com uma lista curta

Um desenho de túnel dual-WAN está terminado quando consegue nomear o par por trás de cada sessão, não quando ambas as SAs estão de pé. Percorra a lista abaixo na máquina que realmente alterou:

• Cada par prometido tem um gateway, uma unidade st0 e uma entrada de rota.
• Cada túnel já foi visto a transportar pacotes, não apenas a manter uma SA.
• Ambas as pontas concordam na deteção e em que lado restaura a preferência.
• O caminho de retorno de cada par está escrito ao lado do seu caminho de ida.

Se uma linha falhar, corrija esse par antes de acrescentar o seguinte; empilhar dois túneis a meio funcionar torna os contadores sem sentido e o comportamento de failover imprevisível.