Sophos Firewall Reiniciar GUI do WebAdmin

Se a GUI do Sophos Firewall WebAdmin não estiver mais acessível, todo o firewall não precisará ser reiniciado imediatamente. Muitas vezes basta reiniciar os serviços WebAdmin de forma controlada utilizando o Advanced Shell. Isso é significativamente menos invasivo do que uma reinicialização completa e pode economizar um tempo valioso durante uma janela de suporte ou manutenção.

Os sintomas típicos são:

• A GUI do WebAdmin mostra Internal Server Error.
• A página de login ou painel não carrega mais completamente.
• O WebAdmin responde muito lentamente ou trava após um clique.
• Outros serviços, como regras de roteamento, VPN ou firewall, continuam em execução.
• SSH ou console local ainda estão acessíveis.

Na prática, isso pode ocorrer após carga pesada da GUI, múltiplas sessões de administração simultâneas, uso intenso de captura de pacotes ou problemas gerais de recursos. Se o firewall estiver geralmente instável, as partições estiverem cheias ou vários serviços estiverem inativos, a GUI do WebAdmin não deve ser a única coisa a considerar. Então Sophos Firewall Serviços e registros, Sophos Firewall Reiniciar serviços com segurança e Verifique o espaço de armazenamento e gerencie relatórios também cabem.

⚠️ Importante: A reinicialização do serviço é uma intervenção no firewall. Antes de fazer alterações produtivas, deve ficar claro quem está conectado, se uma janela de manutenção é necessária e se o acesso alternativo via SSH, console local ou parceiro HA está disponível.

Requisitos

Para uma reinicialização direcionada, você precisa:

• Acesso ao usuário admin.
• Acesso SSH ou acesso ao console local.
• Acesso ao Advanced Shell.
• Uma imagem de erro clara: o WebAdmin foi afetado, mas o firewall não precisa ser reiniciado completamente.
• O menor tempo possível de manutenção ou diagnóstico se vários administradores forem afetados.

Se o SSH ainda não estiver preparado, Sophos Firewall conectar via SSH ajudará. O acesso em si é controlado via Administration > Device access. Configure Device Access corretamente é o artigo básico certo para proteger HTTPS/WebAdmin e SSH.

Após o login por SSH, abre-se Advanced Shell através de 5. Device Management > 3. Advanced Shell. A Sophos fecha sessões SSH inativas após 15 minutos. Durante um incidente de GUI, a verificação de logs, o estado dos serviços e o reinício devem por isso ser feitos sem pausas longas, ou a sessão deve ser reaberta conscientemente se necessário.

Verifique brevemente antes de reiniciar

Antes de reiniciar os serviços, você deve isolar o problema:

1. Verifique se apenas o WebAdmin foi afetado ou se as regras de VPN, roteamento, DNS ou firewall também estão falhando.
2. Se possível, teste com um segundo navegador ou janela privada.
3. Verifique se outros administradores estão trabalhando atualmente na GUI.
4. Faça login via SSH e abra o Advanced Shell.
5. Opcionalmente, visualize brevemente os logs relevantes.

Os arquivos de log mais importantes são:

• Servidor web WebAdmin: /log/apache.log e /log/apache_access.log.
• Aplicativo WebAdmin: /log/tomcat.log.
• Erro de GUI/sistema: /log/error_log.log.

Exemplo de uma inspeção visual rápida:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log

Se quiser fazer backup dos logs de um caso de suporte, você deverá exportá-los antes de reiniciar novamente. O processo está em Sophos Firewall Fazer backup de logs para suporte e análise.

Classifique o padrão de erro corretamente

Nem todo problema do WebAdmin é causado por tomcat ou apache. Antes de reiniciar, uma breve classificação ajudará:

Classificação típica:

• WebAdmin mostra Internal Server Error: Muitas vezes é devido ao aplicativo GUI ou servidor web. Verifique tomcat.log e apache.log e reinicie os serviços especificamente.
• O navegador relata aviso de certificado: Primeiro verifique o certificado, o nome e a cadeia confiável, não reinicie os serviços diretamente.
• A conexão está sendo executada no tempo limite: Então Device Access, roteamento, ACL, VPN ou rede de gerenciamento são mais prováveis. Consulte disponibilidade e Administration > Device access.
• O login funciona, o painel trava depois: Verifique a carga da GUI, sessão, relatórios, memória ou banco de dados.
• WebAdmin e SSH não estão acessíveis: Então é mais sobre caminho de acesso, Device Access ou status do sistema. Verifique o console local, o parceiro HA ou o gerenciamento central.
• Vários serviços falham ao mesmo tempo: Isto sugere um problema de sistema em vez de um problema puro de GUI. Faça backup dos logs, verifique o espaço de armazenamento e avalie a reinicialização ou o caso de suporte.

