バックLANパターン#
本構成は東日本/西日本リージョン1・2向けとなります。
要求事項#
- Webサーバ等の業務用のサーバにログインする際に、インターネット等外部に公開するインターフェイスとログイン用のインターフェースを分けて、より安全にシステムにログインできるようにしたい
対応するデザインパターン概要#
- Webサーバ等のサーバに安全にログインするための方式としては、踏み台サーバを利用したパターン が存在します
- 本パターンでは、ログイン対象のサーバに複数のインターフェースを設けておき、メンテナンス時に外部に公開するサービス用のインターフェースとは別のインターフェースからログインしてメンテナンスする方式を掲載します
Note
このようなインターフェースは、"バックLAN" や "管理LAN"、"裏LAN" 等と呼称されますが、本パターンでは "バックLAN" と呼称します。
本パターンでは "バックLAN" を用いた方式について記載します。
構造 (イメージ図)#
本パターンでは、踏み台サーバのプロジェクト間接続方式の構成例 をもとに、 管理用のネットワークの "バックLAN" を作成して、プロジェクト間接続を行う例を記載します。
以下では、踏み台サーバを配備した既存のプロジェクトを 『共通プロジェクト』、実業務を行うプロジェクトを『業務プロジェクト』として、業務プロジェクトの環境を作成し、共通プロジェクトから業務プロジェクトに接続していきます。
プロジェクト | プロジェクト接続 | 用途 |
---|---|---|
プロジェクトA 『共通プロジェクト』 |
接続元 | 踏み台サーバを配置し、インターネットからの接続を1本化 |
プロジェクトB 『業務プロジェクト』 |
接続先 | 各種業務用のシステムを配備。 本パターンでは共通プロジェクトから接続する業務プロジェクトは 1つですが、共通プロジェクトから複数の業務プロジェクトに接続する形態でも本パターンで対応可能です。 |
実装サンプル#
1. 設定の概要#
(1) 実装サンプルで使用する設定値例#
バックLANパターンの実装サンプルでは、以下の設定値例を使用します。
- ネットワーク/サブネット
ネットワーク | ネットワーク名称 | サブネット名称 | サブネット | プロジェクト | 用途 |
---|---|---|---|---|---|
内部ネットワーク1a | cdp-intnet-000 | cdp-subnet-000 | 192.168.0.0/24 | 共通プロジェクト | 踏み台サーバ用 (作成済とします) |
内部ネットワーク1b | cdp3-intnet-031 | cdp3-subnet-031 | 192.168.31.0/24 | 業務プロジェクト | インターネットからのWebアクセス用 |
内部ネットワーク2b | cdp3-intnet-032 | cdp3-subnet-032 | 192.168.32.0/24 | 業務プロジェクト | バックLANからのWebサーバメンテナンス用 |
- 仮想リソース
仮想リソース | IPアドレス | プロジェクト | 備考 |
---|---|---|---|
踏み台サーバ | 192.168.0.6 | 共通プロジェクト | 作成済/グローバルIP割当済とします |
Webサーバ | 192.168.31.x | 業務プロジェクト | IPアドレスは任意とします |
192.168.32.x | 業務プロジェクト | IPアドレスは任意とします | |
外部ネットワーク接続用仮想ルータ | 192.168.31.1 | 業務プロジェクト | 内部ネットワーク1b側のIPアドレス |
プロジェクト間接続用仮想ルータ | 192.168.32.254 | 業務プロジェクト | 内部ネットワーク2b側のIPアドレス |
192.168.0.232 | 業務プロジェクト | 内部ネットワーク1a側のIPアドレス |
(2) 実装サンプルで使用するルーティング設定の概要#
バックLANパターンの実装サンプルでは、バックLAN に配備する仮想サーバ等が、以下の通信を行えるようにするルーティングを設定します。
(A) 設定内容(業務プロジェクト側)#
①接続元の共通プロジェクトの踏み台サーバと通信する設定
接続元の共通プロジェクトにある 踏み台サーバ と通信するために、共通プロジェクトのサブネットからの接続で使用する仮想ルータを設定します。
②仮想サーバの配備等に使用する特別なIPアドレスと通信する設定
仮想サーバの配備等で使用する特別な IPアドレス と通信するための設定を行います。
特別な IPアドレス 169.254.169.254/32 への接続用には、共通プロジェクトのサブネットとの接続で使用する仮想ルータを設定します。
この設定により、ログを集約する 管理サーバ 等の用途の仮想サーバを 内部ネットワーク2b のバックLAN側のみに配備したい場合も、仮想サーバから 169.254.169.254/32 に接続できるため、問題なく仮想サーバをバックLAN側にのみ配備できるようになります。
③上記以外と通信するために必要な設定(デフォルトゲートウェイ)
上記以外への通信を、内部ネットワーク1b に配備する仮想ルータに設定します。
この設定は、デフォルトゲートウェイやデフォルトルート等と呼ばれる設定です。設定する箇所により、呼ばれ方が異なります。
FJcloud-Oのルーティングの設定では、デフォルトゲートウェイ という呼び方を使用しています。
Linux OS上の設定で、ネットワークインターフェイスを設定する箇所では、デフォルトルート と呼ばれます。
上記の内容を、業務プロジェクト側のルーティングとして以下のように設定します。
- ルーティング(業務プロジェクト側)
設定内容 | 宛先アドレス(destination) | 転送先アドレス(nexthop) | ルーティング情報の設定先 |
---|---|---|---|
①接続元の共通プロジェクトの踏み台サーバと通信する設定 | 192.168.0.0/24 | 192.168.32.254 | 内部ネットワーク2bのサブネット |
②仮想サーバの配備等に使用する特別なIPアドレスと通信する設定 | 169.254.169.254/32 | 192.168.32.254 | 内部ネットワーク2bのサブネット |
③デフォルトゲートウエイ | 0.0.0.0/0 | 192.168.31.1 | 内部ネットワーク1bのサブネット |
(B) 設定内容(共通プロジェクト側)#
既存の共通プロジェクト側には、接続先の業務プロジェクトへのルーティングとして、以下の設定を追加します。
- ルーティング(共通プロジェクト側)
設定内容 | 宛先アドレス(destination) | 転送先アドレス(nexthop) | ルーティング情報の設定先 |
---|---|---|---|
接続先の業務プロジェクトの仮想サーバと通信する設定 | 192.168.32.0/24 | 192.168.0.232 | 内部ネットワーク1aサブネット |
2. 作業概要#
(1) 接続先の業務プロジェクトのバックLAN側ネットワーク環境作成#
接続先の業務プロジェクトで、バックLAN側のネットワーク環境を作成します。
本パターンでは、APIでのみ設定できるパラメータを設定してサブネットを作成します。
サブネットの作成に合わせて、(1)で作成する環境はすべて APIで作成します。
-
内部ネットワーク2b作成
共通プロジェクトから接続を受け付ける内部ネットワークを作成します。 -
内部ネットワーク2bにサブネットを作成
内部ネットワーク2bに対してサブネットを APIで作成します。
作成する際には、内部ネットワーク2b 側に デフォルトゲートウェイ が作成されないように、APIで "gateway_ip": null というパラメータを設定します。
この設定を行わない場合、内部ネットワーク2b には、サブネットアドレス内の先頭IPアドレスをデフォルトゲートウェイとしてサブネットが作成されます。
内部ネットワーク2b にデフォルトゲートウェイが設定されると、内部ネットワーク1b と 内部ネットワーク2b の両方に接続する仮想サーバは、両方のネットワークから デフォルトゲートウェイ の設定を受信することになります。
仮想サーバ内部のOSのネットワークインタフェース設定で、デフォルトゲートウェイ を片方のネットワークに設定することにより、デフォルトゲートウェイが重複する問題は解決可能です。
しかしながら、設定ミスを防ぐため、APIでデフォルトゲートウェイをあらかじめ null に設定しておくことを推奨します。 -
プロジェクト間接続用仮想ルータ作成
接続元の共通プロジェクトと接続するプロジェクト間接続用仮想ルータを作成します。 -
仮想ルータ用のポート作成、仮想ルータにポートをアタッチ
プロジェクト間接続用の仮想ルータを、バックLAN側の 内部ネットワーク2b に接続します。
この作業は、IaaSポータルでは、インタフェース追加 の手順に相当します。
(2) プロジェクト間接続#
仮想ルータを用いて、同一ドメイン内で異なるプロジェクトを接続します。
なお、(2) の作業の手順は、共通サービスパターン と同じです。
作業手順は 共通サービスパターン の各手順を参照してください。
設定値例は、(1) 実装サンプルで使用する設定値例 で読み替えてください。
-
接続元の共通プロジェクトでポート作成
接続元の共通プロジェクトの内部ネットワーク上に、プロジェクト間接続用の仮想ルータに割り当てる ポートを作成します。
ポートには、固定で IPアドレスを割り当てます。
作業手順は、共通サービスパターン の (1) ポート作成 を参照してください。 -
仮想ルータにプロジェクト間接続設定
作成したポートを、接続先の業務プロジェクトの仮想ルータに割り当てます。
作業手順は、共通サービスパターン の (2) 業務プロジェクト(接続先) の仮想ルータに 共通プロジェクト(接続元) のポートを割り当て を参照してください。 -
接続元の共通プロジェクトでルーティング設定
ポートに設定している IPアドレスを、接続先の業務プロジェクトのサブネットへ接続するルータのIPアドレス(nexthop)として、ルーティング情報を設定します。
作業手順は、共通サービスパターン の (3) 共通プロジェクト(接続元) のサブネットに 業務プロジェクト(接続先) のサブネットへのルーティングを設定 を参照してください。
Note
ルーティング情報は、ルーティング情報を設定した共通プロジェクトのサブネット上の仮想サーバをリブートすると反映されます。
仮想サーバをリブートできない場合は、仮想サーバ内部でルーティング情報を直接手動で設定してください。
作業手順は、共通サービスパターン の (4) 仮想サーバにルーティング情報を設定 を参照してください。
(3) ファイアーウォール/セキュリティグループ設定#
仮想サーバ等を配備する前に、ファイアーウォールやセキュリティグループの設定を行ってください。
設定に際しては、以下のデザインパターンをご覧ください。
デザインパターン名称 | 説明 |
---|---|
セキュリティグループ活用 | セキュリティグループ のみでアクセス制御するパターンです。 |
セキュリティグループ/ファイアーウォール併用パターン | セキュリティグループ と ファイアーウォール を組み合わせたパターンです。 |
機能別セキュリティグループ | 機能別にアクセス制限をかけるパターンです。 |
(4) 業務プロジェクト上に仮想サーバ作成#
業務プロジェクト上に、Webサーバ等の仮想サーバを適宜作成します。
作成後、共通プロジェクトの踏み台サーバからログインできるようになります。
- 仮想サーバ作成
- 踏み台サーバからログイン
(5) 接続先の業務プロジェクトのWebサーバ用ネットワーク環境作成#
接続先の業務プロジェクトで、Webサーバ用のネットワーク環境を作成します。
作業については、インターネット接続パターン の ネットワークの作成 や、複数ルータ外部接続パターン を参照してください。
設定値例は、(1) 実装サンプルで使用する設定値例 で読み替えてください。
- 内部ネットワーク1b作成
外部から接続を受け付ける内部ネットワークを作成します。 - 外部接続用ルータ作成
- ゲートウェイ設定
仮想ルータで、外部ネットワークと接続する際の設定です。 - インタフェース追加
仮想ルータで、内部ネットワークと接続する際の設定です。
(6) 仮想サーバにネットワークインタフェースを追加#
業務プロジェクトに作成した仮想サーバに、ネットワークインタフェースを追加します。
-
仮想サーバのスナップショットを取得
設定ミスしてしまった場合でも復旧できるように、仮想サーバの スナップショット を取得しておくことを推奨します。 -
仮想サーバの OS 上で、既存インタフェースを修正
仮想サーバにログインして、OS上で、既存の内部ネットワーク2b 側のネットワークインタフェースの設定を修正します。 -
仮想サーバの OS 上で、新規インタフェースを追加
仮想サーバの OS上で、新規に割り当てるの内部ネットワーク1b 側のネットワークインタフェースの設定を追加します。
-
内部ネットワーク1bに仮想サーバ用のポートを作成
内部ネットワーク1bに、仮想サーバ用に割り当てるポートを作成します。 -
仮想サーバにポートをアタッチ
仮想サーバに、作成したポートをアタッチします。
ポートをアタッチ後、OS上でネットワークインタフェースが認識されます。
数分後、アタッチしたポートから、DHCPで、ルーティング情報が仮想サーバに反映されます。 -
仮想サーバの OS 上でルーティングを確認
仮想サーバの OS 上で、ネットワークインタフェースが認識された後で、ルーティング情報を確認します。
ルーティング情報が正しく反映されていることを確認できたら、仮想サーバを再起動して、ログイン後に再びルーティング情報が正しく反映されていることを確認してください。
3. 作業詳細#
(1) 内部ネットワーク2b作成#
以下のAPIに、設定項目(json)を設定して、接続先の業務プロジェクト で実行してください。
- 設定項目(json)
項目 | 設定値例 | 内容 |
---|---|---|
$NETWORK_NAME | "cdp3-intnet-032" | ネットワーク名称(任意) |
$AZ | "jp-east-1b" | "jp-east-1a"、"jp-east-1b" 等 |
- 実行API
curl -s $NETWORK/v2.0/networks -X POST -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"network":{ "name": "'$NETWORK_NAME'", "availability_zone": "'$AZ'"}}' | jq .
(2) 内部ネットワーク2bにサブネットを作成#
以下のAPIに、設定項目(json)を設定して、接続先の業務プロジェクト で実行してください。
- 設定項目(json)
項目 | 設定値例 | 内容 |
---|---|---|
$SUBNET_NAME | "cdp3-subnet-032" | ネットワーク名称(任意) |
$NETWORK_ID | (生成されたID) | 作成したネットワークのID |
$CIDR | "192.168.32.0/24" | サブネットのアドレス(CIDR)形式 |
$DNS | "" | 空の値を設定 |
$AZ | "jp-east-1b" | "jp-east-1a"、"jp-east-1b" 等 |
$HOST_ROUTES | "{\"nexthop\":\"192.168.32.254\",\"destination\":\"192.168.0.0/24\"}, {\"nexthop\":\"192.168.32.254\",\"destination\":\"169.254.169.254/32\"}" |
ルーティング情報 |
- 実行API
curl -s $NETWORK/v2.0/subnets -X POST -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"subnet": {"name": "'$SUBNET_NAME'", "network_id": "'$NETWORK_ID'", "cidr": "'$CIDR'", "dns_nameservers": ['$DNS'], "ip_version": 4, "gateway_ip": null, "availability_zone": "'$AZ'", "host_routes": ['$HOST_ROUTES'] }}' | jq .
(3) プロジェクト間接続用仮想ルータ作成#
以下のAPIに、設定項目(json)を設定して、接続先の業務プロジェクト で実行してください。
- 設定項目(json)
項目 | 設定値例 | 内容 |
---|---|---|
$ROUTER_NAME | "router-032" | 仮想ルータ名称(任意) |
$AZ | "jp-east-1b" | "jp-east-1a"、"jp-east-1b" 等 |
- 実行API
curl -s $NETWORK/v2.0/routers -X POST -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"router": {"name": "'$ROUTER_NAME'", "tenant_id": "'$PROJECT_ID'", "availability_zone": "'$AZ'"}}' | jq .
(4) 仮想ルータ用のポート作成#
以下のAPIに、設定項目(json)を設定して、接続先の業務プロジェクト で実行してください。
- 設定項目(json)
項目 | 設定値例 | 内容 |
---|---|---|
$PORT_NAME | "cdp3-subnet-032-192_168_32_254" | ポート名称(任意) |
$NETWORK_ID | (生成されたID) | 仮想ルータにアタッチするネットワークID |
$SUBNET_ID | (生成されたID) | 仮想ルータにアタッチするサブネットID |
$FIXED_IP_ADDRESS | "192.168.32.254" | ポートに設定するIPアドレス |
$SG_ID | (生成されたID) | ポートに設定するセキュリティグループID |
$AZ | "jp-east-1b" | "jp-east-1a"、"jp-east-1b" 等 |
- 実行API
curl -s $NETWORK/v2.0/ports -X POST -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"port":{"network_id": "'$NETWORK_ID'", "name": "'$PORT_NAME'", "availability_zone": "'$AZ'", "fixed_ips": [{"subnet_id": "'$SUBNET_ID'", "ip_address": "'$FIXED_IP_ADDRESS'"}], "security_groups": ["'$SG_ID'"] }}' | jq .
(5) 仮想ルータにポートをアタッチ#
以下のAPIに、設定項目(json)を設定して、接続先の業務プロジェクト で実行してください。
- 設定項目(json)
項目 | 設定値例 | 内容 |
---|---|---|
$ROUTER_ID | (生成されたID) | 作成した仮想ルータのID |
$PORT_ID | (生成されたID) | 作成したポートのID |
- 実行API
curl -s $NETWORK/v2.0/routers/$ROUTER_ID/add_router_interface -X PUT -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"port_id": "'$PORT_ID'" }' | jq .
(6) 仮想サーバにログインして、ネットワークインタフェースを設定#
仮想サーバが Linux 系の場合は、仮想サーバにログインして、ネットワークインタフェースを設定します。
なお、仮想サーバが Windows 系の場合は、仮想サーバにポートをアタッチした時点で OS 上でネットワークインタフェースが追加されるため、以下の手順は不要です。
-
ネットワークインタフェースをコピー
cp -pi /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth1
-
既存のネットワークインタフェース ifcfg-eth0 を修正
vi /etc/sysconfig/network-scripts/ifcfg-eth0
変更/削除 | 変更前 | 変更後 |
---|---|---|
DEVICE=eth0 | DEVICE=eth0 | |
TYPE=Ethernet | TYPE=Ethernet | |
UUID=ff971b7a-c2a0-4bc3-827a-5ea0e3e86161 | UUID=d837e0ee-0017-45dd-991d-e8409c118749 | |
ONBOOT=yes | ONBOOT=yes | |
NM_CONTROLLED=no | NM_CONTROLLED=no | |
BOOTPROTO=dhcp | BOOTPROTO=dhcp | |
変更 | DEFROUTE=yes | DEFROUTE=no |
変更 | PEERDNS=yes | PEERDNS=no |
PEERROUTES=yes | PEERROUTES=yes | |
IPV4_FAILURE_FATAL=yes | IPV4_FAILURE_FATAL=yes | |
IPV6INIT=yes | IPV6INIT=yes | |
IPV6_AUTOCONF=no | IPV6_AUTOCONF=no | |
DHCPV6C=yes | DHCPV6C=yes | |
変更 | IPV6_DEFROUTE=yes | IPV6_DEFROUTE=no |
IPV6_FAILURE_FATAL=no | IPV6_FAILURE_FATAL=no | |
NAME="System eth0" | NAME="System eth0" |
- ifcfg-eth0 をコピーして新規に作成したネットワークインタフェース ifcfg-eth1 を修正
vi /etc/sysconfig/network-scripts/ifcfg-eth0
変更/削除 | 変更前 | 変更後 |
---|---|---|
変更 | DEVICE=eth0 | DEVICE=eth1 |
TYPE=Ethernet | TYPE=Ethernet | |
削除 | UUID=ff971b7a-c2a0-4bc3-827a-5ea0e3e86161 | |
ONBOOT=yes | ONBOOT=yes | |
NM_CONTROLLED=no | NM_CONTROLLED=no | |
BOOTPROTO=dhcp | BOOTPROTO=dhcp | |
DEFROUTE=yes | DEFROUTE=yes | |
PEERDNS=yes | PEERDNS=yes | |
PEERROUTES=yes | PEERROUTES=yes | |
IPV4_FAILURE_FATAL=yes | IPV4_FAILURE_FATAL=yes | |
IPV6INIT=yes | IPV6INIT=yes | |
IPV6_AUTOCONF=no | IPV6_AUTOCONF=no | |
DHCPV6C=yes | DHCPV6C=yes | |
IPV6_DEFROUTE=yes | IPV6_DEFROUTE=yes | |
IPV6_FAILURE_FATAL=no | IPV6_FAILURE_FATAL=no | |
変更 | NAME="System eth0" | NAME="System eth1" |
(7) 内部ネットワーク1bに仮想サーバ用のポートを作成#
以下のAPIに、設定項目(json)を設定して、接続先の業務プロジェクト で実行してください。
- 設定項目(json)
項目 | 設定値例 | 内容 |
---|---|---|
$PORT_NAME | "PORT_VM_192_168_31_x" | ポート名称(任意) |
$NETWORK_ID | (生成されたID) | 仮想サーバにアタッチするネットワークID |
$SUBNET_ID | (生成されたID) | 仮想サーバにアタッチするサブネットID |
$FIXED_IP_ADDRESS | "192.168.31.x" | ポートに設定するIPアドレス |
$SG_ID | (生成されたID) | ポートに設定するセキュリティグループID |
$AZ | "jp-east-1b" | "jp-east-1a"、"jp-east-1b" 等 |
- 実行API
curl -s $NETWORK/v2.0/ports -X POST -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"port":{"network_id": "'$NETWORK_ID'", "name": "'$PORT_NAME'", "availability_zone": "'$AZ'", "fixed_ips": [{"subnet_id": "'$SUBNET_ID'", "ip_address": "'$FIXED_IP_ADDRESS'"}], "security_groups": ["'$SG_ID'"] }}' | jq .
(8) 仮想サーバにポートをアタッチ#
以下のAPIに、設定項目(json)を設定して、接続先の業務プロジェクト で実行してください。
- 設定項目(json)
項目 | 設定値例 | 内容 |
---|---|---|
$SERVER_ID | (生成されたID) | 作成した仮想サーバのID |
$PORT_ID | (生成されたID) | 作成したポートのID |
- 実行API
curl -s $COMPUTE/v2/$PROJECT_ID/servers/$SERVER_ID/os-interface -X POST -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{ "interfaceAttachment": {"port_id": "'$PORT_ID'" }}' | jq .
(9) 仮想サーバの OS 上でルーティングを確認#
仮想サーバの OS 上で、ネットワークインタフェースが認識された後で、 /sbin/route
コマンド等でルーティング情報を確認します。
その他、 nslookup
コマンドで DNS の確認や、 yum
コマンドで httpアクセスの確認等を行ってください。
コマンドの確認結果が問題なければ、仮想サーバを再起動してログインし、確認用のコマンドで再度正常に設定できたか確認してください。
- 仮想サーバの OS 上でルーティングの確認例
[k5user@web_server ~]$ /sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 169.254.169.254 192.168.32.254 255.255.255.255 UGH 0 0 0 eth0 192.168.32.0 * 255.255.255.0 U 0 0 0 eth0 192.168.0.0 192.168.32.254 255.255.255.0 UG 0 0 0 eth0 192.168.31.0 * 255.255.255.0 U 0 0 0 eth1 default 192.168.31.1 0.0.0.0 UG 0 0 0 eth1 [k5user@web_server ~]$
メリット・効果#
本パターンを利用して、外部公開用とは別のインターフェースを設けた場合のメリット・効果は以下の通りです。
- システムへのログイン経路をサービス用と分離することで、高いセキュリティを実現可能
- 外部公開用のインターフェースに対する設定を行わないことで、設定ミスを無くす等、運用面での安全性の向上が可能
注意事項#
-
本パターンは2017年5月時点のFJcloud-O 東日本/西日本リージョン1・2で動作検証しています。
-
ログイン用のネットワークに通信が流れるよう、ルーティングの設定が必要となります。
-
仮想サーバのインターフェースを分けても、スループットは向上しないため、性能向上の目的では使用できません。
その他#
接続元のプロジェクトに仮想ルータがある構成について#
以下のイメージ図は、構造 (イメージ図) と異なり、接続元の共通プロジェクトの方に仮想ルータを配備したイメージ図です。
仮想ルータをプロジェクト間接続するプロジェクトのどちらに配備するかについては、共通サービスパターン の その他 を参照してください。