Active Directory サーバを AWS 上に設置して VPN セッションを張ったものの、BGP セッションが確立せず。

同時に GCP (Google Cloud Platform) での VPN を同時に試しており、GCP VPN の方が実はいいんじゃないかと思い始めました。

GCP / AWS とで VPC の考え方的に似ている部分、異なる部分と、RTX1200 での具体的な IPsec VPN 設定 + 2リージョン上に AD を置いた場合の構成、ハマるポイントについて。

GCP 東京リージョンに Active Directory を置いてみよう

GCP は Amazon でいう AWS と同様に、Google のネットワーク、サーバインフラをユーザが使えるようにしたクラウドコンピューティングプラットフォームです。AWS は 2006年、GCP は 2008年にサービス開始で、時期的にそれほど違わないように見えます。

しかし GCP はサービスを提供する SaaS, PaaS も含めた各種サービスの総称ですが、OS から上が好きに使える IaaS である GCE (Google Compute Engine) がサービス開始したのは 2013年でかなり出遅れていました。

仕事でもオンプレか AWS 一辺倒だったのですが、日本国内のリージョン (東京リージョン) が昨年 2016年10月に選択できるようになり。このビッグウェーブに乗るしかない 🙂 ってことで、AWS と GCP を並行していろいろ試しています。

AWS の場合のおさらいから

オンプレにない概念として、AWS にも GCP にも VPC (仮想プライベートクラウド) があります。

AWS - 自宅 LAN 間の VPN

複数のサブネットを含んだ最も外周部分とでも言えばいいでしょうか。

オンプレだとインターネットに出ていくためのゲートウェイや、オンプレに対して VPN の口を開くための VPN ゲートウェイも、あるサブネット上にあるルータがやるから、特定のサブネットに属するような気がしますが、AWS でも GCP でも VPC に対してゲートウェイが設けられます。

サブネットは、AZ (アベイラビリティゾーン) ごとに別個に切ることができ、地理的に離れたデータセンター 1つ1つをサブネットで区切ったうえで、その中にサーバを設置するというのがよくあるパターンですね。さらに、同一 AZ をパブリック / プライベートサブネットの 2つに分割することも行われます。

GCP でもサブネット構成にする意味はあるのか

GCP でも同じように　VPC とサブネットを切ってみました。GCP 本来の使い方とはなんか違う気がしますが。

GCP - 自宅 LAN 間の VPN

GCP には当初 VPC を複数サブネットに分割することはできなかったようですね。

GCEのSubNetwork対応による、変更点とAWSとの違いによると、

ローカルIPアドレスの CIDRだけ指定する
そのCIDRは全リージョンにまたがる

むしろリージョンを挟んでシームレスに同一サブネットとして扱うことができることの方が画期的ですよね。だって大陸間で 1つのサブネットですぜ。自前でヨーロッパとアメリカのどこかと日本と拠点ごとにルータ置いてくりゃそりゃ論理的にはできますが、とにかくスケールがデカい。

ただし、内部 IP アドレス経由の通信料金体系を見ると、

  • 同一リージョン内、同一ゾーン … 無料
  • 同一リージョン内のゾーン間 … $0.01 / GB
  • 大陸間下り … インターネット下り料金に準拠

と、論理的に同一サブネットでも、物理的に離れるほどじわじわ料金がかかることには変わりないわけです。

一方 Active Directory のアーキテクチャ上、離れた拠点間に AD サーバを置く場合、「サイト」という概念があって、サブネット単位でネットワークを区切り、どのサイト間で通信し AD 同士を同期するか、をコントロールできると。

実際にセットアップした後の状態ですが、us-west, asia-northeast をそれぞれ別個のサイトとして定義してあります。

Active Directory on GCP: Site and Services

これとオンプレ側のローカルサイトと、AD x 3台程度じゃサイトもなにも総当たりで同期するしかないでしょって感じですが、結局、台数が増えると、コスト面でジオグラフィカルに ((地理学的に)) サブネットを切るしかなくなるのです。

RTX1210 の設定

実際にヤマハ RTX1210 で動いている設定をさらすと、こんな感じ。
IP アドレスは、図に合わせて変えてあります。

Tunnel 設定

### TUNNEL 3 ###

tunnel select 3
 ipsec tunnel 203
  ipsec sa policy 203 3 esp aes-cbc sha-hmac
  ipsec ike version 3 2
  ipsec ike always-on 3 on
#  ipsec ike duration ipsec-sa 3 3600
  ipsec ike encryption 3 aes-cbc
  ipsec ike group 3 modp1024
  ipsec ike hash 3 sha
  ipsec ike keepalive log 3 on
  ipsec ike keepalive use 3 on icmp-echo 
# ipsec ike local address should be local, otherwise bgp does not work
  ipsec ike local address 3 192.168.0.1