Esta classificação evita que os serviços WebAdmin sejam reiniciados desnecessariamente em caso de problema de acesso à rede ou ao dispositivo. Se apenas o acesso de uma rede específica falhar, Device Access e Local Service ACL a Sophos Firewall geralmente é mais importante do que reiniciar o serviço.

Quando é melhor adiar o reinício

Reiniciar tomcat e apache é relativamente direcionado, mas ainda é uma intervenção no nível administrativo do firewall. Nessas situações, você deve primeiro estabilizar ou documentar brevemente:

• Atualização de firmware, hotfix ou atualização de padrão em execução: Não intervenha nos serviços WebAdmin ao mesmo tempo enquanto o processo de atualização estiver ativo.
• O cluster HA está sincronizando no momento: Verifique primeiro a função HA, a sincronização e o nó ativo.
• Depuração de suporte ou coleta de logs em execução: Primeiro salve os logs relevantes e, em seguida, reinicie os serviços.
• A tarefa central está atualmente ativa: Verifique a fila de tarefas para que uma alteração central em andamento não seja misturada com um problema de GUI local.
• Apenas um navegador do administrador é afetado: Teste primeiro a sessão privada, o segundo navegador ou outro cliente.

Este freio curto economiza trabalho de explicação posterior. Se não estiver mais claro imediatamente após a reinicialização se o erro veio do WebAdmin, Central, HA ou de uma atualização em andamento, a análise se tornará desnecessariamente difícil.

Reinicie os serviços WebAdmin

A GUI do WebAdmin depende principalmente de dois serviços:

• tomcat: aplicativo WebAdmin.
• apache: Servidor web WebAdmin.

Antes do reinício, convém verificar primeiro o estado:

service -S | grep -iE 'tomcat|apache'

Se um serviço estiver STOPPED, iniciá-lo de forma direcionada é mais limpo do que reiniciar às cegas:

service tomcat:start -ds nosync
service apache:start -ds nosync

Se tomcat ou apache mostrarem DEAD, ou se mostrarem RUNNING mas o WebAdmin continuar sem funcionar, ambos os serviços podem ser reiniciados um após o outro:

service tomcat:restart -ds nosync
service apache:restart -ds nosync

Aguarde alguns segundos e abra a GUI do WebAdmin novamente. Se o login funcionar novamente, você ainda deverá verificar se há erros recorrentes visíveis no Log Viewer ou nos logs do sistema.

Verifique o status

Se reiniciar não for suficiente, você pode verificar o status dos serviços:

service tomcat:status -ds nosync
service apache:status -ds nosync

Você também pode verificar se os serviços aparecem na lista de serviços:

service -S | grep -E 'tomcat|apache'

A atribuição geral dos serviços, módulos e arquivos de log está em Sophos Firewall Solução de problemas: serviços e registros. Também explica quando Log Viewer, Advanced Shell ou arquivos de log individuais são a melhor fonte de análise.

Validar após reinicialização

Se o WebAdmin for carregado novamente, o problema ainda não foi completamente resolvido. Você deve verificar brevemente se a GUI permanece estável e se a causa se torna visível novamente.

Verificação de acompanhamento útil:

1. Abra o WebAdmin na rede de gerenciamento pretendida.
2. Faça login com uma conta de administrador e painel de teste, Log Viewer e uma página de configuração não crítica.
3. Verifique tomcat.log, apache.log e error_log.log novamente para novos erros.
4. Verifique o espaço de armazenamento e os relatórios locais se a GUI estava lenta ou vazia anteriormente.
5. Exclua sessões administrativas abertas, cache do navegador ou acesso paralelo de administrador como causa.
6. Restrinja temporariamente o SSH permitido ou o acesso ao dispositivo novamente.
7. Para clusters de alta disponibilidade, verifique se você está trabalhando no nó esperado.

