Neutron/VPNaaS/インストール方法 - OpenStack (2024)

インストール

Neutron-VPNaaS を devstack で使用するには (http://devstack.org) 単一ノードのセットアップの場合、local.conf で次の設定が必要になります (新規: neutron-vpnaas プラグインが追加されました)。

[[local|localrc]]enable_plugin neutron-vpnaas https://git.openstack.org/openstack/neutron-vpnaasdisable_service n-netenable_service q-svcenable_service q-agtenable_service q-dhcpenable_service q-l3enable_service q-meta# オプション、tempest を有効にするdevstackenable_service tempest# IPSec ドライバーの一部として構成を使用します。オプション。デフォルトは OpenSwan.IPSEC_PACKAGE="openswan" です。

クイックテストスクリプト

http://paste.openstack.org/raw/44702/

この簡単なテスト スクリプトは、ルーター、ネットワーク、およびパブリック ネットワークに接続されたサブネットを備えた 2 つのサイトを作成します。次に、両方のサイトを VPN 経由で接続します。

テストに 2 つの DevStack ノードを使用する

共通の「パブリック」ネットワークで接続された 2 つの DevStack ノードを使用して、VPNaaS をテストできます。 2 番目のノードは、異なるゲートウェイ IP (したがってルーター IP) を使用することを除いて、最初のノードと同じパブリック ネットワークを使用してセットアップできます。この例では、2 つの DevStack ノード (East と West) があり、それぞれがハードウェア上で実行されていると仮定します (必要に応じて、複数の VM ゲストで同じことを実行できます)。(注: 2 つの DevStack ノードを使用して同様のトポロジを作成することもできます) 1 つの開発スタックを持つ仮想ルーター)

トポロジの例

