Konfigurera Site-to-Site RED mellan två Sophos Firewall

En Site-to-Site RED-tunnel ansluter två Sophos Firewall direkt till varandra utan en SD-RED-apparat på någon av platserna. En brandvägg fungerar som Firewall RED server och tar emot anslutningen. Den andra fungerar som Firewall RED client och upprättar tunneln till servern.

Det här aktuella SFOS 22-flödet ska inte förväxlas med ett RED-driftläge som Standard/Unified eller Standard/Split. De lägena gäller en fysisk SD-RED. I en brandvägg-till-brandvägg-design används i stället RED-gränssnitt, statiska routes och motsvarande brandväggsregler på båda brandväggarna.

⚠️ Före ändringen behövs en aktuell säkerhetskopia av båda brandväggarna, en oberoende administrativ anslutning och en dokumenterad återställningsväg. Den publika adressen till Firewall RED server bör om möjligt inte översättas med NAT, eftersom översättningen kan störa inkommande RED-anslutningar.

Förloppet i åtta steg

1. Planera roller, RED-IP-adresser, platsnät och en nåbar serveradress.
2. Aktivera RED provisioning service på båda brandväggarna och tillåt RED-kontrollvägen.
3. Skapa gränssnittet Firewall RED server på centralplatsen.
4. Överför den genererade provisioningfilen säkert till den andra platsen.
5. Skapa gränssnittet Firewall RED client på filialen och importera filen.
6. Lägg till en statisk route till fjärr-LAN på båda sidor, med peerens RED-IP som gateway och utan att välja ett gränssnitt.
7. Tillåt datatrafiken på båda brandväggarna med snäva loggade regler; skapa ingen länkad NAT-regel.
8. Kontrollera tunneln, routen, regelträffen och verklig dubbelriktad trafik separat.

Ett grönt RED-gränssnitt bekräftar bara att tunneln har upprättats. Det bevisar inte att routing, brandväggsregler och returväg fungerar.

Planering och design

När Site-to-Site RED passar

Site-to-Site RED är ett enkelt sätt att ansluta två Sophos Firewall. RED-provisionering hanterar en del av den klassiska VPN-förhandlingen, medan de fjärranslutna LAN-näten fortfarande använder vanlig routing och vanliga brandväggsregler.

För nya designer bör valet mellan RED och Site-to-Site IPsec ändå göras medvetet. IPsec erbjuder fler alternativ för profiler, routing, interoperabilitet och redundans. Site-to-Site RED är attraktivt när båda ändpunkterna är Sophos Firewall och en enkel Sophos-specifik tunnel räcker.

En fysisk SD-RED konfigureras enligt Konfigurera och felsök Sophos SD-RED. RED-driftlägena gäller inte för brandvägg-till-brandvägg-tunneln som beskrivs här.

Planera exempeltopologin

Följande exempel använder avsiktligt dokumentationsadresser. De ersätts helt med de verkliga näten och adresserna för de två platserna:

• Centralplats, rollen Firewall RED server: publik adress 198.51.100.10, LAN 10.10.0.0/16
• Filial, rollen Firewall RED client: publik adress 203.0.113.20, LAN 10.20.0.0/16
• Centralplatsens RED-IP: 10.255.100.1
• Filialens RED-IP: 10.255.100.2

De två RED-IP-adresserna bildar adressparet mellan brandväggarna. De får inte kollidera med ett plats-LAN eller något annat gränssnitts- eller VPN-nät. Klientbrandväggen måste kunna nå serverns publika IP-adress eller FQDN på ett tillförlitligt sätt.

Exemplet använder 255.255.255.252 (/30) som RED netmask. Detta lilla transitnät innehåller exakt det adresspar som behövs. Om ett annat ledigt nät väljs ska båda RED-IP-adresserna och masken bytas konsekvent. RED löser inte överlappande plats-LAN; adress- eller NAT-designen måste bestämmas före tunneln.

Sophos beskriver uttryckligen RED-gränssnitt som säkra, krypterade tunnlar. När RED provisioning service registreras använder SFOS registreringsuppgifterna för att generera ett certifikat för säker RED-kommunikation. I det dokumenterade brandvägg-till-brandvägg-flödet väljs därför varken PSK eller certifikat manuellt i gränssnittet: servern genererar en Provisioning file med klientens konfigurationsdata. Filen ska endast överföras via en skyddad kanal.

Konfigurera tunneln och datavägen

Skapa Firewall RED server

Först skapas servern på brandväggen med en stabilt nåbar publik adress:

1. Aktivera RED provisioning service under System services > RED.
2. Öppna Network > Interfaces.
3. Välj Add interface > Add RED.
4. Ange till exempel RED-HQ-Branch under Branch name.
5. Ställ in Type på Firewall RED server.
6. Låt Tunnel ID stå på Automatic.
7. Ange 10.255.100.1 som RED IP.
8. Ange 255.255.255.252 som RED netmask.
9. Tilldela en medvetet vald zon, i exemplet RED-S2S.
10. Lämna först Tunnel compression och MTU oförändrade och spara.
11. Välj Download provisioning file i gränssnittets meny under Network > Interfaces.

Provisioningfilen hör till den här tunneln och ska behandlas som en känslig konfigurationsartefakt. Den överförs till filialen via en skyddad kanal och lämnas inte kvar i en allmänt åtkomlig nedladdnings- eller delningsmapp efter importen.

Zonen påverkar senare regel- och Device Access-träffar. LAN är möjligt, men en separat zon skapar vanligtvis en tydligare säkerhetsgräns när det finns flera platser. Konfigurera zoner och gränssnitt på Sophos Firewall förklarar de allmänna sambanden.

Automatic förhindrar oavsiktlig återanvändning av ett Tunnel ID. Om ett manuellt värde krävs får det enligt Sophos inte redan användas på någon av enheterna. I det dokumenterade klientflödet anges inget andra Tunnel ID; kopplingen kommer från serverns provisioningfil. Tunnel compression kan öka genomströmningen över en långsam anslutning men använder resurser; ändra först efter en reproducerbar före-/eftermätning. RED-gränssnittets MTU påverkar fragmenteringen; ett MTU- eller fragmenteringsproblem kan därför blockera flöden med större paket trots att tunneln är aktiv. En mindre MTU testas bara vid påvisad fragmentering eller ett Path MTU-problem.

Skapa Firewall RED client

På den andra platsen skapas klienten med filen som servern genererade:

1. Aktivera även här RED provisioning service under System services > RED.
2. Skapa ett nytt gränssnitt under Network > Interfaces > Add interface > Add RED.
3. Använd ett Branch name som RED-Branch-HQ.
4. Ställ in Type på Firewall RED client.
5. Ange serverns publika adress eller FQDN under Firewall IP/hostname.
6. Välj filen från serverbrandväggen under Provisioning file.
7. Ange 10.255.100.2 som RED IP.
8. Ange även 255.255.255.252 som RED netmask.
9. Tilldela RED-S2S, lämna Tunnel compression och MTU oförändrade och spara.

Om klienten endast kan nå servern via en översatt eller föränderlig adress måste DNS, uppströms-NAT och returväg testas extra noggrant. Sophos rekommenderar att servern om möjligt görs direkt nåbar utan NAT.

Klienten initierar den utgående anslutningen, så filialen behöver ingen motsvarande inkommande publicering.

Lägg till statiska routes utan gränssnitt

När tunneln har upprättats känner den inte automatiskt till LAN-näten bakom brandväggarna. En IPv4-unicastroute skapas på båda sidor:

• Centralplats: destination 10.20.0.0/16, gateway 10.255.100.2
• Filial: destination 10.10.0.0/16, gateway 10.255.100.1

Det avgörande RED-undantaget är att inget gränssnitt väljs för dessa två routes. Brandväggen skickar ARP-förfrågningar för att fastställa det nåbara RED-gränssnittet för peeradressen. Att välja ett gränssnitt i efterhand kan störa denna mekanism och är ingen förbättring.

Routen skapas under Routing > Static routes > IPv4 unicast route > Add. Administrative Distance och Metric väljs medvetet så att de passar det övriga routingupplägget. Konfigurera och testa en statisk route på Sophos Firewall förklarar den allmänna fältlogiken och verifiering med Route Lookup.

Begränsa RED-tjänsten och brandväggsreglerna

Först måste den lokala RED-tjänsten få ta emot anslutningen. Aktivera under Administration > Device access RED endast för den verkliga ankomstzonen. Om publika källadresser är stabila skapar du i stället under Local service ACL exception rule > Add en snäv Accept-regel med Source zone, Source Network / Host, WAN-gränssnittet som Destination host och Services: RED. Vanliga brandväggsregler styr inte lokala tjänster. Device Access och Local Service ACL förklarar denna skillnad.

Skapa därefter under Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule för ett flöde från centralplatsen: centralt källa LAN/10.10.0.0/16, mål RED-S2S/10.20.0.0/16; på filialen källa RED-S2S/10.10.0.0/16, mål LAN/10.20.0.0/16. Begränsa Services till behovet.

