Configurar e verificar BGP na Sophos Firewall

O BGP troca rotas selecionadas entre routers. Numa Sophos Firewall, é especialmente útil com várias localizações, ligações redundantes e VPNs para AWS ou Azure. Para uma única rede de destino com um Next Hop fixo, uma rota estática continua normalmente a ser mais simples.

No exemplo seguinte, duas Sophos Firewalls estabelecem uma sessão eBGP através de uma rede de trânsito. No final, o Neighbor apresenta Established, a Firewall A conhece a LAN atrás da Firewall B e vice-versa.

⚠️ Dynamic Routing deve estar acessível apenas à contraparte prevista. Uma alteração ao Router ID interrompe todas as sessões BGP; uma alteração à Local AS elimina adicionalmente todos os Neighbors e Networks configurados. Ambas pertencem, por isso, a uma janela de manutenção planeada com um backup atual.

BGP em sete passos

Para uma configuração IPv4 simples, são necessários estes passos:

Definir IPs de trânsito, ASN local e remoto e redes a anunciar.
Verificar a acessibilidade IP direta entre os dois peers BGP.
Em Administration > Device access, permitir Dynamic Routing apenas para a zona do peer ou através de uma Local Service ACL Exception restrita; verificar separadamente as regras firewall exigidas pelo design.
Em Routing > BGP, definir Router ID e Local AS.
Adicionar o IP do peer como Neighbor com a Remote AS.
Introduzir em Networks apenas os prefixos locais necessários.
Em Routing > Information > BGP-IPv4, verificar o State Established, a rota aprendida e, em seguida, tráfego real.

O que o BGP decide na firewall

O BGP responde à pergunta sobre que redes são alcançáveis através de que router. Para isso, cada participante precisa de alguns valores claramente distintos:

A Local AS identifica o próprio sistema autónomo. Dois ASN diferentes formam uma ligação eBGP; o mesmo ASN em ambos os lados seria iBGP.
A Remote AS é o ASN da contraparte.
O Router ID identifica o router BGP na topologia BGP. Tem o formato de um endereço IPv4, mas não tem de ser um endereço de interface e deve permanecer único e estável.
Um Neighbor é o endereço IPv4 ou IPv6 da contraparte com a qual se estabelece a sessão BGP. No exemplo, é o IP de trânsito.
Uma Network é um prefixo local que a firewall deve anunciar à contraparte.

O BGP não autoriza tráfego útil nem o encripta. Dynamic Routing em Device Access ou uma Local Service ACL controla o serviço BGP local. O tráfego por rotas aprendidas exige ainda regras firewall, caminho de retorno e uma configuração NAT deliberada.

Para routing dinâmico dentro de um domínio de routing interno contínuo, OSPF é muitas vezes mais natural. O BGP é mais adequado entre sistemas autónomos diferentes, para fornecedores cloud ou quando as rotas precisam de ser influenciadas seletivamente por políticas.

Planear a topologia de exemplo

O exemplo utiliza duas localizações:

Firewall A: Local AS 65010, Router ID 192.0.2.10, IP de trânsito 198.51.100.1/30, LAN 10.10.10.0/24
Firewall B: Local AS 65020, Router ID 192.0.2.20, IP de trânsito 198.51.100.2/30, LAN 10.20.20.0/24
Rede de trânsito: 198.51.100.0/30

Os intervalos 192.0.2.0/24 e 198.51.100.0/24 são redes de documentação. Devem ser substituídos pelos valores reais do ambiente. Os dois ASN privados são adequados para um exemplo interno; numa ligação a AWS, Azure ou a um fornecedor, utilizam-se os valores de ASN e peer definidos pela contraparte.

O Router ID deve ser escolhido conscientemente, ser único e estável. Com Automatic, o SFOS utiliza o IP de interface mais elevado. Se este mudar mais tarde, a identidade do router também pode mudar inesperadamente. Um valor manual evita esta dependência.

Preparar o BGP com segurança

Antes da configuração, devem estar cumpridos os seguintes pontos:

