Planear o Sophos Switch como camada de acesso para XGS HA

Os switches Sophos podem formar a camada de acesso à frente de um par Sophos Firewall em HA. O princípio de segurança é simples: a Dedicated HA Link liga diretamente as duas firewalls XGS e permanece separada de todos os caminhos de switching de produção. A LAN, a DMZ e, quando aplicável, a WAN são distribuídas por dois switches para que a falha de um deles não desligue simultaneamente ambos os nós de firewall da mesma rede.

Este runbook abrange o lado do switch e do cabeamento. A escolha real entre Active-Passive e Active-Active, bem como a configuração completa do firewall explica Configurar a alta disponibilidade do Sophos Firewall.

Importante: Dois firewalls por si só não eliminam um switch comum, uma fonte de alimentação comum ou um caminho de provedor comum como causa de falha. Um status HA Active-Passive ou Active-Active confirma apenas o cluster de firewall, não a redundância de toda a camada de acesso.

Arquitetura pretendida e limites de segurança

Um design robusto separa três tipos de tráfego:

1. Dedicated HA Link: conexão física direta entre Primary e Auxiliary. O Heartbeat e a sincronização de configuração, status e sessões são executados em cima disso. Em Active-Active, o link também é usado para distribuição de tráfego interno HA entre Primary e Auxiliary. No entanto, não é uma interface LAN, DMZ ou WAN comum e não está integrada em nenhuma dessas redes de produção.
2. Caminhos de produção: Conexões de cada nó do firewall para LAN, DMZ e WAN. Ambos os nós devem ser capazes de alcançar as mesmas redes de produção após uma mudança de função.
3. Caminhos de gerenciamento: Acesso a firewalls e switches para aceitação, solução de problemas e reversão. Pelo menos um acesso independente não deve depender do link exato que está sendo alterado ou testado no momento.

A referência documentada pela Sophos usa dois CS210-48FP para LAN e DMZ. Cada nó do firewall está conectado a um dos dois switches; Uma porta direta transporta LAN e DMZ-VLANs Tagged entre os switches. Um CS110-24FP separado executa o lado WAN dos firewalls e da conexão com a Internet em um Untagged VLAN. O Dedicated HA Link dos firewalls também está conectado diretamente neste exemplo.

Este exemplo não é um plano geral de portas geral. Seus números de porta e IDs VLAN servem apenas para entender as funções:

Os próprios IDs, portas e nomes de interface do VLAN são retirados do plano de rede existente. Você não copia os valores de referência em uma rede produtiva na qual eles já possuem um significado diferente.

O que não torna automaticamente o design de referência redundante

O switch WAN único de referência continua sendo uma zona de falha comum. Se falhar, ambos os nós do firewall perderão esse caminho WAN. Se a camada de comutação WAN também sobreviver a uma falha de dispositivo único, ela precisará de um switch duplo e um design de provedor testados separadamente; O XGS HA não cria essa redundância por si só.

Mesmo dois switches montados um ao lado do outro não são zonas de falha separadas. Para garantir uma separação confiável, verifique pelo menos:

• fonte de alimentação separada ou caminhos de corrente fusíveis separados;
• hardware de switch separado e, sempre que possível, racks ou caminhos de patch separados;
• um nó de firewall por switch em vez de ambos os nós no mesmo switch de acesso;
• Rotas de cabos separadas sem patch compartilhado ou risco de transceptor;
• Acessibilidade das redes de produção através de cada switch individualmente;
• Monitoramento de ambos os switches e ambos os caminhos de firewall;
• responsabilidade documentada por erros de switch, firewall e provedor.

Esta atribuição não é apenas registrada no plano de rede, mas também continua como parte da matriz de metas até o teste e o desmantelamento. Isso significa que permanece visível quais dependências de energia, rack, patch, switch e provedor um caminho específico realmente possui.

VLAN, LAG e STP projetam juntos

A topologia da Camada 2 é totalmente definida antes do cabeamento. Para cada rede, o plano inclui ID VLAN, função Tagged/Untagged, PVID, portas de firewall envolvidas, portas de switch e o caminho esperado após uma falha. A implementação de Tagged, Untagged e PVID está em Configurar Sophos Switch VLANs com segurança.

Mantenha VLANs consistentes em ambos os switches

Na configuração de referência do Sophos, o firewall e as portas de rede para LAN e DMZ são membros de seus respectivos VLANs. A interligação entre os dois switches CS210 carrega VLAN 100 e 200 Tagged. O PVID das portas Untagged corresponde ao respectivo VLAN; Conjuntos Sophos Ingress filtering: On e Accept type: All no exemplo.

