Post

Nebula

Posté
Preview Image
Par Yann
31 min lire
Nebula

Nebula est un outil de réseau superposé évolutif axé sur les performances, la simplicité et la sécurité. Il vous permet de connecter de manière transparente des ordinateurs partout dans le monde. Nebula est portable et fonctionne sous Linux, OSX, Windows, iOS et Android.

Nebula

nebula
Nebula: Open Source Overlay Networking

Fonctionnalités principales

  • Réseau virtuel peer-to-peer, couche 3 (détails techniques)
  • Prise en charge du trafic TCP/UDP/ICMP via un adaptateur TUN avec split-tunneling
  • Pare-feu hôte avec moteur de règles basé sur des groupes pour le trafic overlay
  • Découverte de routes et traversée NAT assistées par de simples hôtes « lookup »

Identité et autorisation

Nebula utilise un modèle PKI pour établir la confiance entre les hôtes et les réseaux.

  • Les certificats d’hôte sont utilisés pour identifier et autoriser les pairs de manière sécurisée.
  • Les hôtes s’authentifient mutuellement en validant les certificats et les autorités de certification.
  • Les règles de pare-feu sont appliquées en évaluant les « groupes de sécurité » des certificats.

Les versions incluent l’exécutable nebula-cert pour générer des clés, des certificats, des autorités de certification et pour signer les certificats d’hôte.

Compatibilité

Nebula est écrit en Go et est conçu pour être portable.

  • Packagé pour Linux, macOS, Windows, iOS, Android et FreeBSD.
  • Fonctionne efficacement sur les matériels x86, ARM, MIPS, PPC et RISC (32 et 64 bits).
  • Un seul exécutable Nebula exécute le pare-feu hôte et le service.
  • Le fichier de configuration hôte définit la confiance CA, le certificat et la clé hôte, ainsi que les règles du pare-feu.
  • Au moins un hôte du réseau superposé doit être un Lighthouse, qui aide les hôtes à découvrir les routes les uns vers les autres et facilite la traversée NAT.

Documentation

Exécution du phare “lighthouse” sur un VPS Webdock Debian 12
Clients, un ordinateur de bureau Arch, un portable laptop, serveur debian et un autre sur un téléphone Android


Réseau privé: 10.19.55.0/24

Il y a toujours un nœud central, introducteur ou Nebula lighthouse (phare) , qui s’assure que tous les nœuds du réseau peuvent communiquer efficacement entre eux. Le phare est également le seul nœud qui nécessite une IP statique. Comme le trafic n’est plus acheminé par un seul nœud, il réduit considérablement les besoins en ressources pour ce nœud, tout en réduisant les goulets d’étranglement.

Dossier Nebula: ~/media/devel/nebula

Nebula - PC1

Nebula binaire

Binaire nebula-linux-amd64.tar.gz pour les architectures amd64

Liste des binaires https://github.com/slackhq/nebula/releases/latest pour les distributions

  1. Téléchargez la dernière version pour votre plateforme depuis GitHub
  2. Extrayez l’archive et placez nebula et nebula-cert dans votre répertoire /usr/local/bin. Assurez-vous qu’ils sont exécutables : sudo chmod +x /usr/local/bin/nebula*

Autorité de certification (AC)

Nebula utilise PKI pour l’authentification sous la forme d’autorité de certification (CA).
Les clients reçoivent la clé publique de l’autorité de certification, et leur propre paire de clés publique/privée signée par l’autorité de certification. Comme chaque client connaît l’autorité de certification, celle-ci peut facilement vérifier si le client est autorisé, et l’ajout de nouveaux clients ne nécessite pas de modifier les fichiers de configuration.

Création ca.key et ca.crt
La première étape consiste à créer les fichiers ca.key et ca.crt, qui constituent les clés privées et publiques de votre AC. Veillez à ce que le fichier ca.key reste privé.
Je recommande de stocker le fichier hors ligne, et de le traiter comme vous le feriez pour une clé privée SSH sur vos serveurs.

1
2
3
4
5

# créer dossier
mkdir -p ~/media/devel/nebula
cd ~/media/devel/nebula
# Créer les fichiers ca.key et ca.crt
nebula-cert ca -name "Réseau Nebula Yan"

Vérification du ca:

1

nebula-cert print -path ./ca.crt

Inspection du certificat.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

NebulaCertificate {
	Details {
		Name: Réseau Nebula Yan
		Ips: []
		Subnets: []
		Groups: []
		Not before: 2025-07-22 16:09:48 +0200 CEST
		Not After: 2026-07-22 16:09:48 +0200 CEST
		Is CA: true
		Issuer: 
		Public key: 0f271...1ac33a1b6a7d31e
		Curve: CURVE25519
	}
	Fingerprint: 3f3478674c...dce3c5e
	Signature: 30d6c148838717af50d...d8a66036e5baf3939247f5b623a9e006
}

Création des certificats clients

Avant de le verrouiller, nous avons besoin qu’il crée quelques certificats clients, 1 pour chaque client. Lors de la génération d’un certificat client, vous devez avoir décidé quel sous-réseau vous utiliserez pour le réseau VPN. On va utiliser 10.19.55.0/24

Phare lighthouse webdock
nebula-cert sign -name "lighthouse" -ip "10.19.55.1/24"

Cela créera un lighthouse.crt et un lighthouse.key, signés en utilisant votre AC Nebula.
Ces fichiers devront ensuite être transférés en toute sécurité à votre client.
Répétez ce processus pour chaque client que vous devez approvisionner, à l’exception des appareils mobiles - nous y reviendrons plus tard.

PC1 endeavouros
nebula-cert sign -name "pc1" -ip "10.19.55.2/24"