A firewall funciona em Gateway Mode. O BGP não está disponível em Transparent Mode.
Ambos os IPs de trânsito alcançam-se diretamente. Num túnel XFRM, a interface de túnel também deve estar up.
Local AS, Remote AS, IPs dos peers e prefixos permitidos estão coordenados com a contraparte.
A tabela de routing local e as Networks planeadas estão documentadas, para que cada anúncio possa ser verificado de forma seletiva após a configuração.
Estão disponíveis um backup de configuração atual e um acesso de management independente.
Foram planeadas regras firewall e caminhos de retorno para o tráfego útil posterior.

Os fundamentos da interface de trânsito e da zona são explicados em Configurar zonas e interfaces da Sophos Firewall. Antes de uma alteração num ambiente de routing produtivo, também deve estar disponível fora da appliance um backup atual da firewall.

Autorizar Dynamic Routing de forma seletiva

Em Administration > Device access, Dynamic Routing está desativado por predefinição para todas as zonas. Numa rede própria utilizada exclusivamente como trânsito, o serviço pode ser ativado na respetiva zona.

Se a interface do peer partilhar a sua zona LAN ou WAN com outras redes, uma Local Service ACL Exception para o IP concreto do peer ou para a rede de trânsito restrita é mais segura do que a autorização ampla da zona. Em Administration > Device access > Local service ACL exception rule > Add, cria-se uma regra Accept com IP version, Source zone, Source networks and hosts, Destination hosts, o serviço Dynamic Routing e a Rule position adequada. Depois, testa-se o acesso a partir do IP do peer permitido e de uma origem não permitida.

A ajuda do BGP da Sophos exige adicionalmente regras firewall para o tráfego BGP de entrada e saída. Ao mesmo tempo, a ajuda de Device Access afirma que os serviços locais não são controlados por regras firewall. Estas indicações não são inequivocamente coincidentes. Devem, por isso, ser considerados separadamente a Local Service ACL para o serviço BGP local, as regras exigidas pelo design específico do túnel ou do fornecedor e as regras normais para o tráfego útil encaminhado. Daqui não se pode deduzir uma regra Any-to-Any genérica para TCP 179. Proteger o acesso ao dispositivo na Sophos Firewall explica a camada de acesso local com mais pormenor.

Configurar BGP no WebAdmin

Os passos seguintes são executados em ambas as firewalls. Apenas se trocam os valores locais e remotos.

1. Definir Router ID e Local AS

Em Routing > BGP, introduzir em Global configuration na Firewall A os seguintes valores:

Se já existir uma configuração BGP, o estado atual deve ser documentado antes de aplicar a alteração: um Router ID alterado reinicia todas as sessões BGP; uma Local AS alterada elimina todos os Neighbors e Networks. Estas alterações só são aplicadas numa janela de manutenção planeada.

Router ID assignment: Manual
Router ID: 192.0.2.10
Local AS: 65010

Na Firewall B também se utiliza Manual, bem como 192.0.2.20 e 65020. Em seguida, aplica-se a configuração global.

A Local AS aceita valores de 1 a 4294967295. Para ambientes internos sem ASN público, a Sophos indica o intervalo privado de 64512 a 65535.

2. Adicionar a contraparte como Neighbor

Em Routing > BGP > Neighbors, selecionar Add e introduzir na Firewall A:

IP version: IPv4
IP address: 198.51.100.2
Remote AS: 65020

A Firewall B utiliza 198.51.100.1 como Neighbor e 65010 como Remote AS. Depois, guardar em cada firewall com Save.

O endereço do Neighbor não é a LAN remota nem o Router ID, mas sim o IP de trânsito diretamente alcançável da contraparte. Se este IP não estiver acessível ou os ASN estiverem trocados, a sessão não consegue alcançar Established.

3. Anunciar a LAN local

Em Routing > BGP > Networks, selecionar Add. A Firewall A anuncia:

IP version: IPv4
IP address: 10.10.10.0
Subnet mask: 255.255.255.0 (/24)