As seguintes regras de teste se aplicam ao seu próprio projeto:

• Um VLAN deve ter o mesmo ID VLAN em todas as extremidades do link envolvidas.
• Somente os VLANs Tagged que realmente precisam alcançar ambos os switches são permitidos no interligação.
• Untagged VLAN e PVID de uma porta de acesso devem corresponder.
• O Dedicated HA Link não está incluído em nenhum desses VLANs de produção.
• A gestão VLAN e a rota de retorno permanecem acessíveis durante a mudança.
• A filtragem de entrada só será reforçada após a comprovação da associação VLAN e PVID.

A referência é baseada em porta e Untagged nas interfaces de firewall. Se seu próprio firewall usa subinterfaces ou troncos VLAN, você não deve adotar os valores Untagged/PVID do exemplo. Então, o caminho Tagged no firewall, switch e interligação deve corresponder consistentemente ao seu próprio design de interface.

Não confunda LAG com redundância de chassi

Um LAG agrupa vários links para uma estação remota lógica. Dependendo da distribuição do tráfego, aumenta a capacidade e pode absorver a falha de um membro. Mas isso não prova que uma mudança completa possa falhar.

As duas fontes compartilhadas Sophos não documentam um LAG multichassis em dois switches Sophos independentes para este exemplo XGS-HA. Portanto, um firewall LAG não é simplesmente distribuído para o Switch A e o Switch B com um membro cada. Tal estrutura só é permitida se toda a solução de switch funcionar explicitamente como uma contraparte lógica LAG suportada para o firewall e o design específico for documentado e testado separadamente.

Sem essa prova, interfaces de firewall separadas para switches separados são o limite de planejamento seguro. LACP, LAGs estáticos, ativação e descomissionamento de membros cobertos Configure com segurança as portas do switch Sophos, LAG e Spanning Tree.

Planeje STP na frente de um caminho redundante de Camada 2

Assim que mais de um caminho de camada 2 puder ser criado entre dois switches ou por meio da infraestrutura downstream LAN/DMZ, a topologia sem loop deverá ser estabelecida antes de conectar o cabo adicional. RSTP é adequado para uma topologia compartilhada simples; MSTP apenas para região deaprovadamente consistente e design de instância.

Antes da mudança, as prioridades desejadas do Root Bridge e da ponte, as portas de encaminhamento ou bloqueio esperado e o comportamento em caso de falha e recuperação do interligado são incluídos na matriz de destino. Com MSTP, a atribuição de VLAN à respectiva instância também está incluída. As portas de borda são reservadas para dispositivos finais reais, não para firewall, switch ou conexões de ponte desconhecidas. Uma abordagem de gestão independente é estabelecida no caso de uma má convergência.

Loopback Detection pode ajudar adicionalmente, mas não substitui STP. Um bloqueio da porta STP não é automaticamente uma falha em um caminho redundante planejado.

Prepare-se para a mudança

Antes da primeira alteração, uma matriz de destino é criada para os nós do firewall e para os switches. É o documento de trabalho vinculativo para construção, teste, aceitação e reversão. O exemplo compacto a seguir mostra a estrutura. XGS-A, SW-A, números de porta e VLANs são valores de exemplo realistas, não especificações de produto; Valores divergentes são obtidos de sua própria rede e plano de patch. As informações entre colchetes ainda precisam ser preenchidas e devem ser substituídas por valores ambientais específicos antes da divulgação.

Matriz alvo CHG-[número] — exemplo de status antes da mudança
HA: Active-Passive | XGS-A = Primary/Active | XGS-B = Auxiliary/Passive | sincronicamente
HA dedicado: XGS-A Port7 <-> XGS-B Port7 | diretamente | não faz parte do teste de falha
Rota de gerenciamento/retorno: [caminho de administração separado] | Responsável: [Nome]
STP: RSTP | Raiz: SW-A [Prioridade] | Secundário: SW-B [Prioridade]
Backups/estado anterior: [Armazenamento de Switch/Firewall] | Cronograma de patches: [versão] | Aprovação da reversão: [Nome]