Portable DELL Latitude e6230
nebula-cert sign -name "e6230" -ip "10.19.55.3/24" -groups "laptop,ssh"

Serveur debian cwwk rnmkcy.eu
nebula-cert sign -name "cwwk" -ip "10.19.55.4/24" -groups "servers"

Serveur debian contabo xoyize
nebula-cert sign -name "xoyize" -ip "10.19.55.5/24" -groups "servers"

Fichiers de configuration (YAML)

La configuration de Nebula, comme tout ce qui se passe dans le cloud, se fait à l’aide d’un fichier YAML. La meilleure façon de commencer est d’utiliser l’exemple de configuration.

Fichiers de configuration
Télécharger une copie de la configuration d’exemple de nebula. Faites deux copies séparées du fichier de configuration exemple, une pour votre phare nommé config-lighthouse.yaml, et une pour chaque hôte non-léger, appelé config.yaml.

1
2
3

curl -o config.yml https://raw.githubusercontent.com/slackhq/nebula/master/examples/config.yml
cp config.yml config-lighthouse.yaml
cp config.yml config.yaml

La configuration d’exemple montre d’excellents exemples sur ce que sont les clés et comment vous pouvez les utiliser. Si vous avez l’intention de déployer Nebula, je vous recommande de la lire en entier. Mais ce sont les choses que vous devez changer pour obtenir un tunnel fonctionnel

Configuration du phare (lighthouse.yaml)

Serveur webdock debian 12 ip publique: 92.113.144.37

Sur l’hôte phare, vous devrez vous assurer que am_lighthouse: true. En général, un phare n’aura pas d’entrées dans sa carte static_host_map, car tous les hôtes se présenteront à un phare. Si vous utilisez plusieurs phares, ils n’ont généralement pas besoin de se connaître.

1
2
3
4
5

static_host_map:
  '10.19.55.1': ['92.113.144.37:4242']

lighthouse:
  am_lighthouse: true

Configuration des hôtes (config.yaml)

Sur les hôtes individuels, assurez-vous que le phare (lighthouse) est correctement défini dans la section static_host_map et que son adresse IP privée soit ajoutée à la section lighthouse: hosts

1
2
3
4
5
6
7
8

static_host_map:
  '10.19.55.1': ['92.113.144.37:4242']

lighthouse:
  am_lighthouse: false
  interval: 60
  hosts:
    - '10.19.55.1'

Paramètres du pare-feu

Le fichier de configuration par exemple permet tout le trafic sortant, mais permet uniquement des connexions spécifiques à chaque hôte Nebula. Vous devriez modifier ces paramètres pour permettre le trafic vers/depuis les hôtes de votre réseau.

1
2
3
4
5
6
7
8
9
10
11
12

firewall:
  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any

  inbound:
    # Allow icmp between any nebula hosts
    - port: any
      proto: icmp
      host: any

Fichier complet (hosts, laptop, desktop et server)

Le fichier complet pour les hosts laptop desktop et server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

pki:
ca'
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key
static_host_map:
  '10.19.55.1': ['92.113.144.37:4242']
lighthouse:
  am_lighthouse: false
  interval: 60
  hosts:
    - "10.19.55.1"
listen:
  host: "::"
  port: 4242
punchy:
  punch: true
relay:
  am_relay: false
  use_relays: true
tun:
  disabled: false
  dev: nebula1
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300

  # Route based MTU overrides, you have known vpn ip paths that can support larger MTUs you can increase/decrease them here
  routes:
 unsafe_routes:
logging:
  level: info
  format: text
firewall:
  outbound_action: drop
  inbound_action: drop
  conntrack:
    tcp_timeout: 12m
    udp_timeout: 3m
    default_timeout: 10m
  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any
  inbound:
    # Allow icmp between any nebula hosts
    - port: any
      proto: icmp
      host: any

Avec la configuration, le certificat et la clé, la dernière étape consiste à copier les fichiers appropriés à chaque hôte et à démarrer votre réseau Nebula.

Machines

VPS webdock (lighthouse)

Copiez le binaire de nebula, ainsi que le config-lighthouse.yaml, ca.crt, phare1.crt et phare1.key vers votre phare. Ne copier pas ca.key

Connexion SSH à votre phare.

1

 ssh yock@92.113.144.37 -p 55037 -i /home/yann/.ssh/vps-yock

Créez un répertoire nommé /etc/nebula sur votre hôte phare (en mode su).

1

mkdir /etc/nebula

Déplacez la configuration, les certificats et la clé dans le répertoire approprié.

Note : La configuration par exemple suppose que votre certificat d’hôte et clé sont nommés host.crt et host.key, de sorte que vous devrez renommer certains fichiers lorsque vous les déplacerez dans le répertoire approprié.

1
2
3
4

mv config-lighthouse.yaml /etc/nebula/config.yaml
mv ca.crt /etc/nebula/ca.crt
mv yock.crt /etc/nebula/host.crt
mv yock.key /etc/nebula/host.key

Le fichier complet /etc/nebula/config.yaml pour le phare lighthouse

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key
static_host_map:
  '10.19.55.1': ['92.113.144.37:4242']
lighthouse:
  am_lighthouse: true
  interval: 60
  hosts:
    - "10.19.55.1"
listen:
  host: "::"
  port: 4242
punchy:
  punch: true
relay:
  am_relay: false
  use_relays: true
tun:
  disabled: false
  dev: nebula1
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300
  routes:
  unsafe_routes:
logging:
  level: info
  format: text
firewall:
  outbound_action: drop
  inbound_action: drop
  conntrack:
    tcp_timeout: 12m
    udp_timeout: 3m
    default_timeout: 10m
  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any
  inbound:
    # Allow icmp between any nebula hosts
    - port: any
      proto: icmp
      host: any

Télécharger les binaires

