Sophos Firewall Configurar zonas e interfaces

Zonas e interfaces estão entre os fundamentos mais importantes de uma Sophos Firewall. Se você planejá-los cuidadosamente, tornará muito mais fáceis as regras de firewall, NAT, VPN, proteção da web e solução de problemas posteriores. Se você juntá-los muito rapidamente, muitas vezes você cria um ambiente no qual as regras se tornam confusas ou os serviços de gerenciamento ficam acessíveis nos lugares errados.

Uma Zona é um grupo de segurança lógico. Uma Interface é uma conexão física ou virtual, por exemplo Port1, uma VLAN, uma Bridge, um LAG, um Alias, uma interface RED ou uma interface XFRM para VPN baseada em rota. Cada interface é atribuída a exatamente uma zona. Posteriormente, as regras de firewall funcionarão fortemente com essas zonas, portanto a estrutura da zona não deve ser planejada apenas tecnicamente, mas também em termos de segurança.

Qual artigo de design de rede se encaixa?

Zonas e interfaces costumam ser o ponto de partida, mas nem sempre o objetivo real da configuração. Dependendo da tarefa, um artigo mais específico cabe melhor:

• Planeje basicamente zonas, interfaces, VLANs, pontes, LAG ou RED: Este artigo.
• Configurar interface VLAN com interface pai, DHCP, Device Access e regras: Sophos Firewall Configurar e testar VLAN.
• Crie e entenda regras de firewall entre zonas: Compreender e configurar corretamente as regras Sophos Firewall.
• Verifique o comportamento da ponte VLAN de acordo com SFOS 22: Sophos Firewall Usar ponte com marcação de VLAN.
• Serviços de gerenciamento seguros como WebAdmin, SSH, User Portal ou DNS: Sophos Firewall Acesso seguro: Configure Device Access corretamente.
• Classifique NAT, SNAT, DNAT ou MASQ com interfaces e zonas: Compreendendo o NAT em Sophos Firewall: SNAT, DNAT, MASQ, PAT.
• Publicar servidor interno por WAN ou DMZ: Publicar servidor via DNAT para Sophos Firewall.
• Controle DNS para domínios internos ou zonas AD: Configurar rotas de solicitação de DNS para Sophos Firewall.
• Defina opções de DHCP para VoIP, PXE ou clientes especiais: Configurar opções de DHCP para Sophos Firewall.
• Planejar VPN site a site com interfaces de túnel: Sophos Firewall Configurar VPN IPsec site a site.
• O tráfego não está passando pela zona ou regra esperada: Sophos Firewall A regra não se aplica: Verifique as causas.Esta separação evita erros típicos de projeto. Uma zona não substitui uma regra de firewall, uma VLAN não substitui um conceito de segurança e Device Access não é igual ao tráfego normal entre duas redes. Primeiro, deve ficar claro quais áreas de segurança existem. Interfaces, VLANs, regras, NAT, DNS e acesso de gerenciamento são então construídos de acordo.

Por que as zonas são importantes

As zonas no Sophos Firewall são mais do que apenas um agrupamento visual. Isso define áreas de segurança que são utilizadas em diversos locais:

• As regras de firewall funcionam com Zona de origem e Zona de destino.
• Device Access controla quais serviços de firewall locais são acessíveis por zona.
• NAT, SD-WAN, VPN, proteção web e logs são mais fáceis de entender por meio de zonas limpas.
• A solução de problemas fica mais clara porque você pode ver imediatamente de qual área de segurança um pacote vem e para onde ele deve ir.

Um bom zoneamento não evita automaticamente todos os erros, mas impõe limites claros. Uma rede de cliente, uma rede de servidor, um WiFi convidado e uma DMZ não devem ser tratadas simplesmente como uma “LAN” se tiverem riscos e regras diferentes. Caso contrário, surgirão mais tarde regras de autorização extensas, exceções pouco claras e acesso de gestão desnecessariamente aberto.

Boas zonas sempre respondem a esta pergunta: Quais redes têm o mesmo nível de confiança e podem ser tratadas de forma semelhante? Se duas redes precisam de direitos de acesso, requisitos de registro ou acesso de gerenciamento diferentes, uma zona separada ou pelo menos um conceito de regra muito consciente faz sentido.

É importante separar zona e objeto de rede. A zona descreve por que área de segurança um pacote entra na firewall ou para onde deve seguir. O objeto de rede descreve a origem IP concreta ou o destino concreto. Uma regra só fica limpa quando ambas as coisas estão corretas: Source zone não deve ser apenas um LAN genérico enquanto Source networks and devices permanece em Any. Inversamente, um objeto de rede correto pouco ajuda se o tráfego entrar por uma zona diferente da esperada.

Entenda as zonas padrão

Sophos Firewall vem com diversas zonas padrão:

• LAN: Redes internas, clientes, servidores e redes de gerenciamento.
• WAN: uplinks de Internet, roteadores de provedores, PPPoE, DHCP ou endereços WAN estáticos.
• DMZ: Servidores publicamente acessíveis, proxies reversos e serviços isolados.
• WiFi: Redes Wi-Fi, Sophos Access Points e segmentos wireless.
• VPN: Remote Access VPN, VPN site a site e outros contextos de túnel.

As zonas padrão podem ser encontradas em Network > Zones. Zonas personalizadas podem ser criadas como tipo LAN ou DMZ. Zonas WAN ou VPN adicionais não podem simplesmente ser criadas livremente porque esses tipos de zona têm funções especiais no firewall.

