Configurer un tunnel IP Sophos Firewall avec 6in4, 6to4, 6rd ou 4in6

Sous Network > IP tunnels, Sophos Firewall crée des tunnels qui encapsulent un protocole réseau dans un autre. IPv6 peut ainsi traverser une infrastructure IPv4, ou IPv4 une infrastructure IPv6. SFOS propose 6in4, 6to4, 6rd et 4in6 pour ces scénarios.

Cette fonction n’est ni le tunnel GRE de Device Console ni un VPN IPsec. Un tunnel IP encapsule les paquets, mais ne les chiffre pas et ne les authentifie pas automatiquement.

Procédure rapide : Planifier séparément le réseau de destination interne et les endpoints externes, enregistrer le type adapté sous Network > IP tunnels > Add, puis ajouter la route, le chemin retour et une règle précise pour le trafic interne. Tester ensuite une nouvelle session applicative et vérifier séparément l’encapsulation externe, la décapsulation et la Rule ID. Save confirme la configuration, pas la réussite d’un test du chemin de données.

⚠️ Un tunnel IP ne doit traverser une infrastructure non fiable que si le design de sécurité accepte explicitement l’absence de confidentialité et d’authentification du peer. Pour une interconnexion de sites protégée, IPsec site-à-site constitue généralement un meilleur point de départ.

Quel type de tunnel choisir ?

Les quatre types ne répondent pas au même besoin :

• 6in4 relie deux réseaux IPv6 à travers un backbone IPv4. Les endpoints IPv4 local et distant sont configurés manuellement. Sophos recommande ce type pour une liaison point à point.
• 6to4 transporte IPv6 sur IPv4 et vise les designs point à multipoint. La source IPv4 locale est définie manuellement, tandis que l’adresse de destination peut être obtenue automatiquement.
• 6rd étend 6to4 avec un préfixe fourni par l’opérateur. Ce type ne convient que si le FAI fournit les valeurs 6rd nécessaires.
• 4in6 relie deux réseaux IPv4 à travers un backbone IPv6. Les endpoints externes local et distant sont des adresses IPv6, et ce type vise une liaison point à point.

L’aide SFOS 23 précise le mécanisme automatique : 6to4 déduit le préfixe IPv6 de l’adresse IPv4 publique locale. Aucun endpoint distant n’est configuré ; la passerelle de destination est déterminée automatiquement à partir de l’adresse IPv6 de destination. 6rd utilise en revanche des préfixes IPv6 et des passerelles relais fournis par le FAI. Le pare-feu détermine automatiquement la passerelle relais fournie par le FAI. Cela nécessite un service 6rd adapté du FAI ; si IPv6 natif est disponible, il est à privilégier. Ces mécanismes ne changent pas l’avertissement ci-dessous sur cette technologie ancienne.

Pour un lien contrôlé avec des endpoints fixes, 6in4 ou 4in6 est plus facile à comprendre. Il ne faut pas choisir 6to4 ou 6rd uniquement parce que SFOS peut créer automatiquement une route. Le plan d’adressage et le design de l’opérateur doivent correspondre exactement à ce mécanisme.

Pour 6to4, il faut aussi distinguer le mécanisme unicast toujours défini du mécanisme de relais anycast public. L’IETF a abandonné l’anycast 6to4 en raison de ses problèmes opérationnels et recommande de laisser 6to4 désactivé par défaut sur les routeurs (RFC 7526). Il ne faut donc pas activer 6to4 pour une nouvelle connexion Internet. Il convient tout au plus à un design unicast existant et explicitement coordonné ; une connectivité IPv6 native, un 6rd géré par l’opérateur ou un peer 6in4 fixe sont plus faciles à maîtriser.

La prise en charge d’IPv6 sur Sophos Firewall résume les limites IPv6 de SFOS. À l’inverse, un tunnel GRE transporte du trafic IP routé via une procédure Device Console distincte et n’est pas interchangeable avec ces quatre types WebAdmin.

Planifier l’exemple et les prérequis

