Compnet

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

2017-07-19(水)

続々:YAMAHA RTX で Azure と VPN 接続する

Posted by Nakane, R. in technical   

半年ほど前に、YAMAHA RTX ルーターで Azure と VPN 接続をするための設定に関する記事を公開し、それに関する追加の検証結果を数日前に公開しました。 これらの記事では、RTX ルーターと Azure の仮想ネットワーク ゲートウェイとで IPsec の VPN トンネルを確立するための RTX ルーターの設定を紹介しています。 半年ほど前の記事では、RTX 側からの SA の更新 (再作成) の失敗により、VPN トンネルを通じた通信ができなくなる現象に対する回避策を紹介しています。 また数日前の記事では、SA の有効期間を Azure 側の値に揃えることで、特別な回避策が不要になる旨の検証結果を紹介しました。

これで一区切りと思ったのですが、改めて数日前の記事に挙げた RTX ルーターの設定を眺めていたら、IKE SA の有効期間が RTX の初期値と同じことに気づきました。 そうであれば、IKE SA を明示的に設定しなくても大丈夫ではないかと、再び検証します。

SA の有効期間を初期値に

まずは数日前の記事の設定を基に、no ipsec ike duration ike-sa 100 として IKE SA の設定を削除して初期値にします。

    :
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 27000
  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
    :

この設定で VPN トンネルの確立後、ほぼ 24 時間ほど放置して SA の更新状況と VPN トンネルと通じた通信状況を確認しました。 結果は以下のログの通りで、何の問題も無く SA が更新されており、VPN トンネルを通じた通信も問題なくできています。

2017/07/15 09:55:33: [IKE2] SA:1/IKE temporarily assigned
2017/07/15 09:55:33: [IKE2] SA:1/IKE established
2017/07/15 09:55:33: [IKE2] SA:2/CHLD_SEND temporarily assigned
2017/07/15 09:55:33: [IKE2] SA:3/CHLD_RECV temporarily assigned
2017/07/15 09:55:33: [IKE2] SA:2/CHLD_SEND established
2017/07/15 09:55:33: [IKE2] SA:3/CHLD_RECV established
2017/07/15 09:55:33: IP Tunnel[100] Up
    :
2017/07/15 15:33:29: [IKE2] SA:5/CHLD_SEND temporarily assigned
2017/07/15 15:33:29: [IKE2] SA:7/CHLD_RECV temporarily assigned
2017/07/15 15:33:29: [IKE2] SA:5/CHLD_SEND established
2017/07/15 15:33:29: [IKE2] SA:7/CHLD_RECV established
    :
2017/07/15 15:55:49: [IKE2] SA:15/IKE temporarily assigned
2017/07/15 15:55:49: [IKE2] SA:15/IKE established
    :
2017/07/15 17:03:03: [IKE2] SA:2/CHLD_SEND deleted
2017/07/15 17:03:03: [IKE2] SA:3/CHLD_RECV deleted
    :
2017/07/15 17:56:04: [IKE2] SA:1/IKE deleted
    :
2017/07/15 21:11:26: [IKE2] SA:1/CHLD_SEND temporarily assigned
2017/07/15 21:11:26: [IKE2] SA:2/CHLD_RECV temporarily assigned
2017/07/15 21:11:26: [IKE2] SA:1/CHLD_SEND established
2017/07/15 21:11:26: [IKE2] SA:2/CHLD_RECV established
    :
2017/07/15 21:56:06: [IKE2] SA:10/IKE temporarily assigned
2017/07/15 21:56:06: [IKE2] SA:10/IKE established
    :
2017/07/15 22:41:00: [IKE2] SA:5/CHLD_SEND deleted
2017/07/15 22:41:00: [IKE2] SA:7/CHLD_RECV deleted
    :
2017/07/15 23:56:20: [IKE2] SA:15/IKE deleted
    :
2017/07/16 02:49:22: [IKE2] SA:8/CHLD_SEND temporarily assigned
2017/07/16 02:49:22: [IKE2] SA:9/CHLD_RECV temporarily assigned
2017/07/16 02:49:22: [IKE2] SA:8/CHLD_SEND established
2017/07/16 02:49:22: [IKE2] SA:9/CHLD_RECV established
    :
2017/07/16 03:56:19: [IKE2] SA:15/IKE temporarily assigned
2017/07/16 03:56:19: [IKE2] SA:15/IKE established
    :
2017/07/16 04:18:56: [IKE2] SA:1/CHLD_SEND deleted
2017/07/16 04:18:56: [IKE2] SA:2/CHLD_RECV deleted
    :
2017/07/16 05:56:37: [IKE2] SA:10/IKE deleted
    :
