Hoppa till innehållet
Avanet

Skapa IPsec-rutt på Sophos Firewall

Sophos Firewall

En manuell ipsec_route hör till policybaserad IPsec. Den kopplar en destinationsvärd eller ett destinationsnät till en befintlig policybaserad tunnel. Den utökar dock inte Traffic Selectors och ersätter varken brandväggs- och NAT-regler eller returvägen på fjärrparten.

Kommandot ska inte användas för ruttbaserad IPsec. I en Any-to-any-tunnel får XFRM-gränssnittet en IP-adress; statiska, SD-WAN- eller dynamiska rutter avgör därefter vägen. För en ruttbaserad tunnel med Traffic Selectors skapar SFOS rutten automatiskt. Det går inte att tilldela det tillhörande XFRM-gränssnittet en IP-adress eller egna rutter.

⚠️ En rutt som är för bred eller har tilldelats fel tunnel kan omdirigera produktionstrafik. Dokumentera utgångsläget innan du gör ändringen och ha det exakta raderingskommandot redo.

När en manuell IPsec-rutt är lämplig

Det vanligaste fallet är vidarebefordrad trafik vars adress ändras med DNAT eller SNAT. NAT ändrar adressen, men inte routningsbeslutet. Därför kan en extra rutt till fjärrnätet behövas.

Kontrollera följande innan du kör kommandot:

  • Anslutningen under Site-to-site VPN > IPsec > IPsec connections är policybaserad.
  • De lokala Traffic Selectors och motsvarande inställningar på fjärrparten omfattar de adresser som faktiskt presenteras för IPsec-behandling efter NAT.
  • Brandväggs- och NAT-reglerna matchar den definierade testtrafiken. För SNAT med policybaserad IPsec ska Outbound interface vara inställt på Any.
  • Fjärrparten förväntar sig den synliga källadressen och har en returrutt genom samma tunnel.
  • En befintlig statisk eller SD-WAN Route och den globala Route Precedence styr inte destinationen till en annan väg.

En manuell rutt åtgärdar inte en felaktig nätmask, en Traffic Selector som inte matchar eller en blockerande regel. Konfigurera en site-to-site IPsec-VPN på Sophos Firewall förklarar tunneltyperna.

Dokumentera utgångsläget i Device Console

Öppna admin > Console i WebAdmin och välj 4. Device console. Vid SSH-åtkomst leder Anslut till Sophos Firewall via SSH till samma meny.

Visa först de befintliga manuella IPsec-rutterna och den globala prioritetsordningen:

system ipsec_route show
system route_precedence show

Spara utdata tillsammans med tunnelnamnet, Traffic Selectors, Firewall Rule ID, NAT Rule ID och det planerade testflödet. I SFOS 22 tillhör både automatiskt genererade policybaserade VPN-rutter och manuella ipsec_route-poster kategorin vpn. Rutterna visas inte i WebAdmins routningstabell, så ip route show table 220 är inte ett tillförlitligt motbevis.

Ändra inte Route Precedence som en sidouppgift. Inställningen är global och påverkar andra anslutningar. Om den verkligen måste ändras beskriver Ändra Route Precedence säkert på Sophos Firewall ett separat förfarande med värdebaserad återställning.

Skapa rutten med ett kontrollerat NAT-exempel

Sophos dokumenterar detta snävt avgränsade användningsfall:

  • En policybaserad tunnel, HO_to_Branch, ansluter det lokala nätverket 192.168.2.0/24 till fjärrnätverket 192.168.3.0/24.
  • Den faktiska lokala servern 172.16.16.10 ligger utanför det lokala adressurvalet för tunneln.
  • Fjärrparten adresserar servern som 192.168.2.1. Ersättningsadressen ingår i det lokala adressurvalet och är i exemplet IP-adressen för brandväggens LAN-gränssnitt.
Remote 192.168.3.0/24 → 192.168.2.1 → DNAT → Server 172.16.16.10
Server 172.16.16.10 → reflexive SNAT → 192.168.2.1 → IPsec → Remote

Ersätt nätverket, adresserna och tunnelnamnet med dina egna värden. Ersättningsadressen måste matcha det lokala Phase 2-valet och fjärrnätverket måste omfattas av den befintliga tunneln.

1. Tilldela fjärrnätet till tunneln

Kör detta kommando i Device Console:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

För net kräver SFOS en fullständig nätmask i punktdecimalform. Använd det smalaste destinationsintervall som programmet kräver. Motsvarande återställningskommando är:

system ipsec_route del net 192.168.3.0/255.255.255.0

Raderingskommandot innehåller inget tunnelnamn. Använd därför system ipsec_route show före radering för att kontrollera att destinationen är entydig. Radera inte tvetydiga poster enbart på grund av en misstanke.

För en destinationsvärd stöder konsolen denna form:

system ipsec_route add host 10.33.46.69 tunnelname Azure_CH
system ipsec_route del host 10.33.46.69

En värdrutt är mer specifik, men är korrekt endast när just den värden är destinationen och Traffic Selectors matchar.