Na Firewall B, introduzem-se em vez disso 10.20.20.0 e 255.255.255.0 (/24).

A entrada Network define o prefixo que o BGP deve anunciar; não substitui a rota local nem uma regra firewall. Depois de guardar, verificar não só a sessão, mas também o prefixo anunciado e o prefixo recebido pela contraparte. Incluir nesta lista apenas os prefixos efetivamente necessários.

Compreender Neighbors e redes IPv6

O SFOS também suporta IPv6 em Neighbors e Networks. O exemplo anterior permanece deliberadamente em IPv4; para IPv6, introduzem-se separadamente a versão IP, um endereço IPv6 diretamente alcançável do peer e o prefixo IPv6.

O WebAdmin adiciona automaticamente a separação necessária. Numa configuração apenas por CLI, os defaults são assimétricos: Networks IPv4 ficam inicialmente ativos para todos os Neighbors, incluindo IPv6. Networks IPv6 não ficam ativos para qualquer Neighbor. Para um Neighbor IPv6, definir explicitamente:

address-family ipv4 unicast
no neighbor <ipv6-neighbor> activate
exit
address-family ipv6 unicast
neighbor <ipv6-neighbor> activate

Para reproduzir os defaults WebAdmin na CLI, a Sophos indica também no bgp ebgp-requires-policy e bgp log-neighbor-changes. show running-config só apresenta valores diferentes dos defaults; um Router ID automático e, por exemplo, maximum-paths ibgp 16 podem não aparecer. Validar IPv4 e IPv6 separadamente em Routing > Information > BGP-IPv4 e BGP-IPv6, com regras IPv6 e caminhos de retorno próprios.

Verificar e validar o BGP

Uma sessão estabelecida não confirma por si só um fluxo de pacotes funcional. A validação é, por isso, feita em vários níveis:

Em Routing > Information > BGP-IPv4 > Neighbors, a contraparte deve aparecer com o State Established.
Em Routes, a Firewall A deve receber o prefixo 10.20.20.0/24; a Firewall B deve receber 10.10.10.0/24.
Em Summary, verificam-se a sessão e o número de prefixos recebidos.
Em Diagnostics > Tools > Route lookup, verifica-se na Firewall A, por exemplo, o destino 10.20.20.10.
Depois, testa-se um serviço real entre um host de cada LAN. Log Viewer e Packet Capture devem mostrar a regra esperada, a interface de trânsito correta e o tráfego de retorno.

Um Neighbor com Established prova apenas que a troca BGP funciona. Só a rota aprendida, o Route Lookup correto e uma ligação real confirmam toda a configuração. Para verificar o fluxo de pacotes, é útil testar uma regra da Sophos Firewall com Log Viewer e Packet Capture.

O mesmo exemplo através da CLI

Como alternativa ao WebAdmin, a mesma configuração base pode ser introduzida na CLI de routing depois da ligação SSH. Não executar os comandos seguintes num ambiente de exemplo já configurado. Guardar o estado atual antes das alterações; mudar o ASN elimina Neighbors e Networks e exige um backup e uma janela de manutenção. O acesso depende da versão SFOS.

SFOS 22: o caminho de menu seguinte abre bgp>. Só este acesso começa com enable:

3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP

Na Firewall A sem ASN ainda atribuído:

enable
configure terminal
router bgp 65010

SFOS 23: 3. Route Configuration > 1. Configure Unicast Routing abre diretamente router#; nem a terceira opção do menu nem enable fazem parte deste acesso. Para a primeira atribuição do ASN na Firewall A:

configure terminal
router bgp 65010

Se o ASN já estiver atribuído no SFOS 23, utilizar antes router bgp sem ASN depois de configure terminal para selecionar a configuração existente. router bgp 65010 destina-se à primeira atribuição ou a uma alteração planeada do ASN, não a uma reatribuição sem controlo.

Depois de exatamente uma destas sequências de acesso, continuar no modo de configuração BGP:

no bgp ebgp-requires-policy
bgp log-neighbor-changes
bgp router-id 192.0.2.10
neighbor 198.51.100.2 remote-as 65020
address-family ipv4 unicast
network 10.10.10.0/24
exit
end
show running-config
write

Na Firewall B, Local AS, Router ID, Neighbor, Remote AS e Network são substituídos respetivamente por 65020, 192.0.2.20, 198.51.100.1, 65010 e 10.20.20.0/24.

show running-config serve para controlo. write guarda permanentemente a configuração CLI, torna as entradas visíveis no WebAdmin e conserva-as depois de um reinício. Sem write, a alteração não fica completamente concluída.

end sai do modo de configuração antes destes dois comandos. Para o SFOS 23, a Sophos documenta a confirmação de gravação esperada Integrated configuration saved to /conf/routing/frr.conf; não é uma saída observada aqui numa appliance. Comparar depois a configuração e as entradas WebAdmin com os valores pretendidos.

A verificação adicional oficialmente documentada é:

show ip bgp

Mostra os prefixos BGP conhecidos e as respetivas informações de caminho. O estado do Neighbor e Summary são verificados de forma fiável em Routing > Information > BGP-IPv4.

⚠️ Não misturar sem controlo configuração CLI avançada e WebAdmin. Editar um Neighbor no WebAdmin pode remover valores CLI adicionais, como uma palavra-passe do Neighbor ou uma Route Map. Assim que se utilizem estas definições, deve guardar-se primeiro show running-config e continuar a gerir a configuração BGP através da CLI.

SFOS 23.0: BFD experimental para BGP

O Bidirectional Forwarding Detection (BFD) monitoriza a acessibilidade de um Neighbor BGP através de pacotes de controlo próprios. Assim, a firewall pode detetar uma falha mais cedo do que apenas com os temporizadores BGP. Este procedimento opcional não faz parte da configuração base de BGP apresentada anteriormente e não se aplica a versões anteriores do SFOS.

⚠️ No SFOS 23.0, o BFD é experimental. A utilização documentada diz respeito ao BGP em implementações Standalone; isto não implica aprovação para clusters HA ou outros protocolos de routing. Para outros protocolos, é necessário envolver o Sophos Support. A Avanet recomenda começar por um ambiente de teste isolado. O BFD não deve ser ativado em produção sem um procedimento de reversão confirmado para o build instalado.

Âmbito e preparação

A Sophos indica Neighbors BGP-IPv4 e BGP-IPv6, bem como Neighbors eBGP, iBGP, eBGP multihop e Route Reflector, como casos de utilização do BFD. O exemplo seguinte mantém o Neighbor IPv4 198.51.100.2 já configurado na Firewall A. Não constitui uma garantia adicional para um serviço Cloud VPN específico ou uma determinada topologia multihop.

Antes de começar, a sessão BGP, os prefixos esperados e o tráfego da aplicação devem funcionar sem BFD. A contraparte deve estar preparada para BFD; os endereços dos peers, a acessibilidade e os temporizadores devem ser coordenados com o respetivo administrador. Registar o build SFOS atual e guardar show running-config, o estado do Neighbor e o resultado de Route Lookup; manter disponíveis um backup, uma janela de manutenção e um acesso de management independente. Confirmar previamente com o Sophos Support, para este build, o procedimento de remoção da associação BFD ao Neighbor, de um perfil de peer adicional e do serviço. A documentação de BFD não fornece comandos completos de remoção ou paragem para este efeito.

Se o Neighbor monitorizado ficar inacessível, a firewall remove imediatamente da tabela de routing todas as rotas aprendidas através dele. O tráfego só pode mudar para um caminho alternativo se este existir; caso contrário, as redes afetadas perdem a sua rota. Quando o Neighbor volta a estar disponível, a Sophos descreve a recuperação das rotas e o regresso ao caminho original. Por isso, devem ser verificados tanto a falha como o restabelecimento, incluindo a rota efetivamente selecionada.

Iniciar o serviço e monitorizar o Neighbor

