Configurar e solucionar problemas do Sophos SD-RED

Com um Sophos SD-RED, é possível conectar filiais, escritórios ou pequenos escritórios domésticos a uma Sophos Firewall. O RED estabelece um túnel criptografado para a firewall e fornece uma rede no local remoto, que é gerida centralmente pela firewall.

A vantagem prática: no local, normalmente não é necessária uma configuração VPN complexa. O SD-RED é conectado à Internet, carrega sua configuração através do Sophos RED Provisioning Service e, em seguida, estabelece o túnel para a Sophos Firewall. No entanto, o túnel por si só não resolve tudo. Zonas, regras de firewall, DHCP, VLANs, roteamento, DNS e versão do firmware também devem estar corretos.

O modo de funcionamento deve ser definido antes da configuração propriamente dita. Determina DHCP, gateway, caminho da internet, controlo central e o comportamento durante uma falha do túnel. Escolher o modo de funcionamento correto do Sophos RED explica as diferenças e os critérios de decisão.

Planeamento e requisitos

Classificação: SD-RED e RED entre firewalls

Existem dois casos atuais de RED que devem permanecer separados. Este artigo trata de uma SD-RED 20 ou SD-RED 60 física numa filial. O SFOS 22 também continua a suportar um túnel Site-to-Site RED entre duas Sophos Firewall, em que uma atua como Firewall RED server e a outra como Firewall RED client.

O segundo caso não necessita de hardware RED. Configurar Site-to-Site RED entre duas Sophos Firewall explica o ficheiro de provisionamento, as rotas estáticas sem interface selecionada, as regras nos dois lados e o serviço RED. Os modos de operação SD-RED não se aplicam a este design.

Requisitos no local principal

Antes de conectar o RED, os seguintes pontos devem estar claros na Sophos Firewall:

• O serviço RED está ativado na firewall.
• O endereço IP público ou o nome DNS/DynDNS da firewall é acessível.
• Conexões RED para a firewall são permitidas no lado WAN.
• RED é permitido em Administration > Device access para a zona WAN apropriada ou liberado especificamente através do Local Service ACL.
• Interface RED, zona e configuração IP estão planejadas.
• Regras de firewall da rede RED para as redes de destino estão previstas.
• DHCP, DHCP Relay ou endereçamento estático para clientes atrás do RED está resolvido.
• O padrão de firmware RED na firewall está atualizado.
• Backup e versão do firmware da firewall estão documentados antes de grandes alterações.

Para a comunicação RED, TCP 3400, UDP 3410 e NTP 123 são particularmente relevantes. Essas conexões não devem ser bloqueadas por roteadores de provedores, firewalls intermediárias ou gateways de segurança.

Requisitos no local remoto

No local remoto, o SD-RED precisa de uma conexão de Internet estável. O que importa não é apenas a largura de banda, mas principalmente a estabilidade, latência, perda de pacotes e se o provedor permite as conexões necessárias.

Deve-se verificar:

• A conexão de Internet é estável.
• A porta WAN do RED recebe um endereço por DHCP ou tem uma configuração estática correta.
• O gateway padrão é acessível.
• O DNS funciona.
• O NTP é acessível.
• TCP 3400, UDP 3410 e NTP 123 não são bloqueados.
• O roteador do provedor ou firewall intermediária não faz filtragem inesperada.
• Em VLANs, está claro qual porta opera como tagged, untagged ou híbrida.

Para locais simples, muitas vezes uma pequena conexão é suficiente. Na prática, no entanto, a perda de pacotes, roteadores de consumo instáveis, CGNAT, problemas de DNS ou firewalls restritivas de provedores são mais frequentemente a causa do que a largura de banda pura.

Provisioning e colocação em serviço

Provisionar automaticamente através do Sophos Provisioning Service

Para o provisionamento online normal, a firewall e a SD-RED precisam de acesso à internet. No primeiro arranque, a SD-RED tem de obter um endereço WAN por DHCP para poder descarregar a configuração. Uma configuração WAN estática exige, portanto, provisionamento manual por USB. Na firewall, ativa-se o serviço de provisionamento RED em System services > RED, introduzem-se os dados de contacto e aceitam-se os termos de utilização da Sophos.

Em seguida, cria-se uma interface em Network > Interfaces > Add interface > Add RED. Para o site, configuram-se Branch name, tipo de dispositivo, Automatically via provisioning service, endereço da firewall, uplink, modo de operação, rede RED, zona e DHCP. Numa RED utilizada pela primeira vez, Unlock code fica vazio. Depois de guardar, a firewall carrega a configuração para o serviço de provisionamento. A SD-RED obtém-na, abre o canal de controlo em TCP 3400 e depois estabelece o túnel de camada 2 em UDP 3410.