P1 LAN: XGS-A Porta1 <-> SW-A 1/0/47 | VLAN 100 Untagged/PVID 100
não LAG | RSTP Forwarding, não Edge | Monitored Port: sim | Caminho atual A
P2 LAN: XGS-B Porta1 <-> SW-B 1/0/47 | VLAN 100 Untagged/PVID 100
não LAG | RSTP Forwarding, não Edge | Monitored Port: sim | Caminho atual B
Interligação P3: SW-A 1/0/52 <-> SW-B 1/0/52 | VLAN 100,200 Tagged
PVID [de acordo com o conceito nativo local VLAN] | não LAG | RSTP Forwarding
[Complete os caminhos DMZ, WAN e LAG no mesmo padrão; para estação remota lógica LAG
e nomeie todos os membros. Marcar explicitamente zonas de falha WAN/provedor compartilhadas.]

Failover de porta monitorada T1: Pré-requisito XGS-A Primary/Active, XGS-B Auxiliary/Passive,
ambos síncronos; exatamente separar XGS-A Port1/P1.
Expectativa/Caminho: XGS-A não está mais processando tráfego; XGS-B torna-se Active;
O tráfego LAN passa por P2 e SW-B.
Validação: status de ambos os nós, sincronização após retorno, portas de switch/caminho VLAN,
Gateway + [destino interno] + [caminho externo] + [aplicativo crítico], carimbo de data/hora.
Abortar: ambos os nós Active, perda de gerenciamento ou falha de tráfego > [duração aprovada].
Caminho de volta: reconecte P1, aguarde a sincronização, verifique novamente o caminho dos dados;
Só então restaure as funções preferenciais de maneira controlada, sem failback descontrolado.
Falha do switch T2: [Isolar SW-A] | Expectativa/Caminho: Atendimento via XGS-B/SW-B e P2
Validação: [mesmos testes técnicos] | Rescisão: [critério]
Retorno: crie SW-A/links individualmente, espere que STP fique estável e HA seja síncrono.

As linhas P são copiadas para outras redes e uma linha T separada é copiada para cada caso de erro aprovado. Isso significa que a estação remota física, zona, função VLAN/PVID, Tagged/Untagged, status LAG e STP, função Monitored Port, HA e status atual não estão em listas de verificação separadas. O caminho de falha esperado, a validação técnica, o aborto e o caminho de retorno permanecem diretamente ligados à interface testada.

Antes da janela de manutenção, as configurações de switch e firewall referenciadas no cabeçalho, a porta efetiva, o pré-estado VLAN, LAG e STP, bem como o plano de cabos e patches devem estar realmente protegidos e acessíveis por meio do caminho de administração independente especificado. Simplesmente inserir um local de armazenamento não é suficiente.

Um backup do switch não substitui a documentação do status efetivo da Camada 2. A diferença entre Fusion e backup local é explicada em Backup e restauração do Sophos Switch.

Construa camada de acesso de maneira controlada

1. Prepare switches sem loop paralelo

1. Processe as linhas P da matriz de destino uma após a outra: configure VLANs, PVIDs e o switch planejado interligado primeiro e confirme o status real diretamente na mesma linha.
2. Antes de ativar um caminho redundante de Camada 2, ligue o STP e verifique o Root Bridge e as funções da porta.
3. Deixe os cabos adicionais desconectados ou mantenha suas portas desativadas.
4. Esclareça a origem da configuração e os conflitos entre Sophos Fusion e a configuração do switch local.
5. Teste novamente o acesso de gerenciamento após cada alteração.

Na interface web do switch local, a referência Sophos para VLANs usa:

Configure > VLAN settings > 802.1Q

PVID, Ingress filtering e Accept type são editados lá em PVID and ingress filter. Outras etapas da UI e seus limites de segurança permanecem no runbook VLAN vinculado para que duas instruções diferentes não sejam mantidas.

2. Ative exatamente um caminho de produção por rede

Primeiro, apenas o caminho individual claramente planejado é ativado para LAN, DMZ e WAN. Então você verifica:

• Estado do link e velocidade acordada;
• adesão efetiva ao VLAN e PVID;
• Gerenciamento de acesso a switch e firewall;
• Acessibilidade do gateway pretendido;
• Tráfego de teste permitido através do firewall atualmente ativo.

Somente quando este estado for estável um switch interligado adicional, membro LAG ou segundo caminho de rede será ativado individualmente. Após cada cabo, a função STP, a associação LAG e o acesso de gerenciamento são verificados novamente.

3. Conecte Dedicated HA Link diretamente

O Dedicated HA Link é conectado diretamente entre as mesmas portas designadas em ambos os firewalls. Ele não é roteado por meio do interlink do switch produtivo, um LAN-/DMZ-/WAN-VLAN ou um switch de acesso compartilhado. Isso mantém uma falha na topologia da Camada 2 de produção separada da pulsação, da sincronização e do caminho de distribuição interno do HA. No Active-Active, esse link direto também pode distribuir tráfego entre nós para processamento; Isto significa que não se torna uma conexão de rede produtiva comum.

