Ligar Sophos Firewall à AWS Site-to-Site VPN

Uma AWS Site-to-Site VPN liga uma rede local atrás da Sophos Firewall a uma AWS VPC ou a um Transit Gateway. Tecnicamente é uma VPN IPsec, mas na operação difere de um túnel Sophos-para-Sophos normal: a AWS cria dois túneis por ligação VPN, usa objetos Customer Gateway e gateway de destino, e o routing depende muito da escolha entre rotas estáticas e BGP.

Este artigo explica a configuração prática com Sophos Firewall e AWS. Complementa o guia geral Configurar uma VPN IPsec site-to-site na Sophos Firewall com os pontos específicos da AWS: dois túneis, vizinhos BGP, route tables, security groups, NACLs e verificações de estado na AWS e na Sophos. Se o túnel já estiver ativo mas o tráfego não passar, consultar Troubleshooting de VPN IPsec na Sophos Firewall.

Quando este artigo se aplica

Este artigo aplica-se quando uma filial, datacenter ou rede local deve ser ligada à AWS através da Sophos Firewall. Abrange AWS Site-to-Site VPN para uma VPC, Virtual Private Gateway ou Transit Gateway. Não aborda a Sophos Firewall como appliance virtual dentro da AWS.

Cenários típicos:

• rede local de servidores para instâncias EC2 numa VPC
• tráfego de backup, monitorização ou gestão para a AWS
• DNS híbrido, AD, jump hosts ou redes administrativas
• migração de VPN estática para routing dinâmico com BGP
• operação redundante com dois túneis AWS

A AWS e a Sophos usam termos diferentes. Na AWS usa-se Customer Gateway, Virtual Private Gateway ou Transit Gateway, Site-to-Site VPN connection, Tunnel Details, Route Tables, Security Groups e Network ACLs. Na Sophos Firewall entram ligações Amazon VPC, perfis IPsec, interfaces XFRM, BGP, rotas e regras firewall.

Planear antes da configuração

A AWS Site-to-Site VPN não deve ser tratada como simples importação de um ficheiro de exemplo descarregado. O ficheiro AWS é útil, mas a validação em produção depende de routing, security groups, NACLs, regras firewall e testes com tráfego real.

Definir redes e gateway de destino

Primeiro é necessário decidir que lado AWS será usado:

• Virtual Private Gateway para uma única VPC clássica.
• Transit Gateway para várias VPC, vários locais ou um desenho de routing maior.
• Cloud WAN ou outras variantes apenas quando a arquitetura AWS o exige explicitamente.

Documentar antes:

• CIDR da AWS VPC, por exemplo 10.60.0.0/16
• subnets AWS e route tables relevantes
• redes locais atrás da Sophos Firewall, por exemplo 172.16.20.0/24
• IP público da Sophos Firewall ou do router upstream
• modo de routing: static ou dynamic BGP
• ASN local e AWS se BGP for usado
• destinos de teste esperados nos dois lados
• opções de túnel planeadas, versão IKE, preshared keys e lifetimes

Redes sobrepostas devem ser corrigidas antes do desenho VPN. NAT sobre IPsec pode funcionar, mas dificulta route tables, security groups, logs e troubleshooting posterior.

Levar os dois túneis a sério

A AWS cria dois túneis por Site-to-Site VPN connection, cada um com um endpoint AWS diferente. Ambos devem ser configurados e verificados na Sophos Firewall. Criar apenas um túnel pode ser cómodo num laboratório, mas em produção desperdiça a redundância AWS.

A expectativa deve ser correta: o caminho de retorno da AWS prefere um túnel conforme o routing e o lado AWS, e pode mudar em caso de falha. Isto não significa que ambos os túneis sejam sempre usados de forma equilibrada. O essencial é que ambos fiquem ativos, que BGP ou rotas estáticas estejam corretos e que o failover seja testado.

Routing estático ou BGP

A AWS Site-to-Site VPN suporta rotas estáticas e routing dinâmico com BGP. BGP é normalmente melhor quando há vários prefixos, crescimento futuro ou Transit Gateway. Rotas estáticas são mais simples, mas cada alteração de rede deve ser mantida manualmente.

Na prática:

• BGP exige valores ASN corretos nos dois lados.
• A Sophos Firewall deve anunciar os prefixos locais pretendidos.
• As route tables AWS devem usar realmente rotas propagadas ou estáticas.
• Security groups e NACLs também devem permitir o tráfego.
• Rotas estáticas e BGP idênticas podem criar prioridades inesperadas.

