Nebula

Nebula は、トンネリングと暗号化を使用して参加ホスト間で安全なプライベートメッシュネットワークを作成する、ユーザー空間メッシュ仮想プライベートネットワーク（VPN）デーモンです。

インストール

基本概念と用語

Nebula は、tinc に触発されたメッシュ VPN 技術です。メッシュ VPN では、個々のノードが互いに直接トンネルを形成します。これにより、中央ノードを経由せずに、ノード間で高速な直接通信を可能にします。ノードは、証明書機関によって署名された証明書を使用して認証されます。

これは、ピアツーピア VPN 技術である WireGuard とは対照的です（ただし、WireGuard 用のメッシュネットワークマネージャーが存在します。例：innernet および wesher^AUR）。

これは、星形トポロジー（ハブアンドスポークとも呼ばれる）を使用する OpenVPN とも異なります。

証明書機関: 証明書機関は、それに署名することでホスト証明書を作成します。
ライトハウス: Nebula ネットワークでは、通常、他のノードの情報ハブとして機能する少なくとも1つのライトハウスノードがあります。ライトハウスノードは、他のノードが互いを見つけてネットワークメッシュを形成するのを助けます。
ノード: Nebula ネットワークのノード。
Nebula IP: Nebula ネットワーク内のノードの IP アドレス。VPN IP としても知られています。
ルーティング可能な IP: ノードの「通常の」または「ネイティブ」の IP アドレス。これは、ノードの場所とネットワークの設定方法によって、公開 IP アドレスまたはプライベート IP アドレスのいずれかになります。ノードは複数のルーティング可能な IP アドレスを持つことができます。

例: シンプルなメッシュ VPN

ネットワーク設定

この例では、3つのノードがあります：

lighthouse
- Nebula IP: 192.168.100.1
- Routable IP: 12.34.56.78
hostA
- Nebula IP: 192.168.100.101
- Routable IP: 10.0.0.22
hostB
- Nebula IP: 192.168.100.102
- Routable IP: 23.45.67.89

lighthouse は公開の静的 IP アドレスを持ち、hostA と hostB からアクセス可能です。hostA は NAT の後ろにあります。hostB は公開 IP アドレスを持っています。

このケースでは、VPN ネットワークのために /24 サブネットを使用します。このネットワークを「My Nebula Network」と呼ぶことにします。

証明書と鍵の生成

最初に、nebula-cert ca -name "My Nebula Network" を使用して CA 証明書と秘密鍵を生成します。これにより、以下の2つのファイルが作成されます：

ca.crt：CA 証明書ファイル
ca.key：CA の秘密鍵

その後、ネットワーク内のノードのための証明書と秘密鍵ファイルを生成します：

$ nebula-cert sign -name lighthouse -ip 192.168.100.1/24
$ nebula-cert sign -name hostA -ip 192.168.100.101/24
$ nebula-cert sign -name hostB -ip 192.168.100.102/24

ca.crt と ca.key を指定していないことに注意してください。デフォルトで、nebula-cert はそれらのファイルを現在のディレクトリで探します。

このステップの後、以下のファイルが得られます：

lighthouse.crt, lighthouse.key
hostA.crt, hostA.key
hostB.crt, hostB.key

設定

lighthouse ノードにこの設定ファイルを作成します：

/etc/nebula/config.yml

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/lighthouse.crt
  key: /etc/nebula/lighthouse.key

lighthouse:
  am_lighthouse: true

firewall:
  outbound:
    - port: any
      proto: any
      host: any
  inbound:
    - port: any
      proto: any
      host: any

hostA にこの設定ファイルを作成します：

/etc/nebula/config.yml

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/hostA.crt
  key: /etc/nebula/hostA.key

static_host_map:
  "192.168.100.1": ["12.34.56.78:4242"]

lighthouse:
  hosts:
    - "192.168.100.1"

punchy:
  punch: true

firewall:
  outbound:
    - port: any
      proto: any
      host: any
  inbound:
    - port: any
      proto: any
      host: any

最後に、hostB 用にこの設定ファイルを使用します：

/etc/nebula/config.yml

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/hostB.crt
  key: /etc/nebula/hostB.key

static_host_map:
  "192.168.100.1": ["12.34.56.78:4242"]

lighthouse:
  hosts:
    - "192.168.100.1"

firewall:
  outbound:
    - port: any
      proto: any
      host: any
  inbound:
    - port: any
      proto: any
      host: any

証明書と秘密鍵の配布

証明書と秘密鍵は証明書機関によって生成されたため、各ノードに配布する必要があります。SCP と SFTP はこの目的に適しています。

具体的には：

