Configurare un tunnel IP su Sophos Firewall con 6in4, 6to4, 6rd o 4in6

In Network > IP tunnels, Sophos Firewall crea tunnel che incapsulano un protocollo di rete in un altro. In questo modo IPv6 può attraversare un’infrastruttura IPv4, oppure IPv4 un’infrastruttura IPv6. SFOS mette a disposizione 6in4, 6to4, 6rd e 4in6 per questi scenari.

Questa funzione non è il tunnel GRE della Device Console e non è una VPN IPsec. Un tunnel IP incapsula i pacchetti, ma non li cifra né li autentica automaticamente.

⚠️ Un tunnel IP deve attraversare un’infrastruttura non attendibile solo se il progetto di sicurezza accetta esplicitamente l’assenza di riservatezza e autenticazione del peer. Per collegamenti protetti tra sedi, IPsec site-to-site è in genere il punto di partenza più adatto.

Quale tipo di tunnel scegliere?

I quattro tipi non risolvono lo stesso problema:

• 6in4 collega due reti IPv6 attraverso un backbone IPv4. Gli endpoint IPv4 locale e remoto vengono impostati manualmente. Sophos consiglia questo tipo per connessioni punto-punto.
• 6to4 trasporta IPv6 su IPv4 ed è pensato per configurazioni punto-multipunto. La source IPv4 locale viene impostata manualmente, mentre l’indirizzo di destinazione può essere ottenuto automaticamente.
• 6rd estende 6to4 con un prefisso fornito dal provider. Questo tipo è adatto solo se l’ISP fornisce i valori 6rd necessari.
• 4in6 collega due reti IPv4 attraverso un backbone IPv6. Gli endpoint esterni locale e remoto sono indirizzi IPv6 e il tipo è pensato per connessioni punto-punto.

Per un singolo collegamento controllato con endpoint fissi, 6in4 o 4in6 è più semplice da comprendere. Non si sceglie 6to4 o 6rd solo perché SFOS può creare automaticamente una route. L’indirizzamento e il progetto del provider devono corrispondere esattamente al meccanismo scelto.

Supporto IPv6 su Sophos Firewall riassume i limiti IPv6 di SFOS. Un tunnel GRE, invece, trasporta traffico IP instradato tramite una procedura separata nella Device Console e non è intercambiabile con questi quattro tipi WebAdmin.

Pianificare l’esempio e i prerequisiti

L’esempio utilizza un tunnel 6in4 statico tra due sedi:

• Nome visualizzato: HQ-IPv6-via-IPv4
• Hardware name: v6hq01
• Indirizzo WAN IPv4 locale: 192.0.2.10
• Endpoint IPv4 remoto: 198.51.100.20
• Rete IPv6 locale: 2001:db8:100::/64
• Rete IPv6 remota: 2001:db8:200::/64
• Server di test: 2001:db8:200::20
• Zona dell’interfaccia tunnel: VPN nell’esempio

192.0.2.0/24, 198.51.100.0/24 e 2001:db8::/32 sono intervalli di documentazione. Devono essere sostituiti, insieme a nomi, zona e prefissi, con i valori reali. La zona VPN è una scelta comprensibile per l’esempio, non un requisito del prodotto. Ciò che conta è che modello delle zone, regole firewall e Device Access corrispondano all’architettura reale.

Entrambi gli endpoint esterni devono essere raggiungibili attraverso l’infrastruttura prima di creare il tunnel. Su entrambi i lati servono un tunnel speculare, reti interne univoche, un percorso di ritorno e una regola firewall per il traffico applicativo reale. Prefissi sovrapposti, un valore del provider mancante per 6rd o una configurazione del peer sconosciuta sono condizioni per fermarsi.

Anche backup, finestra di manutenzione e accesso di gestione indipendente fanno parte del piano di ripristino. Il tunnel non va creato come esperimento sull’unico collegamento di produzione.

Creare il tunnel IP in WebAdmin

In Network > IP tunnels > Add si impostano prima identità e tipo di tunnel, quindi gli endpoint e i valori IP avanzati.

Distinguere Name da Hardware name