1
2
3

cd ~
wget https://github.com/slackhq/nebula/releases/download/v1.9.6/nebula-linux-amd64.tar.gz
tar xzvf nebula-linux-amd64.tar.gz

ATTENTION! Il faut ouvrir le port UDP 4242 sur le serveur “lighthouse”
sudo ufw allow 4242/udp
sudo ufw reload

Démarrer nebula

1
2
3

chmod +x nebula
mv nebula /usr/local/bin/
nebula -config /etc/nebula/config.yaml

Le service systemd /etc/systemd/system/nebula.service

1
2
3
4
5
6
7
8

[Unit]
Description=Nebula service
[Service]
Type=simple
ExecStart=/usr/local/bin/nebula -config /etc/nebula/config.yaml
Restart=on-failure
[Install]
WantedBy=multi-user.target

Serveur cwwk

Connexion SSH à votre serveur.

1

 ssh yick@192.168.0.205 -p 55205 -i /home/yann/.ssh/yick-ed25519

Créez un répertoire nommé /etc/nebula sur votre hôte phare (en mode su).

1

mkdir /etc/nebula

Déplacez la configuration, les certificats et la clé dans le répertoire approprié.

Note : La configuration par exemple suppose que votre certificat d’hôte et clé sont nommés host.crt et host.key, de sorte que vous devrez renommer certains fichiers lorsque vous les déplacerez dans le répertoire approprié.

1
2
3
4

mv config-server-nfs.yaml /etc/nebula/config.yaml
mv ca.crt /etc/nebula/ca.crt
mv cwwk.crt /etc/nebula/host.crt
mv cwwk.key /etc/nebula/host.key

Le fichier complet /etc/nebula/config.yaml pour le serveur cwwk

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key
static_host_map:
  '10.19.55.1': ['92.113.144.37:4242']
lighthouse:
  am_lighthouse: false
  interval: 60
  hosts:
    - "10.19.55.1"
listen:
  host: "::"
  port: 4242
punchy:
  punch: true
relay:
  am_relay: false
  use_relays: true
tun:
  disabled: false
  dev: nebula1
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300
  routes:
  unsafe_routes:
logging:
  level: info
  format: text
firewall:
  outbound_action: drop
  inbound_action: drop
  conntrack:
    tcp_timeout: 12m
    udp_timeout: 3m
    default_timeout: 10m
  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any
  inbound:
    # Allow proto any between any nebula hosts
    - port: any
      proto: any
      host: any

Info: inbound: proto: any pour autoriser tous les accès

Télécharger les binaires

1
2

wget https://github.com/slackhq/nebula/releases/download/v1.9.6/nebula-linux-amd64.tar.gz
tar xzvf nebula-linux-amd64.tar.gz

Démarrer nebula

1
2
3

chmod +x nebula
mv nebula /usr/local/bin/
nebula -config /etc/nebula/config.yaml

Le service systemd /etc/systemd/system/nebula.service

1
2
3
4
5
6
7
8

[Unit]
Description=Nebula service
[Service]
Type=simple
ExecStart=/usr/local/bin/nebula -config /etc/nebula/config.yaml
Restart=on-failure
[Install]
WantedBy=multi-user.target

Recharger systemd

1

systemctl daemon-reload

Activer et lancer le service

1

systemctl enable nebula.service --now

Portable laptop DELL e6230

Pour cet exemple, nous configurons l’hôte créé ci-dessus, nommé serveur. Veuillez remplacer les noms de fichiers appropriés.

Copiez le binaire de nébuleuse, ainsi que le config.yaml, ca.crt, server.crt et server.key vers l’hôte nommé serveur. Ne faites pas le dossier ca.key.

Connexion SSH à votre serveur.

1

 ssh yick@192.168.0.205 -p 55205 -i /home/yann/.ssh/yick-ed25519

Créez un répertoire nommé /etc/nebula sur votre hôte phare (en mode su).

1

mkdir /etc/nebula

Déplacez la configuration, les certificats et la clé dans le répertoire approprié.

Note : La configuration par exemple suppose que votre certificat d’hôte et clé sont nommés host.crt et host.key, de sorte que vous devrez renommer certains fichiers lorsque vous les déplacerez dans le répertoire approprié.

1
2
3
4

mv config.yaml /etc/nebula/config.yaml
mv ca.crt /etc/nebula/ca.crt
mv e6230.crt /etc/nebula/host.crt
mv e6230.key /etc/nebula/host.key

Le fichier complet /etc/nebula/config.yaml pour laptop DELL e6230

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key
static_host_map:
  '10.19.55.1': ['92.113.144.37:4242']
lighthouse:
  am_lighthouse: false
  interval: 60
  hosts:
    - "10.19.55.1"
listen:
  host: "::"
  port: 4242
punchy:
  punch: true
relay:
  am_relay: false
  use_relays: true
tun:
  disabled: false
  dev: nebula1
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300
  routes:
  unsafe_routes:
logging:
  level: info
  format: text
firewall:
  outbound_action: drop
  inbound_action: drop
  conntrack:
    tcp_timeout: 12m
    udp_timeout: 3m
    default_timeout: 10m
  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any
  inbound:
    # Allow icmp between any nebula hosts
    - port: any
      proto: icmp
      host: any

Installer nebula sous archlinux

1

sudo pacman -S nebula

Démarrer nebula

1

nebula -config /etc/nebula/config.yaml

Le service systemd /etc/systemd/system/nebula.service

1
2
3
4
5
6
7
8

[Unit]
Description=Nebula service
[Service]
Type=simple
ExecStart=/usr/bin/nebula -config /etc/nebula/config.yaml
Restart=on-failure
[Install]
WantedBy=multi-user.target

Recharger systemd

1

systemctl daemon-reload

