Creare una rotta IPsec su Sophos Firewall

Una ipsec_route manuale appartiene all’IPsec basato su criteri. Associa un host o una rete di destinazione a un tunnel basato su criteri esistente. Non estende però i selettori di traffico e non sostituisce le regole firewall e NAT né il percorso di ritorno sul peer remoto.

Questo comando non è adatto all’IPsec basato su route. In un tunnel Any-to-any, l’interfaccia XFRM riceve un indirizzo IP; le route statiche, SD-WAN o dinamiche determinano quindi il percorso. In un tunnel basato su route con selettori di traffico, SFOS crea automaticamente la route. Non è possibile assegnare un indirizzo IP o route personalizzate all’interfaccia XFRM associata.

⚠️ Una route troppo ampia o associata al tunnel errato può deviare il traffico di produzione. Registrare lo stato iniziale prima della modifica e tenere pronto il comando di eliminazione esatto.

Quando è appropriata una route IPsec manuale

Il caso tipico è il traffico inoltrato il cui indirizzo viene modificato da DNAT o SNAT. Il NAT cambia l’indirizzo, ma non la decisione di routing. Potrebbe quindi essere necessaria una route aggiuntiva verso la rete remota.

Prima di eseguire il comando, verificare quanto segue:

• La connessione in Site-to-site VPN > IPsec > IPsec connections è basata su criteri.
• I selettori di traffico locali e remoti includono gli indirizzi effettivamente presentati all’elaborazione IPsec dopo il NAT.
• Le regole firewall e NAT corrispondono al traffico di prova definito. Per lo SNAT con IPsec basato su criteri, Outbound interface è impostato su Any.
• Il peer remoto si aspetta l’indirizzo sorgente visibile e dispone di una route di ritorno attraverso lo stesso tunnel.
• Una route statica o SD-WAN esistente e la precedenza globale delle route non dirigono la destinazione verso un altro percorso.

Una route manuale non corregge una maschera di rete errata, un selettore incompatibile o una regola bloccante. Configurare una VPN IPsec site-to-site su Sophos Firewall illustra i tipi di tunnel.

Registrare lo stato iniziale nella Device Console

In WebAdmin, aprire admin > Console e selezionare 4. Device console. Per l’accesso SSH, Connettersi a Sophos Firewall tramite SSH conduce allo stesso menu.

Visualizzare innanzitutto le route IPsec manuali esistenti e l’ordine globale:

system ipsec_route show
system route_precedence show

Salvare l’output insieme al nome del tunnel, ai selettori di traffico, all’ID della regola firewall, all’ID della regola NAT e al flusso di prova previsto. In SFOS 22, le route VPN basate su criteri generate automaticamente e le voci ipsec_route manuali appartengono alla categoria vpn. Queste route non sono visibili nella tabella di routing di WebAdmin, pertanto ip route show table 220 non è una prova attendibile del contrario.

Non modificare la precedenza delle route come attività secondaria. È un’impostazione globale e influisce su altre connessioni. Se occorre realmente modificarla, Modificare in sicurezza la precedenza delle route di Sophos Firewall descrive una procedura separata con ripristino basato sui valori.

Creare la route con un esempio NAT controllato

Sophos documenta questo caso d’uso ben circoscritto:

• Un tunnel basato su criteri HO_to_Branch collega la rete locale 192.168.2.0/24 alla rete remota 192.168.3.0/24.
• Il server locale effettivo 172.16.16.10 non rientra nel selettore locale.
• Il peer remoto lo contatta come 192.168.2.1. Questo indirizzo sostitutivo appartiene al selettore locale e, nell’esempio, è l’indirizzo dell’interfaccia LAN del firewall.

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

Sostituire la rete, gli indirizzi e il nome del tunnel con i propri valori. L’indirizzo sostitutivo deve corrispondere alla selezione locale della fase 2; la rete di destinazione remota deve essere coperta dal tunnel esistente.

1. Associare la rete remota al tunnel

Eseguire questo comando nella Device Console:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Per net, SFOS richiede la maschera completa in notazione decimale puntata. Utilizzare l’intervallo di destinazione più ristretto richiesto dall’applicazione. Il comando di ripristino corrispondente è:

system ipsec_route del net 192.168.3.0/255.255.255.0

Il comando di eliminazione non include il nome del tunnel. Prima di eliminare, usare system ipsec_route show per accertarsi che la destinazione sia univoca. Non eliminare voci ambigue basandosi su una semplice supposizione.

Per un singolo host di destinazione, la console supporta questa forma:

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

Una route host è più specifica, ma è corretta solo quando la destinazione è esattamente quell’host e i selettori di traffico corrispondono.

2. Configurare DNAT e SNAT riflessivo

1. In Rules and policies > NAT rules > Add NAT rule > New NAT rule, creare una regola DNAT. Original source è 192.168.3.0/24, Translated source resta Original, Original destination è 192.168.2.1 e Translated destination è 172.16.16.10.
2. Abilitare Create reflexive rule.
3. Aprire la regola generata Reflexive_NAT#_<DNAT_rule_name>. Per Translated source, selezionare un oggetto host IP con 192.168.2.1. Creare l’oggetto in Hosts and services > IP host > Add. In questa regola riflessiva, Sophos non può eseguire la traduzione direttamente verso un’interfaccia.
4. Controllare ordine, stato e registrazione di entrambe le regole NAT e della regola firewall associata.