Preparar a AWS

Os passos seguintes descrevem o fluxo habitual. Os detalhes diferem entre Virtual Private Gateway e Transit Gateway, mas o princípio é o mesmo.

Criar o Customer Gateway

O Customer Gateway descreve o lado Sophos local na AWS.

Preencher:

1. Na consola AWS, ir para VPC > Virtual private network (VPN) > Customer gateways e selecionar Create customer gateway.
2. Definir Name tag, por exemplo cgw-sophos-hq.
3. Se for utilizado BGP, definir BGP ASN exatamente como o ASN local da Sophos. A AWS também mostra este campo para ligações com routing estático, mas o routing estático não estabelece peering BGP.
4. Em IP address, inserir o endereço estático e acessível pela Internet do lado Sophos. Se a firewall estiver atrás de um dispositivo NAT a montante, inserir no AWS Customer Gateway o endereço IP público desse dispositivo NAT, e não o endereço da interface WAN da Sophos que está atrás dele.
5. Opcionalmente indicar em Device um nome claro e selecionar Create customer gateway.

Se a Sophos Firewall estiver atrás de um router ou equipamento do operador, deve estar claro que IP público a AWS vê e se NAT-T funciona corretamente. As opções do AWS Customer Gateway exigem UDP 500 e, quando se utiliza NAT-T, UDP 4500 entre a rede local e os endpoints AWS Site-to-Site VPN. Configurar o dispositivo NAT/firewall a montante para permitir e encaminhar essas portas entre a interface WAN da Sophos e os endereços de ambos os endpoints dos túneis AWS indicados no ficheiro de configuração; consultar as regras de firewall da AWS.

Criar ou selecionar o gateway de destino

Para uma VPC única, normalmente cria-se um Virtual Private Gateway em VPC > Virtual private network (VPN) > Virtual private gateways e associa-se através de Actions > Attach to VPC. Ambientes AWS maiores usam frequentemente um Transit Gateway.

Verificar:

• O gateway está associado à VPC ou Transit Gateway correto.
• O ASN do lado AWS não colide com o ASN Sophos.
• As route tables da VPC ou Transit Gateway estão planeadas.
• As subnets usadas para testes usam a route table correta.

Criar a Site-to-Site VPN connection

Depois, ir para VPC > Virtual private network (VPN) > Site-to-Site VPN connections e selecionar Create VPN connection. O procedimento AWS atual descreve os mesmos recursos e os valores dependentes do desenho.

Pontos importantes:

• Em Target gateway type, selecionar o Virtual Private Gateway ou Transit Gateway planeado.
• Em Customer gateway, escolher Existing e o Customer Gateway criado anteriormente.
• Definir Routing options como Dynamic (requires BGP) ou Static; em Static IP prefixes, inserir apenas os prefixos locais que a AWS deve alcançar pela VPN.
• Rever Tunnel Options de forma consciente, sobretudo IKE version, encryption, integrity, DH/PFS e DPD.
• Documentar preshared keys por túnel ou deixar a AWS gerá-las deliberadamente.

Para encaminhamento dinâmico, a Sophos exige que Local IPv4 Network Cidr e Remote IPv4 Network Cidr na ligação AWS estejam ambos definidos como 0.0.0.0/0, para que o peering BGP possa ser estabelecido. Se já existir um Local AS configurado na firewall, deve ser introduzido exatamente esse ASN no AWS Customer Gateway.

Após a criação, selecionar Download configuration. Para a importação automática Sophos, selecionar Vendor Sophos, Platform Sophos Firewall, Software v19+ e a IKE version efetivamente planeada. O ficheiro é apenas uma configuração de exemplo: algoritmos, grupos DH, certificados e família IP têm de corresponder ao design de produção. Atrás de NAT, antes da importação, introduzir o endereço local da interface WAN da Sophos nos dois blocos tunnel_outside_address do lado do customer gateway. Manter inalterados os endpoints Outside do lado AWS; não substituir indiscriminadamente todos os blocos XML com o mesmo nome. No AWS Customer Gateway, pelo contrário, mantém-se o endereço público do dispositivo NAT a montante. Para rotas estáticas, selecionar Generic e configurar manualmente. Também é possível configurar manualmente BGP dinâmico com o download Generic descrito abaixo; a importação Sophos não é a única via para BGP.

Verificar route tables, security groups e NACLs

Um túnel VPN verde na AWS ainda não significa que uma instância EC2 esteja acessível.