Activer et lancer le service

1

systemctl enable nebula.service --now

VPS Contabo xoyize

Connexion SSH à votre serveur.

1

 ssh xouser@158.220.91.148 -p 55148 -i /home/yann/.ssh/xoyize-ed25519

Créez un répertoire nommé /etc/nebula sur votre hôte phare (en mode su).

1

mkdir /etc/nebula

Déplacez la configuration, les certificats et la clé dans le répertoire approprié.

Note : La configuration par exemple suppose que votre certificat d’hôte et clé sont nommés host.crt et host.key, de sorte que vous devrez renommer certains fichiers lorsque vous les déplacerez dans le répertoire approprié.

1
2
3
4

mv config-server-nfs.yaml /etc/nebula/config.yaml
mv ca.crt /etc/nebula/ca.crt
mv xoyize.crt /etc/nebula/host.crt
mv xoyize.key /etc/nebula/host.key

Le fichier complet /etc/nebula/config.yaml pour le serveur xoyize

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key
static_host_map:
  '10.19.55.1': ['92.113.144.37:4242']
lighthouse:
  am_lighthouse: false
  interval: 60
  hosts:
    - "10.19.55.1"
listen:
  host: "::"
  port: 4242
punchy:
  punch: true
relay:
  am_relay: false
  use_relays: true
tun:
  disabled: false
  dev: nebula1
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300
  routes:
  unsafe_routes:
logging:
  level: info
  format: text
firewall:
  outbound_action: drop
  inbound_action: drop
  conntrack:
    tcp_timeout: 12m
    udp_timeout: 3m
    default_timeout: 10m
  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any
  inbound:
    # Allow proto any between any nebula hosts
    - port: any
      proto: any
      host: any

Info: inbound: proto: any pour autoriser tous les accès

Télécharger les binaires

1
2

wget https://github.com/slackhq/nebula/releases/download/v1.9.6/nebula-linux-amd64.tar.gz
tar xzvf nebula-linux-amd64.tar.gz

Démarrer nebula

1
2
3

chmod +x nebula
mv nebula /usr/local/bin/
nebula -config /etc/nebula/config.yaml

Le service systemd /etc/systemd/system/nebula.service

1
2
3
4
5
6
7
8

[Unit]
Description=Nebula service
[Service]
Type=simple
ExecStart=/usr/local/bin/nebula -config /etc/nebula/config.yaml
Restart=on-failure
[Install]
WantedBy=multi-user.target

Recharger systemd

1

systemctl daemon-reload

Activer et lancer le service

1

systemctl enable nebula.service --now

Archlinux EndeavourOS PC1

Installer nebula sous archlinux

1

sudo pacman -S nebula

Créez un répertoire nommé /etc/nebula sur votre hôte phare

1

sudo mkdir /etc/nebula

Copier la configuration, les certificats et la clé dans le répertoire approprié.

Note : La configuration par exemple suppose que votre certificat d’hôte et clé sont nommés host.crt et host.key, de sorte que vous devrez renommer certains fichiers lorsque vous les déplacerez dans le répertoire approprié.

1
2
3
4

sudo cp $HOME/media/devel/nebula/nebula_config.yaml /etc/nebula/config.yaml
sudo cp $HOME/media/devel/nebula/ca.crt /etc/nebula/ca.crt
sudo cp $HOME/media/devel/nebula/pc1.crt /etc/nebula/host.crt
sudo cp $HOME/media/devel/nebula/pc1.key /etc/nebula/host.key

Démarrer nebula

1

nebula -config /etc/nebula/config.yaml

Le service systemd /etc/systemd/system/nebula.service

1
2
3
4
5
6
7
8

[Unit]
Description=Nebula service
[Service]
Type=simple
ExecStart=/usr/bin/nebula -config /etc/nebula/config.yaml
Restart=on-failure
[Install]
WantedBy=multi-user.target

Recharger systemd

1

systemctl daemon-reload

Activer et lancer le service

1

systemctl enable nebula.service --now

Annexe

Vérifier fonctionnement

Vous devriez maintenant être en mesure de pinger d’autres hôtes exécutantnebula (en supposant que ICMP est autorisé). Pour pinger ligthhouse (phare):

1

ping -c3 10.19.55.1

Ajout d’hôtes à votre réseau

Il est facile d’ajouter des hôtes à un réseau Nebula établi. Vous créez tout simplement un nouveau certificat d’hôte et une nouvelle clé, puis suivez les étapes sous Lancer Nebula. Vous n’aurez pas besoin de modifier votre phare ou tout autre hôte lors de l’ajout d’hôtes à votre réseau, et les hôtes existants pourront en trouver de nouveaux via le ligthhouse (phare), automatiquement.

Configuration sur iOS/Android

Téléchargez l’application (iOS/Android). Cliquez sur « + » pour ajouter une nouvelle configuration, puis copiez la clé publique de l’appareil (à partir de l’écran « Certificate ») sur votre ordinateur qui contient ca.key.

Envoi du certificat par messagerie, enregistrer dans un fichier $HOME/media/devel/nebula/a528s-nebula.key

Signez la clé en utilisant ca.key:

1
2
3

nebula-cert sign -ca-crt ./ca.crt \
  -ca-key ./ca.key -in-pub a528s-nebula.key \
  -name a528s-nebula -ip 10.19.55.10/24

Cela devrait produire a528s-nebula.crt
Envoyer a528s-nebula.crt et ca.crt sur votre téléphone.

Choose file pour récupérer le certificat a528s-nebula.crt , puis “save”

Cliquer sur CA pour récupérer le certificat ca.crt , puis “File”, “Choose file” et save

Dans l’écran « Hosts », “Add a new entry” définissez l’adresse IP de votre phare, ainsi que son adresse IP publique et son port. Activez l’option « Phare ».

