Sophos RED est un rôle de site distant et non un protocole VPN, et c'est pourquoi le comparer à IPsec ou à OpenVPN répond à la mauvaise question. L'appareil étend le contrôle d'un pare-feu central à une succursale, et le mode que vous choisissez décide qui fournit la passerelle de la succursale, qui distribue les adresses et quel trafic traverse le tunnel. Ces trois réponses pèsent plus que les noms des modes. Les écrire d'abord transforme un choix de produit en décision de conception.

RED est un rôle, pas un protocole

Un appareil RED rattache une succursale à un Sophos Firewall central, et la configuration du pare-feu définit ce que devient la succursale. Le tunnel est un détail de mise en œuvre de ce rattachement, non un point de terminaison VPN universel que l'on pourrait pointer vers n'importe quel pair.

Ce cadrage compte parce qu'un RED n'est pas interchangeable avec un pair IPsec quelconque. Il attend du pare-feu central qu'il le gère, et les modes pris en charge décrivent quelle part de la succursale il prend en charge. Le traiter comme un point de terminaison de tunnel ordinaire crée des attentes que le produit n'a jamais promises. Le traiter comme un rôle fait surgir les questions qui décident réellement de la conception.

Les trois conditions ci-dessous changent la réponse, et toutes portent sur la propriété et non sur le chiffrement.

Trois conditions qui choisissent le mode

Demandez qui possède la passerelle de la succursale, qui exploite DHCP et DNS pour les clients de la succursale, et si la sortie internet locale doit survivre à une panne du tunnel.

Standard/Unified répond aux trois de la même manière : le pare-feu central possède le LAN de la succursale, y compris les tâches de passerelle et de DHCP, et le trafic traverse le tunnel. Standard/Split conserve l'administration centrale et n'envoie dans le tunnel que les réseaux configurés. Transparent/Split laisse le réseau de succursale existant gérer sa propre passerelle et ses adresses, et ne redirige vers le tunnel que le trafic sélectionné. Trois modes, trois propriétaires différents.

ModeBranch gateway and DHCPTraffic through the tunnel
Standard/UnifiedCentral firewall owns bothAll branch traffic
Standard/SplitCentral firewall owns bothOnly the configured networks
Transparent/SplitThe existing branch router keeps bothOnly the selected flows

Lisez d'abord la colonne du milieu, car elle décide quelle part de la succursale fonctionne encore lorsque le tunnel a disparu.

Qui possède la passerelle de la succursale et le DHCP

Dans la disposition unifiée, la succursale n'a pas de passerelle indépendante, ce qui simplifie la configuration et concentre la panne. Cette concentration convient lorsque la succursale est petite et que le pare-feu central est hautement disponible.

Dans un déploiement transparent, la succursale conserve son routeur et le RED se place en ligne pour rediriger le trafic sélectionné. Cela préserve le contrôle local et ajoute un appareil dont la position dans le chemin compte désormais pour chaque flux redirigé. Documentez son emplacement, car une modification ultérieure du routeur de la succursale peut le contourner sans bruit. Aucune des deux dispositions ne gagne en général ; elles répartissent la responsabilité différemment.

La propriété des adresses est la partie à écrire, car deux serveurs DHCP sur un même segment produisent des pannes intermittentes qui sont signalées comme des problèmes de VPN.

Que se passe-t-il lorsque le tunnel tombe

Le fonctionnement en Split est souvent lu comme la promesse que l'internet local continue de fonctionner pendant une panne du tunnel, et cette lecture n'est pas sûre. Le comportement exact dépend du mode choisi, du micrologiciel et de l'appareil, il relève donc des critères d'acceptation et non d'une supposition.

Décidez ce que la succursale doit encore faire sans tunnel : atteindre des imprimantes locales, résoudre des noms, encaisser des paiements, ou rien du tout. Testez ensuite cet état délibérément en bloquant le tunnel et en observant la succursale. Une succursale qui perd le DNS en silence est pire qu'une qui échoue bruyamment, car l'appel au support arrive des heures plus tard. Écrivez le résultat observé dans le dossier de conception.

La dépendance centrale est la même dans tous les modes : quelqu'un doit posséder le chemin de rétablissement de l'appareil lui-même.

Écrivez le contrat de succursale avant de déployer

Un contrat de succursale tient sur une page : propriétaires, sources d'adresses, préfixes tunnelisés, politique de sortie et comportement en panne que vous avez accepté.

Vérifiez ensuite le résultat déployé et non celui qui était prévu. Contrôlez l'adresse du client de la succursale, sa passerelle par défaut, quels préfixes se résolvent par le tunnel et ce qui répond encore lorsque le tunnel est bloqué. Compatibilité, accessibilité et licences doivent toutes être vérifiées face à la documentation actuelle du fournisseur pour le modèle exact, car un nom de produit ne garantit pas un mode. Conservez cette page avec la fiche de l'appareil pour que l'ingénieur suivant hérite des décisions et non du schéma.

ip -br addr
ip route
traceroute -n 10.80.4.10
dig +short intranet.corp.example

Répétez ce bloc avec le tunnel bloqué, et la différence entre les deux exécutions est le comportement en panne que vous avez réellement acheté.

Articles similaires