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.

Per 6to4 occorre inoltre distinguere il meccanismo unicast ancora definito dal meccanismo di relay anycast pubblico. L’IETF ha dismesso l’anycast 6to4 a causa dei suoi problemi operativi e raccomanda che i router lascino 6to4 disattivato per impostazione predefinita (RFC 7526). Non va quindi attivato 6to4 per una nuova connessione Internet. Può avere senso al massimo per un progetto unicast esistente e coordinato esplicitamente; connettività IPv6 nativa, 6rd gestito dal provider o un peer 6in4 fisso sono alternative più controllabili.

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. Il modello delle zone e le regole firewall devono corrispondere all’architettura reale. Device access controlla l’accesso ai servizi del firewall stesso e non sostituisce una regola per il traffico applicativo inoltrato.

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.

L’infrastruttura deve trasportare un protocollo IP incapsulato, non una porta TCP o UDP. 6in4, 6to4 e 6rd usano IPv6-in-IPv4 con il numero di protocollo IPv4 41 (RFC 4213); 4in6 segue il modello di tunnel IPv6 della RFC 2473 e identifica il pacchetto IPv4 interno nell’header IPv6 esterno con il valore Next Header 4 registrato da IANA. Prima della distribuzione, questo preciso percorso dati va confermato con il provider, il firewall a monte e qualsiasi dispositivo NAT. Aprire una porta non sostituisce questa verifica.

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 né valori ottimali universali né un valore predefinito nella pagina di aiuto. Occorre quindi annotare i valori iniziali visualizzati nel proprio modulo e modificarli solo se lo richiede un requisito specifico dell’infrastruttura o della QoS.

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.

Per l’esempio 6in4, andare in Rules and policies > Firewall rules, selezionare IPv6 e quindi Add firewall rule > New firewall rule. Impostare Action: Accept, i valori effettivi di Source zones, Source networks and devices, Destination zones, Destination networks e Services, e attivare Log firewall traffic. Posizionare la regola in modo che una regola più ampia non venga applicata per prima. Le risposte appartenenti a una connessione stateful consentita non richiedono una seconda regola. Creare una regola distinta e altrettanto ristretta solo se il peer deve poter avviare nuove connessioni.

Per un normale collegamento tra sedi si conserva l’indirizzo source originale. Lasciare disattivato Create linked NAT rule; MASQ non va attivato per compensare l’assenza del percorso di ritorno. SFOS inoltra senza traduzione il traffico consentito quando nessuna regola NAT corrisponde. Se il progetto richiede davvero la traduzione, pianificarla e provarla separatamente con i flussi originali e tradotti. 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. In Diagnostics > Tools > Route lookup, inserire l’indirizzo interno 2001:db8:200::20 e confermare l’interfaccia tunnel prevista.
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. In Diagnostics > Packet capture > Configure, inserire host 192.0.2.10 and host 198.51.100.20 in Enter BPF string per il controllo esterno e salvare. Avviare la cattura, generare un solo test e arrestarla. Per una cattura interna separata, cancellare il BPF string in Configure e salvare; quindi impostare Ethernet type: IPv6 e Destination IP: 2001:db8:200::20 in Display filter e salvare. Avviare la cattura per un solo test, quindi arrestarla.
7. Sul peer verificare ingresso, decapsulamento, route di ritorno e indirizzo source effettivo.
8. Provare una nuova connessione avviata dal peer solo se una regola distinta la consente; la regola stateful copre già il traffico di risposta.

Una voce tunnel non dimostra né la route né la raggiungibilità 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 e disattivare la nuova regola firewall. Eliminare soltanto le route manuali create per questo tunnel oppure ripristinare le route modificate allo stato iniziale annotato. Confrontare esplicitamente le route automatiche di 6to4 o 6rd con il rilievo prima/dopo. Eliminare il tunnel solo quando non rimane alcuna dipendenza produttiva, quindi rimuovere singolarmente qualsiasi route automatica rimasta. Infine confermare il percorso precedente con Route lookup e provare nuovamente 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