「Nebula」の版間の差分
Kusanaginoturugi (トーク | 投稿記録) (飜訳) |
Kusanaginoturugi (トーク | 投稿記録) (→参照: TranslationStatus を追加) |
||
227行目: | 227行目: | ||
* [https://github.com/slackhq/nebula Nebula プロジェクト] |
* [https://github.com/slackhq/nebula Nebula プロジェクト] |
||
* [https://theorangeone.net/posts/nebula-intro/ Nebula VPN を説明するブログポスト] |
* [https://theorangeone.net/posts/nebula-intro/ Nebula VPN を説明するブログポスト] |
||
+ | |||
+ | {{TranslationStatus|Nebula|2024/04/11|781267}} |
2024年4月11日 (木) 20:03時点における版
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.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 にコピーする必要があります
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) に発生します。適切な解決策は、それをアップグレードすることです。