Para validação, verificar:

• A VPC route table tem uma rota para a rede local via Virtual Private Gateway ou Transit Gateway.
• Com Virtual Private Gateway, route propagation está ativa ou a rota está definida estaticamente.
• As route tables do Transit Gateway contêm attachments e propagations corretos.
• O security group da instância de destino permite o tráfego necessário a partir da rede local.
• As Network ACLs permitem ida e volta.
• A firewall do sistema operativo da instância não bloqueia o teste.

Esta parte é frequentemente esquecida, porque Sophos e AWS podem mostrar o túnel ligado embora a instância não responda por causa de security group ou rota de retorno.

Configurar Sophos Firewall

A Sophos oferece dois caminhos práticos para AWS: importação via Site-to-site VPN > Amazon VPC ou configuração manual como ligação IPsec route-based. Em muitos cenários AWS, a importação é o início mais limpo, mas os objetos criados automaticamente devem ser revistos.

Importar a configuração AWS

Em Site-to-site VPN > Amazon VPC, a Sophos Firewall pode importar a ligação com Use AWS security credentials ou Use VPC configuration file. Para o método com credenciais, utiliza-se um utilizador IAM da AWS dedicado com as permissões necessárias para as definições de Site-to-Site VPN; a access key e a secret key são protegidas e rodadas como outros segredos administrativos.

A importação é uma captura do momento. Se as opções do túnel ou outros valores da ligação forem alterados na AWS, é necessário voltar a importar as definições e repetir depois toda a validação. Uma importação anterior não acompanha automaticamente a configuração AWS.

O procedimento seguinte utiliza o ficheiro de configuração AWS descarregado:

Passos:

1. Abrir Sophos Firewall.
2. Ir para Site-to-site VPN > Amazon VPC.
3. Selecionar Use VPC configuration file.
4. Carregar o ficheiro de configuração AWS.
5. Iniciar a importação.
6. Verificar ligações, perfis IPsec, interfaces XFRM e definições BGP criadas.

A importação cria perfis IPsec, definições BGP e interfaces XFRM. Em seguida, adicionam-se os prefixos locais em Routing > BGP > Networks. Em Administration > Device access, IPsec deve estar ativado para WAN e Dynamic Routing para VPN. Estas definições permitem o tráfego de controlo do túnel e do encaminhamento; não substituem uma regra de firewall para o tráfego útil.

Atrás de NAT, verificar em cada uma das duas secções de túnel se tunnel_outside_address do lado do customer gateway contém o endereço WAN local da Sophos. Não alterar os endereços Outside do lado AWS; o endereço NAT público mantém-se como endereço do AWS Customer Gateway. Se a associação não estiver clara, não ativar o ficheiro nem os objetos importados; identificar primeiro inequivocamente o lado do cliente e o lado AWS.

Configurar manualmente dois túneis IPv4 VGW com BGP

Esta alternativa descreve uma ligação IPv4 a um Virtual Private Gateway associado à VPC, com Dynamic (requires BGP). Não é um runbook para IPv6/Transit Gateway/Cloud WAN nem uma afirmação geral de que a AWS não suporta IPv6. São pré-requisitos as permissões AWS, os direitos administrativos locais, endpoints Outside acessíveis, redes sem sobreposição e um procedimento de reversão aprovado. Não ativar simultaneamente a importação e uma configuração manual paralela para as mesmas rotas.

1. Na AWS, na ligação VPN prevista, abrir Download configuration: Vendor Generic, Platform Generic, Software Vendor agnostic, IKE version ikev2. Isto aplica-se expressamente também a BGP dinâmico manual. O ficheiro contém PSKs: guardá-lo encriptado e com acesso restrito.
2. Para cada túnel, registar separadamente o endpoint Outside, PSK, CIDR Inside, endereço Inside do cliente, endereço Inside AWS e ASNs da configuração efetivamente gerada. Utilizar duas redes /30 diferentes aceites pela AWS, de 169.254.0.0/16; não utilizar intervalos reservados ou já em uso. O mapeamento seguinte é um exemplo de planeamento legível, não uma atribuição pela AWS:

Tabela de mapeamento: o IP Outside estabelece IPsec; o IP Inside endereça XFRM e BGP. Utilizar exclusivamente os endereços efetivamente fornecidos pela AWS: não deduzir a própria atribuição a partir da ordem dos endereços de demonstração. O endereço XFRM SFOS é o endereço Inside do cliente, nunca o endereço Inside AWS nem o IP público. O neighbor BGP é o endereço Inside AWS, não o endpoint Outside.