ca.crt は、ライトハウス、hostA、hostB の全3ノードにコピーする必要があります
ライトハウス.crt と ライトハウス.key は、ライトハウスノードにコピーする必要があります
hostA.crt と hostA.key は、hostA にコピーする必要があります
hostB.crt と hostB.key は、hostB にコピーする必要があります

ノート: ca.key ファイルは、どのノードにもコピーする必要はありません。安全に保管してください（紛失しないように）し、安全に管理してください（漏洩しないように）。

Nebula デーモンの起動

各ノードで、nebula.service を開始してください。オプションで、ブート時に起動するように有効化することもできます。

どのノードが Nebula デーモンを起動するかは重要ではありません。lighthouse ノードが最後に起動されても構いません。各個別のノードは常に既知の lighthouse ノードのリストに接続しようとするので、任意のネットワーク中断も迅速に解決できます。

メッシュ機能のテスト

メッシュネットワークでは、すべてのノードが他のすべてのノードに直接接続されています。したがって、lighthouse と hostA および hostB の間の接続が遅い場合でも、それら2つの間に直接リンクがある限り、hostA と hostB の間のトラフィックは高速になることがあります。

これは hostA でのシンプルな ping テストによって実証できます：

$ ping -c 5 12.34.56.78

PING 12.34.56.78 (12.34.56.78) 56(84) bytes of data.
64 bytes from 12.34.56.78: icmp_seq=1 ttl=56 time=457 ms
64 bytes from 12.34.56.78: icmp_seq=2 ttl=56 time=480 ms
64 bytes from 12.34.56.78: icmp_seq=3 ttl=56 time=262 ms
64 bytes from 12.34.56.78: icmp_seq=4 ttl=56 time=199 ms
64 bytes from 12.34.56.78: icmp_seq=5 ttl=56 time=344 ms

--- 12.34.56.78 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 199.141/348.555/480.349/108.654 ms

$ ping -c 5 192.168.100.1

PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=218 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=241 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=264 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=288 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=64 time=163 ms

--- 192.168.100.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 162.776/234.874/288.073/42.902 ms

$ ping -c 5 192.168.100.102

PING 192.168.100.102 (192.168.100.102) 56(84) bytes of data.
64 bytes from 192.168.100.102: icmp_seq=1 ttl=64 time=106 ms
64 bytes from 192.168.100.102: icmp_seq=2 ttl=64 time=2.14 ms
64 bytes from 192.168.100.102: icmp_seq=3 ttl=64 time=4.53 ms
64 bytes from 192.168.100.102: icmp_seq=4 ttl=64 time=4.29 ms
64 bytes from 192.168.100.102: icmp_seq=5 ttl=64 time=5.39 ms

--- 192.168.100.102 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 2.136/24.535/106.344/40.918 ms

hostA と lighthouse の間の接続が遅いことに注意してくださいが、hostA と hostB の間の接続は非常に高速です。また、hostA と hostB の間の最初のパケットが少し遅れることにも注意してくださいが、続くパケットはほとんど時間を要しません。

設定オプション

listen.port: これは Nebula デーモンのリスニングポートで、デフォルトでは 4242 です。lighthouse ノードや静的 IP アドレスを持つノードでは、このポートを他の番号に設定して設定をパーソナライズし、そのポートでの望まないサービスの発見や DDoS 攻撃の可能性を減らすことができます。その後、変更を反映するために static_host_map を更新してください。; 動的 IP アドレスを持つノードでは、この値を 0 に設定することが推奨されます。その場合、Nebula デーモンは通信にランダムなポートを使用します。
logging.level: デフォルトでは、Nebula デーモンは INFO レベルのメッセージをログに記録します。これにより、ハンドシェイクが印刷され、多くのログメッセージが生成されることがあります。ログに記録されるメッセージの量を減らすために、warning に設定します。
relay: あるノードから別のノードへ直接到達できない場合に使用できるオプションです。リレーノードは、そのようなノード間の通信を転送するのに役立ちます。
firewall: このオプションを使用して、ノードへのおよびノードからの特定のトラフィックのみを許可することができます。

トラブルシューティング

lighthouse ノードのハンドシェイクに永遠に時間がかかる

ハンドシェイクに長い時間がかかり、ハンドシェイクが完了すると一度に複数のハンドシェイクメッセージが印刷される場合、recvmmsg() をサポートしていない可能性があります。この問題を回避するには、この設定オプションを追加してください：

/etc/nebula/config.yml

listen:
  batch: 1

この問題は通常、Linux カーネルが古すぎる場合 (<2.6.34) に発生します。適切な解決策は、それをアップグレードすることです。

参照