Il normale Name può contenere al massimo 58 caratteri e può essere modificato in seguito. Deve identificare scopo e peer, per esempio HQ-IPv6-via-IPv4.

L’Hardware name è tecnico e non può essere modificato dopo il salvataggio. Può contenere al massimo dieci caratteri e solo A-Z, a-z, 0-9 e _. SFOS blocca inoltre numerosi nomi e frammenti di sistema, tra cui gre, ipsec0, sit, tun, xfrm, Port, MGMT, eth, WLAN e Halink. Il valore neutro v6hq01 evita questi conflitti.

Un Hardware name errato non viene rinominato in seguito. Occorre documentarne le dipendenze e ricreare il tunnel in modo controllato. Per questo il valore va verificato con particolare attenzione prima di Save.

Impostare tipo, zona ed endpoint

Per l’esempio si seleziona 6in4. In Zone si imposta la zona di sicurezza prevista. In Local endpoint si inserisce 192.0.2.10 e in Remote endpoint 198.51.100.20.

La famiglia di indirizzi dipende dal tipo. Per 6in4, 6to4 e 6rd, l’endpoint esterno locale è IPv4; 6in4 dispone inoltre di un endpoint IPv4 remoto fisso. Per 4in6, gli endpoint esterni locale e remoto sono indirizzi IPv6. Una route di destinazione interna non va inserita in un campo endpoint.

Nelle impostazioni avanzate, TTL influisce sulla durata dei pacchetti incapsulati nell’infrastruttura. TOS assegna al pacchetto IP esterno un valore di tipo di servizio per priorità e comportamento di routing. La guida attuale non indica valori ottimali universali. Entrambi i campi restano quindi al valore iniziale documentato finché un problema di routing o QoS misurato non giustifica una modifica.

Dopo Save, SFOS conferma la creazione e apre la finestra delle route. Per 6to4 e 6rd, il firewall crea inoltre automaticamente una route unicast IPv6 statica. Importante: chiudere questa finestra o selezionare Cancel non rimuove il tunnel né le route create automaticamente.

Aggiungere route e regole firewall

Un tunnel salvato non costituisce ancora un percorso dati funzionante. Per 6in4 si aggiunge una route IPv6 statica verso il prefisso remoto 2001:db8:200::/64 tramite la nuova interfaccia tunnel. Il peer necessita del percorso di ritorno speculare verso 2001:db8:100::/64.

Per 4in6, la route interna conduce a una rete di destinazione IPv4. Per 6to4 e 6rd, si legge la route IPv6 creata automaticamente e la si confronta con il progetto del provider prima di aggiungerne altre. Cancel nella prima finestra delle route non è un rollback.

Le route aggiuntive si creano in Routing > Static routes. Route statiche su Sophos Firewall spiega come si combinano prefisso di destinazione, interfaccia, distanza, decisione di routing e test reale.

Si crea quindi una regola firewall ristretta e con logging tra le zone coinvolte, usando i valori reali di source, destination e service. Per un normale collegamento tra sedi si conserva l’indirizzo source originale; MASQ non va attivato per compensare l’assenza del percorso di ritorno. La procedura è descritta in Configurare in sicurezza le regole di Sophos Firewall.

Verificare il tunnel e il traffico applicativo

La verifica separa configurazione salvata, incapsulamento esterno e applicazione interna:

1. In Network > IP tunnels, confrontare Name, Hardware name, tipo, Zone ed endpoint con il peer.
2. In Routing > Static routes, verificare che il prefisso interno remoto punti all’interfaccia tunnel prevista.
3. Eseguire Route Lookup per il server di test interno e confermare l’interfaccia attesa.
4. Dal client di test locale avviare una nuova connessione a 2001:db8:200::20 con un servizio esplicitamente consentito.
5. In Log Viewer controllare Source, Destination, Service, Action e Firewall Rule ID.
6. Con Packet Capture osservare prima gli endpoint esterni e poi l’indirizzo di test interno.
7. Sul peer verificare ingresso, decapsulamento, route di ritorno e indirizzo source effettivo.
8. Ripetere il test in direzione opposta solo con una regola prevista per tale direzione.