Une fois ces informations saisies, vous pouvez enregistrer la configuration.

Vous pouvez ensuite utiliser l’application Nebula ou les paramètres VPN pour activer Nebula. La connexion prendra quelques secondes, puis vous pourrez accéder à tous les appareils connectés à votre VPN.

NebulaOSS v1.10

La prochaine version de Nebula (v1.10) ajoutera la prise en charge des hôtes Nebula IPv6. Pour soutenir la fonctionnalité, Nebula utilise un format de certificat v2. Alors que les certificats v1 ne prennent en charge qu’une seule adresse IPv4 pour un Hébergeur donné, le format v2 permet plusieurs adresses IPv4 et/ou IPv6.
Dans ce guide, nous allons décrire comment mettre à niveau un réseau au format de certificat v2 avec support IPv6.

Puisque Nebula v1.10 n’a pas encore été publié, nous devrons d’abord mettre à jour chaque hôte du réseau avec une version nightly de Nebula. Ensuite, nous émettrons des paquets de certificat v1+v2 rétrocompatibles à chaque hôte. Après la mise à jour de la configuration de chaque hôte avec le nouveau paquet de certificats, nous adopterons une approche prudente pour passer au certificat v2.

Les étapes de base sont:

  • Mettre à niveau Nebula
  • Créer une autorité de certificat v2
  • Émettre des paquets de certificats v1+v2
  • Démarrer la poignée de main (handshaking) avec les certificats v2
  • Supprimer les certificats v1 des hôtes

Mettre à niveau Nebula

​ Tout d’abord, mettre à jour chaque hôte de votre réseau à une version nightly 1.10.x de Nebula qui prend en charge les certificats v2.

Sur le parc existant, on arrête le service Nebula

1
2
3
4
5
6

ssh yano@192.168.10.90 -p 56230 -i /home/yann/.ssh/e6230 'sudo systemctl stop nebula'
ssh yick@192.168.0.205 -p 55205 -i /home/yann/.ssh/yick-ed25519 'sudo systemctl stop nebula'
ssh xouser@158.220.91.148 -p 55148 -i /home/yann/.ssh/xoyize-ed25519 'sudo systemctl stop nebula'
ssh yair@144.91.89.149 -p 55149 -i /home/yann/.ssh/yannir-ed25519 'sudo systemctl stop nebula'
ssh uservps@51.38.37.240 -p 55240 -i /home/yann/.ssh/vps-1780de45 'sudo systemctl stop nebula'
ssh yock@92.113.144.37 -p 55037 -i /home/yann/.ssh/vps-yock 'sudo systemctl stop nebula'

On installe la nouvelle version nebula amd64 1.10

1
2
3
4
5
6

rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55037 -i /home/yann/.ssh/vps-yock" nebula yock@92.113.144.37:/usr/local/bin/
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 56230 -i /home/yann/.ssh/e6230" nebula yano@192.168.10.90:/usr/local/bin/
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55205 -i /home/yann/.ssh/yick-ed25519" nebula yick@192.168.0.205:/usr/local/bin/
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55148 -i /home/yann/.ssh/xoyize-ed25519" nebula xouser@158.220.91.148:/usr/local/bin/
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55149 -i /home/yann/.ssh/yannir-ed25519" nebula yair@144.91.89.149:/usr/local/bin/
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55240 -i /home/yann/.ssh/vps-1780de45" nebula uservps@51.38.37.240:/usr/local/bin/

Créer une autorité de certification v2

​ Ensuite, créez une autorité de certification v2 et ajoutez-la au paquet de confiance de chaque hôte sur le réseau. Créer une nouvelle CA, v2 par défaut, avec la version nightly de Nebula. CA v2 prend en charge la création et la signature à la fois des certificats v1 et v2.

1

nebula-cert ca -name "Yann Nebula CA" -encrypt

En utilisant nebula-cert print, nous pouvons voir qu’il s’agit d’une autorité de certification v2

1

nebula-cert print -path ./ca.crt

Certificat ca.crt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
	"curve": "CURVE25519",
	"details": {
		"groups": null,
		"isCa": true,
		"issuer": "",
		"name": "Yann Nebula CA",
		"networks": null,
		"notAfter": "2026-11-18T13:12:56+01:00",
		"notBefore": "2025-11-18T13:12:56+01:00",
		"unsafeNetworks": null
	},
	"fingerprint": "229a24d8.................a936281219719",
	"publicKey": "f22b33b............................c1a74d93",
	"signature": "dbd1a.................................0f308",
	"version": 2
}

Ajouter le nouveau certificat CA (ca.crt) au bundle de confiance pki.ca dans la configuration de chaque hôte Nebula et recharger Nebula.

Émission des paquets de certificats v1+v2

Une fois que le paquet de confiance de tous les hôtes aura été mis à jour, nous émettrons des paquets de certificats v1+v2 à l’aide de la nouvelle autorité de certification. Nous configurerons les hôtes avec les deux certificats, mais continuerons à utiliser le certificat v1 pour l’instant.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

#
# Génération des certificats, transfert et rechargement
#
# Phare lighthouse webdock  
nebula-cert sign -name "lighthouse" -ip "10.19.55.1/24"

# Cela créera un lighthouse.crt et un lighthouse.key, signés en utilisant votre AC Nebula.  
# Ces fichiers devront ensuite être transférés en toute sécurité à votre client.  

rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55037 -i /home/yann/.ssh/vps-yock" ca.crt yock@92.113.144.37:/etc/nebula/
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55037 -i /home/yann/.ssh/vps-yock" lighthouse.crt yock@92.113.144.37:/etc/nebula/host.crt
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55037 -i /home/yann/.ssh/vps-yock" lighthouse.key yock@92.113.144.37:/etc/nebula/host.key
ssh yock@92.113.144.37 -p 55037 -i /home/yann/.ssh/vps-yock 'sudo systemctl start nebula'