3. Em Profiles > IPsec profiles > Add, criar um perfil personalizado com um nome inequívoco. Um exemplo de âmbito limitado para túneis configurados desta forma em ambos os lados é IKEv2, fase 1 AES256 / SHA2 256 / DH 14 (DH2048) e fase 2 AES256 / SHA2 256 / PFS 14 (DH2048). Ativar Re-key connection; utilizar Key negotiation tries 0 e Use strict profile desativado apenas se o plano operacional aprovado o prever. Os algoritmos e grupos DH/PFS selecionados têm de formar uma proposta comum permitida, não basta terem o mesmo nome de perfil.
4. Documentar separadamente lifetimes e Rekey/DPD. Um exemplo histórico indica fase 1 AWS 28800 segundos, mas SFOS Key life 28000; fase 2 3600 em ambos, Rekey Margin 360 e Fuzz 50 por cento. Temporizadores locais de rekey IKEv2 diferentes não constituem automaticamente um erro de proposta nem prova de interoperabilidade testada. Não adotar silenciosamente um temporizador contraditório como padrão universal: utilizar os valores AWS efetivamente configurados e um plano de rekey SFOS aprovado para esses valores; se as condições não estiverem claras, parar e esclarecer. Um exemplo DPD é AWS Restart e SFOS com DPD ativado, intervalo de verificação 30, tempo de espera de resposta 120 segundos e Re-initiate. Estes valores são um exemplo de perfil a verificar, não uma prescrição universal. Antes da operação em produção, confirmar o comportamento de Rekey/DPD na própria janela de alteração.
5. Em Site-to-site VPN > IPsec > Add, criar uma ligação própria para cada túnel com Connection type Route-based (Tunnel interface), IP version IPv4 e Gateway type Initiate the connection. Em Profile, selecionar o perfil personalizado acabado de verificar, não outro perfil predefinido chamado IKEv2 sem o verificar. Definir Authentication type como Preshared key e introduzir exatamente o PSK desse túnel. Listening interface é a interface WAN local; Gateway address é o respetivo endpoint Outside AWS. Definir os IDs IKE local/remoto apenas de acordo com o plano de identidades efetivamente esperado, nunca utilizar IPs aleatórios; atrás de NAT, o endereço WAN local não equivale ao endereço público do Customer Gateway. Selecionar Activate on save apenas na janela aprovada, após a verificação; guardar e ativar ambas as ligações.
6. Em Network > Interfaces, abrir o XFRM correspondente a cada ligação e verificar a associação à ligação. Em IPv4/netmask, introduzir o IP Inside do cliente e /30 (255.255.255.252) desse túnel. No segundo XFRM, utilizar o respetivo IP Inside; não trocar os mapeamentos.
7. Em Routing > BGP > Global configuration, manter o Local AS já utilizado ou definir o ASN do Customer Gateway aprovado. Utilizar uma Router ID única e estável do próprio plano. Não substituir um ASN global existente para esta VPN; a AWS tem de utilizar o mesmo valor ASN local. Não copiar um intervalo de ASNs ou um ASN de demonstração sem verificação: confirmar primeiro a disponibilidade, a admissibilidade na AWS e a ausência de conflitos. Em Neighbors, criar para cada IP Inside AWS um neighbor IPv4 com Remote AS igual ao ASN real do VGW.
8. Em Routing > BGP > Networks, anunciar apenas os prefixos aprovados e alcançáveis localmente. Em Administration > Device access, permitir IPsec para WAN e Dynamic Routing para VPN; não acrescentar uma permissão LAN indiscriminada se não estiver previsto aí um peer de routing local. Abrir BGP TCP 179 como tráfego de dados a todo o mundo ou entre todas as redes LAN/VPN não substitui esta permissão do plano de controlo. Criar adicionalmente as regras de dados estritamente limitadas descritas na secção seguinte.
9. Para cada neighbor, em Routing > Information > BGP > Neighbors, verificar Established, bem como os prefixos aprendidos e anunciados esperados. Na AWS, em Tunnel Details, verificar ambos os túneis UP e as rotas BGP; verificar a propagação de rotas do VGW nas Route Tables das subnets afetadas. Só depois testar tráfego de aplicação autorizado e uma origem não autorizada. Na janela acordada, desativar um túnel de forma controlada, verificar a manutenção da rota/aplicação esperada através do outro, voltar a ativá-lo e verificar novamente ambas as relações de vizinhança; sem um teste real de failover, não declarar a redundância aceite.