Importante: uma zona não é uma permissão automática. Dependendo da direção e do cenário, também são necessárias regras de firewall apropriadas entre duas interfaces na mesma zona. O tráfego entre duas interfaces de zona LAN não é permitido automaticamente, mas requer uma regra LAN para LAN adequada.

Sophos Firewall suporta zonas próprias, mas não como substituto ilimitado de regras limpas. O limite oficial é de no máximo 100 zonas. Na prática, não se deve esgotar esse limite. Se quase cada VLAN recebe a sua própria zona, embora muitas precisem de regras idênticas e do mesmo Device Access, o conjunto de regras torna-se muitas vezes mais difícil de manter, não mais seguro.

Planeje zonas antes da criação

Antes de configurar, você deve observar quais redes possuem requisitos de segurança diferentes. Exemplos típicos:

• LAN no local de trabalho
• Rede de servidores
• Rede de gerenciamento
• DMZ
• Wi-Fi para hóspedes
• VoIP
• Câmera ou rede IoT
• Rede de produção
• clientes VPN
• MPLS ou conexões de localização

Uma zona separada faz sentido se uma rede precisar de suas próprias regras, de sua própria Device Access ou de outro nível de confiança. No entanto, várias VLANs também podem estar na mesma zona se quiserem ser tratadas igualmente. Muitas zonas não tornam automaticamente uma configuração mais segura. As zonas só são úteis se houver regras claras por trás delas.

Para muitos ambientes de pequeno e médio porte, esta estrutura básica é um bom começo:

• LAN ou Client: clientes normais de estação de trabalho.
• Server: servidores internos, NAS, servidores de aplicativos e controladores de domínio.
• Management: Admin PCs, monitoramento, backup, gerenciamento de switch e firewall.
• Guest ou WiFi: Redes WiFi ou BYOD para convidados com acesso limitado.
• DMZ: Sistemas que devem ser acessíveis pela Internet ou por múltiplas redes.
• WAN: Conexões de Internet e provedor.
• VPN: Remote Access VPN ou contextos VPN site a site.

Nem toda VLAN precisa automaticamente de sua própria zona. Se várias VLANs de cliente obtiverem exatamente as mesmas regras de firewall, política da Web e Device Access, elas poderão permanecer em uma zona de cliente comum. No entanto, se uma VLAN tiver permissão para acessar servidores, outra só tiver permissão para acessar a Internet e uma terceira não tiver acesso aos serviços de firewall locais, a separação deverá ser modelada conscientemente.

Um bom padrão é:

• Outro nível de confiança: Verifique sua própria zona.
• Acesso de gerenciamento próprio ao firewall: verifique sua própria zona ou sua própria regra ACL.
• Outros registros ou outras funções de proteção: a própria zona pode ser útil.
• Apenas faixa de IP diferente, mas mesma política de segurança: o conceito de zona comum pode ser suficiente.

Traduza o modelo de zona em uma matriz de acesso

Após o planejamento da zona, você deve determinar brevemente qual zona tem permissão para conversar com qual outra zona. Essa matriz de acesso costuma ser mais útil do que criar regras imediatamente no WebAdmin porque torna as contradições visíveis.

Um exemplo simples:

• Client a WAN: Permitido para Web, DNS, NTP e aplicativos necessários.
• Client a Server: Somente portas de aplicativos definidas, não Any.
• Guest a WAN: Permitido, principalmente com política da web e registro em log.
• Guest a Server: Normalmente bloqueado.
• IoT a Server: Somente para serviços definidos com precisão, por exemplo MQTT, DNS ou NTP.
• Management a LAN, Server, DMZ: Acesso administrativo, restrito e registrado.
• DMZ a LAN: Bloqueado por padrão, permite apenas conexões de retorno explícitas.
• VPN a Server: Somente metas e serviços internos necessários.

A matriz não precisa ser grande. O importante é que toda direção permitida tenha um propósito. Se uma entrada não puder ser explicada, ela não deverá surgir como uma regra ampla de firewall.

Para cada linha você também deve observar:

-serviços e portas necessários

• se a correspondência de usuário ou grupo é necessária
• se o NAT está envolvido
• se o registro deve permanecer permanentemente ativo
• quais recursos de segurança são adequados, por exemplo IPS, Web Policy ou Application Control
• quem é tecnicamente responsável pelo acesso

As regras reais do firewall são então criadas a partir desta matriz. As opções detalhadas e erros típicos para ordem de regra, origem, destino, NAT e registro estão descritos em Compreender e configurar corretamente as regras Sophos Firewall.

Verificação do planejamento antes das alterações

Antes de zonas ou interfaces serem criadas, movidas ou excluídas, as dependências devem ser esclarecidas por escrito. Muitos erros posteriores não são causados ​​pelo próprio endereço IP, mas por regras de firewall esquecidas, regras NAT, servidores DHCP, Device Access ou decisões de roteamento.

Para cada nova zona ou interface, pelo menos estas perguntas devem ser respondidas:

• Nível de confiança da rede: A zona, regras de firewall e Device Access dependem disso.
• Usuários e sistemas na rede: Clientes, servidores, convidados, IoT, VoIP e gerenciamento precisam de regras diferentes.
• Gateway padrão: O firewall geralmente é o gateway para VLANs, mas às vezes não para migrações.
• Fonte DHCP: Sophos Firewall, servidor DHCP interno ou retransmissão DHCP devem ser planejados deliberadamente.
• Servidor DNS: O DNS afeta a filtragem da Web, a resolução de nomes e a solução de problemas.
• Serviços de firewall local: Device Access para DNS, Ping, HTTPS, SSH ou portais devem corresponder.
• Regras e caminhos NAT: Sem firewall apropriado e regras NAT, a interface está disponível apenas tecnicamente.
• Fluxo de teste: Um cliente de teste, um alvo de teste e uma entrada de log esperada economizam muito tempo de pesquisa.