O serviço BFD está desativado por predefinição. Os comandos seguintes alteram o funcionamento do routing; antes de os executar, devem estar disponíveis o estado inicial guardado e o procedimento de reversão confirmado. Aceder pela CLI a 5. Device Management > 3. Advanced shell e iniciar aí o serviço:

service -ds nosync bfdd:start

Depois, na mesma Advanced Shell, utilizar vtysh para aceder à CLI de routing:

vtysh

Na CLI de routing, adicionar a associação BFD ao Neighbor já existente na Firewall A. Router ID, Local AS, Remote AS e Networks permanecem inalterados:

configure terminal
router bgp
neighbor 198.51.100.2 bfd
end
write

Substituir 198.51.100.2 pelo endereço real do Neighbor, não pela sua LAN nem pelo Router ID. Na Firewall B, o endereço correspondente no exemplo é 198.51.100.1. A contraparte é configurada de acordo com a documentação do respetivo produto. Se o Neighbor BGP ainda não existir, concluir primeiro a configuração base de BGP deste artigo; o BFD não a substitui. write guarda a configuração de routing, mas não comprova uma sessão BFD bem-sucedida nem o arranque automático do serviço após um reinício.

Alterar temporizadores apenas quando houver uma necessidade justificada

Para o primeiro teste, a Avanet recomenda os valores predefinidos documentados: Detect multiplier 3, Transmit interval 300 ms e Receive interval 300 ms. Intervalos muito curtos ou um multiplicador sensível podem aumentar a carga de processamento. Estes valores não garantem um tempo fixo de comutação.

Os temporizadores são definidos na configuração BFD, não no comando do Neighbor BGP. Se for necessário um perfil explícito de peer, este bloco na CLI de routing apresenta os valores predefinidos documentados para o mesmo peer do exemplo:

configure terminal
bfd
peer 198.51.100.2
 detect-multiplier 3
 transmit-interval 300
 receive-interval 300
end
write

peer inicia a monitorização do peer com os temporizadores predefinidos; este bloco adicional não é necessário para configurar apenas a associação ao BGP. Para detect-multiplier, a Sophos documenta o intervalo 1–155 e, para ambos os intervalos, 10–4294967 ms. O valor Transmit indica o intervalo mínimo de envio sem jitter; o valor Receive indica o intervalo mínimo de receção esperado. A contraparte calcula o seu tempo de deteção a partir do multiplicador local e do maior valor entre o intervalo de envio local e o intervalo de receção remoto. Por isso, devem ser coordenados ambos os lados, em vez de se escolher apenas o menor valor local possível. Temporizadores adicionais diretamente após neighbor … bfd não constituem sintaxe válida.

Validar em conjunto BFD, rotas e aplicação

Na CLI de routing, estas duas verificações são apenas de leitura:

show bfd peers
show bfd peers brief

Para o peer previsto, espera-se Status: up. A saída detalhada deve apresentar temporizadores locais e remotos adequados, bem como Diagnostics: ok e Remote diagnostics: ok; a vista resumida associa o endereço do peer ao respetivo estado. Em seguida, voltar a verificar a sessão BGP em Routing > Information > BGP-IPv4 ou BGP-IPv6, os prefixos esperados, Route Lookup e tráfego real da aplicação. BFD up, por si só, não confirma a rota BGP correta nem o caminho dos dados.

Realizar um teste de falha apenas num ambiente de teste autorizado ou numa janela de manutenção planeada, sem comprometer o acesso de management independente. Registar previamente os prefixos aprendidos através do Neighbor monitorizado e o caminho alternativo previsto. Durante a falha controlada do peer, as rotas afetadas devem desaparecer e, se existir, a rota alternativa e o tráfego da aplicação devem funcionar. Após o restabelecimento, voltar a verificar BFD up, BGP, os prefixos recuperados, o caminho selecionado e a aplicação. Nenhuma saída de dispositivo nem comutação bem-sucedida é aqui apresentada como já testada.

Diagnosticar erros e reverter a alteração

