Compnet

仕事とか遊びとか、日々折々

2017-01-16(月)

YAMAHA RTX で Azure と VPN 接続する

Posted by Nakane, R. in technical   

Note

本記事には後日改めて検証した記事があります。

インターネット接続や拠点間を繋ぐ VPN 接続などで利用するブロードバンド ルーターとして、大抵の場合、筆者は YAMAHA RTX シリーズを提案しています。 廉価な割に高い性能と壊れにくさがあり、更に古い機種にまでファームウェアを無償で提供していただけたり、ユーザー同士の活発な交流の場の存在など、総合的な安心感がその理由です。 無線 LAN アクセスポイントや L2 スイッチのラインナップも少しずつですが充実しつつあり、中小企業向けのネットワーク機器の全てを YAMAHA 製品だけで提案できるようになるのもそんなに遠い時期では無いのでは、と考えたりするくらいです。

とまあ、ヤマハ サウンドネットワーク事業部の太鼓持ちはこれくらいにして、本題の YAMAHA RTX シリーズで Microsoft Azure の仮想ネットワーク ゲートウェイへの接続を試みた結果を、ここに記録しておきます。

結論から先に書くと、本来の意味での正しく通信できるには至りませんでした。 しかしそれでも試行錯誤の末に、実際の運用でも堪えられそうな設定を探り当てられた気がします。 若干奇をてらった方法かもしれませんが、現時点では最善の方法ではないでしょうか。

Azure の仮想ネットワーク ゲートウェイでは「ルート ベース」を使用します。 「ルート ベース」であれば複数の拠点と接続できますが、もう一つの「ポリシー ベース」では一箇所としか接続できません。 このため実際の運用では「ルート ベース」の採用が大多数だと思います。 また「ポリシー ベース」との接続であれば、YAMAHA の Web サイトに設定例が公開されているので、改めて検証することもないでしょう。

検証に利用した RTX の機種とファームウェアのバージョンは以下の通りです。 これ以外の機種やバージョンでも同様だと思います。

  • RTX1200 Rev.10.01.65
  • RTX1200 Rev.10.01.71
  • RTX810 Rev.11.01.28
  • RTX810 Rev.11.01.25

とりあえず VPN トンネルを確立する

以下は Azere の仮想ネットワーク ゲートウェイとの VPN トンネルを確立するための RTX の設定です。 なお、経路情報などのトンネル確立に直接関係ない箇所は省略しています。 この例では、トンネルの番号に 100 を、トンネルの割り当てる IPsec の SA ポリシーの番号に 1100 を、IPsec SA ポリシーが使用する IKE のゲートウェイの番号に 100 を使っていますが、これらの番号は適宜変更してかまいません。 なお、この設定のままでは VPN トンネルの確立からしばらくは大丈夫ですが、数時間ほどで VPN トンネルを通る通信がまったくできなくなります。 この数時間で通信できなくなる現象を、どのようにして解決するかが、本記事の主眼です。

    :
tunnel select 100
 ipsec tunnel 1100
  ipsec sa policy 1100 100 esp anti-replay-check=off
  ipsec ike version 100 2
  ipsec ike keepalive log 100 off
  ipsec ike keepalive use 100 on
  no ipsec ike local address 100
  ipsec ike local name 100 <LAN側IPアドレス> ipv4-addr
  ipsec ike nat-traversal 100 on
  ipsec ike pre-shared-key 100 text <事前共有鍵>
  no ipsec ike remote address 100
  ipsec ike remote name 100 <AzureゲートウェイIPアドレス> ipv4-addr
  ipsec auto refresh 100 on
 ip tunnel tcp mss limit 1350
 tunnel enable 100
tunnel select none
    :

この設定の要点を簡単にまとめておきます。 まずは、Azure 仮想ネットワーク ゲートウェイとの VPN トンネルで使用する IPsec が IKEv2 なので、ipsec ike version2 を指定します。

ipsec ike keepalive useon にします。 on に加えて dpd を追加した設定を見かけることがありますが、IKEv2 では on だけの指定と on dpd は同じ意味です。 ところで、ipsec ike keepalive use 自体を省略したり、off を指定していても、VPN 接続は確立するように見えます。 しかしこの場合は、確立したように見えるだけで、それを介した通信はできません。 このときのルーターが保持するセキュリティ アソシエーション (SA) を見ると、通常であれば IKE SA が 1 つと IPsec SA が 1 組の 計 3 つ (最大でも更新時に新旧二組の計 6 つ) が作成されるだけのところが、数十以上の IPsec SA が延々と作成される様子がみられます。

