「Nebula」の版間の差分
Kusanaginoturugi (トーク | 投稿記録) (→Example: Simple mesh VPN: 一部飜訳) |
Kusanaginoturugi (トーク | 投稿記録) |
||
(同じ利用者による、間の12版が非表示) | |||
1行目: | 1行目: | ||
− | [[Category: |
+ | [[Category:仮想プライベートネットワーク]] |
+ | [[en:Nebula]] |
||
[https://nebula.defined.net/ Nebula] は、トンネリングと暗号化を使用して参加ホスト間で安全なプライベートメッシュネットワークを作成する、ユーザー空間メッシュ仮想プライベートネットワーク(VPN)デーモンです。 |
[https://nebula.defined.net/ Nebula] は、トンネリングと暗号化を使用して参加ホスト間で安全なプライベートメッシュネットワークを作成する、ユーザー空間メッシュ仮想プライベートネットワーク(VPN)デーモンです。 |
||
15行目: | 16行目: | ||
;証明書機関: 証明書機関は、それに署名することでホスト証明書を作成します。 |
;証明書機関: 証明書機関は、それに署名することでホスト証明書を作成します。 |
||
− | ; |
+ | ;lighthouse: Nebula ネットワークでは、通常、他のノードの情報ハブとして機能する少なくとも1つの lighthouse ノードがあります。lighthouse ノードは、他のノードが互いを見つけてネットワークメッシュを形成するのを助けます。 |
;ノード: Nebula ネットワークのノード。 |
;ノード: Nebula ネットワークのノード。 |
||
;Nebula IP: Nebula ネットワーク内のノードの IP アドレス。VPN IP としても知られています。 |
;Nebula IP: Nebula ネットワーク内のノードの IP アドレス。VPN IP としても知られています。 |
||
− | ; |
+ | ;Routable IP: ノードの「通常の」または「ネイティブ」の IP アドレス。これは、ノードの場所とネットワークの設定方法によって、公開 IP アドレスまたはプライベート IP アドレスのいずれかになります。ノードは複数のルーティング可能な IP アドレスを持つことができます。 |
== 例: シンプルなメッシュ VPN == |
== 例: シンプルなメッシュ VPN == |
||
24行目: | 25行目: | ||
=== ネットワーク設定 === |
=== ネットワーク設定 === |
||
− | この例では、3つのノードがあります: |
+ | この例では、3 つのノードがあります: |
* lighthouse |
* lighthouse |
||
** Nebula IP: 192.168.100.1 |
** Nebula IP: 192.168.100.1 |
||
58行目: | 59行目: | ||
* {{ic|hostB.crt}}, {{ic|hostB.key}} |
* {{ic|hostB.crt}}, {{ic|hostB.key}} |
||
− | === |
+ | === 設定 === |
+ | lighthouse ノードにこの設定ファイルを作成します: |
||
− | Create this configuration file on the lighthouse node: |
||
{{hc|/etc/nebula/config.yml|2= |
{{hc|/etc/nebula/config.yml|2= |
||
82行目: | 83行目: | ||
}} |
}} |
||
+ | hostA にこの設定ファイルを作成します: |
||
− | Create this configuration file on hostA: |
||
{{hc|/etc/nebula/config.yml|2= |
{{hc|/etc/nebula/config.yml|2= |
||
111行目: | 112行目: | ||
}} |
}} |
||
+ | 最後に、hostB 用にこの設定ファイルを使用します: |
||
− | Finally, use this configuration file for hostB: |
||
{{hc|/etc/nebula/config.yml|2= |
{{hc|/etc/nebula/config.yml|2= |
||
137行目: | 138行目: | ||
}} |
}} |
||
+ | === 証明書と秘密鍵の配布 === |
||
− | === Distribute certificates and private keys === |
||
+ | 証明書と秘密鍵は証明書機関によって生成されたため、各ノードに配布する必要があります。[[SCP と SFTP]] はこの目的に適しています。 |
||
− | Because the certificates and private keys were generated by the certificate authority, they need to be distributed to each node. [[SCP and SFTP]] are suitable for this purpose. |
||
+ | 具体的には: |
||
− | Specifically: |
||
− | * {{ic|ca.crt}} |
+ | * {{ic|ca.crt}} は、lighthouse, hostA, hostB の全 3 ノードにコピーする必要があります |
− | * {{ic|lighthouse.crt}} |
+ | * {{ic|lighthouse.crt}} と {{ic|lighthouse.key}} は、lighthouse ノードにコピーする必要があります |
− | * {{ic|hostA.crt}} |
+ | * {{ic|hostA.crt}} と {{ic|hostA.key}} は、hostA にコピーする必要があります |
− | * {{ic|hostB.crt}} |
+ | * {{ic|hostB.crt}} と {{ic|hostB.key}} は、hostB にコピーする必要があります |
+ | {{Note|{{ic|ca.key}} ファイルは、どのノードにもコピーする必要はありません。安全に保管してください(紛失しないように)し、安全に管理してください(漏洩しないように)。}} |
||
− | {{Note|The {{ic|ca.key}} file does not have to be copied over to any node. Keep it safe (do not lose it) and secure (do not leak it).}} |
||
− | === |
+ | === Nebula デーモンの起動 === |
+ | 各ノードで、{{ic|nebula.service}} を[[開始]]してください。オプションで、ブート時に起動するように[[有効化]]することもできます。 |
||
− | On each node, [[start]] {{ic|nebula.service}}. Optionally, [[enable]] it so that it will be started on boot. |
||
+ | どのノードが Nebula デーモンを起動するかは重要ではありません。lighthouse ノードが最後に起動されても構いません。各個別のノードは常に既知の lighthouse ノードのリストに接続しようとするので、任意のネットワーク中断も迅速に解決できます。 |
||
− | Note that it does not matter which node starts the nebula daemon. The lighthouse node can even be started last. Each individual node always tries to connect to the list of known lighthouse nodes, so any network interruption can be rectified quickly. |
||
− | === |
+ | === メッシュ機能のテスト === |
+ | メッシュネットワークでは、すべてのノードが他のすべてのノードに直接接続されています。したがって、lighthouse と hostA および hostB の間の接続が遅い場合でも、それら2つの間に直接リンクがある限り、hostA と hostB の間のトラフィックは高速になることがあります。 |
||
− | With a mesh network, every node is directly connected to every other node. So, even if the connection between lighthouse and both hostA and hostB is slow, traffic between hostA and hostB can be fast, as long as there is a direct link between those two. |
||
+ | これは hostA でのシンプルな ping テストによって実証できます: |
||
− | This can be demonstrated by a simple ping test on hostA: |
||
{{hc|$ ping -c 5 12.34.56.78|2= |
{{hc|$ ping -c 5 12.34.56.78|2= |
||
200行目: | 201行目: | ||
}} |
}} |
||
+ | hostA と lighthouse の間の接続が遅いことに注意してくださいが、hostA と hostB の間の接続は非常に高速です。また、hostA と hostB の間の最初のパケットが少し遅れることにも注意してくださいが、続くパケットはほとんど時間を要しません。 |
||
− | Notice that the connection between hostA and lighthouse is slow, but the connection between hostA and hostB is very fast. Also notice that the first packet between hostA and hostB is delayed a bit, but subsequent packets take almost no time at all. |
||
− | == |
+ | == 設定オプション == |
+ | ;{{ic|listen.port}}:これは Nebula デーモンのリスニングポートで、デフォルトでは 4242 です。lighthouse ノードや静的 IP アドレスを持つノードでは、このポートを他の番号に設定して設定をパーソナライズし、そのポートでの望まないサービスの発見や DDoS 攻撃の可能性を減らすことができます。その後、変更を反映するために {{ic|static_host_map}} を更新してください。 |
||
− | ;{{ic|listen.port}}:This is the listening port for the nebula daemon, which by default is 4242. On a lighthouse node, or a node with a static IP address, set this to any other number in order to personalize your setup and reduce the chances of unwanted service discovery and DDoS attacks on that port. Then update {{ic|static_host_map}} to reflect the change. |
||
+ | :動的 IP アドレスを持つノードでは、この値を 0 に設定することが推奨されます。その場合、Nebula デーモンは通信にランダムなポートを使用します。 |
||
− | :On a node with a dynamic IP address, it is recommended to set this to 0, such the nebula daemon will use a random port for communication. |
||
+ | ;{{ic|logging.level}}:デフォルトでは、Nebula デーモンは INFO レベルのメッセージをログに記録します。これにより、ハンドシェイクが印刷され、多くのログメッセージが生成されることがあります。ログに記録されるメッセージの量を減らすために、{{ic|warning}} に設定します。 |
||
− | ;{{ic|logging.level}}:By default, the nebula daemon logs INFO-level messages. Thus handshakes are printed, and this can generate a lot of log messages. Set it to {{ic|warning}} in order to reduce the amount of messages logged. |
||
+ | ;{{ic|relay}}:あるノードから別のノードへ直接到達できない場合に使用できるオプションです。リレーノードは、そのようなノード間の通信を転送するのに役立ちます。 |
||
− | ;{{ic|relay}}:This option can be used if a node cannot be reached directly from another node. Relay nodes help forward the communication between such nodes. |
||
+ | ;{{ic|firewall}}:このオプションを使用して、ノードへのおよびノードからの特定のトラフィックのみを許可することができます。 |
||
− | ;{{ic|firewall}}: This option can be used to allow only certain traffic to and from a node. |
||
+ | == トラブルシューティング == |
||
− | == Troubleshooting == |
||
− | === |
+ | === lighthouse ノードのハンドシェイクに永遠に時間がかかる === |
+ | ハンドシェイクに長い時間がかかり、ハンドシェイクが完了すると一度に複数のハンドシェイクメッセージが印刷される場合、{{ic|recvmmsg()}} をサポートしていない可能性があります。この問題を回避するには、この設定オプションを追加してください: |
||
− | If your lighthouse node needs a long time to handshake, and it prints multiple handshake messages all at once when handshake is completed, maybe it does not support {{ic|recvmmsg()}}. To get around this issue, add this configuration option: |
||
{{hc|/etc/nebula/config.yml|2= |
{{hc|/etc/nebula/config.yml|2= |
||
221行目: | 222行目: | ||
}} |
}} |
||
+ | この問題は通常、Linux カーネルが古すぎる場合 (<2.6.34) に発生します。適切な解決策は、それをアップグレードすることです。 |
||
− | This problem usually happens if your Linux kernel is too old (<2.6.34). The proper solution is to upgrade it. |
||
− | == |
+ | == 参照 == |
− | * [https://github.com/slackhq/nebula Nebula |
+ | * [https://github.com/slackhq/nebula Nebula プロジェクト] |
− | * [https://theorangeone.net/posts/nebula-intro/ |
+ | * [https://theorangeone.net/posts/nebula-intro/ Nebula VPN を説明するブログポスト] |
+ | |||
+ | {{TranslationStatus|Nebula|2024/04/11|781267}} |
2024年8月14日 (水) 23:05時点における最新版
Nebula は、トンネリングと暗号化を使用して参加ホスト間で安全なプライベートメッシュネットワークを作成する、ユーザー空間メッシュ仮想プライベートネットワーク(VPN)デーモンです。
目次
インストール
基本概念と用語
Nebula は、tinc に触発されたメッシュ VPN 技術です。メッシュ VPN では、個々のノードが互いに直接トンネルを形成します。これにより、中央ノードを経由せずに、ノード間で高速な直接通信を可能にします。ノードは、証明書機関によって署名された証明書を使用して認証されます。
これは、ピアツーピア VPN 技術である WireGuard とは対照的です(ただし、WireGuard 用のメッシュネットワークマネージャーが存在します。例:innernet および wesherAUR)。
これは、星形トポロジー(ハブアンドスポークとも呼ばれる)を使用する OpenVPN とも異なります。
- 証明書機関
- 証明書機関は、それに署名することでホスト証明書を作成します。
- lighthouse
- Nebula ネットワークでは、通常、他のノードの情報ハブとして機能する少なくとも1つの lighthouse ノードがあります。lighthouse ノードは、他のノードが互いを見つけてネットワークメッシュを形成するのを助けます。
- ノード
- Nebula ネットワークのノード。
- Nebula IP
- Nebula ネットワーク内のノードの IP アドレス。VPN IP としても知られています。
- Routable 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
は、lighthouse, hostA, hostB の全 3 ノードにコピーする必要がありますlighthouse.crt
とlighthouse.key
は、lighthouse ノードにコピーする必要があります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) に発生します。適切な解決策は、それをアップグレードすることです。