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.

Procedura sintetica: Pianificare separatamente la rete di destinazione interna e gli endpoint esterni, salvare il tipo appropriato in Network > IP tunnels > Add, aggiungere la route e il percorso di ritorno, oltre a una regola ristretta per il traffico interno. Quindi provare una nuova sessione applicativa e verificare separatamente incapsulamento esterno, decapsulamento e Rule ID. Save conferma la configurazione, non un percorso dati testato con successo.

⚠️ 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.

La guida SFOS 23 precisa il meccanismo automatico: 6to4 ricava il prefisso IPv6 dall’indirizzo IPv4 pubblico locale. Non si configura un endpoint remoto; il gateway di destinazione viene determinato automaticamente dall’indirizzo IPv6 di destinazione. 6rd utilizza invece prefissi IPv6 e gateway relay forniti dall’ISP. Il firewall determina automaticamente il gateway relay fornito dall’ISP. Occorre quindi un servizio 6rd adeguato dell’ISP; se è disponibile IPv6 nativo, va preferito. Questi meccanismi non modificano l’avvertenza seguente sulla tecnologia legacy.

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.

Nelle altre impostazioni viene visualizzato questo nome personalizzabile dell’interfaccia, non l’Hardware name immutabile.

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.

L’elenco completo delle restrizioni documentate per Hardware name in SFOS 22 e 23 è: all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp, imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port, MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos, GuestAP, spq, Halink. Il nome non può contenere nessuno di questi frammenti; il divieto non riguarda solo nomi completi identici. Le grafie documentate vengono mantenute senza dedurre come vengano controllate maiuscole e minuscole.

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.

L’etichetta Remote endpoint segue la guida SFOS 22. La guida SFOS 23 chiama il campo Remote gateway: accetta un indirizzo IPv4 o un FQDN per 6in4, e un indirizzo IPv6 o un FQDN per 4in6. Un FQDN è il nome DNS completo del peer, non il prefisso interno di destinazione. Per Local endpoint, SFOS 23 descrive un indirizzo associato a un’interfaccia (6in4/6to4), esplicitamente un indirizzo IPv4 associato per 6rd, e un’interfaccia IPv6 per 4in6. La famiglia degli indirizzi locali rimane quella descritta sotto. Le differenze nella guida non dimostrano in quale release esatta sia iniziato il supporto a runtime.

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.

Queste nozioni di base TTL/TOS seguono la guida SFOS 22. La guida SFOS 23 spiega TTL come il numero massimo di router che un pacchetto incapsulato può attraversare prima di essere scartato. Il limite aiuta a prevenire i loop di routing. Anche qui non viene indicato un valore numerico predefinito per TTL o ToS.

Per 4in6, SFOS 23 descrive inoltre queste impostazioni avanzate:

• Inherit ToS è facoltativo e utilizza il valore ToS del pacchetto interno.
• MTU è la dimensione massima del pacchetto in byte che può attraversare il tunnel senza frammentazione. Il valore predefinito documentato è la MTU dell’interfaccia fisica meno 48 byte; la riduzione tiene conto dell’overhead di incapsulamento 4in6.
• Override MSS è facoltativo e permette di specificare manualmente la MSS. MSS indica il payload TCP massimo in byte in un singolo pacchetto TCP senza frammentazione. Regolarla consente di evitare la frammentazione o rispettare i limiti di Path MTU. Il valore predefinito documentato è il valore MTU meno 40 byte.

Queste formule sono valori documentati, non calcoli autonomi dell’overhead del protocollo né risultati di laboratorio. Non viene affermato uno stato di attivazione predefinito per le caselle facoltative. Ogni modifica dipende comunque dal percorso reale.

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.

API SFOS 23: schema e validazione

Questa sezione descrive la documentazione API per Add IP Tunnel / Edit IP Tunnel, non la procedura WebAdmin né una richiesta testata. Rispetto alla documentazione SFOS 22, la tabella dei parametri SFOS 23 aggiunge quattro campi facoltativi di tipo SCALAR:

• MSS: INTEGER, intervallo consentito 536–8912, al massimo quattro cifre.
• MTU: INTEGER, intervallo consentito 576–8952, al massimo quattro cifre.
• LocalInterface: STRING per l’interfaccia locale del tunnel; la cella Default è vuota. Questo non conferma un valore predefinito a runtime.
• InheritToS: valori consentiti Disable ed Enable.