ipsec ike local address は指定しません。 上では明示的に no ipsec ike local address としました。 指定しても構いませんが、その場合は RTX の LAN 側インターフェースに割り当てた IP アドレスを指定します。 RTX に割り当てられたグローバル IP アドレスでも良さそうな気がしますが、これだとなぜか VPN トンネルの接続が確立しません。

ipsec ike local name には RTX の LAN 側インターフェースに割り当てた IP アドレスを指定します。 ID の種類には ipv4-addr を指定します。

ipsec ike pre-shared-key には Azure の仮想ネットワーク ゲートウェイで接続を作るときに指定したのと同じ事前共有鍵 (PSK) を指定します。

ipsec ike remote name には Azure の仮想ネットワーク ゲートウェイに割り当てられたグローバル IP アドレスを指定します。 ID の種類には ipv4-addr を指定します。 これに伴い、ipsec ike remote address は不要になります。 上では明示的に no ipsec ike remote address としましたが、指定してあっても特に問題はありません。。

ip tunnel tcp mss limit は VPN トンネルの接続の確立とは関係ありませんが、これを 1350 にしておかないと Azure の仮想ネットワーク内の仮想マシンとの通信がうまくいかないことが希にあるようです。

VPN トンネル経由の通信が一定時間しか保たない

上に挙げた設定で、Azure の仮想ネットワーク ゲートウェイとの VPN トンネルの接続が確立し、とりあえずはトンネルを通る通信ができるようになります。 「とりあえず」というのは、最初こそは何の問題も無く VPN トンネルを通じた通信ができますが、一定の時間が経つとまったくできなくなるからです。 ただし、このような通信できない状況でも、VPN トンネルの状態は「接続中」のままなので注意が必要です。 VPN トンネルが正しく通信できるかを知るには、VPN トンネルの状態では無く、実際に通信してタイムアウトなどの結果を見る必要があります。

上の設定の場合は、VPN トンネルの確立からほぼ 6 時間で VPN トンネルを通る通信ができなくなります。 色々と試したところ、ipsec ike duration ipsec-saipsec ike duration ike-sa に指定した値が、通信できなくなるまでの時間に影響することを突き止めました。

Azure との VPN トンネルで利用する IPsec は、トンネルの両端のセキュリティ ゲートウェイ (RTX と Azure の仮想ネットワーク ゲートウェイ) のそれぞれが、1 つの IKE SA と送信・受信の 2 つ 1 組の IPsec SA の 2 種類のセキュリティ アソシエーション (SA) を保持しています。 これらの SA は一定時間毎に更新 (再作成) されるのですが、どうやら IPsec sA と IKE SA のどちらか片方でも RTX で更新されると、それに合わせるかのように VPN トンネルを通じた通信ができなくなるようです。

SA の更新では、有効期間が切れる前に多少の時間的な余裕を持って、新しい SA が作成されます。 RTX の規定の設定では、有効期間の 75% を経過したときに新しい SA が作成されます。 上に挙げた設定では明示的に指定していないので、IPsec SA と IKE SA の有効期間は共に規定値の 8 時間 (28800 秒) です。 更新はその 75% の 6 時間です。 この時間は、上の設定で VPN トンネルの確立から、VPN トンネルを通る通信ができなくなるまでの時間と一致します。

ところで、Azure との VPN トンネルの IPsec は IKEv2 なので、SA の更新は両端のセキュリティ ゲートウェイのそれぞれで個別に管理されます。 もしかすると、Azure の仮想ネットワーク ゲートウェイで SA が更新されたときにも、通信できなくなっているのかもしれません。 Azure の Web サイトにある「VPN Gateway 接続の VPN デバイスについて」の Web ページの「IPsec パラメーター」の章によると、Azure の仮想ネットワーク ゲートウェイのルート ベースの接続における SA の有効期間は IKE SA が 10,800 秒 (= 3 時間) 28,800 秒 (= 8 時間) で、IPsec SA が 3,600 秒 (= 1 時間) 27,000 秒 (= 7.5 時間) です。 これは、RTX で SA が更新される 6 時間よりも十分に短くは長いのですが、RTX と同じように 75% の時間を経過したときに更新されると考えると僅かに短く、通信ができなくなるまでに少なくとも一回は Azure 側で SA が更新される値です。 しかし、上の設定で 6 時間以内に通信できなくなったことはありません。 どうやら、Azure の仮想ネットワーク ゲートウェイでの SA の更新で、通信できなくなるようなことは無いと考えてよさそうです。