L’exemple utilise un tunnel 6in4 statique entre deux sites :

• Nom affiché : HQ-IPv6-via-IPv4
• Hardware name : v6hq01
• Adresse WAN IPv4 locale : 192.0.2.10
• Endpoint IPv4 distant : 198.51.100.20
• Réseau IPv6 local : 2001:db8:100::/64
• Réseau IPv6 distant : 2001:db8:200::/64
• Serveur de test : 2001:db8:200::20
• Zone de l’interface de tunnel : VPN dans l’exemple

192.0.2.0/24, 198.51.100.0/24 et 2001:db8::/32 sont des plages de documentation. Elles doivent être remplacées, comme les noms, la zone et les préfixes, par les valeurs réelles. La zone VPN est un choix d’exemple compréhensible, pas une exigence du produit. Le modèle de zones et les règles de pare-feu doivent correspondre à l’architecture réelle. Device access contrôle l’accès aux services du pare-feu lui-même et ne remplace pas une règle pour le trafic applicatif transféré.

Les deux endpoints externes doivent être joignables via l’infrastructure avant la création du tunnel. Chaque côté nécessite un tunnel en miroir, des réseaux internes uniques, un chemin retour et une règle de pare-feu pour le trafic applicatif réel. Des préfixes qui se chevauchent, une valeur opérateur manquante pour 6rd ou une configuration inconnue du peer sont des conditions d’arrêt.

L’infrastructure doit transporter un protocole IP encapsulé, et non un port TCP ou UDP. 6in4, 6to4 et 6rd utilisent IPv6 dans IPv4 avec le numéro de protocole IPv4 41 (RFC 4213) ; 4in6 suit le modèle de tunnel IPv6 de la RFC 2473 et identifie le paquet IPv4 interne dans l’en-tête IPv6 externe par la valeur Next Header 4 enregistrée par l’IANA. Il faut confirmer ce chemin de données précis avec l’opérateur, le pare-feu amont et tout équipement NAT avant le déploiement. Ouvrir un port ne remplace pas cette vérification.

Une sauvegarde, une fenêtre de maintenance et un accès de gestion indépendant font aussi partie du plan de retour. Le tunnel ne doit pas servir d’essai sur l’unique connexion de production.

Créer le tunnel IP dans WebAdmin

Sous Network > IP tunnels > Add, il faut d’abord définir l’identité et le type du tunnel, puis les endpoints et les valeurs IP avancées.

Distinguer Name et Hardware name

Le Name normal peut contenir jusqu’à 58 caractères et être modifié ultérieurement. Il doit identifier l’usage et le peer, par exemple HQ-IPv6-via-IPv4.

Les autres paramètres affichent ce nom d’interface personnalisable, et non le Hardware name immuable.

Le Hardware name est technique et ne peut plus être modifié après l’enregistrement. Il contient au maximum dix caractères et uniquement A-Z, a-z, 0-9 et _. SFOS bloque aussi de nombreux noms et fragments système, notamment gre, ipsec0, sit, tun, xfrm, Port, MGMT, eth, WLAN et Halink. La valeur neutre v6hq01 évite ces conflits.

Un Hardware name incorrect ne peut pas être renommé par la suite. Il faut documenter ses dépendances et recréer le tunnel de façon contrôlée. Cette valeur doit donc être contrôlée avec une attention particulière avant Save.

La liste complète des restrictions documentées pour Hardware name dans SFOS 22 et 23 est : 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. Le nom ne doit contenir aucun de ces fragments ; l’interdiction ne se limite pas aux noms complets identiques. Les graphies documentées sont conservées sans en déduire le comportement de la vérification de casse.

Définir le type, la zone et les endpoints

Pour l’exemple, sélectionner 6in4. Définir la zone de sécurité prévue sous Zone. Saisir 192.0.2.10 sous Local endpoint et 198.51.100.20 sous Remote endpoint.