La tabella non conferma l’applicabilità di ogni campo a ogni tipo di tunnel, la precedenza tra LocalInterface e LocalEndPoint, le combinazioni obbligatorie di campi o la release in cui è iniziato il supporto a runtime. Le indicazioni WebAdmin su endpoint e FQDN non diventano una garanzia di compatibilità API.

Stato API 541 per Add ed Edit

Per entrambe le operazioni, SFOS 23 documenta lo stato 541 con il messaggio MTU and MSS must not exceed the local interface values. MTU e MSS non devono quindi superare i valori corrispondenti dell’interfaccia locale. Prima di modificare qualsiasi valore, confrontare MTU/MSS inviati, l’interfaccia locale associata e la sua configurazione registrata. Questa validazione API non misura la MTU del percorso dati e non conferma una relazione generale di calcolo tra MTU e MSS.

I valori predefiniti contraddittori restano irrisolti

La tabella API riporta letteralmente Default: Enable per MSS, sebbene descriva il campo come INTEGER con un intervallo numerico. Per InheritToS riporta letteralmente Default: off, mentre elenca solo Disable ed Enable come valori consentiti. Questi valori contraddittori della documentazione non sono valori consigliati per un payload e non vengono corretti né reinterpretati come altri token.

L’API indica inoltre una MTU predefinita di 1500 e descrive l’ereditarietà ToS dall’interfaccia locale. La guida WebAdmin per 4in6 indica invece la MTU dell’interfaccia fisica meno 48 byte, MSS uguale a MTU meno 40 byte ed ereditarietà ToS dal pacchetto interno. La corrispondenza tra queste interfacce rimane irrisolta; le formule corrette e i controlli facoltativi WebAdmin descritti sopra restano invariati.

Restano escluse le istruzioni operative di automazione che presuppongono questi valori predefiniti, regole di ereditarietà o priorità tra campi. Qui non viene quindi fornito alcun payload API eseguibile. Occorre un chiarimento di Sophos o un test espressamente autorizzato sulla versione SFOS corrispondente; le informazioni documentate sullo schema e sullo stato non costituiscono un test del prodotto.

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.

Per le route IPv6 aggiuntive dopo il salvataggio di 6to4 o 6rd, SFOS 23 indica nel pop-up i campi Destination IP (IPv6) e Gateway (IPv6). Inserire destinazione e gateway secondo il progetto e selezionare Save; scegliere Cancel se non serve un’altra route. Questi campi IPv6 non si applicano alla route IPv4 interna di un tunnel 4in6. Resta valida l’avvertenza SFOS 22 sulla configurazione salvata quando si usa Cancel.

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.

4in6: trasportare traffico applicativo IPv4 su IPv6

Con 4in6, rispetto all’esempio 6in4, non cambia soltanto il tipo di tunnel. Gli endpoint esterni sono IPv6, mentre le reti instradate e le regole firewall sono IPv4. Un esempio di pianificazione separato utilizza 10.10.10.0/24 come rete locale, 10.20.20.0/24 come rete remota e 10.20.20.20 come server di test. L’indirizzo dell’interfaccia locale esterna è 2001:db8:10::10, mentre l’indirizzo del gateway remoto è 2001:db8:20::20. Le reti IPv4 private e gli indirizzi IPv6 di documentazione vanno sostituiti con reti interne univoche e non sovrapposte ed endpoint IPv6 effettivamente raggiungibili attraverso l’infrastruttura sottostante.

