10/12/2013

Windows Azureのリージョン間でVPN接続してみた

 

前回「Windows Azureの地域間VPNを試してみた(始めの調査編)」では、Windows Azureのデータセンター間で双方向に通信することができませんでしたが、今回は双方向通信を実現する構成の紹介です。(2013年10月7日のWindows Azure機能で構築してます)

1.構成

Windows AzureのEast Asia、West Asiaにそれぞれ仮想ネットワークのゲートウェイを作成しています。それぞれのデータセンタからは、Linux(Ubuntu)で相互に各地域のゲートウェイにVPNトンネルを接続しています。

network-design01

前回の調査結果からこのような構成になりました。現段階ではVPNトンネルを2つ用意して確認しています。

また、Linux(Ubuntu)のVPNゲートウェイで、相手のネットワークからの通信をNAT(MASQUERADE)しています。例えば、vn-asia-vmからvn-us-vmへの通信は、vn-us-gwでNATされています。

network-design02

 

2.作成した仮想ネットワーク

仮想ネットワークは構成の通り、East AsiaとWest USの2つです。

network

それぞれの仮想ネットワークに存在するゲートウェイに接続するローカルネットも作成します。これらのローカルネットは仮想ネットワークのネットワークアドレスと同じ範囲になってしまいますが問題ありません。

localnetwork

3.各地域の仮想マシン

始めに作成した仮想マシンは構成と同じように4台作成しました。この4台はLinux(Ubuntu)のVPN2台(vn-asia-ge, vn-us-gw)と、通信テスト用の仮想マシン2台(vn-sia-vm, vn-us-vm)です。

vms

East Asiaのゲートウェイ

エンドポイントでは、IPSec NAT Traversal用のUDPポートの設定を行います。ISAKMPのUDP 500ポートと、IPSec NAT TraversalのUDP 4500ポートを、vn-asia-vmに向けています。

vn-asia-gw

East Asiaの通信テスト用仮想マシン

vn-asia-vm

West USのゲートウェイ

エンドポイントでは、IPSec NAT Traversal用のUDPポートの設定を行います。ISAKMPのUDP 500ポートと、IPSec NAT TraversalのUDP 4500ポートを、vn-us-vmに向けています。

vn-us-gw

West USの通信テスト用仮想マシン

vn-us-vm

4.各地域の仮想ネットワーク

East Asiaの仮想ネットワークです。仮想マシンがネットワーク上にいることが確認できます。作成したゲートウェイはStatic Routingです。

vn-asia-dashboard

West USの仮想ネットワークです。仮想マシンがネットワーク上にいることが確認できます。作成したゲートウェイはStatic Routingです。

vn-us-dashboard

5.各地域のLinux(Ubuntu)VPN仮想マシン設定

各地域の通信確認用仮想マシンの設定は特に説明しませんが、通信確認する際は下記のコマンドでファイアウォールのルールを削除しておくと便利です。

$sudo iptables –F

5.1.まずは、East Asia側のVPN仮想マシン

5.1.1.VPNの設定

Open Swanのインストール。

$sudo apt-get install openswan

IPSecの設定です。ipsec.conは変更箇所だけ編集して、最後の行にincludeの行を挿入します。

$sudo vi /etc/ipsec.conf
config setup
      protostack=netkey
      nat_traversal=yes
      virtual_private=%v4:10.20.0.0/16
      oe=off
