Deux LAN sur NetBird : quels pairs routent, et qui peut parler

Un poste de travail du LAN ouest ouvre un navigateur, saisit l’adresse d’une application du LAN est et attend l’expiration du délai. Chaque écran de NetBird affirme que les pairs sont connectés, ce qui est vrai et hors sujet : être dans un réseau superposé n’est pas la même chose que d’avoir les deux sous-réseaux locaux dans un seul réseau. Le parcours ci-dessous part de ce poste et se termine par une requête que la conception refuse exprès, et chaque étape est quelque chose qu’on lit sur un appareil plutôt qu’on suppose. Attendez-vous à ce que la pièce manquante soit une route ou une politique, pas la superposition.

Lisez d’abord la panne depuis le poste de travail

Avant d’ouvrir la console d’administration, établissez ce que le poste envoie réellement. Sa propre table de routage décide si le paquet part vers la passerelle du site, vers une interface locale ou nulle part, et cette décision se voit sans aucun outil de superposition. Une machine sans route pour le préfixe distant échouera, aussi saine que paraisse la liste des pairs. La plage de superposition et le préfixe propre au site sont des espaces d’adresses différents, et l’enrôlement n’en a configuré qu’un seul.

Séparez ensuite la résolution de noms de l’accessibilité, car le navigateur signale les deux comme le même délai expiré. Répétez la requête par adresse depuis une machine qui exécute le client NetBird, puis depuis un poste ordinaire qui ne l’exécute pas. Si la machine enrôlée réussit et que l’ordinaire échoue, l’écart est dans le routage local ; si les deux échouent, continuez à lire avant de changer une route.

Choisissez un pair de routage par site

Un pair de routage est un hôte qui représente son LAN dans la superposition, alors choisissez une machine Linux avec une accessibilité stable au sous-réseau plutôt que le poste de bureau de quelqu’un. Enrôlez-la par le processus normal et mettez-la dans un groupe nommé d’après le rôle, car la ressource réseau et la politique feront toutes deux référence à ce groupe. Un représentant par site reste lisible ; une flotte de volontaires annonçant le même préfixe transforme chaque question ultérieure en séance de débogage. L’adresse du pair sur le segment local compte autant que son identité dans la superposition, car cette adresse devient le prochain saut qu’on indique à chaque appareil ordinaire.

Écrivez le plan avant de toucher la console, car les noms et les préfixes sont là où ces conceptions dérivent : préfixe, passerelle, adresse du pair et groupe, par site. L’ouest est 10.52.0.0/24 servi par 10.52.0.5 et l’est est 10.63.0.0/24 servi par 10.63.0.5 ; les deux groupes sont west-routers et east-routers, et aucun préfixe ne doit chevaucher l’autre, la plage de superposition ni une autre destination routée.

Créez la ressource, gardez le masquage

Dans le tableau de bord déployé, créez une ressource réseau par site et attachez-y le groupe de pairs de routage de ce site. La ressource est le préfixe et le groupe est l’hôte qui en répond, et les deux doivent exister avant que quoi que ce soit soit annoncé. Vérifiez que la version auto-hébergée déployée possède bien le flux de travail Réseaux, car une interface plus ancienne avec un objet de route au nom similaire est une autre fonction.

Laissez le masquage activé. Le guide NetBird site à site l’exige dans cette disposition, et le désactiver pour garder chaque adresse d’origine visible n’est pas la même conception avec un saut de moins ; cela change ce que voient les contrôles de source et les politiques de la superposition. La conséquence mérite d’être dite franchement : le service récepteur enregistre le pair de routage comme source, pas le poste individuel. Si la liste d’autorisation ou l’audit de ce service attend des adresses de postes, soit l’attente change, soit l’identité doit être imposée à la frontière du site avant la traduction.

Autorisez les initiateurs, pas les préfixes

Une route rend une adresse joignable et une politique décide qui peut l’utiliser ; ce sont deux objets séparés avec des propriétaires séparés. Écrivez la politique depuis la charge de travail vers l’arrière : quel groupe initie, quelle ressource il cible et quel service TCP il lui faut. Un réseau qui annonce les deux préfixes à chaque pair enrôlé a créé la joignabilité et n’a rien réglé.

Lisez ensuite ce qui est déjà permis, car une règle nouvelle étroite ne révoque pas une ancienne large qui se trouve au-dessus. Quand l’est doit aussi initier des connexions vers l’ouest, écrivez cette direction comme sa propre politique ; le trafic de retour d’une session ouverte par l’ouest est une autre question que d’autoriser de nouvelles sessions vers l’est. Si seuls certains postes ouest doivent atteindre l’application est, sélectionnez-les à la frontière du site avant la traduction et gardez l’authentification propre à l’application. Le pair de routage transporte le trafic du LAN comme le site entier et non comme une identité de superposition par utilisateur, donc la comptabilité par utilisateur doit venir d’ailleurs.

Enseignez à chaque passerelle le prochain saut, puis testez un refus

Les appareils ordinaires ne voient jamais la superposition, donc leur propre passerelle a besoin d’une route statique qui pointe le préfixe distant vers l’adresse LAN du pair de routage. C’est l’étape que les gens sautent, parce que tout ce qui est visible dans NetBird fonctionne déjà alors que les postes ordinaires expirent encore. La passerelle conserve sa route par défaut telle quelle ; ce préfixe est un ajout, pas un remplacement.

Les deux descriptions de route vont dans la configuration de la passerelle de chaque site, pas dans une surcharge sur l’hôte. Toutes deux sont des routes statiques ordinaires, et aucune ne touche la route par défaut :

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

Testez avec l’application dont le projet a réellement besoin, depuis un poste ordinaire, et notez trois choses : le prochain saut choisi côté émetteur, la politique qui a correspondu et l’adresse source que le service a journalisée. Testez aussi un refus, car une conception qui n’a jamais rien refusé a des bords inconnus, et le refus est la seule preuve que c’est la politique et non le routage qui fait le travail. Quand l’est doit aussi initier, lancez une nouvelle connexion depuis ce côté au lieu de supposer que la seconde direction suit. Planifiez aussi le redémarrage, la mise à niveau et le remplacement du pair de routage, car un hôte est devenu une dépendance du site.

Les noms privés ont besoin de leur propre conception de résolveur, car la joignabilité ne crée pas d’enregistrements DNS et un chemin IP fonctionnel avec un nom cassé se lit exactement comme un chemin cassé. Si un pair de routage tourne dans un réseau cloud, examinez aussi les règles de transfert et de pare-feu du fournisseur, car l’enrôlement ne les annule pas. Gardez les observations du test à côté du plan, car la prochaine personne qui déboguera cela voudra la politique correspondante et l’adresse source journalisée, pas une description de la topologie.