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 encaminhamento, a VPN e as regras de firewall continuarem a funcionar e o SSH ou a consola local permanecerem acessíveis, os dois serviços do WebAdmin, tomcat e apache, poderão ser verificados e reiniciados separadamente.

Os comandos seguintes destinam-se a um sistema autónomo. Num cluster HA, o modo de sincronização correto depende do serviço, do nó, da build do SFOS e do problema específico. Não utilize -ds nosync em HA sem verificar primeiro se essa opção é adequada.

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

Procedimento rápido para um sistema autónomo

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

Inicie sessão como admin por SSH ou pela consola local. Se o SSH ainda não estiver configurado, Ligar ao Sophos Firewall por SSH explica como preparar um acesso seguro.
Abra 5. Device Management > 3. Advanced Shell. A Device Console, na opção 4 do menu principal, é outro ambiente de comandos. Execute comandos service e Linux na Advanced Shell, não na Device Console.

O SFOS 22 documenta tail -f <logfilename>.log, service -S | grep <servicename> e service <service name>:<start/restart/stop/debug> -ds nosync na Advanced Shell. Termine cada log em tempo real com Ctrl+C antes de abrir o seguinte. As consultas de estado abaixo são obrigatórias: se tomcat ou apache não aparecer, não execute um comando derivado. Os comandos desta revisão não foram testados em laboratório numa firewall.

Apresente 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:

cd /log
tail -f tomcat.log

Reproduza uma vez o acesso afetado, anote a hora e termine a saída com Ctrl+C. Se necessário, repita o mesmo comando oficialmente documentado com apache.log e error_log.log. Desta forma, o teste fica associado a uma hora específica sem misturar três saídas em tempo real.

Verifique o estado atual dos serviços:

service -S | grep tomcat
service -S | grep apache

Se um serviço mostrar STOPPED, execute apenas o comando de início correspondente:

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

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

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

service tomcat:restart -ds nosync

Teste novamente o WebAdmin. Execute o comando seguinte apenas se apache mostrar DEAD ou se o problema continuar após o reinício de tomcat:

service apache:restart -ds nosync

Aguarde até que ambos os serviços apresentem um estado estável, reabra o WebAdmin a partir da rede de gestão prevista e verifique novamente o seu estado:

service -S | grep tomcat
service -S | grep apache

Os dois serviços devem mostrar RUNNING. No entanto, o teste funcional é decisivo: início de sessão, 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 a funcionar corretamente.

As sessões SSH inativas terminam após 15 minutos. Por isso, prepare a verificação dos logs, o reinício e a validação antes de entrar na Advanced Shell, para que uma sessão expirada não interrompa o procedimento. Se o SSH tiver sido permitido temporariamente para outra zona ou através de uma Local service ACL exception rule, restaure exatamente o estado anteriormente anotado e verifique o acesso a partir da origem de administração prevista.

Verificar se o reinício de um serviço é adequado

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 utilizados pelo WebAdmin e pelo User Portal. Os respetivos logs estão disponíveis na 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 início de sessão incompleta: Verifique tomcat, apache e os logs indicados. Um reinício direcionado é adequado 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 gestão e Administration > Device access. Os serviços locais do firewall são permitidos através 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: Isto aponta mais para carga do sistema, armazenamento, base de dados, HA ou um problema geral do sistema. Não reinicie serviços aleatoriamente.

Se estiver em curso 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, identifique primeiro esse processo e, quando possível, deixe-o terminar. Caso contrário, será difícil determinar depois se o problema veio da atualização, do Central, de HA ou do reinício do serviço.

Preservar evidências antes da intervenção

Um reinício pode remover as mensagens de erro atuais do contexto visível. Para um problema recorrente ou caso de suporte, registe pelo menos a hora, a build 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, é possível transferir logs individuais ou um Consolidated Troubleshooting Report em Diagnostics > Tools. Se apenas a shell estiver disponível, Guardar logs do Sophos Firewall para suporte e análise explica o procedimento. Num cluster HA, cada nó armazena os seus próprios logs; verifique Primary e Auxiliary separadamente quando necessário.

Antes de um reinício em produção, confirme também:

se outros administradores ou uma alteração em curso serão afetados;
se o SSH, a consola local, o Sophos Central ou outra ligação de gestão 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 em segurança explica a utilização geral dos nomes de serviço, estados, logs e limites de HA. Resolução de problemas do Sophos Firewall: serviços e logs contém outras correspondências entre funções e ficheiros de log.

Verificar o resultado e investigar problemas recorrentes

Leia novamente os logs após o reinício. Os novos erros imediatamente após o arranque são mais úteis do que mensagens antigas sem referência de hora:

cd /log
tail -f tomcat.log

Execute uma vez o teste funcional, termine a saída com Ctrl+C e, se necessário, repita o comando com apache.log ou 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, o reinício 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 da base 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.

Gerir 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 nota operacional evita que um problema recorrente seja tratado apenas com reinícios repetidos:

Data, hora e fuso horário:
Firewall e nó HA, se aplicável:
Versão e build 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, o reinício devolver um erro ou o problema voltar imediatamente, guarde 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: consola local por cabo de consola ou Micro-USB nos modelos compatíveis, Sophos Central, uma alternativa de HA preparada ou um reinício planeado. Em sites remotos, determine quem poderá obter acesso local se o firewall não arrancar corretamente. Num 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 a fluir normalmente.

Um reinício completo é mais invasivo do que reiniciar os serviços afetados. O comando oficialmente documentado system restart deve ser executado na Device Console, não na Advanced Shell, e provoca um failover num cluster HA. Considere-o apenas quando vários serviços centrais forem afetados, o firewall continuar instável, um processo de firmware ou hotfix exigir o reinício ou o Sophos Support o recomendar. Primeiro, confirme o backup, a janela de manutenção e os efeitos sobre VPN, encaminhamento, RED, wireless e serviços publicados. Após a confirmação, não há caminho de retorno pela CLI; se o firewall não voltar, utilize o acesso local ou out-of-band preparado em vez de repetir o reinício às cegas. Planear corretamente o backup e o restauro do Sophos Firewall explica a preparação.