1. Verificare prima il percorso IPv6 dell’infrastruttura sottostante verso 2001:db8:20::20. La route verso il peer esterno deve passare attraverso l’infrastruttura sottostante, non attraverso il tunnel che si intende creare proprio con quel peer. Un ping riuscito da solo non dimostra ancora il trasporto dei pacchetti IPv4 incapsulati.
2. In Network > IP tunnels > Add, selezionare 4in6, impostare un nome e un Hardware name univoci e assegnare la Zone prevista. In SFOS 23, in Local endpoint, selezionare l’interfaccia IPv6 con l’indirizzo locale previsto e, in Remote gateway, inserire l’indirizzo IPv6 remoto. Sul peer, gli endpoint locale e remoto vengono invertiti. Restano da rispettare le impostazioni SFOS 23 per MTU, Override MSS e Inherit ToS descritte sopra.
3. Dopo Save, in Routing > Static routes, creare una route IPv4 verso 10.20.20.0/24 tramite la nuova interfaccia tunnel. Sul peer si configura il percorso di ritorno verso 10.10.10.0/24. I campi IPv6 della finestra delle route aggiuntive di 6to4/6rd non costituiscono il modello da seguire per questa operazione.
4. In Rules and policies > Firewall rules, selezionare IPv4. Consentire soltanto le connessioni necessarie dalla rete IPv4 locale a quella remota, impostare le zone e i servizi effettivi e attivare Log firewall traffic. Gli indirizzi IPv6 dell’infrastruttura sottostante non devono sostituire le reti IPv4 interne in questa regola per il traffico applicativo. Se non è prevista una traduzione degli indirizzi, l’indirizzo source viene conservato.
5. Verificare 10.20.20.20 con Diagnostics > Tools > Route lookup, quindi avviare dal client di test locale una nuova connessione consentita verso questo server. Sul peer si verificano il decapsulamento e il percorso di ritorno. Dopo la conclusione della sessione di test, in Log Viewer devono comparire gli indirizzi IPv4 interni e la Firewall Rule ID prevista; durante la sessione, la cattura serve a verificare immediatamente il percorso.
6. Per la cattura esterna, nella procedura di cattura descritta sotto, utilizzare il filtro BPF host 2001:db8:10::10 and host 2001:db8:20::20. Per la cattura interna separata, svuotare nuovamente il BPF string e, in Display filter, selezionare Ethernet type: IPv4 e Destination IP: 10.20.20.20. Acquisire ogni volta un solo test e poi arrestare la cattura. Il rollback segue la stessa verifica delle dipendenze descritta sotto, ma in questo caso riguarda le route e le regole IPv4 create appositamente.

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.

Il filtro sugli host esterni acquisisce anche altro traffico tra gli endpoint. Per l’esempio 6in4, occorre quindi cercare pacchetti con gli indirizzi IPv4 esterni previsti e protocollo IP 41; un ping ICMP tra gli stessi host non dimostra l’incapsulamento. Per 4in6, si verifica analogamente un pacchetto IPv6 esterno contenente un pacchetto IPv4 interno. Solo il confronto con la cattura interna e con la sessione applicativa effettivamente riuscita dimostra il percorso completo. I dati acquisiti possono contenere payload e devono essere conservati solo in modo protetto oppure anonimizzati prima di essere condivisi.

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.

Il traffico di test non compare nella cattura esterna

Confrontare prima i filtri di cattura e di visualizzazione attivi con gli endpoint esterni effettivamente utilizzati. Se Remote gateway è un FQDN, verificare che il firewall possa risolvere il nome nell’indirizzo del peer previsto e appropriato al tipo di tunnel: IPv4 per 6in4, IPv6 per 4in6. La sola opzione FQDN non dimostra né una specifica frequenza di aggiornamento DNS né un failover senza interruzioni in caso di cambio di indirizzo.

Verificare quindi che il client di test invii effettivamente traffico verso la destinazione interna e raggiunga il firewall tramite il proprio gateway. Sul firewall, la decisione di routing per questa destinazione deve selezionare l’interfaccia tunnel. Se l’incapsulamento appropriato è visibile localmente ma non sul peer, si passa alla verifica del percorso dell’infrastruttura sottostante e dei protocolli consentiti dal provider e dai dispositivi a monte. Le regole non vanno estese indiscriminatamente a Any e il NAT non va attivato per tentativi come sostituto di questa analisi. Se la causa resta irrisolta, la versione SFOS, le configurazioni di entrambi gli endpoint, le route e le catture temporalmente coordinate sui due lati costituiscono la base per l’escalation.

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.

Secondo la guida SFOS 23, eliminare un tunnel 6to4 o 6rd elimina anche la relativa route unicast IPv6 statica creata automaticamente. Questa aspettativa non sostituisce i controlli delle dipendenze né il confronto prima/dopo. Non riguarda tutte le route aggiunte manualmente e non viene estesa a SFOS 22 sulla sola base della guida SFOS 23.

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