Le libellé Remote endpoint suit l’aide SFOS 22. L’aide SFOS 23 nomme ce champ Remote gateway : il accepte une adresse IPv4 ou un FQDN pour 6in4, et une adresse IPv6 ou un FQDN pour 4in6. Un FQDN est le nom DNS complet du peer, pas le préfixe interne de destination. Pour Local endpoint, SFOS 23 décrit une adresse associée à une interface (6in4/6to4), explicitement une adresse IPv4 associée pour 6rd, et une interface IPv6 pour 4in6. La famille d’adresses locale reste celle décrite ci-dessous. Ces différences de rédaction ne prouvent pas dans quelle version exacte la prise en charge à l’exécution a commencé.

La famille d’adresses dépend du type. Pour 6in4, 6to4 et 6rd, l’endpoint externe local est en IPv4 ; 6in4 possède aussi un endpoint IPv4 distant fixe. Pour 4in6, les endpoints externes local et distant sont des adresses IPv6. Une route de destination interne ne se place pas dans un champ d’endpoint.

Dans les paramètres avancés, TTL influence la durée de vie des paquets encapsulés dans l’infrastructure. TOS attribue au paquet IP externe une valeur de type de service destinée à la priorité et au comportement de routage. L’aide actuelle ne prescrit ni valeur optimale universelle ni valeur par défaut sur la page d’aide. Il faut donc consigner les valeurs initiales affichées dans son propre formulaire et ne les modifier que si une exigence précise de l’infrastructure ou de QoS le demande.

Ces bases TTL/TOS suivent l’aide SFOS 22. L’aide SFOS 23 explique TTL comme le nombre maximal de routeurs qu’un paquet encapsulé peut traverser avant d’être supprimé. Cette limite aide à éviter les boucles de routage. Elle n’indique pas non plus de valeur numérique par défaut pour TTL ou ToS.

Pour 4in6, SFOS 23 décrit aussi les paramètres avancés suivants :

• Inherit ToS est facultatif et reprend la valeur ToS du paquet interne.
• MTU est la taille maximale d’un paquet, en octets, pouvant traverser le tunnel sans fragmentation. La valeur par défaut documentée est la MTU de l’interface physique moins 48 octets ; cette réduction tient compte de la surcharge d’encapsulation 4in6.
• Override MSS est facultatif et permet de définir manuellement la MSS. La MSS est la plus grande charge utile TCP, en octets, dans un seul paquet TCP sans fragmentation. Son ajustement permet d’éviter la fragmentation ou de tenir compte des limites de Path MTU. La valeur par défaut documentée est la valeur MTU moins 40 octets.

Ces formules sont des valeurs documentées, pas des calculs indépendants à partir de la surcharge du protocole ni des résultats de laboratoire. Aucun état d’activation par défaut n’est affirmé pour les cases facultatives. Tout ajustement dépend toujours du chemin réel.

Après Save, SFOS confirme la création et ouvre la boîte de dialogue des routes. Pour 6to4 et 6rd, le pare-feu crée aussi automatiquement une route unicast IPv6 statique. Important : fermer cette fenêtre ou sélectionner Cancel ne supprime ni le tunnel ni les routes créées automatiquement.

API SFOS 23 : schéma et validation

Cette section décrit la documentation de l’API pour Add IP Tunnel / Edit IP Tunnel, et non la procédure WebAdmin ou une requête testée. Par rapport à la documentation SFOS 22, la table des paramètres SFOS 23 ajoute quatre champs facultatifs de type SCALAR :

• MSS : INTEGER, plage autorisée 536–8912, quatre chiffres au maximum.
• MTU : INTEGER, plage autorisée 576–8952, quatre chiffres au maximum.
• LocalInterface : STRING pour l’interface locale du tunnel ; la cellule Default est vide. Cela ne confirme aucune valeur par défaut à l’exécution.
• InheritToS : valeurs autorisées Disable et Enable.

La table ne confirme ni l’applicabilité de chaque champ à chaque type de tunnel, ni la priorité entre LocalInterface et LocalEndPoint, ni les combinaisons de champs obligatoires, ni la version où la prise en charge à l’exécution a commencé. Les indications WebAdmin sur les endpoints et les FQDN ne constituent pas une promesse de compatibilité avec l’API.