Em caso de erros IPsec, verificar primeiro, por túnel, endpoint, PSK, propostas, IDs e NAT-T; em caso de BGP Active, verificar primeiro os endereços Inside XFRM, ASN, ativação do peer e Device Access. Uma rota estática provisória com ping não é uma reparação BGP geral e pode ocultar o percurso incorreto. Se desaparecerem rotas existentes ou o mapeamento de lifetimes/IDs não estiver claro, não experimentar mais valores; parar a nova configuração e compará-la com o estado guardado. Estas instruções têm um âmbito limitado pela documentação e não foram aqui testadas no equipamento.

Verificar perfil IPsec e túneis

Após a importação, ou numa configuração manual, não se deve confiar apenas no estado.

Verificar:

• Existem os dois túneis AWS.
• A versão IKE corresponde à configuração AWS.
• Encryption, Authentication, DH Group e PFS constituem, por túnel, uma proposal permitida por ambos os lados; os lifetimes e os temporizadores locais de rekey são verificados separadamente face ao plano aprovado, e essa verificação não se limita à igualdade numérica.
• A preshared key está correta por túnel.
• Gateway type e remote gateway apontam para os endpoints AWS corretos.
• As interfaces XFRM existem e têm nomes claros.

Se as opções dos túneis AWS forem alteradas, as proposals da Sophos devem continuar a ser compatíveis e os temporizadores de rekey/DPD documentados separadamente devem estar de acordo com o plano operacional aprovado. Alterações unilaterais ao algoritmo, a DH/PFS, à PSK ou à identidade podem impedir a phase 1 ou a phase 2; diferenças entre os lifetimes locais de IKEv2, por si só, não comprovam um erro de proposal deste tipo.

Configurar BGP ou rotas estáticas

Com BGP, verificar em Routing > BGP se ASN local, neighbor, ASN remoto e redes anunciadas estão corretos. A configuração e validação completas são explicadas em Configurar BGP na Sophos Firewall. Em Routing > Information > BGP, Neighbors, Summary e Routes devem mostrar os valores esperados.

Com routing estático, as rotas para redes AWS devem apontar para a interface XFRM correta. A AWS também deve conhecer os prefixos locais, por rotas VPN estáticas ou pela route table adequada.

Nas duas variantes, o routing deve estar correto nos dois sentidos. Um túnel pode estar ligado enquanto o retorno passa pela internet, por um NAT Gateway ou por uma route table errada.

Criar regras firewall

Route-based IPsec não cria automaticamente regras firewall de produção suficientemente precisas. As regras devem ser criadas e registadas de forma consciente.

Recomendado:

1. Em Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule, criar a regra local-para-AWS: Source zones LAN, Source networks and devices o objeto de rede local, Destination zones VPN e Destination networks o objeto de rede AWS.
2. Em Services, selecionar apenas os serviços necessários; usar Any apenas temporariamente para isolar um problema e substituí-lo depois.
3. Permitir ligações iniciadas no sentido inverso, com Source zones VPN e Destination zones LAN, apenas se a AWS tiver de alcançar ativamente sistemas locais.
4. Ativar Log firewall traffic para a validação.
5. Verificar a posição da regra antes de regras drop ou catch-all gerais.

Se a regra esperada não corresponder, consultar Regra Sophos Firewall não corresponde: como encontrar a causa.

Validar a ligação

A validação deve incluir sempre ambas as plataformas e tráfego real da aplicação. Um estado de túnel verde não chega.

Verificar AWS

Na AWS, verificar:

• VPC > Site-to-Site VPN Connections > Tunnel Details mostra ambos os túneis.
• O estado do túnel é UP.
• Com BGP, as rotas são visíveis.
• A route table da VPC ou Transit Gateway contém as rotas esperadas.
• Security groups e NACLs permitem o teste.
• Métricas CloudWatch ou VPN logs não mostram problemas IKE ou DPD repetidos.

Verificar Sophos Firewall

Na Sophos Firewall, verificar:

• Site-to-site VPN > Amazon VPC ou Site-to-site VPN > IPsec mostra túneis ativos.
• Routing > Information > BGP mostra vizinhos e rotas aprendidas quando BGP é usado.
• Network > Interfaces mostra interfaces XFRM.
• Log Viewer mostra a regra firewall esperada.
• Packet Capture confirma interface de entrada e saída quando os logs não chegam.

Escolher bem o tráfego de teste