Um backup atual também deve estar disponível para alterações produtivas. Se as interfaces já estiverem em uso, o Uso do objeto será obrigatório antes de alterar o nome, a ligação de zona, o endereço IP ou o tipo de interface.

Criar nova zona

Abra Network > Zones e clique em Adicionar.

1. Atribua um nome curto e exclusivo, por exemplo Server, Guest, Management ou MPLS.
2. Selecione LAN ou DMZ como tipo.
3. Em Device Access, especifique conscientemente quais serviços de firewall locais podem ser acessíveis a partir desta zona.
4. Salve.

Depois de guardar, a zona deve ser verificada diretamente em dois locais: em Network > Zones para nome, tipo e Device Access, e mais tarde numa regra de firewall de teste como Source zone ou Destination zone selecionável. Se a zona existir mas nenhuma interface estiver nela, ainda não passará tráfego produtivo por ali.

LAN ou DMZ como tipo de zona?

Para as suas próprias zonas normalmente você pode escolher entre LAN e DMZ no Sophos Firewall. Ambos os tipos agrupam interfaces para que posteriormente possam ser utilizadas de forma limpa em regras, Device Access e políticas. A diferença reside principalmente na ideia de segurança por trás da zona.

LAN é usado para redes internas fundamentalmente confiáveis. Estas incluem, por exemplo, redes de clientes, redes de servidores internos, redes de gerenciamento, VoIP, impressoras ou VLANs internas. O mesmo se aplica a uma zona LAN: o tráfego entre interfaces não é permitido automaticamente. Se duas zonas LAN ou duas interfaces dentro de uma zona LAN conversarem entre si, serão necessárias regras de firewall apropriadas.DMZ é utilizado para redes com maior risco ou isolamento claro. Exemplos típicos são servidores web acessíveis publicamente, proxies reversos, gateways de correio, hosts de salto ou sistemas que devem ser acessíveis a partir de múltiplas áreas de segurança. Uma DMZ deve ser planejada de forma que receba apenas as conexões internas necessárias. Se um servidor comprometido estiver na DMZ, isso não deverá resultar automaticamente em acesso generalizado à LAN interna.

Como uma regra simples:

• LAN: redes internas que geralmente são confiáveis e que se comunicam principalmente de saída ou internamente.
• DMZ: redes expostas ou particularmente isoladas onde o acesso interno deve ser estritamente limitado.

As interfaces HA também pertencem a uma zona DMZ. Para redes normais de administração ou cliente, LAN é geralmente o tipo mais adequado.HTTPS pode ser útil para uma rede administrativa interna. Para redes normais de clientes ou convidados, o acesso de gerenciamento deve ser evitado. Ping/ping6 costuma ser útil para solução de problemas, mas deve ser ativado conscientemente. DNS só será necessário se os clientes nesta zona usarem o firewall como servidor DNS.

⚠️ Device Access não é o mesmo que regra de firewall. O acesso aos serviços de firewall locais, por exemplo WebAdmin, SSH, User Portal, DNS ou Ping, é controlado via Administration > Device access e exceções de ACL locais.

Configurar interface

As interfaces podem ser encontradas em Network > Interfaces. Por exemplo, uma porta física pode ser operada como LAN, WAN ou DMZ. Também são criadas interfaces virtuais como VLAN, Bridge, LAG, RED ou XFRM.

Estes pontos são particularmente importantes para uma interface física:

• Name: nome descritivo para regras e logs posteriores.
• Hardware: porta física, por exemplo Port1, Port2 ou PortA.
• Network zone: Zona de segurança na qual está localizada a interface.
• IPv4 configuration: Estático, DHCP ou PPPoE.
• IPv6 configuration: Estático, DHCP ou Delegado, dependendo do ambiente.
• Gateway: relevante apenas para interfaces WAN.
• MTU / MSS: importante para problemas de PPPoE, VPN, SD-WAN e fragmentação.

Somente as interfaces da zona WAN recebem configuração de gateway. As interfaces internas geralmente são endereçadas estaticamente. DHCP ou PPPoE podem ser úteis para conexões de provedores.

Se o provedor fornecer IPv6 via delegação de prefixo, você deverá planejar as restrições e o processo separadamente. O artigo prático para isso é Configurar a delegação de prefixo IPv6 para Sophos Firewall.

Nomes significativos são importantes. PortD diz pouco em seis meses. Server VLAN, MPLS Provider, Guest WiFi ou Core Switch Trunk ajudam muito mais na operação.

Uma interface física existente é editada assim:

1. Abrir Network > Interfaces.
2. Abrir o menu da porta desejada e escolher Edit interface.
3. Verificar Name, Network zone, configuração IP, gateway e MTU/MSS.
4. Em interfaces WAN, verificar também o nome do gateway e o IP do gateway.
5. Guardar e depois verificar link status, gateway status e Log Viewer.

Antes de alterar uma interface produtiva, deve abrir-se Object usage. Alterações de interface podem afetar zone binding, DNS, gateways, SD-WAN routes, hosts baseados em interface, interfaces VLAN, Dynamic DNS, regras de firewall e NAT. Ao eliminar uma interface virtual, a Sophos também pode remover configurações dependentes, como regras de firewall, referências DHCP ou routing. É precisamente aí que surgem interrupções desagradáveis quando se tinha apenas o nome da porta em mente.