Statut API 541 pour Add et Edit

Pour les deux opérations, SFOS 23 documente le statut 541 avec le message MTU and MSS must not exceed the local interface values. MTU et MSS ne doivent donc pas dépasser les valeurs correspondantes de l’interface locale. Avant toute modification, comparer les valeurs MTU/MSS envoyées, l’interface locale associée et sa configuration consignée. Cette validation de l’API ne mesure pas la MTU du chemin de données et ne confirme aucune relation générale de calcul entre MTU et MSS.

Des valeurs par défaut contradictoires restent non résolues

La table de l’API indique littéralement Default: Enable pour MSS, alors que le champ est décrit comme INTEGER avec une plage numérique. Pour InheritToS, elle indique littéralement Default: off, alors que seules les valeurs Disable et Enable sont autorisées. Ces valeurs contradictoires de la documentation ne sont pas des valeurs recommandées pour un payload ; elles ne sont ni corrigées ni réinterprétées comme d’autres tokens.

L’API indique aussi une MTU par défaut de 1500 et décrit l’héritage ToS depuis l’interface locale. À l’inverse, l’aide WebAdmin pour 4in6 indique la MTU de l’interface physique moins 48 octets, une MSS égale à la MTU moins 40 octets et l’héritage ToS depuis le paquet interne. La correspondance entre ces interfaces reste non résolue ; les formules correctes et les commandes facultatives WebAdmin ci-dessus restent inchangées.

Les instructions d’automatisation directement applicables qui reposent sur ces valeurs par défaut, règles d’héritage ou priorités entre champs restent exclues. Aucun payload d’API exécutable n’est donc fourni ici. Une clarification de Sophos ou un test expressément autorisé sur la version SFOS correspondante est nécessaire ; les informations documentées sur le schéma et le statut ne constituent pas un test du produit.

Ajouter les routes et les règles de pare-feu

Un tunnel enregistré ne constitue pas encore un chemin de données fonctionnel. Pour 6in4, ajouter une route IPv6 statique vers le préfixe distant 2001:db8:200::/64 via la nouvelle interface de tunnel. Le peer a besoin du chemin retour en miroir vers 2001:db8:100::/64.

Pour 4in6, la route interne mène à un réseau de destination IPv4. Pour 6to4 et 6rd, lire la route IPv6 créée automatiquement et la comparer au design de l’opérateur avant d’ajouter d’autres routes. Cancel dans la première boîte de dialogue des routes ne constitue pas un rollback.

Pour les routes IPv6 supplémentaires après l’enregistrement de 6to4 ou 6rd, SFOS 23 indique les champs Destination IP (IPv6) et Gateway (IPv6) dans la fenêtre contextuelle. Saisir la destination et la passerelle selon le design, puis choisir Save ; choisir Cancel si aucune route supplémentaire n’est nécessaire. Ces champs IPv6 ne s’appliquent pas à la route IPv4 interne d’un tunnel 4in6. L’avertissement SFOS 22 sur la configuration enregistrée avec Cancel reste à respecter.

Les routes supplémentaires se créent sous Routing > Static routes. Les routes statiques sur Sophos Firewall expliquent comment le préfixe de destination, l’interface, la distance, la décision de routage et un test réel s’articulent.

Pour l’exemple 6in4, aller dans Rules and policies > Firewall rules, sélectionner IPv6, puis Add firewall rule > New firewall rule. Définir Action: Accept, les valeurs réelles de Source zones, Source networks and devices, Destination zones, Destination networks et Services, puis activer Log firewall traffic. Positionner la règle de sorte qu’aucune règle plus large ne corresponde avant elle. Les réponses appartenant à une connexion avec suivi d’état autorisée ne nécessitent pas de seconde règle. Créer une règle distincte et tout aussi précise uniquement si le peer doit pouvoir initier de nouvelles connexions.

