Reiniciar a GUI do WebAdmin do Sophos Firewall

Se a GUI do WebAdmin do Sophos Firewall deixar de responder, não será necessário reiniciar imediatamente todo o firewall. Enquanto o roteamento, a VPN e as regras de firewall continuarem funcionando e o SSH ou o console local permanecerem acessíveis, os dois serviços do WebAdmin, tomcat e apache, poderão ser verificados e reiniciados separadamente.

Os comandos a seguir são destinados a um firewall autônomo. Em um cluster HA, o modo de sincronização correto depende do serviço, do nó, da compilação do SFOS e do problema específico. Não use -ds nosync em HA sem verificar antes se essa opção é apropriada.

⚠️ Reiniciar um serviço altera o estado do sistema, encerra as sessões ativas do WebAdmin e também pode interromper brevemente o User Portal. Primeiro salve os logs relevantes, informe os outros administradores e prepare uma forma de acesso alternativa para locais remotos.

Procedimento rápido para um firewall autônomo

Este procedimento é adequado quando o WebAdmin mostra um Internal Server Error, um HTTP 503, uma página de login incompleta ou uma interface que não responde de forma permanente, enquanto o SSH e as outras funções do firewall continuam disponíveis.

1. Entre como admin por SSH ou pelo console local. Se o SSH ainda não estiver configurado, Conectar-se ao Sophos Firewall por SSH explica como preparar um acesso seguro.
2. Abra 5. Device Management > 3. Advanced Shell.
3. Exiba os erros mais recentes do WebAdmin e copie as saídas relevantes para a documentação da alteração ou para um caso de suporte:

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

4. Verifique o estado atual dos serviços:

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

5. Se um serviço mostrar STOPPED, execute apenas o comando de inicialização correspondente:

# Se tomcat estiver STOPPED:
service tomcat:start -ds nosync

# Se apache estiver STOPPED:
service apache:start -ds nosync

6. Se um serviço mostrar DEAD, reinicie apenas esse serviço. Se ambos mostrarem RUNNING, mas o WebAdmin continuar inutilizável, comece por tomcat:

service tomcat:restart -ds nosync

Teste o WebAdmin novamente. Somente se apache mostrar DEAD ou se o problema continuar após a reinicialização de tomcat, execute:

service apache:restart -ds nosync

7. Aguarde alguns segundos, reabra o WebAdmin a partir da rede de gerenciamento prevista e verifique novamente o estado dos serviços:

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

Os dois serviços devem mostrar RUNNING. No entanto, o teste funcional é decisivo: login, painel, Log Viewer e uma página de configuração não crítica devem carregar de forma estável. Um processo em execução, por si só, não comprova que o WebAdmin esteja funcionando corretamente.

As sessões SSH inativas são encerradas após 15 minutos. Por isso, prepare a verificação dos logs, a reinicialização e a validação antes de entrar no Advanced Shell, para que uma sessão expirada não interrompa o procedimento.

Verificar se a reinicialização de um serviço é apropriada

Por trás do nome de serviço tomcat está o servidor de aplicações web Jetty; apache é o servidor HTTP Apache. Os dois componentes são usados pelo WebAdmin e pelo User Portal. Seus logs ficam disponíveis no Advanced Shell:

• Servidor de aplicações: /log/tomcat.log
• Servidor web: /log/apache.log e /log/apache_access.log
• Outros erros do servidor web: /log/error_log.log

Nem todo problema do WebAdmin tem origem nesses serviços. O tipo de erro determina a próxima etapa:

• Internal Server Error, HTTP 503 ou página de login incompleta: Verifique tomcat, apache e os logs indicados. Uma reinicialização direcionada é apropriada neste caso.
• Aviso de certificado: Verifique o nome, a validade e a cadeia de confiança do certificado. Reiniciar um serviço não corrige um certificado incorreto.
• Tempo limite ou falha de acesso a partir de apenas uma rede: Verifique a rota, a rede de gerenciamento e Administration > Device access. Os serviços locais do firewall são permitidos por meio de Device Access, e não por uma regra de firewall comum. Device Access e Local Service ACL explica a configuração segura.
• Apenas um navegador é afetado: Teste uma sessão privada, um segundo navegador ou outro cliente de administração antes de alterar o firewall.
• WebAdmin, SSH, VPN ou outros serviços falham ao mesmo tempo: Isso aponta mais para carga do sistema, armazenamento, banco de dados, HA ou um problema geral do sistema. Não reinicie serviços aleatoriamente.

