Konfigurera IPsec Site-to-Site med certifikat på Sophos Firewall

En delad preshared key går snabbt att konfigurera för en enskild tunnel mellan platser. Med flera brandväggar eller striktare PKI-krav är ett digital certificate ofta enklare att kontrollera: varje sida har en egen privat nyckel, peer-enheterna litar på utfärdande CA:er och ett enskilt certifikat kan förnyas eller återkallas selektivt.

Den här proceduren visar en policy-based IPsec-anslutning mellan två Sophos Firewall. Den kompletterar den allmänna guiden för att konfigurera en Site-to-Site IPsec VPN. Route-based design kräver dessutom planering av routing och XFRM, men förtroende- och certifikatproceduren som beskrivs här är densamma.

Den säkra proceduren i åtta steg

1. Dokumentera tunnelroller, nätverk, IKEv2-profil och Certificate ID:n.
2. Kontrollera en konfigurationsbackup och fungerande administratörsåtkomst på båda brandväggarna.
3. Exportera varje brandväggs utfärdande CA och importera den på peer-enheten.
4. Generera ett separat lokalt signerat certifikat med ett unikt Certificate ID på varje brandvägg.
5. Exportera endast det publika certifikatet och importera det på peer-enheten som Remote Certificate.
6. Skapa policy-based IPsec med Authentication type > Digital certificate på båda sidor.
7. Granska Device Access och automatiskt skapade brandväggsregler restriktivt.
8. Validera tunnelstatus, certifikatförtroende, loggar och verklig trafik i båda riktningarna.

⚠️ Filen med den privata nyckeln stannar på brandväggen där certifikatet genererades. Endast CA-certifikat och publika peercertifikat överförs för förtroendeutbytet. Inaktivera inte befintliga PSK-tunnlar och ersätt inte produktionscertifikat utan en testad andra administratörsåtkomst, en backup och en dokumenterad återställningsväg.

Exempel och planeringsvärden

Exemplet ansluter huvudkontoret SF1 till filialen SF2:

SF1-LAN 192.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 192.20.20.0/24 SF2-LAN

• SF1-WAN: 172.10.10.1
• SF2-WAN: 172.20.20.1
• SF1-certifikat: SF1_Certificate
• SF2-certifikat: SF2_Certificate
• SF1 Certificate ID: 172.10.10.1
• SF2 Certificate ID: 172.20.20.1

Dessa adresser och namn är dokumentationsvärden. Använd de verkliga WAN-adresserna, nätverksobjekten och ett unikt ID-schema för hela organisationen i den egna miljön. Certificate ID måste förbli kopplat till motsvarande peer och får inte förväxlas med visningsnamnet eller ett godtyckligt SAN.

Upprätta ömsesidigt CA-förtroende

Kontrollera och ladda först ned den utfärdande CA:n på SF1 under Certificates > Certificate authorities. Om exemplet använder den lokala CA:n Default ger du den exporterade filen ett entydigt namn som Head_Office_Default.pem. Importera den på SF2 under Certificates > Certificate authorities > Add, till exempel som SF1_CA.

Upprepa sedan proceduren i motsatt riktning: exportera CA:n från SF2, ge den ett entydigt namn som Branch_Office_Default.pem och importera den på SF1, till exempel som SF2_CA.

Filnamnen används endast för administration. Subject, Issuer, Fingerprint, giltighetstid och rätt CA-kedja är avgörande. Jämför värdena via en oberoende kanal före importen. Hantera certifikat på Sophos Firewall beskriver de allmänna uppgifterna för CA:er, certifikat och tjänstetilldelningar.

Regenerera inte den inbyggda CA:n Default som en sidoåtgärd. Regenerering ändrar Trust Anchor och kan påverka andra portaler, TLS-tjänster och IPsec-peer-enheter. Importera i stället hela den betrodda kedjan för en företags-CA.

Förbered lokala och externa certifikat

