Nebula
Nebula は、トンネリングと暗号化を使用して参加ホスト間で安全なプライベートメッシュネットワークを作成する、ユーザー空間メッシュ仮想プライベートネットワーク（VPN）デーモンです。
目次
インストール
基本概念と用語
Nebula は、tinc に触発されたメッシュ VPN 技術です。メッシュ VPN では、個々のノードが互いに直接トンネルを形成します。これにより、中央ノードを経由せずに、ノード間で高速な直接通信を可能にします。ノードは、証明書機関によって署名された証明書を使用して認証されます。
これは、ピアツーピア VPN 技術である WireGuard とは対照的です（ただし、WireGuard 用のメッシュネットワークマネージャーが存在します。例：innernet および wesherAUR）。
これは、星形トポロジー（ハブアンドスポークとも呼ばれる）を使用する 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.keyhostA.crt,hostA.keyhostB.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 にコピーする必要があります
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) に発生します。適切な解決策は、それをアップグレードすることです。