Non aggiungere una regola MASQ generica né autorizzare ulteriormente il server effettivo ad attraversare il tunnel con l’indirizzo non tradotto. Comprendere il NAT in Sophos Firewall spiega la corrispondenza e l’ordine delle regole.

Verificare il percorso dei dati

Un tunnel verde e un ping non dimostrano né la traduzione NAT né il percorso di ritorno. Per la verifica, definire un flusso applicativo reale, ad esempio una connessione TCP dal client remoto al servizio pubblicato del server.

1. Eseguire nuovamente system ipsec_route show. La rete di destinazione deve essere associata una sola volta al tunnel previsto.
2. Generare una singola connessione controllata da 192.168.3.0/24 a 192.168.2.1 sul servizio consentito.
3. Filtrare Log viewer per origine, destinazione e ID della regola firewall. Nella vista dettagliata, src_trans_ip mostra l’indirizzo sorgente effettivamente tradotto in modo più affidabile rispetto alla vista riepilogativa.
4. Aprire Monitor & analyze > Diagnostics > Packet capture e filtrare per client, indirizzo sostitutivo e server effettivo. L’ID regola e l’ID NAT devono corrispondere alle regole documentate; le interfacce di ingresso e uscita devono mostrare il percorso previsto.
5. Sul peer remoto, verificare che le risposte da 192.168.2.1 siano previste e restituite attraverso lo stesso tunnel.
6. Provare un host o un servizio vicino non consentito. Questo test negativo deve continuare a non riuscire e conferma che la route e le regole non siano troppo ampie.

Una SA attiva o il solo aumento dei contatori di byte non sono sufficienti. Per un’analisi completa, consultare Risoluzione dei problemi delle VPN IPsec in Sophos Firewall; per analizzare regole e acquisizioni, consultare Verificare una regola firewall con Log Viewer, Policy Test e Packet Capture.

Annullare completamente la modifica

Terminare innanzitutto le nuove sessioni di prova. Ripristinare singolarmente DNAT e SNAT riflessivo allo stato precedente documentato; una modifica successiva della regola DNAT non rimuove automaticamente la regola riflessiva.

Eliminare quindi solo la route appena creata:

system ipsec_route del net 192.168.3.0/255.255.255.0
system ipsec_route show

Rimuovere il nuovo oggetto host IP solo quando Object usage non mostra più alcun riferimento. Ripetere quindi il flusso di controllo originale e il test negativo. La precedenza delle route registrata in precedenza deve rimanere invariata.

Se è stata eliminata per errore soltanto la route, il comando di aggiunta salvato ripristina la voce esatta:

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname HO_to_Branch

Isolare sistematicamente gli errori comuni

La route esiste, ma il traffico va verso la WAN

Controllare system ipsec_route show, la precedenza delle route e le route SD-WAN concorrenti. In SFOS 22, l’assenza di una voce nella tabella di routing di WebAdmin o nella tabella 220 non dimostra che la route IPsec sia assente. Nella precedenza delle route, vpn ha priorità su static solo per il traffico diretto alla zona WAN; occorre quindi verificare anche le zone e il percorso effettivo verso la destinazione.

Il tunnel è attivo, ma il NAT non viene applicato

Confrontare gli indirizzi originali e tradotti con i selettori di traffico. Per lo SNAT basato su criteri, Outbound interface deve essere Any. Controllare quindi l’ID della regola firewall, l’ID NAT e src_trans_ip, anziché affidarsi solo allo stato del tunnel.

Con Any, il firewall utilizza la Translated source della regola SNAT corrispondente, anche quando Override source translation (SNAT) è attivato per specifiche interfacce in uscita. Una regola che indica solo determinate porte WAN in Outbound interface, come la consueta regola SNAT predefinita, non corrisponde a questo traffico IPsec basato su criteri. La spiegazione del NAT nell’articolo sull’IPsec site-to-site chiarisce questa interazione; non giustifica una modifica generalizzata delle impostazioni di override. Dopo una correzione mirata della regola, generare un nuovo flusso applicativo controllato e verificare nuovamente ID NAT, src_trans_ip, selettori e percorso di ritorno, come descritto nella validazione del percorso dati precedente.

Il percorso di andata funziona, ma manca la risposta

Il peer remoto deve conoscere l’indirizzo tradotto e restituire il traffico attraverso lo stesso tunnel. Controllare il selettore, la regola firewall e la route di ritorno sul peer. Un percorso di ritorno diverso non può essere corretto con una ipsec_route locale più ampia.

È interessato il traffico generato dal sistema o DHCP

Le richieste di autenticazione, DNS e DHCP generate dal firewall seguono un processo distinto. In SFOS 22, normalmente non richiedono una route IPsec manuale. Usare Routing SD-WAN per pacchetti di risposta e traffico di sistema o la procedura separata per il relay DHCP, anziché applicare questa procedura di inoltro.

Manca un annuncio dinamico dopo l’aggiornamento a SFOS 22

In SFOS 22, le route VPN basate su criteri non sono normali route del kernel. Se OSPF o BGP le annunciava in precedenza tramite redistribute kernel, Perché redistribute kernel non annuncia più le route IPsec dopo un aggiornamento a SFOS 22 illustra questo problema di migrazione distinto.