Antes de firmware upgrades, deve também garantir-se que nomes de interfaces, hardware e branches não terminam com um bloco longo de números. Nas release notes SFOS está documentado um erro de apresentação no WebAdmin quando esses nomes terminam com dez ou mais dígitos, por exemplo VLAN_1234567890. Verifique Sophos Firewall antes da atualização do SFOS 22 é adequado para planeamento de upgrade e testes específicos.

Criar interface VLAN

Para um processo focado com interface pai, marcação de switch, DHCP, Device Access, regras e testes de firewall, Sophos Firewall Configurar e testar VLAN é adequado. A seção a seguir classifica VLANs dentro do modelo maior de interface e zona.

Uma interface VLAN é criada em Network > Interfaces > Add interface > Add VLAN. A interface pai, zona, ID de VLAN e configuração de IP são particularmente importantes.

A interface pai é a porta física ou um LAG na qual a VLAN chega marcada. Se o switch enviar a VLAN em uma porta diferente, sem etiqueta ou com um ID de VLAN incorreto, o firewall verá uma interface VLAN, mas os clientes não poderão acessá-la de maneira confiável.

Para VLANs internas, um endereço IP estático geralmente é usado no firewall, por exemplo, como gateway padrão para esta VLAN. A zona decide posteriormente quais regras de firewall, políticas da web e configurações Device Access se aplicam. É exatamente por isso que você não deve apenas inserir o endereço IP ao criar uma VLAN, mas também considerar diretamente se a VLAN requer Client, Server, Management, Guest, DMZ ou outra zona.

Um exemplo prático concreto com perfis de portas de switch, comportamento etiquetado/não etiquetado, DHCP e sequência de testes pode ser encontrado em Configurar VLAN em Sophos Firewall e UniFi Switch.

Em hardware XGS, a Sophos não indica um número fixo e rígido de interfaces VLAN por interface física. Isso não significa que uma única parent port seja sempre a melhor decisão operacional. Para performance, troubleshooting e manutenção, as VLANs devem ser distribuídas de forma sensata por portas físicas ou LAGs, sobretudo com muitas VLANs, carga east-west elevada ou designs HA.

Implementação de VLAN limpa

Uma VLAN só é considerada completa quando não apenas a interface foi criada, mas também o switch, o DHCP, o DNS, as regras de firewall e o registro, todos juntos. Especialmente em redes novas, é fácil pesquisar no lugar errado: a regra do firewall parece correta, mas o switch envia sem marcação. Ou o cliente obtém um endereço IP, mas Device Access não permite acesso DNS ao firewall.

Para cada nova VLAN, estes pontos devem ser verificados:

Interface de firewall: ID de VLAN, interface pai, zona, endereço IP e máscara de sub-rede correspondem ao design.

• Porta do switch: O uplink para o firewall está configurado como um tronco e tem a VLAN marcada.
• Porta de acesso ou SSID: Porta do cliente ou SSID WLAN mapeia clientes para a VLAN correta.
• Gateway: O IP do firewall na VLAN é o gateway padrão esperado ou o roteamento é documentado de forma diferente.
• DHCP: servidor DHCP, retransmissão DHCP ou servidor DHCP externo distribui IP, gateway, DNS e concessão corretos.
• DNS: os clientes podem resolver nomes internos e externos conforme planejado.
• Device Access: Somente serviços de firewall locais necessários são permitidos na zona, por exemplo, DNS ou Ping.
• Regra de firewall: zona de origem, rede de origem, zona de destino, serviços e registro correspondem ao fluxo de teste.
• NAT: Ativo apenas se o tráfego realmente precisar ser traduzido. Para tráfego interno normal, o NAT geralmente está errado.
• Teste: Log Viewer mostra o firewall esperado Rule ID; se necessário, Packet Capture confirma o fluxo de pacotes.

Como teste de aceitação, não basta que um cliente receba qualquer endereço IP. Um teste útil consiste em várias etapas: conectar o cliente via DHCP, executar ping no gateway, verificar o DNS, testar uma conexão interna permitida, verificar se o acesso proibido está deliberadamente bloqueado e depois verificar o acesso à Internet. Desta forma você pode ver se VLAN, zona, Device Access, regra de firewall e NAT realmente correspondem.

Se várias VLANs forem criadas ao mesmo tempo, você deverá usar um cliente de teste separado ou pelo menos um IP de teste exclusivo para cada VLAN. Caso contrário, Log Viewer e Packet Capture se tornarão desnecessariamente confusos. Teste a regra de firewall com Log Viewer, Policy Test e Packet Capture é adequado para a verificação real do fluxo de pacotes.

Leia o status da interface corretamente

Em Network > Interfaces, Sophos Firewall exibe mensagens de status. Essas mensagens de status são muito úteis na solução de problemas porque você pode ver rapidamente se uma interface está configurada incorretamente ou se realmente não há link.

• Not configured: A interface não está atribuída a uma zona. Portanto, não pode ser usado de forma significativa até que uma zona seja vinculada.
• Connected: A interface está configurada e conectada.
• Connecting: Um novo endereço IP está sendo obtido, por exemplo, via DHCP.
• Disconnected: O endereço IP foi liberado.
• Disconnecting: O endereço IP está sendo divulgado no momento.
• Unplugged: Não há conexão física. Para WiFi, também pode significar que nenhum Access Point está conectado ou nenhuma rede sem fio está atribuída.
• Not available: As portas FleXi foram configuradas, mas o módulo de porta FleXi correspondente não está mais presente.

Se uma interface mostrar inesperadamente Not configured ou Unplugged, você não deverá procurar regras de firewall primeiro. Primeiro você verifica a ligação da zona, link, SFP/transceptor, cabo, porta do switch e, para DHCP/PPPoE, a atribuição de endereço.