2017/07/16 08:27:17: [IKE2] SA:3/CHLD_SEND temporarily assigned
2017/07/16 08:27:17: [IKE2] SA:4/CHLD_RECV temporarily assigned
2017/07/16 08:27:17: [IKE2] SA:3/CHLD_SEND established
2017/07/16 08:27:17: [IKE2] SA:4/CHLD_RECV established
    :
2017/07/16 09:56:34: [IKE2] SA:10/IKE temporarily assigned
2017/07/16 09:56:34: [IKE2] SA:10/IKE established
    :
2017/07/16 09:56:52: [IKE2] SA:8/CHLD_SEND deleted
2017/07/16 09:56:52: [IKE2] SA:9/CHLD_RECV deleted
    :

それでは、no ipsec ike duration ike-sa 100no ipsec ike duration ipsec-sa 100 として、IKE SA と IPsec SA の有効期間を両方とも、RTX の初期値にします。 これは YAMAHA RTX ルーターで Azure の仮想ネットワーク ゲートウェイとルート ベースの 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
    :

この設定で 24 時間弱ほど放置して、以下のログを得ました。 これを見る限りは、何の問題も無く SA が更新できています。 また、VPN トンネルを通じた通信も確認しましたが、なにも問題なさそうです。

2017/07/17 07:40:56: [IKE2] SA:1/IKE temporarily assigned
2017/07/17 07:40:56: [IKE2] SA:1/IKE established
2017/07/17 07:40:56: [IKE2] SA:2/CHLD_SEND temporarily assigned
2017/07/17 07:40:56: [IKE2] SA:3/CHLD_RECV temporarily assigned
2017/07/17 07:40:56: [IKE2] SA:2/CHLD_SEND established
2017/07/17 07:40:56: [IKE2] SA:3/CHLD_RECV established
2017/07/17 07:40:56: IP Tunnel[100] Up
    :
2017/07/17 13:41:14: [IKE2] SA:10/IKE temporarily assigned
2017/07/17 13:41:15: [IKE2] SA:10/IKE established
    :
2017/07/17 13:41:20: [IKE2] SA:11/CHLD_SEND temporarily assigned
2017/07/17 13:41:20: [IKE2] SA:12/CHLD_RECV temporarily assigned
2017/07/17 13:41:20: [IKE2] SA:11/CHLD_SEND established
2017/07/17 13:41:20: [IKE2] SA:12/CHLD_RECV established
    :
2017/07/17 14:48:27: [IKE2] SA:2/CHLD_SEND deleted
2017/07/17 14:48:27: [IKE2] SA:3/CHLD_RECV deleted
    :
2017/07/17 15:41:27: [IKE2] SA:1/IKE deleted
    :
2017/07/17 19:41:25: [IKE2] SA:4/IKE temporarily assigned
2017/07/17 19:41:25: [IKE2] SA:4/IKE established
    :
2017/07/17 19:41:46: [IKE2] SA:5/CHLD_SEND temporarily assigned
2017/07/17 19:41:46: [IKE2] SA:6/CHLD_RECV temporarily assigned
2017/07/17 19:41:46: [IKE2] SA:5/CHLD_SEND established
2017/07/17 19:41:46: [IKE2] SA:6/CHLD_RECV established
    :
2017/07/17 20:48:51: [IKE2] SA:11/CHLD_SEND deleted
2017/07/17 20:48:51: [IKE2] SA:12/CHLD_RECV deleted
    :
2017/07/17 21:41:46: [IKE2] SA:10/IKE deleted
    :
2017/07/18 01:41:35: [IKE2] SA:1/IKE temporarily assigned
2017/07/18 01:41:35: [IKE2] SA:1/IKE established
    :
2017/07/18 01:42:07: [IKE2] SA:2/CHLD_SEND temporarily assigned
2017/07/18 01:42:07: [IKE2] SA:3/CHLD_RECV temporarily assigned
2017/07/18 01:42:07: [IKE2] SA:2/CHLD_SEND established
2017/07/18 01:42:07: [IKE2] SA:3/CHLD_RECV established
    :
2017/07/18 02:49:16: [IKE2] SA:5/CHLD_SEND deleted
2017/07/18 02:49:16: [IKE2] SA:6/CHLD_RECV deleted
    :
2017/07/18 03:41:56: [IKE2] SA:4/IKE deleted
    :

これはどういうことでしょうか。