Se uma atualização de firmware, hotfix ou padrões, uma sincronização de HA, uma sessão de depuração do suporte ou uma tarefa ativa do Central estiver em andamento, primeiro identifique e, quando possível, conclua esse processo. Caso contrário, será difícil determinar depois se o problema veio da atualização, do Central, de HA ou da reinicialização do serviço.

Preservar evidências antes da intervenção

Uma reinicialização pode remover as mensagens de erro atuais do contexto visível. Para um problema recorrente ou caso de suporte, registre pelo menos o horário, a compilação do SFOS, o caminho de acesso afetado e as mensagens mais recentes de tomcat.log, apache.log e error_log.log.

Se o WebAdmin ainda funcionar parcialmente, logs individuais ou um Consolidated Troubleshooting Report poderão ser baixados em Diagnostics > Tools. Se apenas o shell estiver disponível, Salvar logs do Sophos Firewall para suporte e análise explica o procedimento. Em um cluster HA, cada nó armazena seus próprios logs; verifique Primary e Auxiliary separadamente quando necessário.

Antes de uma reinicialização em produção, confirme também:

• se outros administradores ou uma alteração em andamento serão afetados;
• se o SSH, o console local, o Sophos Central ou outra conexão de gerenciamento oferecem um caminho de retorno;
• se o WebAdmin é o único serviço afetado;
• se o nó correto e instruções atuais da Sophos específicas para o serviço estão disponíveis para um cluster HA.

Reiniciar os serviços do Sophos Firewall com segurança explica o uso geral dos nomes de serviço, estados, logs e limites de HA. Solução de problemas do Sophos Firewall: serviços e logs contém outras correspondências entre funções e arquivos de log.

Verificar o resultado e investigar problemas recorrentes

Leia os logs novamente após a reinicialização. Novos erros imediatamente após a inicialização são mais úteis do que mensagens antigas sem referência de horário:

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

Em seguida, abra o painel, o Log Viewer e uma página não crítica. Restrinja novamente qualquer acesso temporário por SSH ou Device Access às origens de administração previstas.

Se o problema voltar, a reinicialização do serviço foi apenas uma recuperação temporária. A análise da causa raiz deverá incluir:

• espaço livre nas partições, relatórios locais e estado do banco de dados;
• uso de CPU e RAM, além de logs de sistema incomuns;
• sessões simultâneas de administradores ou uso intensivo da captura de pacotes;
• tarefas ativas ou com falha no Central;
• função de HA, sincronização e nó afetado;
• alterações na configuração, no certificado, na interface ou em Device Access imediatamente antes do problema.

Gerenciar o armazenamento e os relatórios do Sophos Firewall ajuda com problemas de armazenamento e relatórios. As alterações feitas antes da falha podem ser rastreadas com os logs do Audit Trail do Sophos Firewall.

Uma breve anotação operacional evita que um problema recorrente seja tratado apenas com reinicializações repetidas:

Data, hora e fuso horário:
Firewall e nó HA, se aplicável:
Versão e compilação do SFOS:
Sintomas:
Logs verificados:
Comando executado:
Resultado e próxima ação:

Se o WebAdmin continuar indisponível

Se um serviço permanecer em STOPPED ou DEAD, a reinicialização retornar um erro ou o problema voltar imediatamente, salve tomcat.log, apache.log, error_log.log, o estado do sistema e o CTR para análise com o Sophos Support. Reiniciar outros serviços aleatoriamente provavelmente só prejudicará as evidências.

Se nem o WebAdmin nem o SSH estiverem acessíveis, o caminho de recuperação dependerá do ambiente: console local por cabo de console ou Micro-USB nos modelos compatíveis, Sophos Central, uma alternativa de HA preparada ou uma reinicialização planejada. Em locais remotos, determine quem poderá obter acesso local se o firewall não iniciar corretamente. Em um cluster HA, não inicie um failover sem verificação apenas porque o WebAdmin não responde enquanto o tráfego de produção continua fluindo normalmente.

Uma reinicialização completa é mais invasiva do que reiniciar os serviços afetados. Considere-a apenas quando vários serviços centrais forem afetados, o firewall continuar instável, um processo de firmware ou hotfix exigir a reinicialização ou o Sophos Support recomendá-la. Primeiro confirme o backup, a janela de manutenção e os efeitos sobre VPN, roteamento, RED, wireless e serviços publicados. Planejar corretamente o backup e a restauração do Sophos Firewall explica a preparação.