# ipsec ike local name must be GLOBAL!, otherwise ipsec does not work
  ipsec ike local name 3 11.22.33.44 ipv4-addr
#  ipsec ike local id 3 192.168.0.1
  ipsec ike nat-traversal 3 on

  ipsec ike pfs 3 on
  ipsec ike pre-shared-key 3 text <あらかじめ設定した pre-shared-key>
  ipsec ike remote address 3 55.66.77.88
  ipsec ike remote name 3 55.66.77.88 ipv4-addr
  ipsec auto refresh 3 on
# ipsec tunnel outer df-bit clear

 ip tunnel tcp mss limit auto
 tunnel enable 3

NAT 設定

nat descriptor type 2 masquerade
## Outer address is provided automatically by ipcp
nat descriptor address inner 2 192.168.0.1-192.168.0.254

nat descriptor masquerade static 2 16 192.168.5.1 udp 500
nat descriptor masquerade static 2 17 192.168.5.1 udp 4500

BGP は結局検証しきれなかったので、今は使っていません。

以下、設定上のポイントです。

トンネル両端のアドレス指定は不要

  ip tunnel address 169.254.xxx.yyy/30
  ip tunnel remote address 169.254.zzz.www

AWS VPN でダウンロードした RTX 向け定義ファイルでは明示的に tunnel 両端のアドレスを指定するようになっていましたが、GCP VPN では不要でした。

rfc4306 による keepalive はうまく動作しない

Compute Engine ドキュメントでは、IKEv1 でも IKEv2 でも使用可能になっています。Cisco ルータ向けガイドでは IKEv2 の例が書いてありますね。

IKEv2 の方が相互接続性は向上することにはなっているので、v2 でまあ試すとして、ヤマハルータの ipsec コマンド体系では、keepalive の方法も IKEv2 (RFC4306) 準拠の方法を使うのがもっとも自然に思えます。

  ipsec ike keepalive use 3 on rfc4306

しかし結果からいうと、1日程度放置しておくと、セッションは切れてしまうようです。

じゃあこのように、トンネルのリモート側に付与された IP アドレスを目がけて icmp-echo を打てばいいのかというと、

  ipsec ike keepalive use 3 on icmp-echo 169.254.zzz.www

これもまた応答しないようで意味なし。

結局、VPC 内の任意のサーバ (ここでは ads-asia-northeast1) で、ファイアウォールルール的に icmp パケットを受けられるように設定して、それ目がけて icmp-echo を打つという原始的な方法を取り、keepalive は一応安定動作するようにはなりました。

  ipsec ike keepalive use 3 on icmp-echo 10.10.1.100

ipsec ike local address はプライベートアドレス

NAT Traversal を利用している場合は、の話です。AWS の場合と同様、local address にはグローバル IP アドレスではなく、

  ipsec ike local address 3 11.22.33.44

プライベート IP アドレスの方を記述する必要があります。

  ipsec ike local address 3 192.168.0.1

ipsec ike local name はグローバルアドレス

ipsec ike local address がプライベートアドレスだったら、
ipsec ike local name も同じだろう

と思いますが、実際にはさにあらずで、こちらはグローバルアドレスを書く必要がありました。

  ipsec ike local name 3 11.22.33.44 ipv4-addr

GCP の方が、設定は簡素だがパワフル

GCP VPN の印象として、AWS のようにルータのオススメ定義ファイルが落ちてくるような親切ウィザードはありません。IPsec の pre-shared-key も自分で生成して貼り付ける必要があります。

逆に AWS VPN で「カスタマーゲートウェイ」「仮想プライベートゲートウェイ」「VPN 接続」と、AWS が決めた部品を 1つずつ積み上げないとつながらない感が GCP にはあまりなく、より少ない画面数で率直に VPN 接続が作成できるシンプル感があって、美徳だと思いますね。

全体に手作業感満載なのを割り引いても、ネットワーク設計自体がダイナミックにスケールするようにできているのが大きな魅力だと思いました。

そして自宅サーバからは (ほとんど) 誰もいなくなった

現状 Nire.Com の Active Directory は asia-northeast1 と us-west1 の 2リージョン間で同期して動いています。
ads-local は、上記 2台の AD がめでたく動くようになったことを確認してお払い箱にしました。

かくして 1994年以来 (typo じゃないぞ、インターネット黎明期からですよ)、動いていた歴史ある自宅サーバ群は、DNS, mail, AD 含めてすべてクラウド上に転出済。

なんか寂しいというか、感慨深いものがあります。

そして最後に ReadyNAS Ultra6 Plus とか、torne などのストレージサーバが動いているだけになっています。他にまだブログネタにしていない色々 AWS, GCP に分散して動いているサーバがありますが、それはまた書くとして。