2. Konfigurera DNAT och reflexiv SNAT

  1. Under Rules and policies > NAT rules > Add NAT rule > New NAT rule, skapa en DNAT-regel. Original source är 192.168.3.0/24, Translated source förblir Original, Original destination är 192.168.2.1, och Translated destination är 172.16.16.10.
  2. Aktivera Create reflexive rule.
  3. Öppna den genererade regeln Reflexive_NAT#_<DNAT_rule_name>. För Translated source, välj ett IP-värdobjekt med 192.168.2.1. Skapa objektet under Hosts and services > IP host > Add. Sophos kan inte översätta direkt till ett gränssnitt i denna reflexiva regel.
  4. Kontrollera ordning, status och loggning för båda NAT-reglerna och den tillhörande brandväggsregeln.

Lägg inte till en bred MASQ-regel och tillåt inte heller den faktiska servern genom tunneln med sin oöversatta adress. Förstå NAT på Sophos Firewall förklarar matchning och regelordning.

Validera datavägen

En grön tunnel och en ping bevisar varken NAT-översättningen eller returvägen. För validering definierar du ett verkligt applikationsflöde, till exempel TCP från fjärrklienten till den publicerade servertjänsten.

  1. Kör system ipsec_route show igen. Destinationsnätverket måste vara tilldelat exakt en gång till den avsedda tunneln.
  2. Skapa en kontrollerad anslutning från 192.168.3.0/24 till 192.168.2.1 på den tillåtna tjänsten.
  3. Filtrera Log viewer efter Source, Destination och Firewall Rule ID. I detaljvyn visar src_trans_ip den faktiska översatta källadressen mer tillförlitligt än sammanfattningsvyn.
  4. Öppna Monitor & analyze > Diagnostics > Packet capture och filtrera efter klienten, ersättningsadressen och den faktiska servern. Rule ID och NAT ID måste matcha de dokumenterade reglerna; inkommande och utgående gränssnitt måste visa den avsedda vägen.
  5. Kontrollera på fjärrparten att svar från 192.168.2.1 förväntas och skickas tillbaka genom samma tunnel.
  6. Testa en närliggande värd eller tjänst som inte är tillåten. Detta negativa test måste fortfarande misslyckas och bekräftar att rutten och reglerna inte är alltför breda.

En aktiv SA eller ökande byte-räknare räcker inte. En fullständig undersökning beskrivs i Felsökning av IPsec-VPN på Sophos Firewall; för analys av regler och paketfångst, se Testa en brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Rulla tillbaka förändringen helt

Avsluta först alla nya testsessioner. Återställ DNAT och reflexiv SNAT var för sig till deras dokumenterade tidigare tillstånd; om DNAT-regeln ändras i efterhand tas den reflexiva regeln inte bort automatiskt.

Ta därefter endast bort den nyligen skapade rutten:

system ipsec_route del net 192.168.3.0/255.255.255.0
system ipsec_route show

Ta bort det nya IP-värdobjektet först när Object usage inte längre visar någon referens. Upprepa sedan det ursprungliga kontrollflödet och det negativa testet. Den Route Precedence som dokumenterades tidigare måste förbli oförändrad.

Om endast rutten raderades av misstag återställer det sparade add-kommandot exakt samma post:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Isolera vanliga fel systematiskt

Rutten finns, men trafiken går till WAN

Kontrollera system ipsec_route show, Route Precedence och konkurrerande SD-WAN-rutter. I SFOS 22 är en saknad post i WebAdmins routningstabell eller i tabell 220 inget bevis för att IPsec-rutten saknas. I Route Precedence har vpn högre prioritet än static endast för trafik till WAN-zonen; därför måste även zonerna och den faktiska destinationsvägen kontrolleras.

Tunneln är aktiv, men NAT tillämpas inte

Jämför de ursprungliga och översatta adresserna med Traffic Selectors. För policybaserad SNAT måste Outbound interface vara Any. Kontrollera därefter Firewall Rule ID, NAT ID och src_trans_ip i stället för att enbart förlita dig på tunnelstatusen.

Med Any använder brandväggen den matchande SNAT-regelns Translated source, även när Override source translation (SNAT) är aktiverat för specifika utgående gränssnitt. En regel som endast anger vissa WAN-portar som Outbound interface, däribland den vanliga standardregeln för SNAT, matchar inte denna policybaserade IPsec-trafik. NAT-förklaringen i artikeln om site-to-site IPsec beskriver detta samspel; det är inte ett skäl att ändra alla override-inställningar. Skapa ett nytt kontrollerat applikationsflöde efter en riktad regelkorrigering och kontrollera NAT ID, src_trans_ip, selectors och returvägen igen enligt valideringen av datavägen ovan.

Den utgående vägen fungerar, men svaret saknas

Fjärrparten måste känna till den översatta adressen och returnera trafiken genom samma tunnel. Kontrollera dess Traffic Selector, brandväggsregel och returrutt. En avvikande returväg kan inte åtgärdas med en bredare lokal ipsec_route.

Systemgenererad trafik eller DHCP påverkas

Autentiserings-, DNS- och DHCP-förfrågningar som genereras av brandväggen följer en separat process. I SFOS 22 kräver de normalt ingen manuell IPsec-rutt. Använd SD-WAN-routing för svarspaket och systemtrafik eller den separata instruktionen för DHCP-relä i stället för att tillämpa den här vidarebefordringsproceduren.

En dynamisk annonsering saknas efter uppgraderingen till SFOS 22

I SFOS 22 är policybaserade VPN-rutter inte vanliga kärnrutter. Om OSPF eller BGP tidigare annonserade dem via redistribute kernel förklarar Varför redistribute kernel inte längre annonserar IPsec-rutter efter en uppgradering till SFOS 22 detta separata migreringsproblem.