# PC1 endeavouros  
nebula-cert sign -name "pc1" -ip "10.19.55.2/24"  

sudo cp ca.crt /etc/nebula/
sudo cp pc1.key /etc/nebula/host.key 
sudo cp pc1.crt /etc/nebula/host.crt 
sudo systemctl start nebula

# Portable DELL Latitude e6230  
nebula-cert sign -name "e6230" -ip "10.19.55.3/24"  

rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 56230 -i /home/yann/.ssh/e6230" ca.crt yano@192.168.10.90:/etc/nebula/
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 56230 -i /home/yann/.ssh/e6230" e6230.crt yano@192.168.10.90:/etc/nebula/host.crt
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 56230 -i /home/yann/.ssh/e6230" e6230.key yano@192.168.10.90:/etc/nebula/host.key
ssh yano@192.168.10.90 -p 56230 -i /home/yann/.ssh/e6230 'sudo systemctl start nebula'

# Serveur debian cwwk rnmkcy.eu  
nebula-cert sign -name "cwwk" -ip "10.19.55.4/24"  

rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55205 -i /home/yann/.ssh/yick-ed25519" ca.crt yick@192.168.0.205:/etc/nebula/
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55205 -i /home/yann/.ssh/yick-ed25519" cwwk.crt yick@192.168.0.205:/etc/nebula/host.crt
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55205 -i /home/yann/.ssh/yick-ed25519" cwwk.key yick@192.168.0.205:/etc/nebula/host.key
ssh yick@192.168.0.205 -p 55205 -i /home/yann/.ssh/yick-ed25519 'sudo systemctl start nebula'

# Serveur debian contabo xoyize  
nebula-cert sign -name "xoyize" -ip "10.19.55.5/24"  

rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55148 -i /home/yann/.ssh/xoyize-ed25519" ca.crt xouser@158.220.91.148:/etc/nebula/
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55148 -i /home/yann/.ssh/xoyize-ed25519" xoyize.crt xouser@158.220.91.148:/etc/nebula/host.crt
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55148 -i /home/yann/.ssh/xoyize-ed25519" xoyize.key xouser@158.220.91.148:/etc/nebula/host.key
ssh xouser@158.220.91.148 -p 55148 -i /home/yann/.ssh/xoyize-ed25519 'sudo systemctl start nebula'

# Serveur debian contabo yannir  
nebula-cert sign -name "yannir" -ip "10.19.55.6/24"  

rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55149 -i /home/yann/.ssh/yannir-ed25519" ca.crt yair@144.91.89.149:/etc/nebula/
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55149 -i /home/yann/.ssh/yannir-ed25519" yannir.crt yair@144.91.89.149:/etc/nebula/host.crt
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55149 -i /home/yann/.ssh/yannir-ed25519" yannir.key yair@144.91.89.149:/etc/nebula/host.key
ssh yair@144.91.89.149 -p 55149 -i /home/yann/.ssh/yannir-ed25519 'sudo systemctl start nebula'

# ovh debian 13  
nebula-cert sign -name "vpsovh" -ip "10.19.55.8/24"

rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55240 -i /home/yann/.ssh/vps-1780de45" ca.crt uservps@51.38.37.240:/etc/nebula/
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55240 -i /home/yann/.ssh/vps-1780de45" vpsovh.crt uservps@51.38.37.240:/etc/nebula/host.crt
rsync -avz --progress --stats --human-readable --delete --rsync-path="sudo rsync" -e "ssh -p 55240 -i /home/yann/.ssh/vps-1780de45" vpsovh.key uservps@51.38.37.240:/etc/nebula/host.key
ssh uservps@51.38.37.240 -p 55240 -i /home/yann/.ssh/vps-1780de45 'sudo systemctl start nebula'

Par défaut, nebula-cert créera les versions v1 et v2 du certificat lors de la création et de la signature d’un certificat.

En utilisant nebula-cert print, nous pouvons voir qu’il s’agit d’une autorité de certification v1 v2

1

nebula-cert print -path ./lighthouse.crt

Certificat lighthouse.crt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

{
	"details": {
		"curve": "CURVE25519",
		"groups": [],
		"isCa": false,
		"issuer": "229a24d896c0867cdde704ff00fa33e1122d0b68ff2a3ac3655a936281219719",
		"name": "lighthouse",
		"networks": [
			"10.19.55.1/24"
		],
		"notAfter": "2026-11-18T13:12:55+01:00",
		"notBefore": "2025-11-18T13:34:05+01:00",
		"publicKey": "6dea115...aaf0b51f506",
		"unsafeNetworks": []
	},
	"fingerprint": "aa8c8....d1e54d275dab8c4",
	"signature": "aca3bdf.....62f4cc34555256125e8fd00ad53da54a00",
	"version": 1
}
{
	"curve": "CURVE25519",
	"details": {
		"groups": null,
		"isCa": false,
		"issuer": "229a24d89....655a936281219719",
		"name": "lighthouse",
		"networks": [
			"10.19.55.1/24"
		],
		"notAfter": "2026-11-18T13:12:55+01:00",
		"notBefore": "2025-11-18T13:34:05+01:00",
		"unsafeNetworks": null
	},
	"fingerprint": "07841db...9337149927402474",
	"publicKey": "6dea115a...110303caaf0b51f506",
	"signature": "0db9a6f4c...............b32e508",
	"version": 2
}

Commencer la négociation avec les certificats v2.