O peer não aparece ou permanece down: Verificar o arranque do serviço e a associação BFD em show running-config; depois, comparar o endereço real do peer, a acessibilidade e a configuração BFD da contraparte. Utilizar show bfd peers para recolher os diagnósticos locais e remotos, bem como os temporizadores. Não adicionar uma autorização ampla Any-to-Any como solução genérica; se os requisitos de acesso não forem claros, envolver o Sophos Support.
O BFD deixa de funcionar após uma alteração: Alterações a definições associadas, como o endereço de destino ou o Remote Gateway, podem remover as definições BFD. Comparar a configuração com o estado guardado, voltar a configurar BFD para o Neighbor afetado e realizar uma validação completa.
Sessão instável ou aumento da carga após alterar os temporizadores: No mesmo contexto do peer BFD, repor os valores anteriormente documentados e guardar com write. Se o estado inicial utilizava o perfil predefinido, o bloco acima apresenta 3 e 300 ms. Depois, verificar os diagnósticos de ambos os peers, as rotas BGP e o tráfego antes de alterar outros valores.
Reversão completa: Aplicar apenas o plano de reversão previamente confirmado para este build e, em seguida, comparar a configuração BGP sem BFD com o estado inicial guardado. Nem um comando no inventado nem a paragem indiscriminada do serviço substituem esse plano. Remover todo o Neighbor BGP não seria uma reversão BFD equivalente, porque também eliminaria as respetivas rotas. A reversão só está concluída quando a sessão BGP, os prefixos necessários, o acesso de management e a aplicação voltarem ao estado previsto.

Weight, MED e Route Precedence global

A Route Precedence global define a ordem entre as categorias static, sdwan_policyroute e vpn. Deve ser distinguida dos atributos que o BGP utiliza para selecionar os seus próprios caminhos. system route_precedence show apresenta o valor global atual; este só deve ser alterado quando as três categorias concorram efetivamente entre si. Ajustar a prioridade de routing na Sophos Firewall explica todo o processo de verificação e reversão.

Entre diferentes protocolos de routing, um dos fatores de decisão é a Administrative Distance. Dentro do BGP, são avaliados atributos BGP. A Sophos indica, por exemplo, que um Weight mais elevado é preferido; em caminhos de resto comparáveis, é preferido um MED mais baixo.

Isto é especialmente importante quando o mesmo prefixo é disponibilizado através de redistribute ospf e, adicionalmente, aprendido a partir de um BGP Neighbor. A rota redistribuída gerada localmente tem, por predefinição, Weight 32768, enquanto a rota aprendida a partir do Neighbor tem Weight 0. Sem um ajuste deliberado, a rota redistribuída é, por isso, a preferida. Se for necessário preferir o caminho através da contraparte, deve atribuir-se a esse caminho um Weight superior e verificar em seguida a rota resultante.

Usar MED para vários caminhos de entrada

SFOS 23: verificar os nomes previamente. Antes de criar ou reutilizar Access Lists, Prefix Lists ou Route Maps, inventariar os seus nomes em todos os protocolos de routing dinâmico. São guardados num único ficheiro de configuração e os nomes devem ser únicos entre protocolos. Evitar colisões e verificar as associações Neighbor/políticas pretendidas face à configuração atual e à guardada. Este requisito não substitui o plano de reversão MED confirmado para o build instalado exigido abaixo; a configuração MED executável continua suspensa até à confirmação desse plano.

Atualização para SFOS 23.0: A partir desta versão, todos os protocolos de routing dinâmico utilizam uma configuração integrada. Ao atualizar a partir de uma versão anterior, a firewall acrescenta automaticamente prefixos de protocolo aos nomes de Route Maps, Prefix Lists e Access Lists, mas apenas se existir um conflito de nomes. Atualiza também automaticamente todas as referências às configurações cujo nome foi alterado. Isto não significa que todos os objetos sejam renomeados.