Skapa det lokala certifikatet på SF1

Skapa ett certifikat på SF1 under Certificates > Certificates > Add > Generate locally-signed certificate. Sophos-exemplet använder RSA, en Key length på 2048 och SHA-256. Dessa värden ersätter inte organisationens kryptografi- och giltighetspolicy; den valda IPsec-profilen och båda peer-enheterna måste stödja dem.

Välj ett Certificate ID under Subject Alternative Names (SANs) > Advanced settings. De typer som stöds är DNS, IP address, Email och DER ASN1 DN [X.509]. Exemplet använder IP address med 172.10.10.1.

Med DER ASN1 DN [X.509] använder Sophos den utfärdande CA:ns Subject. Lämna i detta fall DNS names och IP address under SAN tomma, eftersom ytterligare värden enligt Sophos orsakar en konflikt vid IPsec-autentiseringen.

Efter Save kontrollerar du giltighet, Issuer, Certificate ID och att den privata nyckeln finns. Exportera det publika certifikatet, ändra filändelsen till .cer vid behov och importera det på SF2 under Certificates > Certificates > Add > Upload certificate som SF1_Certificate. Kolumnen Trusted på peer-enheten måste bekräfta förtroendet via SF1_CA.

Skapa det lokala certifikatet på SF2

Upprepa proceduren på SF2 med en separat privat nyckel. I exemplet heter certifikatet SF2_Certificate, dess Certificate ID är 172.20.20.1 och den utfärdande CA:n är den lokala CA:n på SF2.

Importera det publika certifikatet på SF1. Där måste Trusted bekräftas via den tidigare importerade SF2_CA. Varje brandvägg har nu exakt två olika roller:

• Local certificate: det egna certifikatet med den privata nyckeln.
• Remote certificate: peer-enhetens publika certifikat, validerat av dess CA.

En grön förtroendemarkering bevisar certifikatkedjan, men inte att tunneln fungerar. Giltighet, Certificate ID, IKE-profil, gateway och nätverk måste fortfarande stämma överens. Återkallande och CRL-distribution är en separat driftprocess; se Certificate Revocation Lists på Sophos Firewall.

Skapa IPsec-anslutningen på båda sidor

Skapa två motsvarande anslutningar under Site-to-site VPN > IPsec > Add. I exemplet väntar huvudkontoret på filialen:

• Connection type: Policy-based
• Gateway type: Respond only
• Profile: Head office (IKEv2) eller en samordnad egen profilklon
• Authentication type: Digital certificate
• Local certificate: SF1_Certificate
• Remote certificate: SF2_Certificate
• Listening interface: WAN på SF1
• Local subnet: SF1_LAN
• Gateway address: WAN-adress för SF2
• Remote subnet: SF2_LAN

Vänd på rollerna i filialen:

• Gateway type: Initiate the connection
• Profile: Branch office (IKEv2) eller motsvarande egen profil
• Local certificate: SF2_Certificate
• Remote certificate: SF1_Certificate
• Local subnet: SF2_LAN
• Gateway address: WAN-adress för SF1
• Remote subnet: SF1_LAN

Planera profilerna som ett par. Förstå IPsec-profiler på Sophos Firewall beskriver hur IKEv2, fas 1, fas 2, PFS, lifetimes och DPD samverkar.

Kontrollera Device Access och brandväggsregler

Sidan med Gateway type > Respond only måste få ta emot IPsec-anslutningar på den avsedda WAN-vägen. Aktivera därför IPsec under Administration > Device access endast för den WAN-zon som faktiskt behövs eller använd ett begränsat Local Service ACL-undantag för kända peer-adresser. SSO, certifikat eller en stark IPsec-algoritm motiverar inte bred WebAdmin- eller SSH-åtkomst. Konfigurera Device Access säkert på Sophos Firewall beskriver ACL-planeringen.