Pour une liaison de sites normale, conserver l’adresse source d’origine. Laisser Create linked NAT rule désactivé ; ne pas activer MASQ pour compenser un chemin retour absent. SFOS laisse passer le trafic autorisé sans traduction lorsqu’aucune règle NAT ne correspond. Si le design exige réellement une traduction, la planifier et la tester séparément avec les flux avant et après traduction. La procédure est décrite dans Configurer les règles Sophos Firewall en toute sécurité.

4in6 : transporter le trafic applicatif IPv4 sur IPv6

Avec 4in6, le changement par rapport à l’exemple 6in4 ne se limite pas au type de tunnel. Les endpoints externes sont en IPv6, tandis que les réseaux routés et les règles de pare-feu sont en IPv4. Un exemple de planification distinct utilise 10.10.10.0/24 localement, 10.20.20.0/24 à distance et 10.20.20.20 comme serveur de test. L’adresse de l’interface locale externe est 2001:db8:10::10, et l’adresse de la passerelle distante est 2001:db8:20::20. Les réseaux IPv4 privés et les adresses IPv6 de documentation doivent être remplacés par des réseaux internes uniques et sans chevauchement, ainsi que par des endpoints IPv6 réellement joignables via l’infrastructure sous-jacente.

1. Vérifier au préalable le chemin IPv6 de l’infrastructure sous-jacente vers 2001:db8:20::20. La route vers le peer externe doit passer par cette infrastructure, et non par le tunnel que l’on souhaite établir avec ce peer. Un ping réussi ne prouve pas à lui seul que les paquets IPv4 encapsulés peuvent être transportés.
2. Sous Network > IP tunnels > Add, choisir 4in6, définir un nom unique et un Hardware name, puis attribuer la Zone prévue. Dans SFOS 23, sélectionner sous Local endpoint l’interface IPv6 portant l’adresse locale prévue et saisir l’adresse IPv6 distante sous Remote gateway. Sur le peer, les endpoints local et distant sont inversés. Les paramètres SFOS 23 décrits ci-dessus pour MTU, Override MSS et Inherit ToS restent à respecter.
3. Après Save, créer sous Routing > Static routes une route IPv4 vers 10.20.20.0/24 via la nouvelle interface de tunnel. Le peer reçoit la route retour vers 10.10.10.0/24. Les champs IPv6 de la boîte de dialogue des routes supplémentaires pour 6to4/6rd ne servent pas de modèle ici.
4. Sous Rules and policies > Firewall rules, sélectionner IPv4. Autoriser uniquement les connexions nécessaires du réseau IPv4 local vers le réseau IPv4 distant, définir les zones et les services réels, puis activer Log firewall traffic. Les adresses IPv6 de l’infrastructure sous-jacente ne doivent pas remplacer les réseaux IPv4 internes dans cette règle de trafic applicatif. En l’absence de traduction d’adresses prévue, l’adresse source est conservée.
5. Vérifier 10.20.20.20 avec Diagnostics > Tools > Route lookup, puis lancer depuis le client de test local une nouvelle connexion autorisée vers ce serveur. Sur le peer, vérifier la décapsulation et le chemin retour. Une fois la session de test terminée, les adresses IPv4 internes et la Firewall Rule ID attendue doivent apparaître dans Log Viewer ; pendant la session, la capture permet de vérifier immédiatement le chemin.
6. Pour la capture externe, utiliser le filtre BPF host 2001:db8:10::10 and host 2001:db8:20::20 dans la procédure de capture décrite ci-dessous. Pour la capture interne distincte, effacer à nouveau le BPF string et sélectionner Ethernet type: IPv4 ainsi que Destination IP: 10.20.20.20 sous Display filter. Ne capturer qu’un seul test à la fois, puis arrêter la capture. Le rollback s’effectue avec la même vérification des dépendances que ci-dessous, mais porte ici sur les routes et les règles IPv4 créées spécifiquement.

Valider le tunnel et le trafic applicatif