Une fois que tous les hôtes sont configurés avec un ensemble de certificats v1+v2, nous pouvons passer à la négociation avec le certificat v2. Pour ce faire, nous définissons l’option de configuration pki.initiating_version sur 2.

Nous vous recommandons d’effectuer cette modification progressivement, en commençant par un petit sous-ensemble d’hôtes et en vérifiant la modification avant de la déployer à grande échelle. Après avoir mis à jour l’option de configuration, rechargé Nebula et établi un tunnel, vous pouvez vérifier que le certificat v2 est utilisé via la commande print-tunnel du serveur SSH de débogage.

La section pki configure les informations d’identification et les relations de confiance pour un nœud Nebula. Toutes les options de cette section prennent en charge le rechargement à chaud, à l’exception de la sélection du chiffrement initiating_version.

1
2
3
4
5
6

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key
  disconnect_invalid: true
  initiating_version: 2

Dans cet exemple, nous avons mis à jour l’hôte xoyize (10.19.55.5) avec pki.initiating_version défini sur 2 et redémarré Nebula. Comme sa version par défaut est définie sur 2, il utilisera le certificat v2 lors de la négociation avec Lighthouse. Comme Lighthouse dispose d’un ensemble v1+v2 configuré, il est en mesure d’établir la connexion, même si son pki.initiating_version est toujours défini sur 1.

Si Lighthouse était configuré avec un certificat v1 uniquement, host-1 ne pourrait pas se connecter, même s’il dispose d’un ensemble de certificats v1+v2 configuré. En effet, pki.initiating_version indique la version du certificat qui doit être utilisée dans les handshakes sortants. Si le destinataire ne prend pas en charge les certificats v2, l’initiateur ne se rabattra pas sur un certificat v1.

On se connecte SSH: ssh xouser@127.0.0.1 -p 2222 -i .ssh/xouser_nebula_key, on arrive sur le prompt xouser@nebula >
Saisir

1

print-tunnel 10.19.55.1

Le résultat est sélectionné puis copié dans un fichier tmp.txt et pour la mise au format json:

1

cat tmp.txt |jq

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

{
  "vpnAddrs": [
    "10.19.55.1"
  ],
  "localIndex": 3675975684,
  "remoteIndex": 326484131,
  "remoteAddrs": [
    "92.113.144.37:4242"
  ],
  "cert": {
    "curve": "CURVE25519",
    "details": {
      "groups": null,
      "isCa": false,
      "issuer": "229a24...81219719",
      "name": "lighthouse",
      "networks": [
        "10.19.55.1/24"
      ],
      "notAfter": "2026-11-18T13:12:55+01:00",
      "notBefore": "2025-11-18T13:34:05+01:00",
      "unsafeNetworks": null
    },
    "fingerprint": "078...............................474",
    "publicKey": "6de...............06",
    "signature": "0db9................................................508",
    "version": 2
  },
  "messageCounter": 10,
  "currentRemote": "92.113.144.37:4242",
  "currentRelaysToMe": [],
  "currentRelaysThroughMe": []
}

Vous pouvez également rechercher dans les journaux de l’hôte le champ certVersion dans les handshakes, par exemple :

1

nov. 18 18:33:29 mx1.xoyize.xyz nebula[25505]: time="2025-11-18T18:33:29+01:00" level=info msg="Handshake message received" certName=cwwk certVersion=2 durationNs=51515443 fingerprint=ffefb933be8ea5cafc9e3a790de09930acea6dcca198b072c75a10ca2e25ce1e handshake="map[stage:2 style:ix_psk0]" initiatorIndex=2577420195 issuer=229a24d896c0867cdde704ff00fa33e1122d0b68ff2a3ac3655a936281219719 remoteIndex=2577420195 responderIndex=1804124513 sentCachedPackets=1 udpAddr="[2a01:e0a:9c8:2080:aab8:e0ff:fe04:ec45]:4242" vpnAddrs="[10.19.55.4]"

Supprimer les certificats v1 des hôtes

Maintenant que tous les hôtes du réseau communiquent via des certificats v2, vous pouvez supprimer les certificats v1 en réémettant les certificats. Passez -version 2 pour créer uniquement des certificats au format v2.

1

nebula-cert sign -name "host-1" -networks "192.168.1.1/24" -version 2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

❯ nebula-cert print -path host-1.crt
{
	"curve": "CURVE25519",
	"details": {
		"groups": null,
		"isCa": false,
		"issuer": "62aabc872783f1036c7075fa49302c306baa1efb2afe9966f08401f157b6ae75",
		"name": "host-1",
		"networks": [
			"192.168.1.1/24"
		],
		"notAfter": "2026-04-01T17:02:35-04:00",
		"notBefore": "2025-04-01T20:40:00-04:00",
		"unsafeNetworks": null
	},
	"fingerprint": "05930841ba198874b932504de1cceb26e8d84b931ea29c673e22e0be06fb75f0",
	"publicKey": "501410109bd531fc5af3c75019cd2ed8349abfb56e3299a30ff72773300d1a4a",
	"signature": "fa1db2751fcbd6db73133364075f1577e17c3db4009bb84a7d82f159aaa4e17bb3b43636295567abda3ba9c9ad4cd5ed6357fffb8c93ebc299f3f8809e3aeb0e",
	"version": 2
}

À ce stade, vous pouvez attribuer une adresse IPv6 :

1

nebula-cert sign -name "host-1" -networks "192.168.1.1/24,fdc8:d0db:a315:cb00::1/64" -version 2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