つまり、通信できなくなる問題は RTX だけに依存し、VPN トンネルの確立からしばらくは正常に使えますが、RTX で SA が更新 (再作成) されると通信できなくなるということのようです。 逆に言えば、VPN トンネルの確立から SA が更新 (再作成) されるまでの期間に限れば、問題無く正常に通信できるとも言えます。 これをうまく利用できれば、運用方法にも依りますが十分実用になりそうです。

Note

追記 [2017.7.12]

本記事執筆時から変更があったのか、Azure 側の SA、特に IPsec SA の有効期間が大きく変化していました。 もしかすると、参照する欄を筆者が見間違えただけかもしれません。

とりあえず、本日 (2017.7.12) 時点の値に訂正します。

VPN トンネル経由の通信を維持する

VPN トンネルを確立した後に RTX での SA の更新 (再作成) で VPN トンネルを通じた通信ができなくなるのなら、SA の更新までの時間を十分に長くすれば、正常に通信できる時間も長くなるはずです。 さらには、VPN トンネルを通じた通信が、必ず VPN トンネルの確立から SA が更新されるまでの間に行われるようにできれば、正常な通信になるはずです。

そのために例えば、更新までの時間が 24 時間以上になるように、SA の有効期間を指定します。 具体的には、IPsec SA と IKE SA の有効期間を両方共に 36 時間にします。 有効期間が 36 時間だと、その 75% は 27 時間で、24 時間よりも十分に長い期間です。 これで、VPN トンネルの確立から 24 時間は正常な通信ができるはずです。 その上で 24 時間毎に VPN トンネルを強制的に切断して、すぐに再確立するようにします。 これによって、VPN トンネルを通じた通信が、必ず VPN トンネルの確立から SA が更新されるまでの間に行われるようになり、常に正常な通信が期待できそうです。 気になる点としては、強制的に切断・再確立するときに生じるごく僅かな時間の通信の切断がありますが、誰も使わないような深夜 2 時などに行えば影響を無視できるでしょう。

この考えに基づいて、RTX に以下の設定を追加します。

    :
  ipsec ike duration ipsec-sa 100 129600
  ipsec ike duration ike-sa 100 129600
    :
schedule at 1 */* 02:00 * ipsec sa delete all
    :

SA の有効期間が 36 時間 (= 129600 秒) になるように、ipsec ike duration ipsec-saipsec ike duration ipsec-sa129600 を指定します。 そして、トンネルを強制的に切断、再確立するための ipsec sa delete all コマンドを、深夜 2 時に定期的に実行させるために schedule at 1 */* 02:00 * ipsec sa delete all を設定します。

この設定で試したところ、VPN トンネルを再確立する午前 2 時から午前 9 時頃までは問題無く通信できました。 しかし、午前 9 時以降は通信できなくなってしまいました。 どうやら、VPN トンネルの確立から 7 時間が経つと SA が更新されるようです。 想定していた 25 時間に比べると、かなり早い時間で更新されます。 これ以前に試したときは、ipsec ike duration ipsec-saipsec ike duration ipsec-sa を指定しないときは、省略時の有効期間である 8 時間の 75% にあたる 6 時間で SA が更新されていました。 また、それよりも短い有効期間を指定したときにも、その 75% の時間で SA が更新されることを確認しています。

想定した更新期間にまったく満たない 7 時間で SA が更新されてしまう原因は、まったくもって分かりません。 SA の更新時間の上限が、どこかで 7 時間とでも指定されているのでしょうか。 とにもかくにもどうやっても SA の更新時間を 7 時間以上に延ばせそうにありません。 そこで、SA の更新時間を 7 時間未満になるように指定して、VPN トンネルの強制的な切断・再確立もそれに合わせることにします。