Ao guardar pela primeira vez, o serviço de provisionamento gera um código de desbloqueio específico do dispositivo. O código aparece no WebAdmin e é enviado para o endereço de e-mail configurado em System services > RED. Deve ser guardado em segurança porque é necessário ao mover a RED para outra firewall. O WebAdmin volta a mostrá-lo quando a interface é eliminada. Se o código não estiver disponível, deve contactar-se o Sophos Support.

Definir conscientemente as proteções RED globais

Durante a ativação inicial em System services > RED, o SFOS cria um certificado para a comunicação RED a partir de Organization name, City, Country e Email. Por isso, Organization name e City não podem conter tremas nem caracteres especiais. O endereço de e-mail deve permanecer acessível, porque a Sophos envia para lá novos códigos de desbloqueio.

Para SD-RED 20 e 60 atuais, TLS v1.2 (strict) and later é o ponto de partida recomendado. Esta seleção utiliza apenas as cifras TLS 1.2 recomendadas pela Sophos. TLS v1.2 and later inclui também cifras que a Sophos não recomenda e não deve ser escolhido sem uma necessidade de compatibilidade comprovada. Após a alteração, todos os túneis RED de produção devem ser novamente ligados e testados de forma controlada.

Automatic device deauthorization impede que uma RED desligada durante muito tempo permaneça autorizada indefinidamente. O período deve adequar-se ao processo de incidentes e substituição da organização: depois de expirar, o dispositivo não é eliminado, mas a interface RED tem de ser explicitamente reativada em Network > Interfaces. A monitorização e a documentação do código de desbloqueio fazem, por isso, parte desta proteção.

Em SD-RED 20 e 60, mantenha RED unified firmware ativado. Um novo padrão de firmware RED é instalado conscientemente em Backup & firmware > Pattern updates e não é aplicado automaticamente. Deve ser planeada uma janela de manutenção e, em seguida, testados o túnel e um cliente.

Conectar o SD-RED

Procedimento típico:

1. Conectar a porta WAN do SD-RED ao roteador do provedor ou modem.
2. Conectar a porta LAN a um cliente de teste, switch ou rede local.
3. Fornecer energia ao SD-RED.
4. Aguardar até que o RED inicie, verifique o gateway e a Internet, carregue a configuração e estabeleça o túnel.
5. Verificar na Sophos Firewall se a interface RED está ativa.
6. Conectar o cliente de teste atrás do RED e verificar IP, DNS, gateway e acesso ao destino.

Se todos os LEDs relevantes estiverem verdes, o túnel técnico está estabelecido. Depois disso, começa a verificação real da rede: Zona, DHCP, regras de firewall, roteamento de retorno, DNS e, se necessário, VLANs.

Provisioning manual com pen USB

Normalmente, um SD-RED é provisionado através do Sophos RED Provisioning Service. O provisioning manual por pen USB é útil quando o dispositivo está numa rede privada ou fortemente restringida, precisa de uma configuração WAN estática ou o caminho de provisioning automático não é fiável.

O processo é mais preciso do que apenas copiar um ficheiro de provisioning para USB:

1. Na firewall, abrir Administration > Time, selecionar Use custom NTP server e adicionar o endereço IP da firewall como servidor NTP. No setup manual, o RED tem de conseguir obter uma hora válida da firewall através do caminho previsto para que o TLS handshake funcione.
2. Em Network > Zones, criar para os locais RED uma zona dedicada do tipo LAN ou DMZ. Uma zona separada impede que as regras LAN gerais se apliquem involuntariamente ao local remoto. Se for usada a zona VPN, a firewall não responde diretamente às consultas DNS dos clientes RED; nesse caso, o DHCP tem de distribuir outro servidor DNS acessível.
3. Em System services > RED, ativar o RED Provisioning Service.
4. Em Network > Interfaces > Add interface > Add RED, criar a interface RED.
5. Em Device deployment, escolher Manually via USB stick.
6. Introduzir RED ID, Unlock Code, uplink, RED network settings, zona, DHCP e VLANs adequados ao site.
7. Descarregar o ficheiro de provisioning gerado na interface RED.
8. Copiar o ficheiro para o diretório raiz da pen USB.
9. Desligar o RED, inserir a pen USB e voltar a ligar o RED.
10. Após o arranque, verificar interface, LEDs, IP do cliente, DNS, regra de firewall e acesso aos destinos.