Um teste deve usar host de origem, host de destino e serviço concretos, por exemplo ICMP, RDP, SSH, HTTPS ou DNS. Se ICMP estiver bloqueado, ping não é significativo. É melhor testar o serviço que será realmente usado.

Erros típicos

Erros de AWS VPN parecem muitas vezes problemas IPsec, mesmo quando a causa é routing ou controlos de segurança AWS. Os seguintes casos são especialmente comuns.

Só um túnel está ativo

Um túnel basta para um primeiro teste, mas não para operação correta. Os dois túneis AWS têm endpoints e parâmetros próprios. Verificar por túnel preshared key, parâmetros IKE/IPsec, interface XFRM, neighbor BGP e estado AWS.

BGP não estabelece

Se o túnel está ligado mas BGP não faz peering, verificam-se primeiro ASN, IP do neighbor, anúncios locais e endereços inside tunnel. Existe um caso Sophos bem delimitado quando o túnel AWS VPC está ativo e ligado na firewall, o neighbor BGP permanece em Active, a AWS mostra a VPN como down enquanto o IPsec está up e a configuração BGP ativa contém no bgp default ipv4-unicast.

Só quando todas estas características coincidem se registam a configuração BGP atual, o Local AS e o IP do neighbor. Em seguida, abre-se a consola BGP através de 3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP e ativa-se exatamente o neighbor AWS afetado:

enable
conf t
router bgp <as-number>
neighbor <ip-address> activate
write

<as-number> é substituído pelo ASN local da Sophos e <ip-address> pelo endereço inside tunnel do neighbor AWS afetado. Em seguida, voltam a verificar-se o resumo BGP, os prefixos aprendidos e anunciados, o estado do túnel AWS e o tráfego real. Se no bgp default ipv4-unicast não existir ou os endereços e ASN da AWS não coincidirem, estes comandos não são aplicados. O comando provém do procedimento SFOS 22 limitado a problemas de ligações Amazon VPC e não é uma reparação BGP geral.

Antes de conf t, documentar a configuração BGP atual e o método de recuperação aprovado para o ambiente. Se o neighbor não atingir Established ou desaparecerem rotas existentes, não improvisar e usar apenas esse método previamente testado. Se tal método não existir, terminar antes da alteração e escalar para o Sophos Support.

Túnel verde, instância inacessível

A causa está muitas vezes fora de IPsec: route table AWS errada, route propagation em falta, security group, NACL, firewall do sistema operativo, rede de origem errada ou regra Sophos em falta.

O retorno segue o caminho errado

A AWS deve conhecer o retorno para a rede local via VPN. Localmente, o retorno para a AWS VPC deve passar por XFRM ou BGP. Routing assimétrico pode parecer normal no estado do túnel, mas quebrar sessões reais.

MTU ou fragmentação afetam aplicações

AWS Site-to-Site VPN e overhead IPsec podem expor problemas de MTU. Se testes pequenos funcionam, mas transferências maiores ou certas aplicações ficam bloqueadas, verificar MSS/MTU, fragmentação e packet captures.

Operação e revisão

Após a entrada em produção, o túnel deve passar para o processo operacional normal. Isto inclui owner, processo documentado para preshared keys, janela de alteração para parâmetros IPsec, monitorização dos túneis, testes regulares de failover e procedimento claro para alterações AWS ou ISP.

Sempre que CIDR da VPC, routing do Transit Gateway, route tables, security groups, redes locais ou anúncios BGP mudarem, a validação VPN deve ser repetida. Cloud VPN não é um clique único, mas parte da arquitetura de rede.

Reverter seletivamente os novos túneis e rotas

Antes da alteração, guardar o backup, os perfis IPsec e o mapeamento dos túneis, os endereços XFRM, os neighbors/anúncios BGP, as regras firewall e as Route Tables AWS, incluindo a propagação. Em caso de anúncios inesperados, destino incorreto ou interrupção do tráfego existente, retirar primeiro os prefixos recém-introduzidos ou desativar a nova ligação e repor apenas as regras/rotas alteradas no estado seguro documentado. Não eliminar nem repor os neighbors BGP existentes, o ASN global ou gateways/VPC/subnets partilhados. Voltar a verificar as rotas existentes previstas, as aplicações autorizadas e o bloqueio de uma origem não autorizada. Sem um procedimento de reversão aprovado, parar a alteração antes da ativação. Não foi realizado qualquer restauro, failover ou teste de tenant AWS para este artigo.

FAQ