Cascade SoftEther : relier deux hubs virtuels à dessein
Une cascade relie un hub local à un hub distant sous une identité configurée. Ce n’est pas un nœud de sortie, et elle transporte tout ce que ces hubs pontent déjà.
Deux hubs SoftEther reliés par une cascade partagent un seul domaine de diffusion, donc une boucle ou un second serveur DHCP cesse d’être une erreur locale et devient une erreur partagée. C’est tout le modèle de risque. La cascade elle-même est une relation client configurée : le hub virtuel local se connecte vers le hub d’un serveur distant sous une identité que ce serveur autorise. C’est une brique pour un réseau virtuel plus vaste, jamais une sortie internet.
1. Décidez ce que le lien doit transporter
Partez du besoin, pas de la fonction. Une cascade déplace des trames de couche deux entre hubs, ce qui est voulu quand deux sites doivent ressembler à un seul segment Ethernet. Si le besoin n’est qu’un accès routé à quelques sous-réseaux, un chemin routé est plus simple et échoue de façons plus visibles. Choisir une cascade vous engage à la diffusion partagée, à la découverte partagée et à une seule topologie de boucle.
Écrivez le besoin en une ligne avant de toucher un serveur : quels systèmes doivent apparaître sur le même câble, et lesquels n’ont besoin que d’une route. Tout ce qui répond « une route » reste hors de la cascade. Cette seule phrase évite la plupart des conceptions qui finissent avec des services d’adresses en double.
2. Délimitez l’identité qui l’autorise
Les identifiants qui administrent un serveur et l’identité qu’une cascade utilise pour se connecter sont des secrets différents, et les mélanger est un raccourci courant à longue traîne. Le hub distant a besoin d’une entrée d’utilisateur ou de politique qui autorise cette cascade à se connecter. Cette entrée est l’autorisation ; une connexion réussie ne dit rien de ce qui se trouve derrière le hub distant.
Notez quel hub initie, à quel hub distant il se joint et ce que l’identité distante peut atteindre. Comparez les deux architectures avant de vous engager :
| Requirement | Routed path | Cascaded segment |
|---|---|---|
| Broadcast domain | Separate on each side | Shared across the link |
| Address service | One DHCP server per side | Must not run two on one domain |
| Loop risk | Route loops only | Layer-two loops if segments overlap |
Tenez à jour les identifiants et les instructions de récupération des deux côtés. Un changement de mot de passe ou une modification de politique sur le hub distant casse la cascade sans toucher à vos utilisateurs locaux, et la panne apparaît généralement comme un lien actif mais vide.
3. Inspectez ce que le hub transporte déjà
Un hub est rarement isolé. Il ponte peut-être déjà vers un adaptateur physique, route via un routeur virtuel ou cascade ailleurs, et chacune de ces attaches est transportée dans la nouvelle relation. C’est pourquoi « nous avons juste relié deux hubs » se transforme si souvent en « pourquoi ces deux sites ne font-ils plus qu’un segment ? ».
Deux hubs pontés dans le même segment physique puis mis en cascade l’un vers l’autre forment une boucle. Ajoutez spanning tree ou ne le construisez pas. Le même test s’applique à un hub qui atteint déjà la cible par une autre cascade : un second lien n’ajoute pas de capacité, il ajoute un chemin.
N’ajoutez pas un lien parce qu’une route manque ; corrigez la route. Dessinez d’abord la topologie sur papier, y compris chaque pont et chaque cascade, car le schéma prend deux minutes et attrape la plupart des boucles avant qu’elles existent.
4. Réglez l’adressage avant de joindre
Les segments réunis apportent des sous-réseaux en double, et les serveurs DHCP en double sont le symptôme classique : les clients prennent un bail auprès du serveur qui répond en premier, donc le comportement semble aléatoire et se déplace entre les redémarrages. Décidez à l’avance quel côté possède l’attribution d’adresses, et donnez au segment éloigné une plage qui ne chevauche rien de local. Désactivez l’autre service DHCP avant que la cascade soit en ligne, pas après la première plainte.
DNS est une question distincte. Une cascade transporte des trames ; elle ne configure pas de résolveurs, et un nom qui se résout côté local peut ne pas se résoudre à travers le lien. Testez la résolution séparément du chemin IP, car un ping qui fonctionne ne prouve qu’une des deux choses.
5. Prouvez-le avec une ressource réelle
Choisissez un service autorisé sur le segment distant visé et confirmez que la réponse revient par la cascade. Répétez ensuite pour la résolution de noms. Si la cible dépend de la découverte par diffusion, attendez-vous à un comportement différent sur un lien ponté que sur un seul câble, et prévoyez-le au lieu de le consigner comme un défaut.
Enfin, écrivez la topologie : quel hub cascade vers où, quelle identité l’autorise, quels segments sont pontés et qui possède l’attribution d’adresses sur chacun. Cette note permet à la personne suivante de changer une politique sans faire tomber un segment dont elle ignorait l’existence.