Nebulaのソースを表示

[[Category:Virtual Private Network]]
[[en:Nebula]]
[https://nebula.defined.net/ Nebula] は、トンネリングと暗号化を使用して参加ホスト間で安全なプライベートメッシュネットワークを作成する、ユーザー空間メッシュ仮想プライベートネットワーク（VPN）デーモンです。

== インストール ==

{{pkg|nebula}} パッケージを[[インストール]]します。

== 基本概念と用語 ==

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

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

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

;証明書機関: 証明書機関は、それに署名することでホスト証明書を作成します。
;lighthouse: Nebula ネットワークでは、通常、他のノードの情報ハブとして機能する少なくとも1つの lighthouse ノードがあります。lighthouse ノードは、他のノードが互いを見つけてネットワークメッシュを形成するのを助けます。
;ノード: 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」と呼ぶことにします。

=== 証明書と鍵の生成 ===

最初に、{{ic|nebula-cert ca -name "My Nebula Network"}} を使用して CA 証明書と秘密鍵を生成します。これにより、以下の2つのファイルが作成されます：
* {{ic|ca.crt}}：CA 証明書ファイル
* {{ic|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

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

このステップの後、以下のファイルが得られます：
* {{ic|lighthouse.crt}}, {{ic|lighthouse.key}}
* {{ic|hostA.crt}}, {{ic|hostA.key}}
* {{ic|hostB.crt}}, {{ic|hostB.key}}

=== 設定 ===

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

{{hc|/etc/nebula/config.yml|2=
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 にこの設定ファイルを作成します：

{{hc|/etc/nebula/config.yml|2=
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 用にこの設定ファイルを使用します：

{{hc|/etc/nebula/config.yml|2=
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]] はこの目的に適しています。

具体的には：
* {{ic|ca.crt}} は、ライトハウス、hostA、hostB の全3ノードにコピーする必要があります
* {{ic|ライトハウス.crt}} と {{ic|ライトハウス.key}} は、ライトハウスノードにコピーする必要があります
* {{ic|hostA.crt}} と {{ic|hostA.key}} は、hostA にコピーする必要があります
* {{ic|hostB.crt}} と {{ic|hostB.key}} は、hostB にコピーする必要があります

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

=== Nebula デーモンの起動 ===

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

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

=== メッシュ機能のテスト ===

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

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

{{hc|$ ping -c 5 12.34.56.78|2=
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
}}

{{hc|$ ping -c 5 192.168.100.1|2=
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
}}

{{hc|$ ping -c 5 192.168.100.102|2=
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 の間の最初のパケットが少し遅れることにも注意してくださいが、続くパケットはほとんど時間を要しません。

== 設定オプション ==

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

== トラブルシューティング ==

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

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

{{hc|/etc/nebula/config.yml|2=
listen:
  batch: 1
}}

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

== 参照 ==

* [https://github.com/slackhq/nebula Nebula プロジェクト]
* [https://theorangeone.net/posts/nebula-intro/ Nebula VPN を説明するブログポスト]

{{TranslationStatus|Nebula|2024/04/11|781267}}