Se o problema persistir, você não deve reiniciar tomcat e apache todos os dias. Em seguida, é necessária uma análise da causa raiz: espaço de armazenamento, status do banco de dados, relatórios, erros de GUI, carga do sistema, função de HA e alterações recentes de configuração. Para alterações pouco antes do erro, Sophos Firewall Verifique os registros da trilha de auditoria é útil.

Se o WebAdmin ainda estiver indisponível

Se a GUI ainda estiver indisponível após reiniciar tomcat e apache, você não deve reiniciar quantos serviços desejar. Uma limitação estruturada faz mais sentido:

• Verifique Device Access: HTTPS/WebAdmin é permitido na zona e origem atuais?
• Excluir navegador: Cache de teste, sessão privada ou segundo navegador.
• Verificar certificado: Um certificado expirado ou incorreto pode dificultar o acesso, mas geralmente não produz um erro interno real do servidor.
• Verifique a carga do sistema: O alto uso de CPU, RAM ou disco pode afetar o WebAdmin.
• Verifique o espaço em disco: Partições cheias podem causar problemas de GUI e de relatório.
• Verifique os registros: Verifique tomcat.log, apache.log e error_log.log em busca de erros atuais.
• Observação contexto de HA: Para clusters de HA, verifique em qual nó você está trabalhando e qual nó está ativo.
• Verifique as alterações recentes: Audit Trail e Config Studio podem mostrar se Device Access, certificado, interface ou configurações de administrador foram alterados recentemente.

Se o WebAdmin e o SSH não estiverem acessíveis, dependendo da localização, restam apenas o console local, o gerenciamento Sophos Central, o failover de HA ou uma reinicialização planejada. Em ambientes produtivos, este caso deve ser preparado no processo de operação e recuperação.

Sites remotos e clusters HA

Com um único firewall no local principal, a reinicialização do WebAdmin geralmente é fácil de controlar. Para locais remotos ou clusters de HA, você deve verificar com mais detalhes antecipadamente qual caminho o acesso ocorre e qual nível de fallback está disponível.

Perguntas importantes:

• O acesso é direto da rede de gerenciamento, via VPN, via Sophos Central ou via jump host?
• O SSH é realmente acessível ou apenas uma sessão WebAdmin existente funciona?
• Existe alguém no local que possa verificar o aparelho, se necessário?
• Para HA: em qual nó você está trabalhando e qual nó é atualmente primário?
• Um failover planejado criará mais riscos do que a reinicialização direcionada de tomcat e apache?
• Os logs e o tempo são documentados antes que um failover ou reinicialização dificulte a análise?Em ambientes de alta disponibilidade, você não deve fazer failover automaticamente só porque o WebAdmin está pendurado no nó ativo. Se o tráfego continuar, uma reinicialização direcionada do serviço GUI geralmente será menos invasiva. No entanto, se vários serviços forem afetados, o nó ativo parecer instável ou o acesso for completamente perdido, o caso pertence a um processo de HA controlado ou de recuperação de site.

Quando uma reinicialização completa faz mais sentido

Uma reinicialização não é a primeira medida para uma GUI WebAdmin suspensa. Mas pode ser útil se:

• vários serviços centrais já não respondem
• o firewall permanece instável após a reinicialização do serviço
• Problemas de memória ou banco de dados foram resolvidos e é necessária uma inicialização limpa
• O Suporte Sophos ou uma janela de manutenção especifica isso
• um cluster HA pode fazer failover de maneira controlada

Antes da reinicialização, o backup, as janelas de manutenção, o acesso à localização e o impacto na VPN, roteamento, RED, sem fio e serviços publicados devem ser conhecidos.

Lista de verificação

• Imagem de erro documentada: Internal Server Error, timeout ou página WebAdmin vazia.
• SSH ou console local disponível.
• Advanced Shell aberto.
• tomcat.log e apache.log verificados brevemente.
• Estado verificado com service -S | grep -iE 'tomcat|apache'.
• service tomcat:restart -ds nosync executado.
• service apache:restart -ds nosync executado.
• WebAdmin testado novamente.
• Verificou o espaço de armazenamento, Device Access e os logs do sistema em busca de erros recorrentes.
• Logs salvos para suporte em caso de interrupções produtivas.
• Verificou atualizações contínuas, sincronização HA, tarefas centrais ou depuração de suporte antes de reiniciar.
• SSH temporário ou compartilhamentos de acesso a dispositivos foram removidos novamente.
• Erros recorrentes não ficam ocultos apenas nas reinicializações do serviço.

Perguntas frequentes