❯ nebula-cert print -path host-1.crt
{
	"curve": "CURVE25519",
	"details": {
		"groups": null,
		"isCa": false,
		"issuer": "62aabc872783f1036c7075fa49302c306baa1efb2afe9966f08401f157b6ae75",
		"name": "host-1",
		"networks": [
			"192.168.1.1/24",
			"fdc8:d0db:a315:cb00::1/64"
		],
		"notAfter": "2026-04-01T17:02:35-04:00",
		"notBefore": "2025-04-01T20:38:21-04:00",
		"unsafeNetworks": null
	},
	"fingerprint": "2eda0f2dc5c5f8b097a09027fc896c9b6ba78d8fdac1559878caccd4c947e3ff",
	"publicKey": "d8ebf7a93e62044eee4bc504aa2e82e80d79db11cfee37c75b3769df261d343b",
	"signature": "5a5987e2e7e0e8619b0b111d951b3297f2c704387a032f84876172a3f1864e7fb2a5bf2ce48f3fa48ff6f60d39749ba3444b073485f6a9d41c6d3c9d7856f104",
	"version": 2
}

Une fois que vous avez basculé les services vers les nouvelles adresses IPv6, vous pouvez décider de déprécier les adresses IPv4 ou de continuer à exploiter votre réseau superposé avec les sous-réseaux IPv4 et IPv6. Si vous décidez de passer exclusivement à IPv6, n’oubliez pas de mettre à jour votre static_host_map.

Annexe

Débogage avec les commandes SSH Nebula

Ce guide décrit les commandes utiles intégrées au serveur SSH accessible via Nebula, qui permettent de déboguer la connectivité réseau de l’hôte Nebula.

Commencez par générer une nouvelle clé SSH pour l’hôte que vous souhaitez déboguer

1

sudo ssh-keygen -t ed25519 -f /etc/nebula/ssh_host_ed25519_key

Configurez ensuite la section sshd sur l’hôte que vous souhaitez déboguer.

En mode normal

1

ssh-keygen -t ed25519 -f $HOME/.ssh/user_nebula_key

La clé publique: cat $HOME/.ssh/user_nebula_key.pub à copier

1

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHjAKD3hgxnmXuR2vJ9erD+evAz6KRcwecLV61H5WiEP xouser@mx1.xoyize.xyz

Configurer le fichier /etc/nebula/config.yaml

1
2
3
4
5
6
7
8
9

sshd:
  enabled: true
  listen: 127.0.0.1:2222
  host_key: /etc/nebula/ssh_host_ed25519_key
  authorized_users:
    - user: xouser
      keys:
        - '[ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHjAKD3hgxnmXuR2vJ9erD+evAz6KRcwecLV61H5WiEP xouser@mx1.xoyize.xyz]'

Dans ce cas, xouser et sa clé publique ssh doivent être les valeurs correspondant à l’utilisateur pour lequel vous souhaitez activer l’accès au débogage. Vous devez ajouter la clé publique ssh correcte pour les utilisateurs que vous souhaitez autoriser à accéder au serveur ssh. Si vous ne disposez pas encore d’une clé SSH pour l’hôte à partir duquel vous souhaitez accéder, suivez ce guide de GitHub : Generating a new SSH key and adding it to the ssh-agent

Définissez la propriété listen sur localhost pour le débogage local ou sur votre IP Nebula pour activer l’accès via le réseau overlay Nebula.

Redémarrez Nebula et lancer la commande

1

ssh xouser@127.0.0.1 -p 2222 -i .ssh/user_nebula_key

Vous pouvez désormais déboguer votre installation Nebula, en interrogeant des éléments tels que votre hôte :

1
2
3

> list-hostmap
[10.19.55.1]: [92.214.144.37:4242]
[10.19.55.4]: [82.70.18.243:53761 192.168.0.205:4242 192.168.10.100:4242 192.168.100.1:4242]

Vous devriez pouvoir exécuter help une fois connecté.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

steeeeve@nebula > help
Available commands:
change-remote - Changes the remote address used in the tunnel for the provided vpn ip
close-tunnel - Closes a tunnel for the provided vpn ip
create-tunnel - Creates a tunnel for the provided vpn ip and address
device-info - Prints information about the network device.
help - prints available commands or help <command> for specific usage info
list-hostmap - List all known previously connected hosts
list-lighthouse-addrmap - List all lighthouse map entries
list-pending-hostmap - List all handshaking hosts
log-format - Gets or sets the current log format
log-level - Gets or sets the current log level
logout - Ends the current session
mutex-profile-fraction - Gets or sets runtime.SetMutexProfileFraction
print-cert - Prints the current certificate being used or the certificate for the provided vpn ip
print-relays - Prints json details about all relay info
print-tunnel - Prints json details about a tunnel for the provided vpn ip
query-lighthouse - Query the lighthouses for the provided vpn ip
reload - Reloads configuration from disk, same as sending HUP to the process
save-heap-profile - Saves a heap profile to the provided path
save-mutex-profile - Saves a mutex profile to the provided path
start-cpu-profile - Starts a cpu profile and write output to the provided file
stop-cpu-profile - Stops a cpu profile and writes output to the previously provided file
version - Prints the currently running version of nebula

Vous pouvez obtenir des informations supplémentaires sur chaque commande en exécutant help <command>.

1
2
3
4
5
6
7
8

> help list-hostmap
list-hostmap - List all known previously connected hosts
  -by-index
    	gets all hosts in the hostmap from the index table
  -json
    	outputs as json with more information
  -pretty
    	pretty prints json, assumes -json

Remarques concernant certaines commandes

  • query-lighthouse <some-ip> renverra initialement un ensemble de résultats vide si l’hôte n’est pas connecté, mais déclenchera une requête en arrière-plan vers Lighthouse. Cela signifie que vous devez l’exécuter deux fois pour obtenir un résultat.
  • change-remote n’a qu’un effet temporaire : après un certain temps, Nebula « reviendra » à son distant préféré.
  • logout pour sortir de la session
network
Cet article est sous licence CC BY 4.0 par l'auteur.