A referência do Sophos configura o firewall no Interactive mode: primeiro o Auxiliary, depois o Primary. Ambos usam a mesma porta de link e senha HA dedicadas. No Primary, o ID do cluster, o endereço do link de peer, os valores Monitored Ports, Peer Administration e Keepalive são definidos. Esses campos de firewall não são adotados cegamente do exemplo de referência; O processo completo e os requisitos podem ser encontrados no artigo vinculado do Firewall HA.

4. Selecione Monitored Ports por domínio de falha

Um Monitored Port destina-se a detectar uma falha de caminho relevante. A alteração de função ou status resultante depende do modo HA e de qual nó ou caminho é afetado. No exemplo do Sophos, o Primary monitora suas portas LAN e DMZ. Somente interfaces críticas permanentemente conectadas são selecionadas para seu próprio ambiente.

Portas não utilizadas, apenas temporariamente ativas ou desconectadas intencionalmente não são úteis. Você acionaria um failover desnecessário. O Dedicated HA Link e o Monitored Port permanecem interfaces diferentes com tarefas diferentes.

Testes de aceitação e falha

Os testes ocorrem em uma janela de manutenção. Antes de cada teste de falha, as alterações em produção em andamento são interrompidas, as funções atuais são anotadas e uma pessoa responsável pelo caminho de retorno imediato é nomeada. Apenas um domínio de falha é alterado por vez.

Cada teste de porta monitorado segue uma linha T aprovada, como T1: modo HA, nó afetado, função configurada, status atual de Active/Passive, interface exata, expectativa e condição de encerramento são reconfirmados imediatamente antes da desconexão. O teste de failover normal Active-Passive desconecta especificamente uma interface monitorada do nó de processamento de tráfego atualmente ativo; o par deve assumir o controle do tráfego. Para Active-Active ou um caminho do nó Auxiliary, uma linha T separada com o comportamento realmente esperado é aprovada em vez de exigir a mudança de função de T1.

Verificar o estado base

Antes de um failover, o estado normal deve estar claro:

• Ambos os switches estão acessíveis e suas portas esperadas estão estáveis.
• As associações VLAN, as interligações PVIDs e Tagged correspondem à matriz de destino.
• LAGs contêm apenas os membros planejados.
• As funções e estados das portas Root Bridge, STP são consistentes com o design.
• Ambos os firewalls mostram o modo programado HA e um estado síncrono.
• Dedicated HA Link e todos os Monitored Ports selecionados estão ativos.
• Teste os clientes alcançando o gateway, os destinos internos permitidos explicitamente e o caminho externo pretendido.
• Trabalhos de administração por pares ou acesso de gerenciamento independente.

Manutenção e testes de erros em ordem segura

1. Desconecte um membro LAG de maneira controlada, se presente. O caminho lógico deve funcionar no membro restante; em seguida, adicione o membro novamente e verifique sua associação.
2. Desconecte o Switch Interlink de maneira controlada. Faça isso somente se o caminho de dados esperado estiver claramente descrito no plano sem ele. Verifique as funções, a acessibilidade do VLAN e a integridade do STP, depois restaure o link e observe a reconvergência.
3. Desconecte o caminho do firewall monitorado especificado na matriz de destino. No Active-Passive, a interface monitorada exata do nó de processamento de tráfego atualmente ativo é usada e é verificado se o peer assume o controle conforme documentado. Os testes de caminho Active-Active e Auxiliary seguem apenas seu estado esperado documentado separadamente. Se houver uma discrepância, interrompa o teste e restaure o caminho. Em seguida, verifique a sincronização, o status de ambos os nós e o mesmo tráfego de teste; não permita que um failback automático prossiga de forma incontrolável.
4. Desconecte ou isole completamente um switch de acesso de maneira controlada. O outro switch, o nó de firewall associado e as redes pretendidas devem entregar o serviço esperado no projeto.
5. Restaure o estado normal preferido de maneira controlada. As funções de switch, links e firewall só podem ser retornadas após uma sincronização estável e um caminho de dados verificado.

O Dedicated HA Link não é desconectado como um teste normal de disponibilidade na rede produtiva em execução. Sua falha pode fazer com que ambos os firewalls não vejam mais o par. Esse teste de split-brain requer um procedimento separado e explicitamente aprovado, com interfaces de produção isoladas. Para aceitação normal é suficiente verificar o status do link, a sincronização do HA e o procedimento documentado para sua falha.