Após a atualização, comparar os nomes dos objetos e as referências guardados previamente com o show running-config atual e registar a correspondência entre os nomes antigos e os atuais. Verificar se as associações Neighbor/Route Map pretendidas continuam a apontar para as políticas corretas, incluindo as associações MED existentes. Não repor os nomes antigos sem verificar essa correspondência. Em Routing > Information > BGP-IPv4 > Routes e com show ip bgp na contraparte, verificar se os prefixos de rede esperados estão presentes, se os não permitidos estão ausentes e se o caminho pretendido é selecionado; verificar também o caminho efetivamente utilizado com Route Lookup. Esta verificação não substitui o plano de reversão MED exigido abaixo para o build instalado nem levanta a suspensão da configuração MED.

O Multi-Exit Discriminator (MED) indica a um AS vizinho direto qual de vários caminhos de entrada no AS local deve preferir. Um MED inferior é melhor e o default é 0. Por isso, anuncia-se um valor superior no caminho menos desejado. Por predefinição, MED só é comparado quando o mesmo prefixo é aprendido por vários links do mesmo AS vizinho.

MED não é transitivo. Quando o AS recetor encaminha a rota para outro AS, o valor regressa a 0. O BGP avalia primeiro Weight, Local Preference, rota gerada localmente, comprimento do AS Path e Origin Type. MED só decide se estes atributos forem iguais. Um valor configurado não comprova que o caminho pretendido vence.

A Sophos define o MED através de uma Route Map de saída com um número de sequência fixo e associa-a a um Neighbor específico na IPv4 Address Family. out altera o anúncio enviado a essa contraparte; não impõe diretamente o caminho de saída do tráfego de dados da Sophos Firewall. A página oficial do SFOS 22 documenta a configuração, mas não uma reversão completa. Por esse motivo, a alteração só deve ser aplicada depois de os comandos exatos de remoção terem sido confirmados separadamente para a versão instalada e registados num plano de recuperação juntamente com o show running-config previamente guardado.

Após uma alteração autorizada, show ip bgp no router recetor deve apresentar o MED esperado e o caminho preferido. Numa Sophos Firewall que funcione como contraparte, a rota também está disponível em Routing > Information > BGP-IPv4 > Routes. Sem esta comparação antes e depois, esta secção constitui uma ajuda à decisão, não uma alteração de produção pronta a executar.

BGP através de route-based IPsec e Cloud VPN

O BGP pode funcionar através de uma interface XFRM endereçada de um túnel Site-to-Site IPsec route-based. Para isso, ambas as interfaces XFRM recebem IPs de trânsito adequados. Dynamic Routing é permitido seletivamente para a zona VPN; as regras para o tráfego útil continuam a ser necessárias.

Nas ligações cloud, os valores não são escolhidos livremente:

Para AWS Site-to-Site VPN, os endereços Inside Tunnel, Remote AS e outros valores de túnel provêm da configuração AWS. Ambos os túneis AWS são verificados separadamente.
No Azure VPN Gateway, o IP XFRM local deve corresponder ao IP de peer BGP previsto; o ASN local e o ASN Azure têm de ser diferentes.

Um túnel IPsec verde e um BGP Neighbor com Established são dois pontos de verificação separados. Depois, os prefixos esperados e o tráfego real da aplicação devem funcionar.

Diagnosticar erros sistematicamente

Neighbor permanece em Active ou não aparece

Active não significa que a sessão esteja ativamente funcional. A firewall continua a tentar estabelecer uma ligação BGP. Primeiro, verificar a acessibilidade direta do IP do peer, o estado da interface e do túnel, Local AS, Remote AS e o IP do Neighbor. Depois, confirmar se Dynamic Routing está permitido na zona correta ou através de uma Local Service ACL Exception adequada.

Com XFRM, confirmar também que ambos os endereços do túnel estão corretos e que o túnel IPsec está up. Em implementações cloud e XFRM, também se verificam as regras previstas no respetivo design VPN. Se os respetivos Services forem restritos, devem incluir TCP 179 entre os dois IPs dos peers. Device Access ou a Local Service ACL para o serviço BGP local continua separado destas regras.

Neighbor está Established, mas falta a rede remota