include /etc/ipsec.d/*.conf

$sudo vi /etc/ipsec.d/azure-us.conf
conn azure-us
   authby=secret
   auto=start
   type=tunnel
   left=10.20.0.4
   leftsubnet=10.20.0.0/16
   leftnexthop=%defaultroute
   right=168.61.64.182
   rightsubnet=10.10.0.0/16
   ike=aes128-sha1-modp1024
   esp=aes128-sha1
   pfs=no

IPSecの鍵設定をします。鍵はWindows Azureの仮想ネットワークのダッシュボードから取得します。

$sudo vi /etc/ipec.secrets
10.20.0.4 168.61.64.182 : PSK "krOurXxXX6XxXXX7xxxwnXXXXXaLkXXX"

$sudo vi /etc/sysctl.conf
net.ipv4.ip_forward=1
$sudo sysctl -p /etc/sysctl.conf
$sudo service ipsec restart

5.1.2.ファイアウォールとNATの設定

VPNの設定が終わったら、ファイアウォールとNATの設定をします。今回使用しているLinuxはUbuntuですので、Ubuntuのお作法にのっとってiptablesの設定をします。

https://help.ubuntu.com/lts/serverguide/firewall.html

まずは、ファイアウォール設定から。SSH用のポート設定は重要です。この設定をしないとLinux(Ubuntu)にアクセスできなくなります。(一回やってしまった)

$sudo ufw allow proto tcp to any port 22
$sudo ufw allow proto udp to any port 500
$sudo ufw allow proto udp to any port 4500

つぎにNAT(MASQUERADE)の設定です。VPNの設定でOSのIPフォワード設定をしましたが、ここではファイアウォール側のフォワード設定を行います。

$sudo vi /etc/default/ufw
DEFAULT_FORWARD_POLICY="ACCEPT"

次にNATの設定を行います。以下の設定をファイルのトップに書いてください。

$sudo vi /etc/ufw/before.rules

# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic from eth1 through eth0.
-A POSTROUTING -s 10.10.0.0/16 -o eth0 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT

さいごにファイアウォールを有効にします。

$sudo ufw disable && sudo ufw enable

5.2.次に、West USの設定


5.2.1.VPNの設定


Open Swanのインストール。


$sudo apt-get install openswan


IPSecの設定です。ipsec.conは変更箇所だけ編集して、最後の行にincludeの行を挿入します。


$sudo vi /etc/ipsec.conf
config setup
      protostack=netkey
      nat_traversal=yes
      virtual_private=%v4:10.10.0.0/16
      oe=off
include /etc/ipsec.d/*.conf


$sudo vi /etc/ipsec.d/azure-asia.conf
conn azure-asia
   authby=secret
   auto=start
   type=tunnel
   left=10.10.0.4
   leftsubnet=10.10.0.0/16
   leftnexthop=%defaultroute
   right=207.46.137.55
   rightsubnet=10.20.0.0/16
   ike=aes128-sha1-modp1024
   esp=aes128-sha1
   pfs=no


IPSecの鍵設定をします。鍵はWindows Azureの仮想ネットワークのダッシュボードから取得します。


$sudo vi /etc/ipec.secrets
10.10.0.4 207.46.137.55 : PSK "krOurXxXX6XxXXX7xxxwnXXXXXaLkXXX"


$sudo vi /etc/sysctl.conf
net.ipv4.ip_forward=1
$sudo sysctl -p /etc/sysctl.conf
$sudo service ipsec restart


5.2.2.ファイアウォールとNATの設定


VPNの設定が終わったら、ファイアウォールとNATの設定をします。


まずは、ファイアウォール設定から。SSH用のポート設定は重要です。この設定をしないとLinux(Ubuntu)にアクセスできなくなります。


$sudo ufw allow proto tcp to any port 22
$sudo ufw allow proto udp to any port 500
$sudo ufw allow proto udp to any port 4500


つぎにNAT(MASQUERADE)の設定です。VPNの設定でOSのIPフォワード設定をしましたが、ここではファイアウォール側のフォワード設定を行います。


$sudo vi /etc/default/ufw
DEFAULT_FORWARD_POLICY="ACCEPT"


次にNATの設定を行います。以下の設定をファイルのトップに書いてください。


$sudo vi /etc/ufw/before.rules


# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]


# Forward traffic from eth1 through eth0.
-A POSTROUTING -s 10.20.0.0/16 -o eth0 -j MASQUERADE


# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT


さいごにファイアウォールを有効にします。

$sudo ufw disable && sudo ufw enable

6.Windows Azureの地域に分かれる仮想ネットワーク間で通信してみる


Pingで確認してみます。まずは、East Asiaのvn-asia-vmからWest USのvn-us-vmに通信します。


vn-asia-vm-ping


通信できますね。次はWest USのvn-us-vmからEast Asiaのvn-asia-vmに通信します。


vn-us-vm-ping


問題なく通信できますね。


7.最後に


Windows Azureの機能では、地域間VPNの機能がありませんが、自分でVPNを動かせばVPNトンネルを使った通信ができることがわかりました。次は、SQL ServerとかActive Directoryとかを拠点間で動かしてみたいですね。

10/06/2013

Windows Azureの地域間VPNを試してみた(始めの調査編)

 

Windos Azureの地域間VPN接続を試してみましたが、仮想ネットワークの動きを知らないと構築しにくいと思いますので、とりあえずメモしてきます。構成の設定を順に紹介していきます。

始めの調査ということで、今回は失敗した記事となっています。。。

 

1.始めに考えた構成

Windows AzureのEast AsiaにGatewayを作成し、West USからはlinuxのopenswanを使用したVPN GatewayでEast AsiaのGatewayにIPSecでVPN接続する構成です。

azurevpn

 

2.仮想ネットワーク設定


East Asia側の仮想ネットワークはvn-asiaとして作成ました。West US側の仮想ネットワークはvn-usとして作成しています。

nv-networks

また、vn-asiaとvn-usをサイト間接続するため、East Asia側ゲートウェイの先にあるWest USのネットワークを、ローカルネットワークとしてvn-local-usとして作成しています。

nv-localnetworks

 

East Asia側のネットワーク設定

East Asia側のネットワーク設定では、ゲートウェイ作成と、仮想ネットワークアドレス空間の設定、ローカルネットワークの指定を行います。ここで指定するローカルネットワークはWest US側のアドレス空間です。(構築後の設定を見ていますので、VPNとしては繋がってます)

nv-asia-dashboard 


nv-asia-config

 

West US側のネットワーク設定

West US側のネットワーク設定では、仮想ネットワークアドレス空間の設定だけを行っています。

nv-us-dashboard
nv-us-config

 

3.West US側VPN Gatewayの作成

VPN Gateway として利用するUbuntuのlinux仮想マシンをWest USの仮想ネットワークに作成します。

nv-us-vm-gw-os

nv-us-vm-gw

linuxにsshでログインした後に、openswanのインストールと設定をします。以下のコマンドでインストールおよび設定、サービスの起動を行います。viコマンドの下に書かれている行は変更内容です。/etc/ipec.secretsの設定には、East Asiaのゲートウェイアドレスとキーを設定します。

 

$sudo apt-get install openswan
$sudo vi /etc/ipsec.conf
config setup
      protostack=netkey
      nat_traversal=yes
      virtual_private=%v4:10.0.0.0/16
      oe=off
include /etc/ipsec.d/*.conf

$sudo vi /etc/ipsec.d/azure-asia.conf
conn azureasia
   authby=secret
   auto=start
   type=tunnel
   left=10.10.0.4
   leftsubnet=10.10.0.0/16
   leftnexthop=%defaultroute
   right=207.46.137.55
   rightsubnet=10.20.0.0/16
   ike=aes128-sha1-modp1024
   esp=aes128-sha1
   pfs=no

$sudo vi /etc/ipec.secrets
10.10.0.4 207.46.137.55 : PSK "krOurXxXX6XxXXX7xxxwnXXXXXaLkXXX"

$sudo vi /etc/sysctl.conf
net.ipv4.ip_forward=1
$sudo sysctl -p /etc/sysctl.conf
$sudo service ipsec restart

 

エンドポイントでは、IPSec NAT Traversal用のUDPポートの設定を行います。ISAKMPのUDP 500ポートと、IPSec NAT TraversalのUDP 4500ポートを、VPN Gatewayのlinuxの仮想マシンに向けます。

 

nv-us-vpngw-endpoint

 

4.通信確認


地域間でVPNを使用した通信に問題がないか確認してみます。今回はそれぞれの地域に確認用サーバのlinuxを作成してみました。East AsiaのUbuntuは以下のようになります。あと、標準でlinuxのファイアウォール設定がされているので注意してください。簡単に外す場合は、以下のコマンドです。

$sudo iptables –F

nv-asia-vm-srv

 

West USの確認用サーバのlinuxは以下のような感じです。East Asiaの確認用サーバと同じようにファイアウォール設定に注意してください。あと、VPN経由で通信するために、スタティックルートの設定をします。簡単に設定する場合は以下のコマンドです。

 

$sudo route add -net 10.20.0.0/16 gw 10.10.0.4

 

nv-us-vm-srv

 

 

West USのVPN GatewayからEast Asiaのサーバにアクセス

まずは、West USのlinuxのVPN GatewayからEast Asiaの確認用linuxにPingしてみます。

nv-asia-vpngw

  Pingの応答があるのですが念のためにEast Asiaの確認用linuxにPingのicmpパケットが届いているかtcpdumpで確認してみます。

問題なさそうですね。行きと帰りでパケットが通っているようです。

  nv-srv-asia-tcmdump

 

West USとEast Asia間のlinuxで通信確認

確認してみましたが通信できませんでした。以下はtcpdumpした内容です。

West USからEast Asiaに通信

West USのlinux

ua00

West USのVPN Gateway

ua01

East Asiaのlinux

ua03

 

East AsiaからWest USに通信

East Asiaのlinuxのtcpdump

au00

West USのVPN Gatewayのtcpdump

au01

West USのlinuxのtcpdump

au02

 

5.まとめ

West USのネットワークでは、設定したアドレスの範囲外アドレスがIPヘッダの送信元か送信先に含まれると、仮想ネットワーク内でドロップしています。ここからは推測ですが、これは仮想ネットワークで管理されていないIPアドレスが含まれているため、ホストの仮想スイッチでドロップしているのではないかと考えています。Hyper-Vのネットワーク仮想化と同じ動きだとも考えています。

East Asiaではローカルネットワークとして登録しているのでGatewayを通って、West USのVPN Gatewayまではパケットが流れていますね。AzureでNew-NetVirtualizationCustomerRoutのようなPSコマンドが欲しいです。

動きがわかれば、対策は立てられるので、次回は地域間で通信できる構成を紹介する予定です。

あと、Hyper-Vのネットワーク仮想化に関しては、後藤さんのnvgreの資料を参考にしました!ありがとうございます。