La validation distingue la configuration enregistrée, l’encapsulation externe et l’application interne :

1. Sous Network > IP tunnels, comparer Name, Hardware name, type, Zone et endpoints avec le peer.
2. Sous Routing > Static routes, vérifier que le préfixe interne distant pointe vers l’interface de tunnel attendue.
3. Sous Diagnostics > Tools > Route lookup, saisir l’adresse interne 2001:db8:200::20 et confirmer l’interface de tunnel attendue.
4. Depuis le client de test local, lancer une nouvelle connexion vers 2001:db8:200::20 avec un service explicitement autorisé.
5. Dans Log Viewer, contrôler Source, Destination, Service, Action et Firewall Rule ID.
6. Sous Diagnostics > Packet capture > Configure, saisir host 192.0.2.10 and host 198.51.100.20 dans Enter BPF string pour la vérification externe, puis enregistrer. Démarrer la capture, générer un seul test, puis l’arrêter. Pour une capture interne distincte, effacer le BPF string sous Configure et enregistrer ; définir ensuite Ethernet type: IPv6 et Destination IP: 2001:db8:200::20 sous Display filter, puis enregistrer. Démarrer la capture pour un seul test, puis l’arrêter.
7. Sur le peer, vérifier l’entrée, la décapsulation, la route retour et l’adresse source réelle.
8. Tester une nouvelle connexion initiée par le peer uniquement si une règle distincte l’autorise ; la règle avec suivi d’état couvre déjà le trafic de réponse.

Le filtre externe par hôtes capture aussi d’autres trafics entre les endpoints. Pour l’exemple 6in4, il faut donc rechercher des paquets portant les adresses IPv4 externes attendues et utilisant le protocole IP 41 ; un ping ICMP entre les mêmes hôtes ne prouve pas l’encapsulation. Pour 4in6, vérifier de la même manière un paquet IPv6 externe contenant un paquet IPv4 interne. Seule la comparaison avec la capture interne et une session applicative réellement réussie prouve le fonctionnement du chemin complet. Les données de capture peuvent contenir des données applicatives et doivent être stockées de manière sécurisée ou anonymisées avant toute transmission.

Une entrée de tunnel ne prouve ni la route ni l’accessibilité du peer. Une route créée automatiquement ne prouve pas non plus que l’opérateur, les équipements intermédiaires et les règles transportent effectivement l’encapsulation. Packet Capture sur Sophos Firewall explique la capture contrôlée.

Rechercher la panne par symptôme

Impossible d’enregistrer le tunnel

Contrôler séparément Name et Hardware name. Hardware name comporte au maximum dix caractères, uniquement les caractères autorisés et aucun terme système bloqué. Vérifier ensuite que le type de tunnel et la famille d’adresses des endpoints local et distant correspondent.

Un nom affiché différent ne corrige pas un Hardware name non valide. Si une autre interface utilise déjà cette valeur, planifier un nom technique unique plutôt que d’essayer plusieurs suffixes aléatoires.

Le tunnel existe, mais aucune route ne mène au réseau de destination

Pour 6in4 et 4in6, ajouter explicitement la route statique nécessaire. Pour 6to4 et 6rd, vérifier que SFOS a créé la route unicast IPv6 attendue et que son préfixe correspond au design. Une fenêtre précédemment fermée avec Cancel ne supprime pas la configuration enregistrée automatiquement.

Route Lookup et la table de routage apportent la preuve suivante. Ne pas modifier Route Precedence globalement sur la base d’un soupçon et ne pas ajouter de route blackhole ou fictive concurrente pour tester.

Le trafic de test est absent de la capture externe

Comparer d’abord les filtres de capture et d’affichage actifs avec les endpoints externes réellement utilisés. Si Remote gateway est défini par un FQDN, vérifier que le pare-feu peut résoudre ce nom en l’adresse du peer attendue, dans la famille correspondant au type de tunnel : IPv4 pour 6in4, IPv6 pour 4in6. La seule présence de l’option FQDN ne prouve ni une fréquence précise de mise à jour DNS ni un basculement sans interruption lors d’un changement d’adresse.