Classifique VLAN, Bridge, LAG, Alias e RED

Sophos Firewall suporta diferentes tipos de interface. Para iniciantes, o mais importante é saber qual tipo faz sentido.

• VLAN: ​​​​Padrão para redes segmentadas em uma porta tronco.
• Bridge: Conexão transparente de múltiplas portas, geralmente para configurações ou migrações simples.
• LAG: Agrupamento de vários links físicos para redundância ou largura de banda.
• Alias: endereço IP adicional em uma interface existente.
• RED: Remote Ethernet Device para locais externos.
• XFRM: Interface VPN IPsec baseada em rota.

Interfaces Alias são muitas vezes subestimadas. São especialmente úteis quando um provider disponibiliza vários endereços IP públicos na mesma subnet. Várias interfaces WAN separadas na mesma subnet causam problemas ARP na Sophos Firewall e podem tornar gateways inacessíveis. Nestes desenhos, um alias na interface WAN existente ou um LAG bem planeado costuma ser a melhor escolha.

Para novas instalações, a VLAN em um uplink claramente definido para o switch geralmente é mais limpa do que uma grande ponte sobre muitas portas. Uma ponte pode ser útil para migrações ou configurações muito simples porque múltiplas portas são tratadas como um segmento comum da Camada 2. Mas essa é exatamente a desvantagem: os limites de segurança, os domínios de transmissão e as fontes de erro tornam-se menos visíveis.

Portanto, recomendamos pontes apenas especificamente e não como um projeto padrão. Na prática, as pontes apresentam várias desvantagens:

• Várias portas compartilham o mesmo segmento de Camada 2, fazendo com que transmissões e interferências afetem mais facilmente vários dispositivos.
• As regras de firewall estão se tornando menos claras porque a separação não é mais claramente visível nas suas próprias interfaces, VLANs e zonas.
• A solução de problemas se torna mais difícil, pois o fluxo de pacotes, o aprendizado de MAC, os problemas de STP e a configuração do switch devem ser considerados em conjunto.
• A segmentação posterior torna-se mais complexa se forem criadas redes separadas de clientes, servidores, convidados ou de gerenciamento a partir de uma simples ponte.
• Os designs de HA, VLAN, DHCP ou acesso a dispositivos rapidamente se tornam confusos se muitas funções forem executadas em uma ponte.

Bridges podem ser criadas na Sophos Firewall via interfaces físicas, interfaces RED, VLANs ou LAGs e operadas com ou sem endereço IP próprio. É exatamente aqui que muitas vezes surgem mal-entendidos:

• Sem um endereço IP, a ponte funciona de forma transparente, mas não pode ser usada como uma interface roteada normal.
• Se o roteamento for necessário em uma ponte, um endereço IP deverá ser atribuído à ponte.
• Para o tráfego entre membros da ponte, ainda são necessárias regras de firewall apropriadas entre as zonas envolvidas, por exemplo, LAN para LAN.
• O STP pode ser útil se houver caminhos redundantes e loops de ponte devem ser evitados. No entanto, com HA ativo, STP não pode ser ativado em interfaces Bridge.
• Filtros VLAN e filtros EtherType podem ajudar a limitar o tráfego da Camada 2 que passa por uma ponte. Se um filtro VLAN estiver ativo, mas não houver VLANs permitidas configuradas, a firewall descarta o tráfego tagged de todas as VLANs. O tráfego untagged não é afetado.
• O tráfego em interfaces de ponte sem endereço IP pode ser descartado se atingir uma regra de firewall com filtragem de proxy da Web ou uma regra NAT. Essas quedas não são registradas. Com o NAT você deve prestar atenção especial à tradução de origem ou substituir a tradução de origem.

Este último ponto é importante: se de repente você não vir nenhum registro em uma ponte, mesmo que o tráfego pareça não estar funcionando, o problema nem sempre é com o Log Viewer. Pode ser devido ao modo bridge, NAT ou filtragem de proxy da web.

Se já existirem VLANs no switch, o firewall deverá adotar conscientemente essas VLANs como suas próprias interfaces VLAN. Isso resulta em zonas mais claras, regras de firewall mais limpas e geralmente é mais fácil de manter a longo prazo.

SFOS 22: Verifique o tráfego da ponte, SNAT e gancho

Com o SFOS 22 há um caso especial de ponte adicional que é rapidamente esquecido nas migrações. O roteamento através de uma interface de ponte pode falhar se SNAT ou MASQUERADE for aplicado ao tráfego através da ponte e a origem e o destino forem acessíveis através do mesmo membro da ponte física. Neste cenário hairpin, os pacotes de resposta podem ser descartados na ponte sem que a queda seja claramente visível em drppkt.

Este não é um problema normal de correspondência de regras. Se o Log Viewer mostrar pouco, a regra parecer correta e ainda assim apenas algumas conexões em uma ponte falharem, você deve verificar o NAT e a topologia da ponte juntos:

• O SNAT ou o MASQUERADE são realmente necessários no tráfego de pontes?
• A origem e o destino passam pelo mesmo membro da ponte física?
• Existe apenas um membro da ponte usado ativamente?
• Um design roteado ou uma interface física dedicada seria mais limpo?
• O tráfego pode ser testado sem tradução de origem?

Há também um caso SFOS 22 separado para tráfego marcado com VLAN para o próprio firewall. O procedimento prático está em Sophos Firewall Verifique VLANs de ponte de acordo com SFOS 22.

RED Bridge: estende a rede entre locais

