古河電工FITELnet F220 とさくらクラウドVPCルータでサイト間VPN を張る
古河電工FITELnet F220 を導入後、ファームウェアのバグを踏むなど、一筋縄ではいかなかったサイト間VPN だがバグ修正されたバージョンのファームウェアに入れ替えてからはすこぶる快調に動いていた。
しかし今度は、さくらクラウド側の仕様でちょっとしたトラブルがあった上、それなりにレアケースと思うので同様の問題で悩む人が出てくるかもしれないため私の方で判明してた範囲で経緯をまとめておく。
まず、前回の記事までの記述での対抗側VPCルータの仕様は「VPCルータバーション 1」を使ったものだった。さくらクラウドのマニュアルによれば、VPCルータのバージョンが変わっても基本的な仕様は同じものでバージョンが上がるごとに安定性が上がる、ということだった。
VPCルータではバージョンが大きいほど安定性が向上し、より快適にご利用いただけるようになります。
実際に VPCルータのバージョンを変更したところ、バージョン 1 とバージョン 2 では少し挙動が違っており、FITELnet F220 側の設定も変えないといけなかった。
さくらクラウド VPCルータ バージョン 1 で接続
マニュアルなどはバージョン1 とバージョン2 の違いは書かれておらず、仕様として、
認証方式
Pre-Shared Key(事前共有鍵) (＊1)
暗号アルゴリズム
AES128 もしくは AES256
暗号利用モード
CBC
ハッシュアルゴリズム
SHA1 もしくは SHA256
メッセージ認証符号
HMAC
PFS(Perfect Forward Secrecy)
有効
DH(Diffie-Hellman)
グループMODP1024(グループ2)、MODP2048(グループ14)、
MODP3072(グループ15) もしくは MODP4096(グループ16)
などと書かれているが、これはバージョン2 の場合のようで、バージョン1 だとこれに合わせて設定してもサイト間VPN は接続できなかった。
マニュアルに掲載された設定例などは、バージョン 1 を想定したものが書かれているようで、そこから判明する接続が可能な設定は以下の通り。
認証方式
Pre-Shared Key(事前共有鍵)
暗号アルゴリズム
AES128もしくは AES256
暗号利用モード
CBC
ハッシュアルゴリズム
SHA1もしくは SHA256
メッセージ認証符号
HMAC
PFS(Perfect Forward Secrecy)
有効
DH(Diffie-Hellman)グループMODP1024(グループ2)、MODP2048(グループ14)、MOD1536(グループ5)
MODP3072(グループ15) もしくは MODP4096(グループ16)
FITELnet F220 との相性問題なのはかはわからないが、この設定以外の組み合わせではリンクアップしなかった。
この設定で接続する場合の、FITELnet F220 の設定は以下の通り。
crypto ipsec security-association lifetime seconds 1800
!
crypto ipsec policy sakuratokyo
set pfs group5
set security-association always-up
set security-association lifetime seconds 1800
set security-association transform esp-aes esp-sha-hmac
set ip df-bit 0
set ip fragment post
exit
!
crypto ipsec selector sakuratokyo
src 1 ipv4 any
dst 1 ipv4 any
exit
!
crypto isakmp policy sakuratokyo
authentication pre-share
encryption aes
group 5
lifetime 28800
hash sha
exit
!
crypto isakmp profile sakuratokyo
local-address 172.30.128.254
keepalive interval 15 always-send
self-identity address 172.30.128.254
set isakmp-policy sakuratokyo
set ipsec-policy sakuratokyo
set peer 27.133.132.134
ike-version 1
local-key THIS-IS-SECRET-KEY
exit
!
crypto map sakuratokyo ipsec-isakmp
match address sakuratokyo
set isakmp-profile sakuratokyo
exit細かい設定内容は割愛する。
これでサイト間VPN に接続した場合の SA は以下の通り。
#show crypto sa
IPSEC SA <I>
Selector :
0.0.0.0/0 ALL ALL <---> 0.0.0.0/0 ALL ALL
Interface : tunnel 1
Peer IP : 27.133.132.134/500
Local IP : 172.30.128.254/500
Encryption algorithm : AES-CBC/128
Authentication algorithm : HMAC-SHA1-96/160
Life time : 568/1800 sec
PFS : on (group 5) ESN : off
IN
SPI : 93c1ab67
Packets : 6
Octets : 296
Replay error : 0
Auth error : 0
Padding error : 0
Rule error : 0
Cipher Key : 0x5cfc51fc465b4743718389b0d401d39c
Auth Key : 0x0863fb7d9f439b5f7842bc7b1588e165bc736ac0
OUT
SPI : cb5be797
Packets : 821
Octets : 482024
Seq lapped : 0
Cipher Key : 0xd0470f34d9baba9f369cd5ba0b877f11
Auth Key : 0xe0dd472e17d86b4ad21c82841734d16b1cd21195
Total number of ISAKMP SA 0
Total number of IPSEC SA 1さくらクラウド VPCルータのマイグレーション
さくらクラウドの VPCルータのマイグレーションはマニュアルに書かれている通り、API経由でしか行えない。
APIを利用したバージョン1からのマイグレーション
バージョン1のVPCルータをご利用の場合、以下のAPIを呼び出すことで、バージョン2へのマイグレーションが行えます。現在のネットワーク設定や構成情報は維持されます。
curl を使って API経由でマイグレーションを実行したところ、新しく立ち上がってきたルータへ VPN がつながらないだけでなく、ログなども見れない状態となりスタックしてしまった。サポートにコンタクトしたがすぐに返答がなく、試行錯誤していたところ動くようになった。
実際にやってみた作業としては、電源ダウン(これはコントロールパネルからも行える)、あらかじめエクスポートしてあった設定ファイルをインポート、電源アップ、の手順でルータのリソースが立ち上がるようになり、サイト間VPN も接続できるようになった。
FITELnet F220 の設定
さくらクラウドの VPCルータのサイト間VPN の設定は以下の通り。
バージョン 1 のときは VPN接続が確立できなかった暗号アルゴリズムを AES256、ハッシュアルゴリズムを SHA256 に変更する。バージョン 2 へマイグレーションすると、DHグループの設定も可能になるので、modp2048(group 14) へ変更する。
バージョン 2 にマイグレーションした場合は、先に設定した FITELnet F220 の config のままだとサイト間VPN が確立できないので、設定を変更する必要がある。
変更箇所は以下の通り。
!
crypto ipsec security-association lifetime seconds 1800
!
crypto ipsec policy sakuratokyo
set pfs group14
set security-association lifetime seconds 180
set security-association transform esp-sha256-hmac esp-aes
exit
!
crypto isakmp policy sakuratokyo
group 14
hash sha-256
exit
!
FITELnet F220 側で config して end、save、commit したらさくらクラウドのコントロールパネルから「VPN再接続」をクリックすると新しい設定で VPN接続が確立する。
接続が確立したときの、さくらクラウド側のログが以下の通り。
Jul 18 13:21:32 rt-112700568505 ipsec_starter[23403]: starter is already running (/var/run/starter.charon.pid exists) -- no fork done
Jul 18 13:21:35 rt-112700568505 charon: 11[KNL] creating rekey job for CHILD_SA ESP/0xce40cea8/27.133.132.134
Jul 18 13:21:37 rt-112700568505 charon: 14[KNL] creating rekey job for CHILD_SA ESP/0x56542c81/126.169.118.242
Jul 18 13:21:40 rt-112700568505 charon: 16[NET] <2> received packet: from 126.169.118.242[500] to 27.133.132.134[500] (184 bytes)
Jul 18 13:21:40 rt-112700568505 charon: 16[ENC] <2> parsed ID_PROT request 0 [ SA V ]
Jul 18 13:21:40 rt-112700568505 charon: 16[IKE] <2> received DPD vendor ID
Jul 18 13:21:40 rt-112700568505 charon: 16[IKE] <2> 126.169.118.242 is initiating a Main Mode IKE_SA
Jul 18 13:21:40 rt-112700568505 charon: 16[CFG] <2> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Jul 18 13:21:40 rt-112700568505 charon: 16[ENC] <2> generating ID_PROT response 0 [ SA V V ]
Jul 18 13:21:40 rt-112700568505 charon: 16[NET] <2> sending packet: from 27.133.132.134[500] to 126.169.118.242[500] (124 bytes)
Jul 18 13:21:40 rt-112700568505 charon: 06[NET] <2> received packet: from 126.169.118.242[500] to 27.133.132.134[500] (308 bytes)
Jul 18 13:21:40 rt-112700568505 charon: 06[ENC] <2> parsed ID_PROT request 0 [ KE No ]
Jul 18 13:21:40 rt-112700568505 charon: 06[ENC] <2> generating ID_PROT response 0 [ KE No ]
Jul 18 13:21:40 rt-112700568505 charon: 06[NET] <2> sending packet: from 27.133.132.134[500] to 126.169.118.242[500] (324 bytes)
Jul 18 13:21:40 rt-112700568505 charon: 05[NET] <2> received packet: from 126.169.118.242[500] to 27.133.132.134[500] (108 bytes)
Jul 18 13:21:40 rt-112700568505 charon: 05[ENC] <2> parsed ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
Jul 18 13:21:40 rt-112700568505 charon: 05[CFG] <2> looking for pre-shared key peer configs matching 27.133.132.134...126.169.118.242[172.30.128.254]
Jul 18 13:21:40 rt-112700568505 charon: 05[CFG] <2> selected peer config "peer-126.169.118.242-tunnel-vti"
Jul 18 13:21:40 rt-112700568505 charon: 05[IKE] <peer-126.169.118.242-tunnel-vti|1> schedule delete of duplicate IKE_SA for peer '172.30.128.254' due to uniqueness policy and suspected reauthentication
Jul 18 13:21:40 rt-112700568505 charon: 05[IKE] <peer-126.169.118.242-tunnel-vti|2> IKE_SA peer-126.169.118.242-tunnel-vti[2] established between 27.133.132.134[27.133.132.134]...126.169.118.242[172.30.128.254]
Jul 18 13:21:40 rt-112700568505 charon: 05[IKE] <peer-126.169.118.242-tunnel-vti|2> scheduling reauthentication in 28632s
Jul 18 13:21:40 rt-112700568505 charon: 05[IKE] <peer-126.169.118.242-tunnel-vti|2> maximum IKE_SA lifetime 28721s
Jul 18 13:21:40 rt-112700568505 charon: 05[ENC] <peer-126.169.118.242-tunnel-vti|2> generating ID_PROT response 0 [ ID HASH ]
Jul 18 13:21:40 rt-112700568505 charon: 05[NET] <peer-126.169.118.242-tunnel-vti|2> sending packet: from 27.133.132.134[500] to 126.169.118.242[500] (92 bytes)
Jul 18 13:21:40 rt-112700568505 charon: 05[IKE] <peer-126.169.118.242-tunnel-vti|1> destroying duplicate IKE_SA for peer '172.30.128.254', received INITIAL_CONTACT
Jul 18 13:21:40 rt-112700568505 charon: 05[KNL] <peer-126.169.118.242-tunnel-vti|1> error uninstalling route installed with policy 0.0.0.0/0 === 0.0.0.0/0 out (mark 9437185/0xffffffff)
Jul 18 13:21:40 rt-112700568505 charon: 09[NET] <peer-126.169.118.242-tunnel-vti|2> received packet: from 126.169.118.242[500] to 27.133.132.134[500] (508 bytes)
Jul 18 13:21:40 rt-112700568505 charon: 09[ENC] <peer-126.169.118.242-tunnel-vti|2> parsed QUICK_MODE request 1133148741 [ HASH SA No KE ID ID ]
Jul 18 13:21:40 rt-112700568505 charon: 09[CFG] <peer-126.169.118.242-tunnel-vti|2> selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
Jul 18 13:21:40 rt-112700568505 charon: 09[ENC] <peer-126.169.118.242-tunnel-vti|2> generating QUICK_MODE response 1133148741 [ HASH SA No KE ID ID ]
Jul 18 13:21:40 rt-112700568505 charon: 09[NET] <peer-126.169.118.242-tunnel-vti|2> sending packet: from 27.133.132.134[500] to 126.169.118.242[500] (460 bytes)
Jul 18 13:21:40 rt-112700568505 charon: 07[NET] <peer-126.169.118.242-tunnel-vti|2> received packet: from 126.169.118.242[500] to 27.133.132.134[500] (92 bytes)
Jul 18 13:21:40 rt-112700568505 charon: 07[ENC] <peer-126.169.118.242-tunnel-vti|2> parsed INFORMATIONAL_V1 request 785607369 [ HASH D ]
Jul 18 13:21:40 rt-112700568505 charon: 07[IKE] <peer-126.169.118.242-tunnel-vti|2> received DELETE for ESP CHILD_SA with SPI 56542c81
Jul 18 13:21:40 rt-112700568505 charon: 07[IKE] <peer-126.169.118.242-tunnel-vti|2> CHILD_SA not found, ignored
Jul 18 13:21:40 rt-112700568505 charon: 11[NET] <peer-126.169.118.242-tunnel-vti|2> received packet: from 126.169.118.242[500] to 27.133.132.134[500] (76 bytes)
Jul 18 13:21:40 rt-112700568505 charon: 11[ENC] <peer-126.169.118.242-tunnel-vti|2> parsed QUICK_MODE request 1133148741 [ HASH ]
Jul 18 13:21:40 rt-112700568505 charon: 11[IKE] <peer-126.169.118.242-tunnel-vti|2> CHILD_SA peer-126.169.118.242-tunnel-vti{3} established with SPIs ccbf4f48_i f188d39c_o and TS 0.0.0.0/0 === 0.0.0.0/0
Jul 18 13:21:55 rt-112700568505 charon: 14[NET] <peer-126.169.118.242-tunnel-vti|2> received packet: from 126.169.118.242[500] to 27.133.132.134[500] (108 bytes)
Jul 18 13:21:55 rt-112700568505 charon: 14[ENC] <peer-126.169.118.242-tunnel-vti|2> parsed INFORMATIONAL_V1 request 1110252631 [ HASH N(DPD) ]
Jul 18 13:21:55 rt-112700568505 charon: 14[ENC] <peer-126.169.118.242-tunnel-vti|2> generating INFORMATIONAL_V1 request 2751919319 [ HASH N(DPD_ACK) ]
Jul 18 13:21:55 rt-112700568505 charon: 14[NET] <peer-126.169.118.242-tunnel-vti|2> sending packet: from 27.133.132.134[500] to 126.169.118.242[500] (108 bytes)FITELnet F220 側からも接続が確認できる。
VPCルータによるサイト間接続では、公式の動作確認済みルータのリストに入っていないため、マニュアルなどに書かれた内容だけで一筋縄に設定できるわけではないが、古河電工FITELnet F220 でも接続できることがわかった。
バージョン 2 にマイグレーションするメリット
正直、これまでのバージョン 1 を使っているだけでは特に不満があるわけではなかった。ただ、設定変更を試そうとしたときに、マニュアルに記述された設定内容では接続できないことに気づき、試行錯誤してバージョン 2 にマイグレーションすることになった。
バージョン 2 になったと言っても設定を変えるだけでサイト間VPN 自体は変わらないのでユーザとしてはどちらのバージョンを使うかは好みの問題とも言える。(ただし今後、マニュアルとの乖離が進む可能性もあるので、適度に最新版を追っておくのがいいかもしれない)
マイグレーション後に気づいたこととしては、これまで VPCルータの CPU使用率が平均して 28msec、多いときに 40msec といった数値になっていた。
これが、マイグレーション後は 4msec を切るような概ね 3.3msec か 6.6msec で安定するようになり、コントロールパネルから確認できるメモリ空き容量も概ね 55% ほどとリソースに余裕ができているように見える。
元々、IPSec SA の寿命はさくらクラウド側のデフォルト値の 1,800sec に設定していたが、リソースに余裕があるようなので 180sec に変更した。
この値は FITELnet ではデフォルト値が 600sec、YAMAHA RTシリーズだと最小で 300sec からなので、180sec というのは極端に小さいようにも思えるが、回線側でトラブルがあった際にも、最小で 180secダウンするだけで再接続の処理が走ることを期待して設定してある。(本来の死活監視としては DPD が有効なので不要言えば不要かもしれない)
この記事が気に入ったらサポートをしてみませんか？