Vérifier ensuite que le client de test envoie effectivement du trafic vers la destination interne et atteint le pare-feu via sa passerelle. Sur le pare-feu, la décision de routage pour cette destination doit sélectionner l’interface de tunnel. Si l’encapsulation appropriée est visible localement mais pas sur le peer, vérifier ensuite le chemin de l’infrastructure sous-jacente et les autorisations de protocole chez l’opérateur et sur les équipements en amont. Ne pas élargir systématiquement les règles à Any, ni activer NAT à titre d’essai pour remplacer cette recherche ciblée. Si la cause reste inconnue, la version SFOS, les configurations des deux endpoints, les routes et des captures synchronisées des deux côtés constituent la base de l’escalade.

Les paquets externes sont visibles, mais le trafic interne manque

Le type du peer, les adresses d’endpoint, le préfixe interne ou la route retour sont souvent incohérents. Comparer les deux configurations en miroir, puis vérifier la règle de pare-feu, la Firewall Rule ID attendue et une capture des adresses source et destination internes.

Une encapsulation fonctionnelle ne prouve pas que le trafic applicatif est autorisé. Inversement, l’absence de Rule ID peut signifier que le paquet interne n’a jamais été décapsulé ou qu’une autre route l’a traité.

Les petits paquets passent, mais les applications se bloquent

L’encapsulation IP externe supplémentaire réduit la taille de paquet utilisable par rapport à l’infrastructure. Au lieu de reprendre une valeur MTU étrangère au chemin, mesurer Path MTU, la fragmentation et l’application concernée. La procédure contrôlée de vérification de MTU et MSS pour les problèmes de tunnel convient aussi à cette analyse, sans reprendre des valeurs IPsec fixes pour le tunnel IP.

HA, modifications et rollback

Les deux pages d’aide SFOS 22 ne promettent pas un état HA ininterrompu pour ces tunnels IP. Après un changement de rôle planifié, contrôler à nouveau l’entrée du tunnel, Route Lookup, l’encapsulation externe, Firewall Rule ID et une nouvelle session applicative. Une connexion existante ne prouve pas la continuité.

Avant toute modification, documenter Name, le Hardware name immuable, le type, Zone, les endpoints, les routes créées automatiquement et manuellement, les règles et le dernier test réel. Il devient alors possible de distinguer une modification de configuration d’un changement de chemin de données.

Selon l’aide SFOS 23, supprimer un tunnel 6to4 ou 6rd supprime aussi sa route unicast IPv6 statique créée automatiquement. Cette attente ne remplace ni la vérification des dépendances ni la comparaison avant/après. Elle ne concerne pas toutes les routes ajoutées manuellement et n’est pas étendue à SFOS 22 sur la seule base de l’aide SFOS 23.

Pour le rollback, arrêter d’abord le trafic de test et désactiver la nouvelle règle de pare-feu. Supprimer uniquement les routes manuelles créées pour ce tunnel ou remettre les routes modifiées dans leur état initial consigné. Comparer explicitement les routes automatiques de 6to4 ou 6rd au relevé avant/après. Supprimer le tunnel seulement lorsqu’il ne reste aucune dépendance de production, puis supprimer individuellement toute route automatique qui subsisterait. Enfin, confirmer l’ancien chemin avec Route lookup et tester de nouveau un flux connu.

Liste de contrôle

• Le type choisi correspond aux familles d’adresses interne et externe.
• Les deux endpoints et les préfixes sont convenus avec le peer.
• Le nom affiché et le Hardware name immuable sont documentés.
• Zone, route statique et chemin retour correspondent au design de sécurité.
• Les routes automatiques de 6to4 ou 6rd ont été contrôlées.
• Une règle précise correspond à la Firewall Rule ID attendue.
• L’encapsulation externe et le trafic interne ont été testés séparément.
• MTU, HA et rollback ont été validés sur le chemin réel.

Questions fréquentes