今度は 6 時間毎にトンネルを切断・再確立するように設定を直します。 6 時間から逆算した SA の有効期間は 8 時間ですが、多少の余裕を見て 8 時間 20 分 (30000 秒) にしました。 また、ipsec sa delete all コマンドも 6 時間毎に実行するように直します。

    :
  ipsec ike duration ipsec-sa 100 30000
  ipsec ike duration ike-sa 100 30000
    :
schedule at 1 */* 01:00 * ipsec sa delete all
schedule at 2 */* 07:00 * ipsec sa delete all
schedule at 3 */* 13:00 * ipsec sa delete all
schedule at 4 */* 19:00 * ipsec sa delete all
    :

この設定で 10 日ほど検証して、いまのところは問題無く通信できていることを確認しています。 ただし、ほとんど影響が無いとはいえ、トンネルの切断・再確立を日中に行わざるを得ない点が、少々気にはなります。

Note

追記 [2017.7.20]

再検証の切っ掛けをいただいた方からの再々の指摘により、RTX で設定した有効期間よりに満たない 7 時間ほどで SA が更新される理由が推察できました。 幾度も目を通したはずの RTX ルーターのリファレンス マニュアルでしたが、ipsec ike duration の項の IKEv2 に関する補足に書かれている「相手側セキュリティ・ゲートウェイの方がSA更新のタイミングが早ければ、SAはその分早く更新されることになる。」という箇所を読み落としていたようです。 この記載の意味は、SA は IPsec の両端で設定した更新間隔の短い方でなるということなので、RTX で有効期間を大きな値にしても、それよりも短期間に設定されている Azure によって、SA の更新が行われているのだと思われます。

RTX による Azure (ルート ベース) との VPN 接続

ここまでの検証で得た最終的な RTX の設定を以下にまとめます。 例の如く、経路情報などのトンネル確立に直接関係ない箇所は省略します。

    :
tunnel select 100
 ipsec tunnel 1100
  ipsec sa policy 1100 100 esp anti-replay-check=off
  ipsec ike version 100 2
  ipsec ike duration ipsec-sa 100 30000
  ipsec ike duration ike-sa 100 30000
  ipsec ike keepalive log 100 off
  ipsec ike keepalive use 100 on
  no ipsec ike local address 100
  ipsec ike local name 100 <LAN側IPアドレス> ipv4-addr
  ipsec ike nat-traversal 100 on
  ipsec ike pre-shared-key 100 text <事前共有鍵>
  no ipsec ike remote address 100
  ipsec ike remote name 100 <AzureゲートウェイIPアドレス> ipv4-addr
  ipsec auto refresh 100 on
 ip tunnel tcp mss limit 1350
 tunnel enable 100
tunnel select none
    :
schedule at 1 */* 01:00 * ipsec sa delete all
schedule at 2 */* 07:00 * ipsec sa delete all
schedule at 3 */* 13:00 * ipsec sa delete all
schedule at 4 */* 19:00 * ipsec sa delete all
    :

同じ設定で複数の拠点からの同時接続も確認しました。 いずれはこのような姑息な手段を採らずとも、素直に接続できるような改善がされることをメーカーに強く望むばかりです。 冒頭で胡麻を擂った効果が少しでもあると良いのですが。

Note

追記 [2017.7.12]

この記事では、Azure とのトンネルの切断・再確立のために SA を無理矢理削除 (ipsec sa all) しています。 しかしながら、この方法では Azure とのトンネルに限らず他の IPsec トンネルもすべて切断・再確立してしまいます。 schedule コマンドの数は増えますが以下のようにすれば Azure とのトンネルだけを切断・再確立できるので、この方が多少はいいかもしれません。

    :
schedule at 1 */* 01:00 * no ipsec ike pre-shared-key 100
schedule at 2 */* 07:00 * no ipsec ike pre-shared-key 100
schedule at 3 */* 13:00 * no ipsec ike pre-shared-key 100
schedule at 4 */* 19:00 * no ipsec ike pre-shared-key 100
schedule at 5 */* 01:00 * ipsec ike pre-shared-key 100 text <事前共有鍵>
schedule at 6 */* 07:00 * ipsec ike pre-shared-key 100 text <事前共有鍵>
schedule at 7 */* 13:00 * ipsec ike pre-shared-key 100 text <事前共有鍵>
schedule at 8 */* 19:00 * ipsec ike pre-shared-key 100 text <事前共有鍵>
    :

Comments