A sessão funciona, mas o prefixo não está a ser anunciado ou aceite. Na firewall emissora, verificar a entrada Network, a respetiva versão IP e máscara, bem como show running-config. Em seguida, confirmar na contraparte, em Routes e Summary, se o prefixo chega ou se é rejeitado por uma política local.

Se, após uma atualização para o SFOS 22, faltar uma rede atrás de um túnel IPsec policy-based, a causa pode ser a dependência anterior de redistribute kernel. A sessão BGP pode continuar em Established; SFOS 22: rotas IPsec e redistribute kernel explica a alteração da versão e o design XFRM route-based de destino.

A rota BGP está visível, mas não é utilizada

Primeiro, utilizar Route Lookup para verificar que rota vence para um IP de destino concreto. Uma rota mais específica tem prioridade sobre um prefixo mais amplo. Quando várias origens concorrem, a Administrative Distance, os atributos BGP e só depois a categoria global de Route Precedence devem ser avaliados separadamente.

A rota está correta, mas o tráfego não funciona

O BGP cumpriu a sua função assim que a rota correta está instalada. Depois disso, os erros encontram-se normalmente na regra firewall, NAT, caminho de retorno ou sistema de destino. Em redes entre localizações com routing normal, muitas vezes não é necessário SNAT, porque ambos os lados devem conhecer os prefixos LAN reais.

Definições avançadas desapareceram após uma edição no WebAdmin

O WebAdmin representa apenas os valores básicos. Se um Neighbor tiver sido guardado no WebAdmin depois de uma configuração CLI avançada, podem ter sido removidos a palavra-passe, a Route Map ou valores predefinidos alterados. Aplicar Global configuration também remove alterações a bgp log-neighbor-changes e no bgp ebgp-requires-policy. Comparar o estado guardado, restaurar os valores através da CLI e guardar com write.

Verificar logs de BGP e routing

A referência de logs do SFOS 22 associa BGP e BGPv6 ao ficheiro bgpd.log. O ficheiro zebra.log diz respeito à instalação de rotas IPv4 e IPv6 dinâmicas no kernel; em IPsec route-based, xfrmi.log corresponde à interface de túnel XFRM. Esta associação permite separar a classe do erro: primeiro a sessão e o anúncio BGP, depois a integração na tabela de routing do sistema e, se necessário, o estado do túnel. Serviços e ficheiros de log da Sophos Firewall explica como aceder aos logs e identifica outros ficheiros. Não são necessários comandos live-shell não documentados para esta validação.

Reverter a alteração com segurança

Antes de remover o BGP, deve existir um caminho alternativo ou uma janela de manutenção para cada rede de destino aprendida. Primeiro removem-se as Networks e os Neighbors afetados; depois, a configuração BGP global só é alterada se não dependerem dela outros peers. Dynamic Routing só pode ser desativado quando a zona já não precisar de outro serviço de routing dinâmico.

No WebAdmin, remover primeiro os anúncios que já não são necessários em Routing > BGP > Networks e, depois, as contrapartes afetadas em Neighbors. Após cada passo, verificar se as rotas alternativas esperadas estão ativas. Manter o Router ID e a Local AS inalterados enquanto outras ligações BGP dependerem deles; uma alteração à Local AS eliminaria todos os Neighbors e Networks restantes.

As páginas gerais de BGP consultadas para SFOS 22 e 23 apresentam uma sintaxe para desligar a configuração de routing BGP. Porém, isto não valida o contexto completo de execução nem uma reversão segura para o build instalado. A sintaxe anómala da fonte não é reproduzida como comando executável nem corrigida silenciosamente; não se deduz uma paragem confirmada do daemon nem a eliminação do processo. Não se recomenda qualquer comando CLI destrutivo. Para reverter políticas CLI avançadas, são necessários os comandos de remoção confirmados para o build instalado e o bloco da configuração anterior previamente guardado.

Em seguida, voltam a verificar-se Routing Information, Route Lookup, acesso de management e tráfego real. Um rollback só está concluído quando não apenas desapareceu a sessão BGP, mas também todas as redes de destino necessárias continuam alcançáveis através do caminho alternativo previsto.