Configurar IPsec Site-to-Site com certificados na Sophos Firewall
Uma preshared key partilhada é rápida de configurar para um único túnel entre locais. Com várias firewalls ou requisitos PKI mais rigorosos, um digital certificate é frequentemente mais fácil de controlar: cada lado possui a sua própria chave privada, os peers confiam nas CA emissoras e um certificado individual pode ser renovado ou revogado de forma seletiva.
Este procedimento mostra uma ligação IPsec policy-based entre duas Sophos Firewall. Complementa o guia geral para configurar uma VPN IPsec Site-to-Site. Os designs route-based exigem ainda o planeamento do routing e do XFRM, mas o procedimento de confiança e certificados aqui descrito permanece igual.
O procedimento seguro em oito passos
- Documentar os papéis do túnel, as redes, o perfil IKEv2 e os Certificate IDs.
- Verificar em ambas as firewalls um backup da configuração e um acesso administrativo funcional.
- Exportar a CA emissora de cada firewall e importá-la no peer.
- Gerar em cada firewall um certificado separado assinado localmente com um Certificate ID único.
- Exportar apenas o certificado público e importá-lo no peer como Remote Certificate.
- Criar IPsec policy-based com Authentication type > Digital certificate em ambos os lados.
- Rever de forma restritiva o Device Access e as regras de firewall geradas automaticamente.
- Validar o estado do túnel, a confiança dos certificados, os logs e o tráfego real em ambas as direções.
⚠️ O ficheiro da chave privada permanece na firewall onde o certificado foi gerado. Para a troca de confiança são transferidos apenas certificados de CA e certificados públicos dos peers. Sem um segundo acesso administrativo testado, um backup e um caminho de recuperação documentado, não desativar túneis PSK existentes nem substituir certificados de produção.
Exemplo e valores de planeamento
O exemplo liga a sede SF1 à filial SF2:
SF1-LAN 10.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 10.20.20.0/24 SF2-LAN
- WAN da SF1:
198.51.100.10 - WAN da SF2:
203.0.113.20 - Certificado da SF1:
SF1_Certificate - Certificado da SF2:
SF2_Certificate - Certificate ID da SF1:
198.51.100.10 - Certificate ID da SF2:
203.0.113.20
Estes endereços e nomes são valores de documentação. Os endereços WAN pertencem aos intervalos RFC 5737 e os endereços LAN são privados. No ambiente real, utilizar os endereços WAN, objetos de rede e um esquema de ID único em toda a organização. O Certificate ID tem de permanecer associado ao respetivo peer e não deve ser confundido com o nome de apresentação ou um SAN arbitrário.
Antes da criação, verificar o NTP em Administration > Time; uma hora errada pode impedir a importação e a validação. Usar um certificado RSA, pois o SFOS 22 suporta ECDSA para outros fins, mas não em ligações IPsec.
Estabelecer confiança mútua entre as CA
Primeiro, em SF1, verificar e descarregar a CA emissora em Certificates > Certificate authorities. Se o exemplo utilizar a CA local Default, atribuir ao ficheiro exportado um nome inequívoco como Head_Office_Default.pem. Em SF2, importá-lo em Certificates > Certificate authorities > Add, por exemplo com o nome SF1_CA.
Depois, repetir o procedimento na direção oposta: exportar a CA de SF2, atribuir-lhe um nome inequívoco como Branch_Office_Default.pem e importá-la em SF1, por exemplo com o nome SF2_CA.
Os nomes dos ficheiros servem apenas para administração. O que importa são Subject, Issuer, Fingerprint, validade e a cadeia de CA correta. Comparar estes valores através de um canal independente antes da importação. Gerir certificados na Sophos Firewall explica as tarefas gerais relacionadas com CA, certificados e atribuição a serviços.
Não regenerar incidentalmente a CA integrada
Default. A regeneração altera o Trust Anchor e pode afetar outros portais, serviços TLS e peers IPsec. Para uma CA empresarial, importar antes a respetiva cadeia fidedigna completa.
Preparar certificados locais e remotos
Criar o certificado local na SF1
Em SF1, criar um certificado em Certificates > Certificates > Add > Generate locally-signed certificate. O exemplo da Sophos utiliza RSA, uma Key length de 2048 e SHA-256. Estes valores não substituem a política de criptografia e validade da organização; o perfil IPsec selecionado e ambos os peers têm de os suportar.
Em Subject Alternative Names (SANs) > Advanced settings, selecionar um Certificate ID. Os tipos suportados são DNS, IP address, Email e DER ASN1 DN [X.509]. O exemplo utiliza IP address com 198.51.100.10.
Com DER ASN1 DN [X.509], a Sophos utiliza o Subject da CA emissora. Neste caso, deixar DNS names e IP address vazios nos SANs, porque, segundo a Sophos, valores adicionais provocam um conflito durante a autenticação IPsec.
Depois de Save, verificar a validade, o Issuer, o Certificate ID e a existência da chave privada. Exportar o certificado público, alterar a extensão para .cer se necessário e importá-lo em SF2 em Certificates > Certificates > Add > Upload certificate com o nome SF1_Certificate. A coluna Trusted no peer tem de confirmar a confiança através de SF1_CA.
Criar o certificado local na SF2
Repetir o procedimento em SF2 com uma chave privada separada. No exemplo, o certificado chama-se SF2_Certificate, o Certificate ID é 203.0.113.20 e a CA emissora é a CA local de SF2.
Importar o certificado público em SF1. Aí, Trusted tem de ser confirmado através da SF2_CA importada anteriormente. Cada firewall possui agora exatamente dois papéis diferentes:
- Local certificate: o seu próprio certificado com a chave privada.
- Remote certificate: o certificado público do peer, validado pela respetiva CA.
Uma marca verde de confiança comprova a cadeia de certificados, mas não um túnel funcional. Validade, Certificate ID, perfil IKE, gateway e redes têm ainda de coincidir. A revogação e a distribuição de CRL são um processo operacional separado. Após uma revogação local, transferir a CRL predefinida atual para o peer e importá-la em Certificates > Certificate revocation lists > Add; para uma CA externa, importar a sua CRL. Consulte Certificate Revocation Lists na Sophos Firewall.
Criar a ligação IPsec em ambos os lados
Em Site-to-site VPN > IPsec > Add, criar duas ligações correspondentes. No exemplo, a sede aguarda pela filial:
- Connection type:
Policy-based - Gateway type:
Respond only - Profile:
Head office (IKEv2)ou um clone de perfil personalizado coordenado - Authentication type:
Digital certificate - Local certificate:
SF1_Certificate - Remote certificate:
SF2_Certificate - Listening interface: WAN da
SF1 - Local subnet:
SF1_LAN - Gateway address: endereço WAN da
SF2 - Remote subnet:
SF2_LAN
Inverter os papéis na filial:
- Gateway type:
Initiate the connection - Profile:
Branch office (IKEv2)ou o perfil personalizado correspondente - Local certificate:
SF2_Certificate - Remote certificate:
SF1_Certificate - Local subnet:
SF2_LAN - Gateway address: endereço WAN da
SF1 - Remote subnet:
SF1_LAN
Planear os perfis como um par. Importar a CA do peer como Validation only, incluindo toda a cadeia até à root. Na SF1, adicionar Remote CA certificate: SF2_CA, Local ID type / Local ID: IP address / 198.51.100.10 e Remote ID type / Remote ID: IP address / 203.0.113.20; na SF2, inverter os valores e escolher SF1_CA. Tipo e valor devem coincidir exatamente. Para DER ASN1 DN [X.509], Remote ID é o Distinguished Name do certificado do peer. Não usar uma CA pública como Remote CA: a Sophos avisa que um certificado adequado emitido por ela pode permitir acesso não autorizado. Compreender os perfis IPsec na Sophos Firewall explica como IKEv2, fase 1, fase 2, PFS, lifetimes e DPD funcionam em conjunto.
Verificar o Device Access e as regras de firewall
O lado com Gateway type > Respond only tem de poder aceitar ligações IPsec no caminho WAN previsto. Em Administration > Device access, ativar por isso IPsec apenas para a zona WAN realmente necessária ou utilizar uma exceção Local Service ACL restrita a endereços conhecidos dos peers. SSO, certificados ou um algoritmo IPsec forte não justificam acesso amplo ao WebAdmin ou SSH. Configurar o Device Access em segurança na Sophos Firewall explica o planeamento das ACL.
Quando Create firewall rule está ativado, o SFOS cria regras VPN automáticas. Estas regras são um ponto de partida. Em Rules and policies > Firewall rules, verificar a ordem, direção, redes de origem e destino, serviços e logging e limitá-las à necessidade real. Criar regras de firewall na Sophos Firewall explica a validação das regras.
Ping/Ping6 para a zona VPN só é necessário quando se pretende utilizar deliberadamente um endereço da própria firewall como destino de teste. Este serviço local não precisa de ser amplamente ativado para um teste end-to-end normal entre hosts atrás das firewalls.
Validar o túnel e os certificados
A validação separa quatro níveis:
- Em Site-to-site VPN > IPsec, a ligação e o túnel estão ativos.
- Ambas as firewalls mostram os Local e Remote Certificate esperados, períodos de validade corretos e um Issuer fidedigno.
- Um host de teste real alcança o serviço pretendido na rede remota e, em seguida, é testada a direção oposta.
- Firewall Rule ID, Packet Capture e os logs IPsec confirmam o mesmo caminho e os mesmos timestamps.
/log/strongswan.log é o principal ponto de partida para erros de IKE e certificados. /log/charon.log regista o serviço VPN IPsec e /log/ipsec_monitor.log monitoriza o serviço IPsec; /log/ipsec_conn/ipsec_<connectionname>.log regista ações específicas da ligação. /log/dgd.log aplica-se ao failover de ligações ou VPN. Troubleshooting de IPsec na Sophos Firewall descreve o procedimento de diagnóstico completo.
Limitar os erros por sintoma
O túnel permanece down
Primeiro, confirmar que Local certificate e Remote certificate estão realmente invertidos em ambos os lados. Depois, verificar Certificate ID, Gateway address, perfil IKEv2, validade e cadeia de confiança. Um certificado do peer importado sem a CA correspondente não é uma identidade fidedigna.
O certificado está Trusted, mas a autenticação continua a falhar
Trusted confirma apenas a cadeia. Com DER ASN1 DN [X.509], nenhum valor adicional de SAN DNS ou IP pode sobrepor-se ao identificador. Nos outros tipos de ID, o valor, o tipo e o peer esperado têm de coincidir exatamente. Comparar em strongswan.log os ID realmente apresentados e esperados para a mesma tentativa de ligação.
O túnel está verde, mas não há tráfego
A autenticação por certificado já foi concluída. Verificar agora as sub-redes locais e remotas, as regras VPN automáticas, a Rule ID, o NAT, a rota de retorno e o serviço de destino real. Regenerar certificados sem evidência apenas oculta o estado original neste cenário.
O certificado está prestes a expirar
Preparar o novo certificado local em paralelo, transferir a respetiva parte pública para o peer e confirmar aí a confiança. Alterar Local certificate e Remote certificate em ambos os lados de forma controlada apenas durante uma janela de manutenção. Manter os certificados e CA antigos disponíveis até à validação bidirecional bem-sucedida e removê-los ou revogá-los só depois.
Rollback e operação
Antes da alteração, documentar ambas as ligações IPsec, os nomes dos certificados, os Fingerprints, os Certificate IDs, os períodos de validade e a ordem atual das regras. Um backup da configuração da Sophos Firewall faz parte da preparação, mas não substitui um acesso direto de recuperação à firewall.
Se a validação falhar, restaurar as atribuições de certificados utilizadas anteriormente ou reativar o túnel PSK ainda disponível. Eliminar certificados de peers ou CA recentemente importados apenas depois de confirmar que nenhuma outra ligação ou serviço os utiliza. Depois, verificar novamente o estado do túnel e um fluxo de teste real.
Em operação, os certificados necessitam de um responsável, monitorização da validade e uma janela de renovação planeada. O primeiro alerta deve deixar tempo suficiente para emissão, distribuição da confiança, teste em paralelo e rollback. Substituir um certificado apenas na data de expiração transforma uma manutenção planeada numa indisponibilidade da VPN.
Num cluster HA, alterar o Primary atual, aguardar a sincronização com o Auxiliary e testar depois a seleção dos certificados, o túnel e um failover planeado com tráfego real. Um backup HA só é restaurado no Primary atual e reinicia-o sem failover: é recuperação com interrupção, não uma alternativa rápida à reposição das atribuições de certificados anteriores.