Filtres du phare Nebula face au pare-feu : ce que chacun bloque

Regardez une poignée de main Nebula depuis le mauvais bout et les deux mécanismes semblent interchangeables. L’un décide quelles adresses un nœud annonce au phare et quelles adresses distantes il essaiera ; l’autre décide ce qui peut passer une fois le tunnel établi. Un filtre peut arrêter une connexion avant qu’une seule règle de pare-feu soit évaluée, et une règle de pare-feu ne peut pas ranimer un point de terminaison que la découverte a supprimé. Les deux couches répondent à des questions différentes, et l’ordre dans lequel elles agissent est la clé.

Suivez une connexion à travers quatre étapes : l’adresse locale annoncée, le point de terminaison distant envisagé, la poignée de main et le trafic dans la couche superposée. Chaque étape a sa propre configuration et sa propre signature de panne.

Commencez par l’adresse locale que le nœud annonce

local_allow_list filtre les adresses locales de cet hôte avant qu’elles ne soient rapportées aux phares. Les entrées peuvent être des plages d’adresses, et la configuration prend aussi en charge des motifs de nom d’interface. C’est utile quand un hôte a des ponts de conteneurs ou des interfaces de tunnel supplémentaires qui ne doivent pas devenir des points de terminaison pour les pairs.

Parcourez les interfaces de l’hôte et demandez auxquelles un pair distant peut réellement accéder. Une adresse de pont Docker est locale à cet hôte et inutile pour un pair d’un autre réseau. L’annoncer gaspille la découverte et peut envoyer un pair vers une adresse qui ne répond jamais. Tout ce à quoi un pair ne peut pas router est du bruit dans la réponse du phare.

Une liste d’autorisations étroite est ici plus sûre qu’une large liste de refus. Si seules des entrées d’autorisation sont présentes, le reste non spécifié est exclu ; ajouter plus tard une entrée de refus change la logique par défaut et exige sa propre revue. Ce changement mérite un second regard sur la valeur par défaut.

Observez ensuite la sélection du point de terminaison distant

remote_allow_list filtre les adresses que cet hôte envisagera pour un pair distant pendant une poignée de main. Cela s’applique à l’adresse de la couche sous-jacente, pas à l’adresse de la couche superposée que le pair utilisera une fois le tunnel levé.

Une plage privée peut être parfaitement utilisable sur un réseau de bureau partagé et n’avoir aucun sens quand les deux hôtes sont dans des réseaux sans rapport qui utilisent tous deux 10.0.0.0/8. Le filtre vous permet de préférer le chemin routable et d’ignorer la coïncidence.

Quand un pair ne parvient pas à se connecter, comparez l’adresse essayée à la règle qui lui correspond. Activez les journaux de poignée de main et lisez l’adresse distante sélectionnée ; la ligne de journal nomme le point de terminaison qui a survécu au filtrage, ce qui est plus utile que la liste des adresses que le pair possède.

Un filtre de nom d’interface du côté annonceur peut retirer le point de terminaison avant même que le côté récepteur ne le voie. Vérifiez les deux nœuds quand un seul sens échoue.

Après la poignée de main, les règles d’accès de la couche superposée s’appliquent

Les règles de pare-feu de Nebula opèrent à l’intérieur de la couche superposée, après l’établissement du tunnel. Elles font correspondre hôtes, groupes, ports et protocoles, et décident si un paquet peut entrer dans l’hôte local ou en sortir. Elles ne sélectionnent pas un point de terminaison de la couche sous-jacente.

Cette séparation explique un diagnostic erroné fréquent. Un opérateur ajoute une règle de pare-feu pour un port et ne peut toujours pas se connecter, parce que le filtre du phare a supprimé le seul point de terminaison joignable. Un autre ouvre le filtre d’adresses et n’atteint toujours pas le service, parce que le pare-feu de la couche superposée refuse le port.

Lisez la panne à la bonne couche. Une poignée de main qui ne se termine jamais pointe vers la découverte, le filtrage des points de terminaison ou le chemin réseau. Une poignée de main terminée suivie d’une connexion de service refusée ou abandonnée pointe vers le pare-feu de la couche superposée ou vers l’application.

Lisez la valeur par défaut quand autorisation et refus se mélangent

La configuration du phare prend en charge les listes uniquement d’autorisation, uniquement de refus et mixtes, et la valeur par défaut du reste non spécifié diffère entre ces formes. Une liste mixte a besoin d’une valeur par défaut explicite pour la famille d’adresses ; supposer que le reste se comporte comme la configuration précédente est la façon dont un point de terminaison fonctionnel disparaît en silence.

lighthouse:
  local_allow_list:
    interfaces:
      docker0: false
  remote_allow_list:
    192.168.0.0/16: true
    default: false

Traitez la valeur par défaut comme faisant partie de la règle, non comme du texte de modèle. Si la valeur par défaut de la famille est le refus, toute adresse non listée est exclue, y compris une nouvelle plage de bureau ajoutée après l’écriture de la configuration.

Notez quelles adresses devaient être joignables et testez des deux côtés. Un filtre qui fonctionne pour une paire de pairs peut échouer pour une autre paire dont le seul chemin commun utilise une adresse que la liste exclut.

Utilisez le relais quand aucun point de terminaison direct n’est joignable

Si chaque point de terminaison candidat est filtré ou injoignable, la réponse n’est pas une liste d’autorisations plus large qui réadmet des adresses auxquelles vous ne faites pas confiance. La configuration de relais de Nebula offre un chemin de pair alternatif quand la connectivité directe n’est pas réalisable.

Le relais résout le transport et la découverte, pas l’autorisation, et il n’élargit pas le pare-feu. Le pare-feu de la couche superposée décide toujours quels services peuvent être utilisés, et le relais ne transforme pas le filtrage du phare en mécanisme de contrôle d’accès.

Testez le chemin de relais avec les points de terminaison directs désactivés et confirmez que le service voulu fonctionne encore alors qu’un service non voulu non. Ce seul test sépare une correction de transport d’un changement de politique et garde les deux couches honnêtes.