Reiniciar serviços da Sophos Firewall em segurança
A forma mais segura de reiniciar um serviço específico da Sophos Firewall é em System services > Services. Se o serviço não aparecer aí, isso não justifica executar um comando shell qualquer: utilizar a Advanced Shell apenas com instruções atuais da Sophos específicas para o serviço ou num caso de suporte. Primeiro, é necessário identificar o serviço afetado e determinar que ligações o reinício poderá interromper.
⚠️ Importante: Reiniciar um serviço altera o estado do sistema e pode interromper VPN, routing, DNS, DHCP, acesso web ou acesso administrativo. Guardar previamente o estado e os logs e garantir um acesso alternativo para locais remotos.
Reiniciar um serviço pelo WebAdmin
Antes de clicar, registar o estado atual, a hora exata do erro e o teste funcional que falha. Os ficheiros relevantes podem ser descarregados individualmente em Diagnostics > Tools > Troubleshooting logs. Para um caso de suporte, um Consolidated troubleshooting report (CTR) inclui também o estado do sistema, os processos e a utilização de recursos. Num local remoto, a verificação prévia deve ainda incluir uma janela de manutenção e acesso alternativo.
- Abrir System services > Services.
- Verificar o serviço afetado e o respetivo estado atual. Não iniciar um serviço intencionalmente parado ou não configurado.
- Em Manage, clicar em Restart.
- Aguardar que o serviço regresse ao estado anterior
Runninge testar depois a função afetada.
O WebAdmin apresenta, entre outros, Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, DHCPv6 server, Router advertisement service, Hotspot e Packet capture and Live connections. Se um serviço não estiver configurado, o botão permanece desativado. Anti-spam exige uma política de spam de entrada ou saída. Parar Packet capture and Live connections termina as capturas em curso e deixa indisponível a vista Live Connections. Se o Packet Capture não iniciar mesmo com o interruptor ativo, a Sophos indica especificamente este reinício pelo WebAdmin como passo de recuperação.
O reinício de um serviço não tem rollback que restaure sessões ativas. Por isso, o estado a preservar é o estado do serviço registado previamente. Se um serviço que estava ativo não regressar a Running, não clicar repetidamente em Restart. Registar uma nova hora, descarregar o log ou o CTR e investigar a falha ou contactar o Sophos Support.
Em Control Center > System, o estado dos serviços mostra se um serviço está parado ou não conseguiu iniciar. É um bom ponto de partida, mas não substitui um teste funcional. Se apenas a interface WebAdmin deixar de responder, utilizar a instrução específica Reiniciar a GUI do Sophos Firewall WebAdmin.
Serviço antivírus parado após falhas nas atualizações de padrões
Se o serviço Antivirus permanecer parado depois de falharem as atualizações de padrões SAVI e AVIRA, não se deve clicar repetidamente em Restart. Primeiro, guardar a versão e o build do firmware, a hora da falha e os ficheiros avd.log e up2date_av.log associados. Em Backup & firmware > Pattern updates, registar também a última atualização bem-sucedida e o estado atual: Ready to install, Downloading, Success ou Failed. O procedimento geral para verificar estes estados está em Configurar e verificar atualizações de padrões no Sophos Firewall.
A Sophos regista este problema como NC-180066; foi corrigido no SFOS 22.0 MR2 Build 546. Se os sintomas corresponderem num build anterior do SFOS 22, verificar o caminho suportado com a preparação da atualização do firmware e atualizar primeiro para MR2 Build 546 ou para uma versão posterior aprovada. Em geral, é possível efetuar um único reinício em System services > Services, mas a Sophos não o documenta como solução alternativa nem como correção para NC-180066, e esse reinício não substitui a atualização do firmware.
Só depois da atualização do firmware, clicar em Update pattern now em Backup & firmware > Pattern updates. A atualização do padrão Antivirus afetado deve atingir o estado Success e o serviço Antivirus deve permanecer ativo. O estado apresentado do serviço não é suficiente: a atualização do padrão também deve terminar com êxito. Se o problema voltar a ocorrer no MR2 Build 546 ou posterior, enviar ao Sophos Support os logs e as horas guardados em vez de continuar a assumir que se trata de NC-180066.
Reiniciar o IPsec através de VPN Management
O menu principal da CLI disponibiliza em 6. VPN Management > Restart VPN Service um reinício suportado do daemon do serviço VPN. A Sophos avisa que esta operação desliga todos os túneis VPN. Se apenas uma ligação VPN tiver de ser restabelecida, utilizar antes a respetiva ação no WebAdmin. Antes do reinício, guardar o estado dos túneis, a hora exata e strongswan.log; depois, verificar novamente as Child SAs, os peers e o tráfego real das aplicações. O reinício não corrige erros de proposal, routing ou NAT.
No mesmo menu, é possível gerar novamente o par de chaves RSA utilizado para autenticação IPsec. Não se trata de um reinício do serviço, mas de uma mudança de chaves. Nas ligações com RSA key, os peers precisam depois da nova chave pública; os utilizadores de acesso remoto têm de voltar a descarregar a configuração VPN. A Sophos não documenta um regresso com um clique ao par de chaves anterior. Esta ação só deve ser utilizada como rotação planeada, com inventário completo dos túneis, janela de manutenção e acesso administrativo alternativo, nunca como passo geral de troubleshooting. Também não corrige problemas de PSK ou certificados.
Reiniciar um serviço pela Advanced Shell
Utilizar a Advanced Shell apenas quando instruções atuais da Sophos indicarem o serviço e o comando exatos ou quando o Sophos Support os fornecer. Para acesso SSH e verificação da chave do host, seguir Ligar à Sophos Firewall por SSH. O SSH só deve ser permitido a partir de redes administrativas fidedignas; as definições adequadas estão em Device Access e Local Service ACL. As sessões SSH inativas são encerradas após 15 minutos.
Depois de iniciar sessão, abrir:
5. Device Management > 3. Advanced Shell
A Device Console, na opção 4 do menu, valida os comandos documentados e destina-se a diagnósticos de rede e sistema suportados. Já a Advanced Shell, em 5. Device Management > 3. Advanced Shell, é uma shell Linux com acesso total a bases de dados e serviços do sistema. As alterações de configuração feitas nessa shell não são persistentes nem incluídas nos backups. Realizar primeiro verificações apenas de leitura e reiniciar apenas depois de confirmar o nome do serviço, o impacto, a janela de manutenção e o acesso de recuperação.
1. Verificar o nome e o estado do serviço
Os serviços conhecidos e o respetivo estado atual são apresentados com:
service -S
A saída pode ser filtrada pelo serviço suspeito. Para IPsec, por exemplo:
service -S | grep -i strongswan
RUNNING significa que o serviço está em execução. STOPPED, UNREGISTERED ou UNTOUCHED não indicam automaticamente uma falha: dependendo do firmware e da configuração, um serviço pode estar intencionalmente inativo ou não registado. Primeiro, verificar se a função, política ou licença associada é realmente utilizada.
Se o nome técnico do serviço não for claro, consultar Troubleshooting da Sophos Firewall: serviços e logs. O artigo associa áreas funcionais aos respetivos ficheiros de log.
2. Verificar os logs antes da intervenção
Um reinício pode ocultar indícios importantes da causa. Para IPsec, ler primeiro strongswan.log e guardar as mensagens relevantes:
less /log/strongswan.log
Premir q para sair de less. Em análises mais extensas, exportar previamente os logs conforme descrito em Guardar logs da Sophos Firewall para suporte e análise. Em clusters HA, cada nó guarda apenas os logs do tráfego que processa; pode ser necessário verificar ambos os nós separadamente.
3. Reiniciar o serviço numa firewall standalone
O exemplo seguinte pressupõe uma firewall standalone. Antes da execução, service -S | grep -i strongswan tem de confirmar o serviço. O reinício pode interromper ligações IPsec site-to-site e de acesso remoto. Verificar previamente os túneis, os peers remotos e a janela de manutenção.
A Sophos documenta este padrão:
service <service>:restart -ds nosync
Um exemplo completo para o serviço IPsec é:
service strongswan:restart -ds nosync
A sintaxe genérica e service -S estão documentados na ajuda atual do SFOS 22, onde strongswan está associado ao serviço IPsec. Este exemplo não foi executado numa firewall e, por isso, não é apresentado como testado em laboratório. Não deduzir o nome de outro serviço a partir de uma lista.
Para continuar a análise, consultar Troubleshooting de IPsec na Sophos Firewall.
⚠️ Cluster HA: Não aplicar o comando para uma firewall standalone sem verificação. Dependendo do serviço e da situação, as instruções da Sophos utilizam
syncounosync; a documentação pública não fornece uma regra geral suficiente. O serviço, nó, build SFOS e modo de sincronização devem resultar de instruções atuais da Sophos específicas para o serviço ou de um caso de suporte.
Os comandos stop e start separados só devem ser utilizados quando o Sophos Support o indicar para o serviço específico. Entre ambos os comandos, o serviço permanece totalmente parado.
Este reinício também não tem rollback que preserve o estado: as Security Associations e sessões desligadas não podem ser restauradas. O critério seguro para parar é a comparação com a verificação prévia. Se strongswan não regressar ao estado anterior ou os túneis não forem restabelecidos, não efetuar um segundo reinício. Guardar os logs e o CTR e escalar o problema.
4. Validar o resultado
Depois do reinício, verificar o estado, o log e a função real:
service -S | grep -i strongswan
tail -f /log/strongswan.log
grep -i 'error' /log/strongswan.log
tail -f apresenta continuamente novas mensagens e termina com Ctrl+C. Comparar as mensagens com a hora registada antes do reinício; um grep sem filtro pode também mostrar erros antigos. Depois, verificar os túneis IPsec e testar um host no local remoto. O estado RUNNING, por si só, não prova que a ligação voltou a funcionar.
Se o reinício falhar, verificar também csc.log. Para problemas de HA, dependendo dos sintomas, ha.log, msync.log e applog.log também podem ser relevantes.
Serviços comuns e testes funcionais adequados
O nome exato do serviço deve ser confirmado na firewall afetada com service -S. As principais associações são:
strongswan: IPsec site-to-site e de acesso remoto. Depois, verificar o estado dos túneis,strongswan.loge a acessibilidade do local remoto.dnsd: Serviço DNS. Depois, testar a resolução de nomes interna e externa,dnsd.loge as DNS Request Routes configuradas.dhcpd: Servidor DHCP. Durante o reinício, clientes novos ou em renovação podem não receber resposta. Depois, testar a atribuição de leases edhcpd.log.awed: Comunicação entre a firewall e dispositivos AP/APX. Depois, verificar o estado de ligação dos access points eawed.log.zebra: Instala rotas dinâmicas e estáticas no kernel. Um reinício é, portanto, invasivo e só deve ser executado com uma instrução específica da Sophos; depois, testar a tabela de routing, os gateways e os percursos reais.smtpd: Proxy SMTP no modo MTA. O proxy transparente legacy utiliza outro serviço; antes da intervenção, verificar o modo de operação e os logssmtpd_*. Depois, testar de forma controlada o envio e a receção de e-mail.
Para WAF, Web proxy, IPS, Authentication e os serviços disponíveis no WebAdmin, o reinício em System services > Services é normalmente mais claro do que um comando de shell.
Quando não é adequado reiniciar um serviço
Reiniciar um serviço individual é adequado quando um módulo específico está afetado e o resto da firewall permanece estável. Não reiniciar serviços indiscriminadamente quando:
- a causa ou o serviço afetado ainda não são claros;
- vários serviços centrais falham ao mesmo tempo;
- esse serviço fornece o único acesso remoto restante;
- o erro é reproduzível e os logs ainda não foram guardados;
- o mesmo serviço já foi reiniciado várias vezes;
- o papel HA, o nó ou o modo de sincronização necessário não são claros.
Se vários serviços forem afetados, verificar primeiro a carga do sistema, o armazenamento, o estado da base de dados, HA e as últimas alterações de configuração ou firmware. Reinícios repetidos muitas vezes apenas ocultam a causa.
Um reboot completo é mais invasivo e só deve ser considerado se a firewall continuar globalmente instável, se um processo de firmware ou hotfix o exigir ou se o Sophos Support o indicar. Na Device Console, system restart reinicia a firewall; num cluster HA, o comando provoca um failover. Já system shutdown apenas a desliga. Antes de ambas as ações, verificar o equipamento e o nó HA de destino, o backup, a janela de manutenção e o acesso local ou out-of-band; num shutdown, esse método de recuperação tem de permitir efetivamente voltar a ligar o equipamento. Depois do reinício, verificar o papel e a sincronização HA, o estado dos serviços e os caminhos de dados afetados. As sessões interrompidas não podem ser restauradas. Se o equipamento não voltar a ficar disponível, não repetir o comando: utilizar o acesso de recuperação preparado e contactar o Sophos Support, se necessário. Consultar Planear corretamente o backup e restore da Sophos Firewall.
Documentar brevemente a intervenção
Para problemas recorrentes ou um caso de suporte, basta uma nota curta. Mais tarde, permite saber se o reinício resolveu o problema de forma duradoura ou apenas ocultou um sintoma:
Date/time and time zone:
Firewall / HA node:
Service and command:
Reason:
Users/sites affected:
Logs checked before restart:
Result after restart:
Next action:
Antes da intervenção, registar a hora, a função afetada e as mensagens de log relevantes. Depois, anotar o estado do serviço, o teste funcional e a próxima ação. Remover regras temporárias de SSH ou Device Access e desativar modos de debug após a análise.