É tecnicamente possível incluir interfaces RED em uma ponte e, assim, estender uma rede de Camada 2 por vários locais. Isto pode ajudar em casos especiais, por exemplo, quando uma aplicação deve permanecer na mesma sub-rede ou uma migração deve ocorrer sem alterações imediatas de IP.

Recomendamos este design apenas com muita cautela. Uma ponte sobre RED estende o domínio da Camada 2 sobre o túnel. Isso faz com que transmissões, ARP, pacotes unicast desconhecidos e outros efeitos da Camada 2 sejam executados em uma conexão WAN ou Internet. Isso pode piorar o desempenho e tornar os erros mais difíceis de entender. Se o túnel RED estiver instável, isso também afetará diretamente a rede esticada.

Na maioria dos casos, um design roteado é melhor: cada local tem suas próprias sub-redes, as rotas de firewall entre as redes e as regras de firewall definem especificamente o que é permitido. Isso é mais limpo, mais escalonável e muito mais conveniente na solução de problemas.

LAG: Planeje redundância e largura de banda corretamente

Um Grupo de agregação de links (LAG) combina diversas portas físicas em uma interface lógica. Isso faz sentido se você precisar de redundância para o switch principal ou quiser fornecer mais largura de banda entre o firewall e o switch. Mas o GAL não substitui o zoneamento limpo. No final das contas, a interface LAG ainda é apenas uma interface na qual você pode, por exemplo, operar VLANs ou atribuir uma zona.

Sophos Firewall suporta principalmente dois modos de operação típicos:

• Active-Backup: Um link está ativo, outro assume se falhar. Isso é simples e bom para redundância.
• LACP (802.3ad): Vários links podem ser usados ​​em paralelo. Isso requer LACP em ambos os lados, ou seja, no firewall e no switch.

É importante: o LACP só funciona corretamente se o outro lado estiver configurado corretamente. No switch, as portas devem estar no mesmo grupo LAG, usar a mesma velocidade e modo duplex e corresponder à configuração do firewall. Se você criar apenas um LAG no firewall, mas não configurar o switch adequadamente, muitas vezes surgirão perdas de pacotes difíceis de entender ou problemas de conexão assimétrica.

Algumas limitações práticas aplicam-se aos GAL:

• Um LAG no Sophos Firewall consiste em duas a quatro interfaces físicas.
• Somente interfaces físicas não vinculadas com configuração estática são adequadas como membros.
• Interfaces PPPoE, Cellular WAN e WLAN não podem ser usadas como membros LAG.
• Para LACP (802.3ad) as portas membros devem ter o mesmo tipo e velocidade.
• O xmit-hash-policy determina como as sessões são distribuídas pelos links. Uma única sessão TCP normalmente não se torna repentinamente mais rápida porque geralmente permanece em um link.

Para ambientes pequenos, uma única porta tronco limpa geralmente é suficiente. O LAG é particularmente útil se o switch principal for conectado de forma redundante, se muitas VLANs rodarem no mesmo uplink ou se o firewall realmente precisar de mais rendimento para o switch.

XFRM: Compreendendo o IPsec baseado em rota como uma interfaceUma interface XFRM pertence ao tópico VPN IPsec baseada em rota. Não é planejado como uma VLAN normal ou porta física, mas é criado no contexto de uma conexão IPsec. O Sophos Firewall cria uma interface XFRM automaticamente quando as sub-redes locais e remotas são definidas como Any em uma conexão IPsec.

Esta é uma diferença importante em relação aos túneis IPsec clássicos baseados em políticas. Com a VPN baseada em rotas, não apenas a política IPsec, mas também o roteamento, as regras de firewall e a interface XFRM decidem para onde vai o tráfego. Isso torna as conexões de site mais complexas mais flexíveis, mas requer um planejamento cuidadoso:

• A interface XFRM está na zona VPN.
• Em Administration > Device access deve ser permitido IPsec para a zona WAN para que a conexão possa ser estabelecida.
• Se as sub-redes locais ou remotas não forem Any, nenhuma interface XFRM será criada.
• MTU e MSS são particularmente importantes para VPN baseada em rotas porque o IPsec cria sobrecarga adicional. O procedimento do teste prático está em Sophos Firewall Verifique MTU e MSS em busca de problemas de VPN.
• Uma interface XFRM não é desativada diretamente em Network > Interfaces, mas sim através da conexão IPsec associada em Site-to-site VPN > IPsec.

O XFRM é particularmente relevante para administradores quando o roteamento SD-WAN, o roteamento dinâmico ou múltiplas redes precisam ser controlados adequadamente por meio de um túnel de localização. Se tudo o que você precisa é de uma conexão site a site muito simples com duas redes fixas, um túnel clássico baseado em políticas costuma ser mais fácil de entender.

RED: Locais externos como um conceito de interface separado

As interfaces RED não são uma porta de switch normal. RED significa Remote Ethernet Device e é usado para conectar um local externo ao Sophos Firewall por meio de um túnel criptografado. Isso pode ser implementado com hardware SD-RED dedicado ou com conexões RED firewall a firewall.

Antes de planejar, deve ficar claro qual modo de operação é necessário:

• Standard/Unified: O firewall gerencia a rede remota. O tráfego passa pelo firewall central. Muito fácil de controlar, mas dependente do túnel.
• Standard/Split: Apenas redes de destino definidas passam pelo túnel, o tráfego da Internet sai localmente no local. Menos largura de banda na sede, mas menos controle central.
• Transparent/Split: RED trava de forma transparente em uma rede existente. Bom para casos especiais, mas mais difícil de entender e não adequado para todos os projetos.
• Manual/Split: Mais configuração de rede manual. O site pode continuar a operar localmente se o túnel falhar.