För flöden som filialen initierar lägger du till det omvända paret. Aktivera Log firewall traffic, kontrollera regelpositionen och lämna Create linked NAT rule av. Bevara verkliga källadresser och kompletta returvägar; skriv inte över ett avsiktligt NAT-undantag utan granskning. Förstå och konfigurera Sophos Firewall-regler ger mer information.

Verifiering, troubleshooting och rollback

Verifiera tunneln kontrollerat

Verifieringen börjar med ett enda testflöde vars exakta tid dokumenteras. Först kontrolleras att båda RED-gränssnitten är aktiva och att Route Lookup visar den förväntade vägen för en adress i fjärr-LAN. Därefter måste flödet träffa avsedd Rule ID på båda brandväggarna.

En Packet Capture på Sophos Firewall visar om paketet går in i RED-gränssnittet på källsidan, anländer till peeren och vidarebefordras till destinations-LAN. Returvägen testas separat. Enbart ping räcker inte när produktionsapplikationen använder TCP eller UDP på andra portar.

Framgång innebär därför att alla följande punkter samtidigt är uppfyllda:

• RED-gränssnitten är aktiva på båda sidor.
• Route Lookup visar den planerade vägen i båda riktningarna.
• Den förväntade brandväggsregeln träffas på båda brandväggarna.
• Ett verkligt applikationsflöde fungerar dubbelriktat.
• Käll- och destinationsadresser visas utan oavsiktlig NAT.
• Efter en kontrollerad omstart fungerar ett nytt flöde igen; ett HA-kluster kräver dessutom ett separat failovertest.

Sophos dokumenterar för HA en fördröjning medan RED-tunnlar återansluter till Auxiliary Firewall efter failover. Tiden beror på antalet gränssnitt och andra inställningar och gäller även Site-to-Site RED. Utlova inte omedelbar återställning: dokumentera tidpunkt, gränssnittsstatus och återanslutningstid och testa sedan applikationsflödet igen.

Avgränsa fel systematiskt

Klienten upprättar inte tunneln: Kontrollera RED provisioning service, serveradress, DNS, nåbarhet, Device Access och provisioningfilen som hör till tunneln. Kombinera inte blint en ny fil med en gammal klientkonfiguration.

Provisioningfilen avvisas: kontrollera att den kommer från det aktuella servergränssnittet och inte ändrades under överföringen. Spara först föregående läge; ladda vid behov ner en ny fil och återskapa klienten under ett underhållsfönster.

Tunneln är aktiv men fjärr-LAN är inte nåbart: Kontrollera destinationsnätet och peerens RED-IP i den statiska routen på båda sidor. Inget gränssnitt får vara valt för denna särskilda RED-route. Kontrollera därefter regelträff och returroute.

Endast en riktning fungerar: Vanligtvis saknas en passande regel eller route på en brandvägg, eller så nås ett platsnät redan via en mer specifik väg eller en väg med högre prioritet. Route Lookup, Packet Capture och verklig returtrafik måste stämma överens.

Anslutningen är instabil: Korrelera latens, paketförlust, serverns publika nåbarhet, NAT framför servern och ändringar av WAN-vägen. Spara nodlokala loggar för den exakta testtidpunkten. Hitta och analysera Sophos Firewall-serviceloggar förklarar loggfilerna och supportvägarna.

Tunneln är aktiv men flöden med större paket stannar: granska båda riktningarna i Packet Capture efter fragmentering och ICMP Path MTU-meddelanden. Jämför MTU-värdena på båda RED-gränssnitten och testa olika paketstorlekar. Testa först med dessa belägg samma MTU stegvis på båda gränssnitten. Ändra inte compression och MTU samtidigt.

Ingen bred Any-regel, generell WAN-tillåtelse, tjänsteomstart eller slumpmässig ändring av RED-IP-adresser och routes ersätter denna korrelation. Om felet förblir oklart trots korrekt design samlas säkerhetskopia, SFOS-build, tidsstämpel, gränssnittsstatus, routes, Rule IDs, Packet Capture och relevanta loggar in för Sophos Support.

Rulla tillbaka säkert

Om piloten misslyckas inaktiveras först reglerna och routena tas bort, därefter klient- och sist servergränssnittet. Återställ Device Access/Local Service ACL och MTU- eller compressionvärden; ta bara bort nya objekt om inget annat använder dem.

En befintlig hanteringsväg som använder just den här tunneln tas inte bort innan en alternativ åtkomstmetod har testats med godkänt resultat. Efter återställningen kontrolleras normal routing, tidigare regler och båda brandväggarnas nåbarhet igen.

FAQ