専用の物理ポートは、物理スイッチによって相互接続された「パブリック」ネットワーク接続 (eth2 など) に使用できます。各 DevStack ノードの OVS ブリッジにポートを追加する必要があります (例:sudo ovs-vsctl add-port br-ex eth2）。

(10.1.0.0/24 - DevStack東) | | 10.1.0.1 [Neutron ルーター] | 172.24.4.226 | | 172.24.4.225 [インターネット GW] | | 【インターネットGW】 | 172.24.4.232 | | 172.24.4.233 [中性子ルーター] | 10.2.0.1 | (10.2.0.0/24 開発スタック西)

DevStack の構成

のために東これらの行を localrc に追加すると、プライベート ネットワーク 10.1.0.0/24 とパブリック ネットワーク 172.24.4.0/24 が得られます。

PUBLIC_SUBNET_NAME=あなたのサブネットPRIVATE_SUBNET_NAME=mysubnetFIXED_RANGE=10.1.0.0/24NETWORK_GATEWAY=10.1.0.1PUBLIC_NETWORK_GATEWAY=172.24.4.225Q_FLOATING_ALLOCATION_POOL=start=172.24.4.226,end=172.24.4.2 31

のために西これらの行を localrc に追加すると、別のローカル ネットワーク、パブリック GW (および暗黙的なルーター) IP を使用できます。

PUBLIC_SUBNET_NAME=あなたのサブネットPRIVATE_SUBNET_NAME=mysubnetFIXED_RANGE=10.2.0.0/24NETWORK_GATEWAY=10.2.0.1PUBLIC_NETWORK_GATEWAY=172.24.4.232Q_FLOATING_ALLOCATION_POOL=start=172.24.4.233,end=172.24.4.2 38

VPNaaS 構成

DevStack が East と West で実行され、接続が確認された (一方のルーター/GW からもう一方のルーター/GW に ping できることを確認してください) と、これらの VPNaaS CLI コマンドを実行できます。

の上東

neutron vpn-ikepolicy-create ikepolicy1neutron vpn-ipsecpolicy-create ipsecpolicy1neutron vpn-service-create --name myvpn --description "私の vpn サービス" router1 mysubnet

neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpn --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1 --peer-address 172.24.4.233 --peer-id 172.24.4.233 --peer- cidr 10.2.0.0/24 --psk シークレット

の上西

neutron vpn-ikepolicy-create ikepolicy1neutron vpn-ipsecpolicy-create ipsecpolicy1neutron vpn-service-create --name myvpn --description "私の vpn サービス" router1 mysubnet

neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpn --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1 --peer-address 172.24.4.226 --peer-id 172.24.4.226 --peer- cidr 10.1.0.0/24 --psk シークレット

注: セキュリティ グループを必ず設定してください (VPN サブネットの icmp を開くなど)。

検証

各ノードで VM をスピンアップし、VM から遠端ルーターのパブリック IP に ping を送信できます。とtcpdumpいずれかのノードで実行すると、ping が暗号化パケット (ESP) として表示されることがわかります。 2 つのノード間の BOOTP、IGMP、およびキープアライブ パケットは暗号化されないことに注意してください (2 つの外部 IP アドレス間の ping も暗号化されません)。

キロアップデート

Kilo の場合、localrc の内容は local.conf に移動されました。 (VirtualBox) VM がホストとして使用され、eth0 が NAT として設定され、eth1 が内部ネットワークとして設定され、local.conf で次の構成が使用されました。

OVS_PHYSICAL_BRIDGE=br-ex PUBLIC_INTERFACE=eth1

スタックされると、テスト用に VM が作成され、ノード間の接続を確立するために VPN IPSec コマンドが使用され、ICMP と SSH を許可するためにセキュリティ グループ ルールが追加されました。

単一の DevStack と 2 つのルーターを備えた VPNaaS

リファレンス実装 (OpenSwan) を使用して VPNaaS IPSec 接続を確立できるテスト環境をセットアップする方法に関する簡単な手順。この例では、ラップトップ上で実行される VIrtualBox を使用して、DevStack を実行するための VM を提供します。 Kilo リリース (Juno 後) を前提としています。

ここでの考え方は、DevStack を使用して作成された 1 つの OpenStack クラウド、2 つのルーター (1 つは自動的に作成)、2 つのプライベート ネットワーク (1 つは自動的に作成) -10.1.0.0/24 および 10.2.0.0/24、各プライベート ネットワークに VM を配置することです。そして、パブリック ネットワーク (172.24.4.0/24) を使用して、2 つのプライベート ネット間に VPN 接続を確立します。

準備

インターネットにアクセスするための NAT I/F を備えた、Ubuntu 14.04 を実行する VM (例: 7 GB RAM、2 CPU) を作成します。最新の DevStack リポジトリのクローンを作成します (この例では Kilo-1 を使用)。

DevStack の構成

この例では、次の local.conf が使用されます。

 ローカルrcGIT_BASE=https://github.comDEST=/opt/stack disable_service n-net Enable_service q-svc Enable_service q-agt Enable_service q-dhcp Enable_service q-l3 Enable_service q-meta Enable_service neutron Enable_plugin neutron-vpnaashttps://git.openstack.org/openstack/neutron-vpnaasFIXED_RANGE=10.1.0.0/24 FIXED_NETWORK_SIZE=256 NETWORK_GATEWAY=10.1.0.1 PRIVATE_SUBNET_NAME=privateA PUBLIC_SUBNET_NAME=パブリックサブネット FLOATING_RANGE=172.24.4.0/24 PUBLIC_NETWORK_GATEWAY=172.24.4.10 Q_FLOATING_ALLOC ATION_POOL="開始=172.24.4.11、終了=172.24.4.29" LIBVIRT_TYPE=qemu IMAGE_URLS=http://cloud-images.ubuntu.com/releases/14.04.1/release/ubuntu-14.04-server-cloudimg-amd64.tar.gz、http://download.cirros-cloud.net/0.3.3/ cirros-0.3.3-x86_64-uec.tar.gz" SCREEN_LOGDIR=/opt/stack/screen-logs SYSLOG=True LOGFILE=~/devstack/stack.sh.log ADMIN_PASSWORD=パスワード MYSQL_PASSWORD=パスワード RABBIT_PASSWORD=パスワード SERVICE_PASSWORD=パスワード SERVICE_TOKEN=トークントークン Q_USE_DEBUG_COMMAND=True # RECLONE=No RECLONE=yエスオフライン=False

./stack.sh を使用してクラウドを起動し、正常に完了することを確認します。スタックしたら、RECLONE を No に変更できます。

クラウド構成

スタッキングが完了すると、プライベート ネットワーク (10.1.0.0/24) とルーター (router1) が作成されます。 VPN 接続の確立を準備するには、2 番目のネットワーク、サブネット、ルーターを作成し、各プライベート ネットワークで VM を起動する必要があります。

# 2 番目のネット、サブネット、ルーターのソースを作成します ~/devstack/openrc admin Demon neutron net-create privateB neutron subnet-create --name subB privateB 10.2.0.0/24 --gateway 10.2.0.1 neutron router-create router2 neutron router-interface -add router2 subB neutron router-gateway-set router2 public # privateA サブネットで VM を起動します。 PRIVATE_NET=`中性子ネットリスト | grep 'プライベート' | Cut -f 2 -d' '' nova boot --flavor 1 --image cirros-0.3.3-x86_64-uec --nic net-id=$PRIVATE_NET peter # privateB サブネットで VM を起動します PRIVATE_NETB=`neutronネットリスト | grep プライベート B | Cut -f 2 -d' '' nova boot --flavor 1 --image cirros-0.3.3-x86_64-uec --nic net-id=$PRIVATE_NETB paul

この時点で、基本的な接続があることを確認できます。 DevStack は、プライベート B ネットワークから router1 のプライベート I/F IP に ping できる静的ルートを作成することに注意してください。必要に応じてルートを削除できます。

IPSec サイト間接続の作成

次のコマンドは IPSec 接続を作成します。

# VPN 接続を作成する neutron vpn-ikepolicy-create ikepolicy neutron vpn-ipsecpolicy-create ipsecpolicy neutron vpn-service-create --name myvpn --description "My vpn service" router1 privateA neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpn \ --ikepolicy-id ikepolicy --ipsecpolicy-id ipsecpolicy --peer-address 172.24.4.13 \ --peer-id 172.24.4.13 --peer-cidr 10.2.0.0/24 --psk シークレットneutron vpn-service-create --name myvpnB --description "My vpn serviceB" router2 subB neutron ipsec-site-connection-create --name vpnconnection2 --vpnservice-id myvpnB \ --ikepolicy-id ikepolicy --ipsecpolicy-id ipsecpolicy --peer-address 172.24.4.11 \ --peer-id 172.24.4.11 --peer-cidr 10.1.0.0/24 --psk シークレット

この時点 (接続がアクティブになると、最大 30 秒ほどかかる場合があります) で、privateA ネットワークの VM から privateB ネットワークの VM に ping できるようになります。いずれかのルーター名前空間から qg-# インターフェイスを使用して tcpdump を実行すると、暗号化されたパケットが表示されます。接続の 1 つを削除すると、ping が失敗することがわかります (すべてが正しく機能した場合)。

複数のローカルサブネット

Mitaka の初期段階では、IPSec サイト間接続は、現在の複数のピア CIDR に加えて、複数のローカル サブネットをサポートする予定です。複数のローカル サブネット機能は、次によってトリガーされます。ないVPN サービスの作成時にローカル サブネットを指定します。 VPN サービスの作成時にサブネットを提供することで、単一のローカル サブネットとの下位互換性が維持されます。

複数のローカル サブネットをサポートするために、「エンドポイント グループ」と呼ばれる新しい機能が (Liberty で) 提供されました。各エンドポイント グループは、特定のタイプの 1 つ以上のエンドポイントを定義し、IPSec 接続のローカル エンドポイントとピア エンドポイントの両方を指定するために使用できます。エンドポイント グループは、VPN サービスの「何を接続するか」と「接続方法」を分離し、将来的にはさまざまな種類の VPN に使用できます。例：

# VPN 接続を作成する neutron vpn-ikepolicy-create ikepolicy neutron vpn-ipsecpolicy-create ipsecpolicy neutron vpn-service-create --name myvpnC --description "My vpn service" router1

IPSec サイト間を準備するには、次のように、ローカル サブネットのエンドポイント グループとピア CIDR のエンドポイント グループを作成します。

neutron vpn-endpoint-group-create --name my-locals --type subnet --value privateA --value privateA2 neutron vpn-endpoint-group-create --name my-peers --type cidr --value 10.2.0.0 /24 --値 20.2.0.0/24

ここで、privateA と privateA2 は 2 つのローカル (プライベート) サブネットで、10.2.0.0/24 と 20.2.0.0/24 は、接続で使用されるピア (プライベート) サブネットを表す 2 つの CIDR です。次に、IPSec サイト間接続を作成するときに、peer-cidrs 属性の代わりに、次のエンドポイント グループ ID が指定されます。

neutron ipsec-site-connection-create --name vpnconnection3 --vpnservice-id myvpnC \ --ikepolicy-id ikepolicy --ipsecpolicy-id ipsecpolicy --peer-address 172.24.4.11 \ --peer-id 172.24.4.11 -- local-ep-group my-locals --peer-ep-group my-peers --psk Secret

ノート：

• 検証ロジックにより、エンドポイント グループとピア CIDR が混在していないことが確認されます。
• エンドポイント グループのタイプは、サブネット、cidr、ネットワーク、ルーター、および vlan です。ただし、サブネットとcidrのみが実装されています(IPSec用)。
• グループ内のエンドポイントは同じタイプである必要がありますが、IP バージョンが混在していてもかまいません。
• IPSec 接続の場合、現在、ローカル エンドポイントとピア エンドポイントがすべて同じ IP バージョンを使用することが検証によって強制されます。
• IPSec 接続の検証では、ローカル エンドポイントがサブネットであり、ピア エンドポイントが CIDR である必要があります。
• 移行により、既存の VPN サービスと接続の情報がエンドポイント グループに変換されます。
• 元の API は下位互換性のために機能します。

ホライズンのサポート

• チェックアウトテストブランチ

Horizo​​n サポートが統合されました。

• Horizo​​n の VPN セクションを有効にする

ff q-vpn が有効になっていると、Horizo​​n VPN サポートが自動的に有効になることに注意してください。

開ける

/opt/stack/horizo​​n/openstack_dashboard/local/local_settings.py

そして交換してください

OPENSTACK_NEUTRON_NETWORK = { 'enable_vpn': False,}

と

OPENSTACK_NEUTRON_NETWORK = { 'enable_vpn': True,}

• Apache を再起動して使用を開始します

• ユーザーシナリオをテストする

https://wiki.openstack.org/wiki/Neutron/VPNaaS/UI