Para muitas empresas, Standard/Unified é a opção mais limpa caso o local precise ser totalmente protegido através do firewall central. A desvantagem é clara: se o túnel RED falhar, o local também perde o acesso à Internet controlado centralmente, dependendo do projeto. Standard/Split reduz esta dependência, mas também significa que o tráfego local da Internet não é mais completamente filtrado e registrado através do Sophos Firewall central.

Com o RED você deve verificar estes pontos com antecedência:

-O serviço RED deverá ser ativado em System services > RED.

• TCP 3400, UDP 3410 e NTP 123 são normalmente necessários para a conexão.
• Os dispositivos SD-RED precisam de tempo correto, caso contrário, o handshake TLS e o estabelecimento do túnel poderão falhar.
• Ao comissionar pela primeira vez, o DHCP no uplink geralmente é mais fácil porque o dispositivo precisa realizar o provisionamento.
• As VLANs não são igualmente úteis em todos os modos RED. Standard/Split e Transparent/Split não se destinam a quadros marcados com VLAN. Se forem necessárias VLANs atrás de um SD-RED, você deve escolher o modo operacional com especial cuidado.
• Se um dispositivo RED estiver atrás de um roteador do provedor, as conexões de saída e o DNS/NTP deverão funcionar.

RED é muito conveniente para sites pequenos, mas você não deve tratá-lo como um cabo LAN normal. O factor decisivo é se o local deve ser protegido centralmente, localmente autónomo ou apenas parcialmente ligado através do túnel. Esta decisão afeta DHCP, DNS, VLANs, roteamento, regras de firewall, registro e solução de problemas.

Device Access restringir de forma limpaEm Administration > Device access você pode ver quais serviços de firewall locais estão acessíveis em quais zonas. Estes incluem, entre outros:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

Para ambientes produtivos, quanto menos serviços locais puderem ser alcançados a partir de uma zona, melhor. Em particular, HTTPS e SSH só devem ser permitidos em redes de gerenciamento confiáveis ​​ou por meio de uma regra de exceção de ACL de serviço local.

Se for necessário SSH, este guia ajudará: Estabeleça uma conexão SSH com o Sophos Firewall.

Em zonas próprias, Device Access também pode estar visível diretamente ao criar ou editar a zona. Tecnicamente continua a tratar-se de serviços locais da firewall, não de tráfego de trânsito normal. Se clientes usam a firewall como servidor DNS, DNS deve estar permitido para essa zona. Se administradores precisam de acesso WebAdmin, isso não deve ser ativado de forma ampla para toda a zona de clientes, mas através de uma rede de management ou de uma exceção Local Service ACL.

Tenha as dependências em mente

Alterações em interfaces raramente são isoladas. Zone binding, DNS, gateways, SD-WAN routes, hosts baseados em interface, interfaces VLAN, Dynamic DNS, regras de firewall e regras NAT podem depender da mesma interface. Antes de alterações importantes deve verificar-se em Object usage onde uma interface, uma zona ou um objeto host já está em uso. Sophos Firewall mostra a utilização de objetos e liga diretamente a muitas configurações dependentes.

Você precisa ter cuidado especial ao desativar ou excluir:

• Se uma interface for desativada, a configuração é mantida e o status ainda fica visível.
• Os túneis IPsec site a site onde o firewall é o iniciador são imediatamente desconectados.
• Túneis IPsec site a site, pois os respondedores e as conexões de acesso remoto são desconectados, o mais tardar, devido à inatividade ou à detecção de pares mortos.
• As interfaces Alias ​​​​e XFRM não podem ser desativadas diretamente como as interfaces normais. As interfaces de alias seguem a interface física, as interfaces XFRM são desativadas via Site-to-site VPN > IPsec.
• Quando uma interface virtual é excluída, regras de firewall dependentes, configurações de DHCP, entradas ARP, rotas, hosts de interface e outras referências podem ser removidas com ela.

Portanto, antes de excluir, você deve sempre verificar se a interface é utilizada em regras de firewall, regras NAT, DHCP, roteamento, SD-WAN, DNS dinâmico ou objetos de host. Uma exclusão descuidada pode remover mais do que apenas a interface em si.

Implemente mudanças com segurança

As mudanças na interface devem ser graduais. Locais remotos, clusters HA, interfaces WAN, troncos VLAN, interfaces XFRM e redes de gerenciamento são particularmente críticos. Uma pequena alteração na ligação da zona pode ser suficiente para que as regras de firewall, Device Access ou rotas SD-WAN não funcionem mais conforme o esperado.

Processo comprovado:

1. Documente a configuração atual da interface e da zona.
2. Verificar dependências através de Object usage e anotar diretamente os resultados mais importantes.
3. Crie backup.
4. Defina a janela de manutenção ou o tempo de fallback.
5. Adicione uma nova zona ou nova interface primeiro, não exclua imediatamente a configuração antiga.
6. Prepare o cliente de teste ou o tráfego de teste.
7. Após a alteração, verifique o status do link, endereço IP, gateway, DHCP e DNS.
8. Valide a regra de firewall, a regra NAT e Device Access com Log Viewer ou Packet Capture.
9. Remova regras, interfaces ou objetos antigos apenas quando o novo caminho estiver estável.

Um backup é apenas parte do caminho de volta. Antes de alterações críticas de interface ou zona, também deve ser documentado qual endereço IP antigo, zona, ID de VLAN, gateway, rota, rota SD-WAN, regra de firewall e regra NAT devem ser restaurados no caso de uma anulação. Sophos Firewall Criar ou restaurar backup é adequado para o processo real de backup e restauração.