Se o lado WAN do RED usar DHCP, tem de existir realmente um servidor DHCP a responder no site remoto. Se o RED não receber um endereço, pode entrar num ciclo de reinício. Com configuração WAN estática, IP, gateway, DNS e NTP têm de ser verificados com especial cuidado.

Um RED provisionado offline também precisa de uma hora válida. Para sincronização direta, tem de conseguir resolver os nomes 0.sophos.pool.ntp.org a 3.sophos.pool.ntp.org e aceder a esses servidores por UDP 123. Se isso falhar, tenta sincronizar a hora com a firewall através de HTTPS em TCP 4444. Pode ser necessária uma Local service ACL exception rule específica. Defina apenas o IP conhecido do RED como source e a porta WAN da firewall como destination; o service é HTTPS e a action Accept. Como esta exceção expõe o serviço de administração HTTPS, tem de permanecer restrita ao IP do RED.

Estado, atualizações e migração

Entender o status dos LEDs

Os LEDs de status são frequentemente o ponto de partida mais rápido para o troubleshooting do RED, pois indicam em que ponto o processo de inicialização está travado.

Legenda:

• ⚫ apagado
• 🟢 aceso verde
• 🟢 piscando verde
• 🔴 aceso vermelho
• 🔴 piscando vermelho

Dependendo do ângulo de visão, foto ou luz ambiente, um LED pode parecer amarelado ou laranja. Para o diagnóstico, o que importa é qual LED está aceso ou piscando e se é verde ou vermelho.

Processo de inicialização normal

Se todos os quatro LEDs estiverem verdes, mas nenhum tráfego funcionar, o problema geralmente não está mais na configuração do túnel. Nesse caso, regras de firewall, DHCP, VLANs, DNS, NAT ou roteamento são mais prováveis.

Códigos de erro

Failover 3G/4G

Em modelos SD-RED com failover 3G/4G ou módulo correspondente, podem ocorrer padrões adicionais.

Controlar atualizações de firmware

Se os LEDs piscarem juntos, o RED pode estar instalando um firmware. Nesta fase, não se deve desligar o dispositivo nem desconectá-lo da Internet. Uma atualização pode levar alguns minutos.

Na Sophos Firewall, deve-se verificar adicionalmente:

Backup & firmware > Pattern updates

Aí, o RED Firmware Pattern deve estar atualizado. Segundo a Sophos, a transferência e a instalação demoram entre cinco e dez minutos. Se um RED ficar preso num ciclo ou não arrancar corretamente após uma atualização da firewall, vale a pena verificar se o RED Firmware Pattern está desatualizado. Configurar e verificar atualizações de padrões no Sophos Firewall explica a relação entre o estado, a transferência automática e a instalação deliberada.

Um desejo operacional relacionado está descrito em Solicitação de Recurso da Sophos Firewall 2024: Em atualizações de firmware de RED e Access Point, muitas vezes faltam notas de lançamento visíveis diretamente no backend. Para ambientes produtivos, as atualizações devem ser planejadas conscientemente e não instaladas de forma descoordenada durante horários críticos de operação.

Verificar interface RED, zona e regras

Após o estabelecimento bem-sucedido do túnel, o RED precisa de uma configuração de firewall limpa.

Pontos típicos de verificação:

• A interface RED está ativa em Network > Interfaces.
• A interface está na zona correta.
• O servidor DHCP ou o DHCP Relay está configurado corretamente.
• Os clientes recebem endereço IP, gateway e DNS.
• As regras de firewall permitem apenas os destinos necessários.
• O roteamento de retorno para a rede RED funciona.
• O NAT é usado apenas quando planejado conscientemente.
• A configuração VLAN corresponde ao modo RED e à porta do switch.

Para o primeiro teste funcional, basta uma regra estritamente limitada em Rules and policies > Firewall rules: definir Source zone como a zona dedicada RED-Branch, indicar a rede dos clientes RED em Source networks and devices e permitir como destino apenas a rede interna de teste necessária. O acesso à internet exige uma regra separada com a zona WAN como destino e o tratamento NAT previsto. Em seguida, limite destinos e serviços às necessidades de produção. Assim, testa-se o caminho pretendido sem dar ao local remoto acesso a todas as redes internas.

Para as bases das regras, consulte Entender e configurar corretamente as regras da Sophos Firewall. Se o túnel estiver estabelecido, mas o tráfego não fluir, deve-se combinar Log Viewer e Packet Capture.