När Create firewall rule är aktiverat skapar SFOS automatiska VPN-regler. Dessa regler är en utgångspunkt. Under Rules and policies > Firewall rules granskar du ordning, riktning, käll- och målnätverk, tjänster och logging och begränsar dem sedan till det faktiska behovet. Skapa brandväggsregler på Sophos Firewall beskriver regelvalideringen.

Ping/Ping6 för zonen VPN behövs endast när en adress på själva brandväggen avsiktligt används som testmål. Denna lokala tjänst behöver inte aktiveras brett för ett normalt end-to-end-test mellan värdar bakom brandväggarna.

Validera tunneln och certifikaten

Valideringen delar upp kontrollen i fyra nivåer:

1. Under Site-to-site VPN > IPsec är anslutningen och tunneln aktiva.
2. Båda brandväggarna visar förväntade Local och Remote Certificate, giltiga löptider och en betrodd Issuer.
3. En verklig testvärd når den avsedda tjänsten i fjärrnätverket, därefter testas motsatt riktning.
4. Firewall Rule ID, Packet Capture och IPsec-loggar bekräftar samma väg och tidsstämplar.

strongswan.log är den viktigaste utgångspunkten för IKE- och certifikatfel. charon.log, ipsec_monitor.log och den anslutningsspecifika loggen under /log/ipsec_conn/ ger ytterligare bevis. Sophos Firewall IPsec-felsökning beskriver hela diagnostikproceduren.

Avgränsa fel efter symptom

Tunneln förblir down

Bekräfta först att Local certificate och Remote certificate verkligen är speglade på båda sidor. Kontrollera därefter Certificate ID, Gateway address, IKEv2-profil, giltighet och förtroendekedja. Ett importerat peercertifikat utan motsvarande CA är ingen betrodd identitet.

Certifikatet är Trusted, men autentiseringen misslyckas ändå

Trusted bekräftar endast kedjan. Med DER ASN1 DN [X.509] får inga ytterligare DNS- eller IP-SAN-värden åsidosätta identifieraren. För de andra ID-typerna måste värde, typ och förväntad peer stämma exakt. Jämför de ID:n som faktiskt erbjuds och förväntas i strongswan.log för samma anslutningsförsök.

Tunneln är grön, men ingen trafik flödar

Certifikatautentiseringen har redan lyckats. Kontrollera nu lokala nät och fjärrnät, automatiska VPN-regler, Rule ID, NAT, returväg och den verkliga måltjänsten. Att regenerera certifikat utan belägg döljer bara det ursprungliga tillståndet i det här scenariot.

Certifikatet går snart ut

Förbered det nya lokala certifikatet parallellt, överför dess publika del till peer-enheten och bekräfta förtroendet där. Ändra Local certificate och Remote certificate på båda sidor kontrollerat endast under ett underhållsfönster. Behåll gamla certifikat och CA:er tills den dubbelriktade valideringen har lyckats och ta bort eller återkalla dem först därefter.

Rollback och drift

Dokumentera båda IPsec-anslutningarna, certifikatnamn, Fingerprints, Certificate ID:n, giltighetsperioder och aktuell regelordning före ändringen. En konfigurationsbackup av Sophos Firewall ingår i förberedelsen, men ersätter inte direkt återställningsåtkomst till brandväggen.

Om valideringen misslyckas återställer du tidigare certifikattilldelningar eller återaktiverar den fortfarande tillgängliga PSK-tunneln. Ta bort nyimporterade peercertifikat eller CA:er först efter att ha bekräftat att ingen annan anslutning eller tjänst använder dem. Kontrollera sedan tunnelstatus och ett verkligt testflöde igen.

I drift behöver certifikat en ägare, övervakning av utgångsdatum och ett planerat förnyelsefönster. Det första larmet bör lämna tillräckligt med tid för utfärdande, distribution av förtroende, parallell testning och rollback. Att ersätta ett certifikat först på utgångsdatumet förvandlar ett planerat underhåll till ett VPN-avbrott.

Vanliga frågor