• A zona de gerenciamento ou Device Access foi ajustada: O acesso de administrador alternativo é testado antes que a acessibilidade antiga seja removida.
• Interface WAN ou gateway alterado: Caminho do provedor antigo, valores PPPoE/DHCP/estáticos e rota SD-WAN estão documentados.
• O tronco da VLAN está sendo convertido: ID da VLAN antiga, VLAN nativa, perfil da porta do switch e interface do firewall são rastreáveis.
• Bridge, LAG ou RED foram alterados: O status do link, as portas envolvidas e o acesso ao local podem ser verificados de forma independente.
• A interface XFRM ou VPN foi alterada: Regras de túnel, roteamento e firewall são validadas antes de excluir o caminho antigo.

Atenção especial deve ser dada ao comportamento marcado/não marcado durante migrações de VLAN. Se o switch e o firewall usarem IDs de VLAN, VLANs nativas ou perfis de tronco diferentes, o firewall não verá nenhum tráfego ou o tráfego acabará na zona errada.

Para locais remotos, sempre deve haver um caminho de acesso fora da interface que você acabou de alterar. Pode ser Sophos Central, um segundo acesso WAN, um administrador local no local ou uma rede de gerenciamento separada.

Obstáculos típicos

A interface está desvinculada ou desativada: Primeiro verifique se uma zona está atribuída. Uma interface física não pode ser excluída, mas sua configuração pode ser removida configurando a zona como None.

VLAN não funciona: Verifique o ID da VLAN, a porta do switch, a configuração marcada/não marcada, a VLAN nativa e a interface pai.

Os clientes não podem acessar o firewall via ping ou HTTPS: Não verifique primeiro as regras normais do firewall. Administration > Device access e exceções de ACL locais são cruciais.

O tráfego entre duas redes internas não funciona: Verifique a zona de origem, zona de destino, objetos de rede, roteamento e posição da regra de firewall.

Gateway WAN não fica ativo: Verifique a configuração IP, IP do gateway, status do link, credenciais PPPoE, DNS e se necessário Gerenciador de link WAN.

Várias interfaces WAN na mesma sub-rede: Se várias interfaces WAN usarem endereços IP da mesma sub-rede, poderão ocorrer problemas de ARP e os gateways poderão ficar inacessíveis. Se um provedor fornecer vários IPs públicos na mesma sub-rede, as interfaces de alias ou LAG geralmente serão mais limpas do que várias interfaces WAN separadas na mesma rede.

SFP, velocidade da porta ou breakout não correspondem: A velocidade da porta no switch, roteador, transceptor e firewall deve corresponder. Uma porta de 25 Gbit/s não pode ser conectada diretamente a uma porta de 40 Gbit/s sem tecnologia apropriada. Para modelos com portas 40G ou 100G, os cabos breakout podem ser relevantes se uma porta for dividida em várias portas menores.

Problemas de MTU com VPN ou PPPoE: Verifique MTU e MSS. Para o tráfego VPN, um valor de MTU muito alto pode levar à perda de pacotes, o que na vida cotidiana parece ser um problema de conexão aleatório. Sophos Firewall Verifique MTU e MSS em busca de problemas de VPN é adequado para limitação sistemática.

Solução de problemas

Esta ordem é prática para solução de problemas:

1. Network > Interfaces: Verifique o status do link, endereço IP, zona e gateway.
2. Network > Zones: Verifique Device Access e tipo de zona.
3. Hosts e serviços: Verifique se os objetos de host e serviço estão corretos.
4. Rules and policies > Firewall rules: Verifique zona de origem, zona de destino, serviços e pedido.
5. Rules and policies > NAT rules: Se NAT estiver envolvido, compare o original e o traduzido cuidadosamente.
6. Visualizador de log: verifique qual regra ou eliminação se aplica.
7. Diagnostics > Tools > Packet capture: Verifique se os pacotes chegam e para onde são encaminhados.

Se as zonas e interfaces estiverem devidamente dispostas, o próximo passo se torna muito mais fácil: Compreender e configurar corretamente as regras Sophos Firewall. Se o tráfego não funcionar apesar da zona aparentemente correta, a lista de verificação A regra do firewall não funciona: verifique a ordem, a correspondência e os registros ajudará. Para uma análise mais aprofundada você também pode utilizar Use Packet Capture no WebAdmin e para traduções ou encaminhamento de porta o artigo Compreendendo o NAT em Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Lista de verificação operacional

• Modelo de zona documentado: Cliente, servidor, gerenciamento, convidado, DMZ, WAN e VPN deliberadamente separados ou deliberadamente combinados.
• Novas VLANs documentadas com VLAN ID, interface pai, perfil de porta do switch e IP do gateway.
• Zona e objeto host IP concreto documentados para cada rede importante.
• Device Access verificado por zona, especialmente para HTTPS, SSH, DNS, Ping, User Portal e VPN Portal.
• Regras de firewall criadas com zona de origem, zona de destino, serviços e log.
• Alias verificado em vez de uma interface WAN adicional quando vários IPs públicos são usados na mesma subnet do provider.
• Regras NAT verificadas se estiver envolvido acesso à Internet, DNAT, SNAT ou VPN.
• DHCP, DNS e NTP testados para novas redes.
• Object usages verificado antes de alterações nas interfaces existentes.
• Status do link, Log Viewer e Packet Capture verificados quanto a alterações.
• Acesso de gerenciamento garantido por caminho independente.
• Backup disponível antes de grandes mudanças.

Perguntas frequentes