Una voce tunnel verde o presente non dimostra né la route né il funzionamento del peer. Anche una route creata automaticamente non dimostra che provider, dispositivi intermedi e regole trasportino davvero l’incapsulamento. Packet Capture su Sophos Firewall spiega la cattura controllata.

Individuare gli errori in base al sintomo

Impossibile salvare il tunnel

Controllare separatamente Name e Hardware name. Hardware name può avere al massimo dieci caratteri, usare solo quelli consentiti e non contenere termini di sistema bloccati. Verificare quindi che tipo di tunnel e famiglia di indirizzi degli endpoint locale e remoto coincidano.

Un nome visualizzato diverso non corregge un Hardware name non valido. Se il valore è già usato da un’altra interfaccia, si pianifica un nome tecnico univoco invece di provare ripetutamente suffissi casuali.

Il tunnel esiste, ma manca la route verso la rete di destinazione

Per 6in4 e 4in6 si aggiunge esplicitamente la route statica necessaria. Per 6to4 e 6rd si verifica che SFOS abbia creato la route unicast IPv6 prevista e che il prefisso corrisponda al design. Una finestra chiusa in precedenza con Cancel non elimina la configurazione salvata automaticamente.

Route Lookup e la tabella di routing costituiscono la verifica successiva. Route Precedence globale non va modificata sulla base di un sospetto e non va aggiunta una route blackhole o fittizia concorrente per il test.

I pacchetti esterni sono visibili, ma manca il traffico interno

Spesso non coincidono tipo del peer, indirizzi degli endpoint, prefisso interno o route di ritorno. Confrontare le configurazioni come immagini speculari, quindi verificare la regola firewall, la Firewall Rule ID prevista e una cattura degli indirizzi source e destination interni.

Un incapsulamento funzionante non dimostra che il traffico applicativo sia consentito. Al contrario, l’assenza di Rule ID può indicare che il pacchetto interno non è mai stato decapsulato o è stato elaborato da un’altra route.

I pacchetti piccoli funzionano, ma le applicazioni si bloccano

L’incapsulamento IP esterno aggiuntivo riduce la dimensione utile dei pacchetti rispetto all’infrastruttura. Invece di copiare un valore MTU estraneo, si misurano Path MTU, frammentazione e applicazione interessata. La procedura controllata in Verificare MTU e MSS nei problemi di tunnel vale anche per questa analisi, senza trasferire al tunnel IP valori IPsec fissi.

HA, modifiche e rollback

Le due pagine della guida SFOS 22 non promettono uno stato HA ininterrotto per questi tunnel IP. Dopo un cambio di ruolo pianificato, ricontrollare voce del tunnel, Route Lookup, incapsulamento esterno, Firewall Rule ID e una nuova sessione applicativa. Una connessione esistente non dimostra continuità.

Prima di una modifica si documentano Name, Hardware name immutabile, tipo, Zone, endpoint, route create automaticamente e manualmente, regole e ultimo test reale. In questo modo è possibile distinguere una modifica di configurazione da un cambiamento del percorso dati.

Per il rollback, interrompere prima il traffico di test. Disattivare in modo controllato le regole e le route manuali dipendenti, oppure ripristinarne lo stato precedente confermato. Controllare esplicitamente le route automatiche di 6to4 o 6rd. Eliminare il tunnel solo quando non rimane alcuna dipendenza produttiva. Infine verificare nuovamente il percorso precedente e un flusso noto.

Checklist

• Il tipo selezionato corrisponde alle famiglie di indirizzi interna ed esterna.
• Entrambi gli endpoint e i prefissi sono concordati con il peer.
• Il nome visualizzato e l’Hardware name immutabile sono documentati.
• Zone, route statica e percorso di ritorno corrispondono al progetto di sicurezza.
• Le route automatiche di 6to4 o 6rd sono state controllate.
• Una regola ristretta corrisponde alla Firewall Rule ID prevista.
• Incapsulamento esterno e traffico applicativo interno sono stati testati separatamente.
• MTU, HA e rollback sono stati verificati sul percorso reale.

Domande frequenti