Um teste não é considerado aprovado simplesmente porque o ping continua. Após cada etapa, também são verificados as funções, a sincronização, os estados das portas do switch, o caminho VLAN e os aplicativos críticos para o site. As observações e os carimbos de data/hora vão para o registro operacional; Os tempos de comutação garantidos não podem ser reivindicados sem medição.

Isolar erros por sintoma

HA está verde, mas uma rede não pode ser alcançada após a mudança de função

• Compare o ID VLAN e a associação Tagged/Untagged em ambos os switches.
• Verifique PVID da porta Untagged afetada.
• Verifique se o VLAN está realmente homologado no interligado Tagged.
• Verifique a porta do firewall e o cabeamento físico em relação à matriz de destino.
• Para um LAG, determine se todos os membros levam à contraparte lógica correta.
• Verifique a função da porta STP; um caminho inesperadamente bloqueado ou desabilitado pode impedir a acessibilidade.

O failover ocorre inesperadamente

• Verifique no firewall qual Monitored Port acionou a condição.
• Examine flaps de link, transceptores, cabos e ajuste de velocidade/duplex na porta do switch associada.
• Certifique-se de que nenhuma porta opcional ou desconectada intencionalmente esteja sendo monitorada.
• Verifique o status do LBD e STP antes de reativar uma porta.

Ambos os firewalls não veem mais o par

O Dedicated HA Link é o primeiro limite de teste. Não reconecte cabos produtivos aleatoriamente e não reinicie ambos os nós ao mesmo tempo. Determine qual nó deve continuar o tráfego, desconecte ou desligue o outro da rede de produção de forma controlada e em seguida verifique os cabos, portas e status do link direto HA. Somente após um contato estável entre pares e funções claras o segundo nó será totalmente integrado novamente.

Depois de ativar o segundo caminho, ocorre perda de pacotes ou loop

1. Desconecte o último link adicional ativado de forma controlada.
2. Crie novamente um caminho individual exclusivo.
3. STP Root Bridge, verifique as funções e estados das portas de ambos os switches.
4. Para um tipo LAG e portas membros, compare em ambas as extremidades.
5. Verifique a lista de interligação VLAN e possível conexão Untagged não intencional.
6. Reative apenas exatamente um link adicional após a correção.

Switch não pode mais ser administrado

Use o acesso de gerenciamento independente preparado. Desfaça a última alteração em Management-VLAN, PVID, Uplink, LAG ou STP com base no estado anterior. Não reinicie ambos os switches por precaução: isso pode resultar na perda do caminho de dados que ainda está funcionando.

Reversão

Uma reversão restaura o estado anterior documentado e começa na última redundância adicionada:

1. Pare o tráfego de teste e salve o estado atual de HA, switch e STP.
2. Desconecte o último link adicional ativado, membro LAG ou interligue de maneira controlada até que exista novamente um caminho de produção claro.
3. Retorne funções de firewall somente se o caminho normal pretendido for estável.
4. Desfaça as alterações LAG, STP e VLAN em ambas as extremidades do link na ordem inversa.
5. Restaure as associações Tagged/Untagged anteriores e PVIDs da matriz de destino.
6. Repita o acesso de gerenciamento, sincronização HA e o mesmo teste funcional de antes da mudança.
7. Deixe o Dedicated HA Link conectado diretamente como está, a menos que este link exato seja reparado usando seu próprio procedimento aprovado.

Se o próprio estado anterior tivesse apenas um switch comum ou um único uplink, o desmantelamento restaura deaprovadamente a sua menor disponibilidade. Isto está documentado na conclusão da mudança como um risco remanescente e não é descrito como um sucesso completamente redundante.

Lista de verificação operacional

• Cada linha P da matriz alvo contém o estado real confirmado; Os desvios foram resolvidos ou aprovados como risco remanescente.
• Cada linha T contém resultado, carimbo de data/hora e verificador. Os testes foram executados individualmente, não como uma falha combinada.
• As funções Dedicated HA Link, HA, sincronização, estado STP e acesso de gerenciamento voltaram ao estado normal aprovado.
• A configuração do switch e do firewall, o plano de patches atualizado e o registro dos testes técnicos são salvos no local de armazenamento especificado.
• O caminho de reversão, os responsáveis e as zonas comuns restantes de energia, patch, rack, WAN ou falhas do provedor são registrados na conclusão da mudança.