A opção MAC filtering type pode aplicar na rede RED uma allow list ou block list com um limite dependente do dispositivo, mas não substitui uma regra de firewall. Remote IP assignment também não é uma configuração predefinida: atribui por DHCP ou de forma estática um endereço ao bridge com o túnel RED no lado WAN e só deve ser investigada quando os dispositivos atrás da RED não respondem a pedidos ARP. Nenhuma das opções deve ser ativada como correção geral de desempenho ou conectividade.

Armadilhas de atualização e migração

Não confundir Site-to-Site RED com SD-RED

Um túnel RED entre firewalls continua a ser um design independente suportado no SFOS 22. Não utiliza nenhum dos quatro modos de operação SD-RED e não é definido através de DHCP nem das portas LAN de uma SD-RED. Durante uma atualização, ambos os tipos de RED são inventariados e cada um é depois validado com o respetivo teste funcional.

Para um planeamento de atualização mais amplo, consulte Planear corretamente a atualização de firmware da Sophos Firewall. O processo completo entre firewalls encontra-se em Configurar Site-to-Site RED entre duas Sophos Firewall.

Remover Firewall RED legacy e dispositivos RED antigos antes do SFOS 22

O SFOS 22.0 e versões posteriores já não suportam Firewall RED Server Legacy nem Firewall RED Client Legacy. Enquanto existir uma configuração deste tipo entre UTM e SFOS, a atualização, o restauro e a importação de configurações para o SFOS 22 ficam bloqueados. Isto não afeta os tipos atuais Firewall RED server e Firewall RED client. Antes da atualização, devem ser substituídas todas as dependências das interfaces legacy, eliminadas as interfaces e criada uma nova cópia de segurança da configuração.

RED 15, RED 15w e RED 50 também chegaram ao fim de vida. Os seus túneis deixaram de estabelecer ligação a partir do SFOS 20.0 MR1. Após uma atualização ou restauro para o SFOS 22, a configuração antiga permanece visível, mas não é aplicada e só pode ser eliminada. Não pode ser importada. Estes sites devem ser migrados para SD-RED 20 ou SD-RED 60 antes da atualização e testados com o respetivo caminho de dados real.

Máscara /32 corrigida para os hosts do sistema RED

A Sophos corrigiu para /32 a máscara de sub-rede dos objetos de host do sistema RED gerados automaticamente no SFOS 21.0 MR2 e 21.5 MR1. Se esses objetos eram anteriormente usados em regras ou outras configurações para vários endereços de host, as regras podem passar a corresponder ao tráfego de forma diferente após a atualização.

Após uma atualização, deve-se verificar:

• Os hosts do sistema RED são usados em regras de firewall?
• Uma regra espera erroneamente uma rede em vez de um único host?
• Devem ser substituídos objetos IP Host ou Network Host?
• As correspondências de regras no Log Viewer ainda estão corretas?

RED e failover HA

Em ambientes HA, os sites RED devem ser testados conscientemente após um failover. A Sophos indica que os túneis RED nem sempre se reconectam imediatamente ao dispositivo auxiliary após um failover HA. A duração depende, entre outros fatores, do número de interfaces e da configuração.

Para sites críticos, não se deve verificar apenas o estado HA da firewall. Também verificar:

• estado da interface RED após failover
• acesso de clientes atrás do RED
• correspondências relevantes de regras de firewall
• DNS e DHCP atrás do RED
• alertas de monitoring para interrupções de túnel prolongadas

Verificar o débito e o desempenho do RED

A Sophos indica um débito máximo do túnel de 250 Mbit/s para o SD-RED 20 e de 850 Mbit/s para o SD-RED 60. Estes são valores máximos da plataforma, não uma garantia para uma transferência SMB individual, um teste de velocidade no browser ou um único fluxo TCP. Os endpoints, o armazenamento, a janela TCP, a latência real entre os locais, a perda de pacotes, o percurso do operador, a carga da firewall e os perfis de segurança também influenciam o resultado.

Um ping de, por exemplo, 8 ms para um servidor público de teste de velocidade não descreve necessariamente a latência entre os dois locais RED. Um teste em cada ligação à Internet também não verifica o percurso cifrado end-to-end através do túnel RED. Para responder a esta questão, é necessário um servidor de teste numa LAN e um cliente de teste na LAN do outro local.

Testar o túnel RED com iPerf3 em ambas as direções

Antes do teste do túnel, deve criar-se uma baseline local com os mesmos endpoints ligados por cabo. Em seguida, executa-se o iPerf3 através do túnel RED, primeiro com um fluxo TCP, depois na direção inversa e, por fim, com quatro fluxos paralelos:

iperf3 -c 10.10.10.50 -t 30
iperf3 -c 10.10.10.50 -t 30 -R
iperf3 -c 10.10.10.50 -t 30 -P 4

10.10.10.50 é apenas um endereço de exemplo e deve ser substituído pelo endereço IP do servidor iPerf3 na LAN remota. O teste gera carga deliberadamente e deve ser realizado numa janela adequada. Testar corretamente o desempenho do Sophos Firewall com iPerf3 explica a instalação, a regra temporária da firewall, os testes UDP e a análise completa dos resultados.

Os três resultados respondem a perguntas diferentes:

• Se a baseline local já for lenta, verificar primeiro endpoints, NICs, controladores, cabos, switches e armazenamento.
• Se um fluxo for significativamente mais lento do que -P 4, é mais provável que a limitação esteja na latência, na janela TCP ou no fluxo individual da aplicação. Isto ainda não prova um limite do RED.
• Se um e quatro fluxos pararem no mesmo limite em ambas as direções, investigar as ligações físicas, o percurso do operador, a perda de pacotes, a configuração RED e a carga da firewall.
• Se apenas uma direção for lenta, comparar as respetivas velocidades de upload, os contadores das interfaces, os erros, os drops e o percurso de retorno.

Um padrão prático típico seria cerca de 400 Mbit/s com um fluxo e entre 700 Mbit/s e 800 Mbit/s com -P 4. Isto indica que o percurso pode transportar uma capacidade agregada significativamente maior, embora um único fluxo TCP ou SMB não a consiga utilizar por completo. Não garante que todas as aplicações atinjam o mesmo resultado com vários fluxos.

Durante cada execução, devem ser documentados o round-trip time real e a perda de pacotes entre os locais, as retransmissões do iPerf, a Firewall Rule ID, os perfis de segurança, a CPU da firewall e os contadores das portas envolvidas. As ligações WAN e LAN devem funcionar efetivamente a 1 Gbit/s, em Full Duplex e sem aumento dos contadores de erros ou drops. A velocidade e o duplex devem permanecer em auto-negotiation em ambos os lados, em vez de se forçar gigabit apenas num deles.

IPS ou outros perfis de segurança não devem ser desativados de forma geral. Para um teste A/B, utiliza-se no máximo uma regra temporária limitada à origem, ao destino e ao serviço iPerf3 concretos, removendo-a imediatamente depois. Se o resultado não mudar sem IPS, é menos provável que IPS seja a causa neste percurso de teste específico.

Desativar realmente 802.3az ou EEE

Para obter o melhor desempenho, a Sophos recomenda desativar 802.3az nos switches ligados a um SD-RED 20 ou SD-RED 60. Trata-se de Energy Efficient Ethernet, ou EEE. O EEE coloca partes do PHY Ethernet no estado Lower Power Idle quando a utilização da ligação é baixa, poupando energia. Não é o mesmo que PoE ou 802.3x Flow Control.

A definição não se encontra no WebAdmin nem na CLI do Sophos Firewall, nem num ecrã documentado do SD-RED. É alterada na porta do switch diretamente ligada. Isto aplica-se às ligações LAN utilizadas pelo RED e, se estiver envolvido um switch ou router gerível, também à ligação WAN física. Em dispositivos de outros fabricantes, a opção pode chamar-se EEE, Energy Efficient Ethernet, Green Ethernet, 802.3az ou Power Saving. Não existe uma CLI universal.

Num Sophos Switch, utiliza-se a página Port settings:

1. Selecionar a porta ligada diretamente ao SD-RED.
2. Abrir Edit.
3. Definir EEE status como Off.
4. Guardar com Apply.
5. Verificar o estado da ligação, a velocidade negociada, o duplex e os contadores de erros e repetir o mesmo teste iPerf3.

Num Sophos Switch atual, o estado pode ser apresentado em modo read-only na CLI:

show eee

Para a porta de exemplo 0/1, o EEE é desativado da seguinte forma:

configure terminal
interface gigabitethernet 0/1
no eee
exit
exit
save
show eee

0/1 deve ser substituído pela porta realmente ligada ao RED. no eee altera a configuração da porta. Se o switch só estiver acessível através deste percurso RED, são necessários uma janela de manutenção e um acesso de gestão local ou alternativo. Dependendo do switch e do firmware, a alteração pode provocar uma nova negociação da ligação.

Para repor o estado anterior num Sophos Switch, utiliza-se eee em vez de no eee no mesmo Interface Configuration Mode:

configure terminal
interface gigabitethernet 0/1
eee
exit
exit
save
show eee

Desativar EEE não desativa Ethernet nem gigabit. A desvantagem é que o PHY deixa de poupar a mesma quantidade de energia durante os períodos de inatividade, pelo que a porta consome um pouco mais e pode gerar mais calor. Não há garantia de um aumento específico do débito. O que conta é o teste reproduzível antes e depois. Num switch não gerido sem opção EEE, a definição não pode ser alterada de forma fiável; para o teste é necessário contornar o dispositivo ou utilizar temporariamente um switch gerível.

Alterar Tunnel compression e MTU apenas de forma controlada

A interface RED pode ser editada em Network > Interfaces. Aí encontram-se Tunnel compression e MTU. A Sophos descreve Tunnel compression como uma forma de comprimir o tráfego RED e aumentar o débito, sobretudo em ligações lentas. Dados já comprimidos ou cifrados praticamente não podem ser reduzidos, enquanto a compressão acrescenta trabalho de processamento. Por isso, uma única definição não é adequada para todos os locais.

Para um teste A/B, documentam-se primeiro o estado inicial e as medições. Depois altera-se apenas Tunnel compression, guarda-se e repete-se exatamente a mesma série iPerf3. Em seguida, repõe-se o estado inicial ou documenta-se conscientemente a variante que demonstrou ser melhor. Guardar pode interromper brevemente o túnel RED, pelo que uma janela de manutenção e um acesso alternativo são recomendáveis.

MTU não é um controlo geral da velocidade. Só deve ser investigado quando os pacotes pequenos funcionam mas as transferências maiores param, existe fragmentação visível ou o iPerf3 mostra muitas retransmissões. Verificar MTU e MSS do Sophos Firewall em problemas de VPN explica o teste DF seguro, os tamanhos dos pacotes e a reposição. Sem uma constatação MTU reproduzível, mantém-se o valor inicial documentado.

Solução de problemas

Não é possível alterar o IP do RED no SFOS 22.0 MR2

No SFOS 22.0 MR2 Build 546, pode surgir a mensagem Failed to update RED interface ao alterar o endereço IP de uma interface RED existente. O problema é que o WebAdmin pode já mostrar o novo IP, embora a firewall continue a utilizar internamente o endereço antigo. Por isso, o IP visível não confirma, por si só, que a alteração foi bem-sucedida.

O workaround documentado pela Sophos também altera o nome da filial e volta a guardar a interface:

1. Documentar o IP RED atual, a máscara de rede, o Branch Name e qualquer intervalo DHCP RED existente.
2. Em Network > Interfaces, abrir a interface RED afetada e introduzir o IP pretendido.
3. Se surgir Failed to update RED interface, voltar a abrir a interface.
4. Alterar efetivamente o Branch Name, por exemplo de Branch-Zurich para Branch-Zurich-01, e voltar a guardar com Save.
5. Em 5. Device Management > 3. Advanced Shell, verificar com o comando apenas de leitura ifconfig se o novo endereço está ativo na interface RED:

ifconfig

O nome da interface depende da configuração e pode ser identificado em Network > Interfaces. Reiniciar o dispositivo, reiniciar um serviço ou eliminar a interface RED não faz parte deste workaround.

Se o novo IP RED estiver numa rede diferente do intervalo DHCP RED anterior, o SFOS desativa o servidor DHCP RED. Este é um comportamento normal do produto e não depende da mensagem de erro. Em Network > DHCP, é então necessário adaptar o servidor existente à nova rede ou criar um novo servidor DHCP. O intervalo de leases, os mapeamentos MAC estáticos, o gateway e o DNS têm de corresponder ao novo endereçamento.

Por fim, renovar o lease DHCP num cliente atrás do RED e verificar o endereço IP, o gateway, o DNS, o estado do túnel e o acesso previsto. No Log Viewer, o tráfego deve voltar a corresponder à regra de firewall esperada. Se o IP no backend continuar antigo apesar de se voltar a guardar, não existe atualmente uma correção de produção publicada para NC-184971. As regras ou interfaces dependentes não devem ser eliminadas por tentativa; em vez disso, deve efetuar-se uma cópia de segurança da configuração e contactar o Sophos Support.

RED não recebe endereço IP

Se o RED ficar preso na etapa do roteador ou o código de erro indicar DHCP ou gateway, a causa geralmente está no local remoto.

Verificar:

• O roteador do provedor fornece um endereço IP por DHCP?
• O cabo de rede está corretamente conectado à porta WAN?
• O gateway padrão é acessível?
• Um endereço IP estático foi totalmente inserido?
• O endereço IP, máscara de sub-rede, gateway e DNS estão corretos?
• Um dispositivo intermediário está bloqueando o tráfego?

Se o DHCP no local remoto não funcionar, o RED pode entrar em um loop de reinicialização.

RED não alcança a Internet

Se o roteador ou gateway for acessível, mas o LED da Internet não ficar verde permanentemente, o problema geralmente está atrás do roteador local.

Verificar:

• A conexão de Internet funciona com um cliente normal?
• O DNS funciona?
• O NTP é acessível?
• TCP 3400, UDP 3410 ou NTP 123 estão bloqueados?
• Existe um proxy ou firewall entre o RED e a Internet?
• A conexão do provedor é estável o suficiente?
• O serviço de provisionamento está acessível por HTTPS em TCP 443?

Para o aprovisionamento RED, o dispositivo deve alcançar o Sophos Provisioning Service. A Sophos documenta *.astaro.com através de TCP 3400 e UDP 3410; os restantes destinos do fabricante e os limites de validação estão em Verificar serviços e portas de saída da Sophos Firewall.

Um cliente na mesma rede que a porta WAN do RED pode executar telnet red.astaro.com 3400 para testar a resolução DNS e o estabelecimento de uma ligação TCP. Uma ligação bem-sucedida confirma apenas que TCP 3400 está acessível; não informa sobre UDP 3410, provisionamento, autenticação ou o túnel RED.

RED não alcança a Sophos Firewall

Se a Internet for acessível, mas o túnel não for estabelecido, deve-se verificar o lado da firewall.

Verificar:

• O serviço RED está ativado na Sophos Firewall?
• O RED está corretamente configurado?
• A ID RED e o Código de Desbloqueio estão corretos?
• O IP público ou o FQDN da firewall é acessível?
• Administration > Device access para RED está permitido na zona WAN apropriada?
• Um Local Service ACL permite o acesso do local remoto?
• TCP 3400 e UDP 3410 chegam à firewall?
• A hora do RED está adequada para o TLS handshake no provisioning manual?
• Um RED offline alcança NTP ou a exceção Local Service ACL planeada?

Na Advanced Shell, pode-se verificar se o tráfego RED está chegando:

tcpdump -ni any port 3400 or port 3410

Se nada chegar, o problema geralmente está antes da firewall: roteador do provedor, NAT, firewall intermediária, IP público incorreto, FQDN ou bloqueio de porta.

RED reinicia continuamente

Um loop de reinicialização pode ter várias causas:

• fornecimento de energia instável
• fonte de alimentação defeituosa
• sem endereço IP por DHCP
• configuração IP estática incorreta
• portas bloqueadas
• padrão de firmware RED desatualizado
• Código de Desbloqueio incorreto
• configuração RED danificada ou incorreta

Primeiro, verifique a alimentação, os cabos e o DHCP. Depois, verifique o padrão de firmware RED, a acessibilidade das portas e a configuração. Considere um Factory Reset apenas se as verificações anteriores não revelarem a causa. Antes disso, guarde a ID RED, o Unlock Code e a configuração da interface. Se estes dados não estiverem disponíveis, poderá ser necessário contactar o Sophos Support para voltar a autorizar o dispositivo.

Túnel está verde, mas nenhum tráfego flui

Este caso é particularmente comum. O RED está conectado, mas os clientes não alcançam sistemas internos ou a Internet.

Possíveis causas:

• Falta de regra de firewall ou está muito baixa.
• Interface RED está na zona errada.
• DHCP distribui gateway ou servidores DNS incorretos.
• Falta de roteamento de retorno para a rede RED.
• NAT traduz o tráfego inesperadamente.
• Tagging VLAN não está correto.
• Recurso de segurança bloqueia o tráfego.

Ordem de verificação:

1. Verificar IP do cliente, gateway e DNS.
2. Filtrar no Log Viewer pelo IP de origem do cliente RED.
3. Verificar correspondência da regra de firewall.
4. Executar Packet Capture na interface RED e na interface de destino.
5. Verificar o caminho de retorno do sistema ou rede de destino.
6. Controlar NAT e roteamento.

Para correspondências de regras incertas, consulte Testar regra de firewall com Log Viewer, Policy Test e Packet Capture.

Tráfego VLAN não funciona

No SD-RED 60, cenários VLAN são possíveis, mas o modo de porta, ID VLAN e modo RED devem corresponder.

Verificar:

• IDs VLAN estão corretas na firewall, RED e switch.
• Porta RED está configurada como Access, Hybrid ou Tagged Trunk adequadamente.
• Porta do switch no local remoto está corretamente tagged ou untagged.
• DHCP e DNS estão planejados por VLAN.
• Regras de firewall existem para as respectivas redes VLAN.
• O modo RED escolhido suporta o cenário VLAN desejado.

Para a solução de problemas, uma rede de teste untagged simples é útil. Se esta funcionar, a causa geralmente está na ID VLAN, tagging, modo de porta ou configuração do switch.

Pontos de Acesso RED permanecem inativos

Se os Pontos de Acesso RED ou funções Wi-Fi em cenários VLAN permanecerem inativos, a opção DHCP 234 pode ser relevante. Isso é especialmente relevante em casos onde a comunicação RED ou Access Point ocorre através de interfaces VLAN.

Configure esta opção apenas quando o cenário se aplicar e for conhecido o endereço IP da interface da firewall que os dispositivos devem alcançar. Escolher corretamente os modos de funcionamento do Sophos RED explica a relação completa entre a zona Wi-Fi, a VLAN e a opção DHCP 234. A opção 234 não é a primeira verificação para problemas gerais de ligação RED.

Provisionamento offline é sobrescrito

Se um RED foi provisionado online primeiro e depois provisionado offline via USB, uma configuração online antiga pode permanecer no Sophos Provisioning Server. Se o RED não alcançar a firewall, ele pode provisionar novamente online e sobrescrever a configuração USB.

Nesse caso, o RED deve ser provisionado offline novamente. Além disso, a configuração online antiga deve ser removida através do suporte da Sophos.

Diagnóstico e verificação operacional

Pontos de diagnóstico na Sophos Firewall

Para problemas RED, estes locais são úteis:

• Network > Interfaces para interface RED e status
• Administration > Device access para liberações de serviço RED
• Rules and policies > Firewall rules para tráfego da rede RED
• Diagnostics > Packet capture para verificação de caminho
• Log viewer com eventos RED, de firewall e de sistema
• Backup & firmware > Pattern updates para padrão de firmware RED
• Advanced Shell com tcpdump

Uma ligação bem-sucedida também pode ser confirmada nos logs específicos do dispositivo. Em /log/red.log surge uma mensagem como New connection from ... with ID <RED ID>. Em /log/red-<RED ID>.log aparecem depois connected OK, pushing config e, após uma nova ligação, is now re-connected. Estas linhas confirmam a ligação e a transferência da configuração, mas não um caminho de tráfego produtivo funcional. O log completo específico do dispositivo pode conter dados de provisionamento e configuração e deve ser limpo antes de ser partilhado.

Para arquivos de log e atribuição de serviços, consulte Solução de problemas da Sophos Firewall: Serviços e Logs.

Se, pelo contrário, toda a firewall iniciar no modo Failsafe com Failed to start Red server service, não se trata de um erro normal do túnel RED. O runbook de Failsafe explica a diferenciação do Build e a recolha de provas antes do recovery.

Lista de verificação operacional

Antes do lançamento:

• ID RED e Código de Desbloqueio documentados.
• Endereço público da firewall ou FQDN verificado.
• TCP 3400, UDP 3410 e NTP 123 verificados.
• Serviço RED e Device Access planejados na firewall.
• Zona, DHCP, roteamento e regras de firewall definidos.
• Modo VLAN testado antecipadamente, se necessário.

Após a conexão:

• LEDs indicam estabelecimento bem-sucedido do túnel.
• Interface RED está ativa.
• Cliente recebe IP, gateway e DNS.
• Log Viewer mostra a regra de firewall esperada.
• Sistemas de destino internos e caminho para a Internet funcionam conforme planejado.
• Padrão de firmware está atualizado.

Em operação:

• Verificar regularmente o padrão de firmware RED.
• Testar conexões do local após atualizações da firewall.
• Testar túneis RED entre firewalls separadamente dos locais SD-RED físicos.
• Após uma atualização para o SFOS 21.0 MR2 ou 21.5 MR1, verificar os efeitos da máscara /32 corrigida nos hosts do sistema RED.
• Comparar o débito RED com uma baseline local, um e quatro fluxos iPerf3 e ambas as direções.
• Manter 802.3az ou EEE desativado nas portas de switch diretamente ligadas e voltar a verificar após a substituição de switches.
• Alterar Tunnel compression e MTU apenas com um teste documentado antes e depois.
• Incluir locais RED em monitoramento, backup e planejamento de emergência.

FAQ