半年ほど前に試したときは SA の更新が行われると、VPN トンネルを通る通信が途絶する現象が発生していました。 しかし、今回はそれとまったく同じ設定にも関わらず、何の問題もなく、VPN トンネルを通る通信ができなくなることもありません。 なお、筆者が検証に利用したルーターは、最初の記事のときからファームウェアを含めて同一のものを使っています。 つまり、RTX 側の動作は変わっていないということになるため、半年前から今日までの間に Azure 側で IPsec 絡みのパラメーターが調整され、RTX ルーターが SA を更新するときの不具合が解消されたのではないかと憶測できそうです。

もしかすると、最初の記事で先日訂正した「Azure 側の SA の有効期間」が筆者の見間違いなどではなく、実際に記事執筆時からこの半年の間に変更になっていたのかもしれません。 Web Archive を探してみましたが、残念なことに最初の記事を執筆した当時の記載を見つけられませんでした。 しかし、Azure 側の SA の有効期間が実際にこの半年の間に変更されたのなら、その際に IPsec の他のパラメーターが調整されていてもおかしくありません。

SA の有効期間をもっと大きく

ものは試しと思い切って、IKE SA と IPsec SA の有効期間を 36 時間 (= 129600 秒) と大きな値にしてみます。 結果は以下のログの通りです。

2017/07/18 07:11:05: [IKE2] SA:1/IKE temporarily assigned
2017/07/18 07:11:05: [IKE2] SA:1/IKE established
2017/07/18 07:11:05: [IKE2] SA:2/CHLD_SEND temporarily assigned
2017/07/18 07:11:05: [IKE2] SA:3/CHLD_RECV temporarily assigned
2017/07/18 07:11:05: [IKE2] SA:2/CHLD_SEND established
2017/07/18 07:11:05: [IKE2] SA:3/CHLD_RECV established
2017/07/18 07:11:05: IP Tunnel[100] Up
    :
2017/07/18 14:18:24: [IKE2] SA:4/CHLD_SEND temporarily assigned
2017/07/18 14:18:24: [IKE2] SA:5/CHLD_RECV temporarily assigned
2017/07/18 14:18:24: [IKE2] SA:4/CHLD_SEND established
2017/07/18 14:18:24: [IKE2] SA:5/CHLD_RECV established
2017/07/18 14:18:24: [IKE2] SA:2/CHLD_SEND deleted
2017/07/18 14:18:24: [IKE2] SA:3/CHLD_RECV deleted
    :
2017/07/18 14:47:14: [IKE2] SA:2/IKE temporarily assigned
2017/07/18 14:47:14: [IKE2] SA:2/IKE established
2017/07/18 14:47:14: [IKE2] SA:1/IKE deleted
    :
2017/07/18 21:24:49: [IKE2] SA:7/CHLD_SEND temporarily assigned
2017/07/18 21:24:49: [IKE2] SA:8/CHLD_RECV temporarily assigned
2017/07/18 21:24:49: [IKE2] SA:7/CHLD_SEND established
2017/07/18 21:24:49: [IKE2] SA:8/CHLD_RECV established
2017/07/18 21:24:49: [IKE2] SA:4/CHLD_SEND deleted
2017/07/18 21:24:49: [IKE2] SA:5/CHLD_RECV deleted
    :
2017/07/18 22:23:14: [IKE2] SA:10/IKE temporarily assigned
2017/07/18 22:23:14: [IKE2] SA:10/IKE established
2017/07/18 22:23:14: [IKE2] SA:2/IKE deleted
    :
2017/07/19 04:31:08: [IKE2] SA:13/CHLD_SEND temporarily assigned
2017/07/19 04:31:08: [IKE2] SA:14/CHLD_RECV temporarily assigned
2017/07/19 04:31:08: [IKE2] SA:13/CHLD_SEND established
2017/07/19 04:31:08: [IKE2] SA:14/CHLD_RECV established
2017/07/19 04:31:08: [IKE2] SA:7/CHLD_SEND deleted
2017/07/19 04:31:08: [IKE2] SA:8/CHLD_RECV deleted
    :
2017/07/19 05:59:14: [IKE2] SA:4/IKE temporarily assigned
2017/07/19 05:59:15: [IKE2] SA:4/IKE established
2017/07/19 05:59:15: [IKE2] SA:10/IKE deleted
    :

SA の更新や削除の周期こそ、有効期間 (= 36 時間) の 75% にあたる 25 時間よりも遙かに短い 7 時間強で更新されていますが、VPN トンネルの確立から 48 時間を越えた今でも VPN トンネルを通る通信に問題は起きていません。

Note

追記 [2017.7.20]

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

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

ここまでの検証で、RTX ルーターで Azure の仮想ネットワーク ゲートウェイとルート ベースの VPN トンネルが、問題無く確立できそうだということが分かりました。 後は、YAMAHA から公式に Azure との接続についての検証が表明されることを心待ちするだけです。

Comments