2022年03月03日
Tweet
NEC IX の設定をしていたとき、 ikev2 を利用すると、 config がとてもすっきりすることがわかりました。
じゃあ ix 側はなるべく ikev2 で利用したいなぁと思ったのです。
Yamaha も ikev2 に対応しているようです。
ということで以下の config で接続できました。
NEC IX
------------
ikev2 authentication psk id fqdn [対向のローカルIP] key char [事前共有キー]
interface Tunnel0.0
tunnel mode ipsec-ikev2
ip unnumbered BVI0
ip tcp adjust-mss auto
ikev2 connect-type auto
ikev2 local-authentication id ipv4 [自身のローカルIP]
ikev2 peer-fqdn-ipv4 [対向のDDNS(netvolante)] authentication id ipv4 [対向機のローカルIP]
no shutdown
------------
Yamaha RTX1210 Rev.14.01.40
------------
tunnel select 100
ipsec tunnel 100
ipsec sa policy 100 100 esp aes256-cbc sha-hmac
ipsec ike version 100 2
ipsec ike always-on 100 on
ipsec ike keepalive log 100 off
ipsec ike keepalive use 100 on heartbeat 10 6
ipsec ike local name 100 [自身のローカルIP] ipv4-addr
ipsec ike pre-shared-key 100 text [事前共有キー]
ipsec ike remote address 100 [対向機のDDNS(nmddns)]
ipsec ike remote name 100 [対向機のローカルIP] ipv4-addr
ip tunnel tcp mss limit auto
tunnel enable 100
yamahaで確認できるステータスは以下の通りでした。
SA[9] 状態: 確立済 寿命: 28788秒
プロトコル: IKEv2
ローカルホスト: XXXXXXXX:500
リモートホスト: XXXXXXXX:500
暗号アルゴリズム: AES256_CBC PRF : HMAC_SHA2_256
認証アルゴリズム: HMAC_SHA2_256_128 DHグループ: MODP_2048

じゃあ ix 側はなるべく ikev2 で利用したいなぁと思ったのです。
Yamaha も ikev2 に対応しているようです。
ということで以下の config で接続できました。
NEC IX
------------
ikev2 authentication psk id fqdn [対向のローカルIP] key char [事前共有キー]
interface Tunnel0.0
tunnel mode ipsec-ikev2
ip unnumbered BVI0
ip tcp adjust-mss auto
ikev2 connect-type auto
ikev2 local-authentication id ipv4 [自身のローカルIP]
ikev2 peer-fqdn-ipv4 [対向のDDNS(netvolante)] authentication id ipv4 [対向機のローカルIP]
no shutdown
------------
Yamaha RTX1210 Rev.14.01.40
------------
tunnel select 100
ipsec tunnel 100
ipsec sa policy 100 100 esp aes256-cbc sha-hmac
ipsec ike version 100 2
ipsec ike always-on 100 on
ipsec ike keepalive log 100 off
ipsec ike keepalive use 100 on heartbeat 10 6
ipsec ike local name 100 [自身のローカルIP] ipv4-addr
ipsec ike pre-shared-key 100 text [事前共有キー]
ipsec ike remote address 100 [対向機のDDNS(nmddns)]
ipsec ike remote name 100 [対向機のローカルIP] ipv4-addr
ip tunnel tcp mss limit auto
tunnel enable 100
yamahaで確認できるステータスは以下の通りでした。
SA[9] 状態: 確立済 寿命: 28788秒
プロトコル: IKEv2
ローカルホスト: XXXXXXXX:500
リモートホスト: XXXXXXXX:500
暗号アルゴリズム: AES256_CBC PRF : HMAC_SHA2_256
認証アルゴリズム: HMAC_SHA2_256_128 DHグループ: MODP_2048
stock_value at 11:12│Comments(8)│技術
この記事へのコメント
1. Posted by 高デイル 2022年03月09日 12:00
はじめまして。
高(コウ)と申します。
nmcliコマンドについて調べてるうちにここまでたどり着きました。問題もお陰様で解決しました。
ところで、
仕事くださいと書いてあったのが気になってるんですが。。。
知り合いが会社全体(工場あり)のネットワークの再編成を考えてるんです。
もし、お話が出来るのであれば、連絡お願いいたします。
高(コウ)と申します。
nmcliコマンドについて調べてるうちにここまでたどり着きました。問題もお陰様で解決しました。
ところで、
仕事くださいと書いてあったのが気になってるんですが。。。
知り合いが会社全体(工場あり)のネットワークの再編成を考えてるんです。
もし、お話が出来るのであれば、連絡お願いいたします。
2. Posted by syo@管理者 2022年03月14日 17:37
コメントありがとうございます。
syoichi_s at hotmail.com にメールを頂けませんでしょうか。
syoichi_s at hotmail.com にメールを頂けませんでしょうか。
3. Posted by s-tech 2023年01月15日 15:33
NECとYamahaのIKEv2/IPSECの暫定コンフィグを見ましたが、IPSECの死活監視機能ですが、Heartbeat方式の設定をされている様ですが、こちらはYamaha独自の死活監視の機能ですので、対向先のIXルーターの生存状況の把握は正確には出来ていないかと思います。
NECのIXルーターやWAルーター系では、どちらかと言いましたら、シスコ系など業界標準のDPD死活監視の機能になっておりますので、HeartBeat方式からDPD方式の死活監視にされた方が良いかと思います。
Yamaha同士ではRFC4706の方式の死活監視の設定を推奨しているようですが。
NEC側より、死活監視をさせる方法も出来るかと思います。
ネットワークモニター機能を併用して、IKE-SAの消去、接続タイマーの監視をする形になるかと思います。
NECのIXルーターやWAルーター系では、どちらかと言いましたら、シスコ系など業界標準のDPD死活監視の機能になっておりますので、HeartBeat方式からDPD方式の死活監視にされた方が良いかと思います。
Yamaha同士ではRFC4706の方式の死活監視の設定を推奨しているようですが。
NEC側より、死活監視をさせる方法も出来るかと思います。
ネットワークモニター機能を併用して、IKE-SAの消去、接続タイマーの監視をする形になるかと思います。
4. Posted by s-tech 2023年01月15日 16:00
一部、誤字になります。
(誤)RFC4706
(正)RFC4306
(誤)RFC4706
(正)RFC4306
5. Posted by syo@管理者 2023年01月18日 14:14
コメントありがとうございます。非常に高度な内容で大変勉強になります。
Yamahaの heartbeat ですが、Yamaha 側で ikev2 を選択すると、そもそも heartbeat は利用できず、RFC4306で動作するようです。
それがご指摘の通りで、結果的に利用できていたようです。
http://www.rtpro.yamaha.co.jp/RT/manual/rt-common/ipsec/ipsec_ike_keepalive_use.html
> その他、 IKEv2 で対応していない方式 ( 書式 ) が設定されている場合は、代替方式として RFC4306 で動作する。
yamaha 同士でも標準の DPD を利用した方がいいように思いましたが、なぜこうなってるのでしょうか。
ちなみにNEC-AWSとのVPNを別でやったのですが、このときは DPD 設定のミスでよく切れており、再接続されないトラブルに見舞われていました。
このときは知識不足を痛感しました。
ネットワークモニターは正直私の知識レベルではコンフィグが複雑になりすぎる感じがしてしまい利用していません。最近はあまりNEC触ってないのですが、今度触る機会があったら積極的に利用してみたいと思います。
Yamahaの heartbeat ですが、Yamaha 側で ikev2 を選択すると、そもそも heartbeat は利用できず、RFC4306で動作するようです。
それがご指摘の通りで、結果的に利用できていたようです。
http://www.rtpro.yamaha.co.jp/RT/manual/rt-common/ipsec/ipsec_ike_keepalive_use.html
> その他、 IKEv2 で対応していない方式 ( 書式 ) が設定されている場合は、代替方式として RFC4306 で動作する。
yamaha 同士でも標準の DPD を利用した方がいいように思いましたが、なぜこうなってるのでしょうか。
ちなみにNEC-AWSとのVPNを別でやったのですが、このときは DPD 設定のミスでよく切れており、再接続されないトラブルに見舞われていました。
このときは知識不足を痛感しました。
ネットワークモニターは正直私の知識レベルではコンフィグが複雑になりすぎる感じがしてしまい利用していません。最近はあまりNEC触ってないのですが、今度触る機会があったら積極的に利用してみたいと思います。
6. Posted by s-tech 2023年01月19日 21:11
承知致しました。
ヤマハ系ですが、一般の他社メーカーの標準の基準をデフォルトでは選択していないメーカーでしたので、
IKEV2-IPSECで運用する場合にですが、一般の他社ですが、
シスコ系では、Ping-ECHO方式、DPD方式
アライド系では、Ping-ECHO方式、DPD方式
富士通系では、Ping-ECHO方式、DPD方式
になっていますが、
IKEV1を採用する場合には、その死活監視の機能は汎用性・柔軟性があるので、他社メーカーの組み合わせの場合には、却ってIKEV1-IPSECの方が良い場合あるとのことです。
ちなみに、ヤマハ系のDPD方式は、IKEV2での動作をさせる場合には、RFC3706規格からRFC4306に独自に委譲するようになっています。
よって、NECとヤマハの組み合わせの死活監視の場合にですが、NEC側のデフォルトでは、IKEV2のDPD死活監視の機能は停止になっていますが、対向側より何らかの疎通が有った場合に、その疎通の情報に対して、SNMP応答レベルでIKE-SAを返すようになっているとのことです。
NEC側でのヤマハとの組み合わせでのPing-ECHO返す場合には、ネットワークモニター監視にて、Ping-ECHOの返信をする形になります。
あと、ヤマハ系で未実装な機能で、他社では実装している機能として、IKEV2-IPSECの仮想トンネル内の仮想MTU、MSSの部分ですが、WAN機能とIKE-SAの暗号化レベルによって、動的にMTUとMSSが設定されるようになっていますが、そのIPSECのChild-IKE、Child-SAの暗号化パケットの部分もMTUとMSSの影響を受けて、IPSECトンネルの通信がうまくいかない部分があるのですが、その機能を「IPSECのプリフラグメント機能」と言っていますが、
そのIKE-SAのパケットをIPSECの疎通の前にてフラグメント処理をさせて、IPSECトンネルの接続に影響を与えない設定の部分が、ヤマハ系では割愛されているようです。
よって、ヤマハ系の対応の場合には、IKEV2-IPSECのMTUとMSSをあえて少なめに手動設定をして、フラグメント対応するケースを推奨しているとのことです。
ヤマハ系ですが、一般の他社メーカーの標準の基準をデフォルトでは選択していないメーカーでしたので、
IKEV2-IPSECで運用する場合にですが、一般の他社ですが、
シスコ系では、Ping-ECHO方式、DPD方式
アライド系では、Ping-ECHO方式、DPD方式
富士通系では、Ping-ECHO方式、DPD方式
になっていますが、
IKEV1を採用する場合には、その死活監視の機能は汎用性・柔軟性があるので、他社メーカーの組み合わせの場合には、却ってIKEV1-IPSECの方が良い場合あるとのことです。
ちなみに、ヤマハ系のDPD方式は、IKEV2での動作をさせる場合には、RFC3706規格からRFC4306に独自に委譲するようになっています。
よって、NECとヤマハの組み合わせの死活監視の場合にですが、NEC側のデフォルトでは、IKEV2のDPD死活監視の機能は停止になっていますが、対向側より何らかの疎通が有った場合に、その疎通の情報に対して、SNMP応答レベルでIKE-SAを返すようになっているとのことです。
NEC側でのヤマハとの組み合わせでのPing-ECHO返す場合には、ネットワークモニター監視にて、Ping-ECHOの返信をする形になります。
あと、ヤマハ系で未実装な機能で、他社では実装している機能として、IKEV2-IPSECの仮想トンネル内の仮想MTU、MSSの部分ですが、WAN機能とIKE-SAの暗号化レベルによって、動的にMTUとMSSが設定されるようになっていますが、そのIPSECのChild-IKE、Child-SAの暗号化パケットの部分もMTUとMSSの影響を受けて、IPSECトンネルの通信がうまくいかない部分があるのですが、その機能を「IPSECのプリフラグメント機能」と言っていますが、
そのIKE-SAのパケットをIPSECの疎通の前にてフラグメント処理をさせて、IPSECトンネルの接続に影響を与えない設定の部分が、ヤマハ系では割愛されているようです。
よって、ヤマハ系の対応の場合には、IKEV2-IPSECのMTUとMSSをあえて少なめに手動設定をして、フラグメント対応するケースを推奨しているとのことです。
7. Posted by s-tech 2023年01月19日 21:11
AWSとIXルーターの接続ですが、DPDの設定の場合には、両端ともにDPDの設定が必要ですが、
AWSのVPCゲートウェイのOSの出来があまり良くないため、ケースバイケースにて、AWSトランジットゲートウェイ方式の接続、若しくは他社のVPNサーバを用意して、L2延伸接続をした方が良い場合あるとのことです。
その他社のVPNサーバを採用しました場合には、VPCゲートウェイ側は、NAPTポート転送にて、VPC-EC2の仮想サーバ側にVPNサーバソフトウェアを適用して、そのVPNサーバ間との接続の方が、ヤマハとNEC、富士通、シスコのマルチ接続の方法が採れるかと思います。
例 Packetix-VPN、SoftEther-VPN
ご質問の件 「yamaha 同士でも標準の DPD を利用した方がいいように思いましたが、なぜこうなってるのでしょうか。」
ですが、恐らく当初はヤマハのみの対応を想定しており、ドラフト仕様にて機能実装後に、規格として認められたのがDPD方式だったからでしょうね。
AWSのVPCゲートウェイのOSの出来があまり良くないため、ケースバイケースにて、AWSトランジットゲートウェイ方式の接続、若しくは他社のVPNサーバを用意して、L2延伸接続をした方が良い場合あるとのことです。
その他社のVPNサーバを採用しました場合には、VPCゲートウェイ側は、NAPTポート転送にて、VPC-EC2の仮想サーバ側にVPNサーバソフトウェアを適用して、そのVPNサーバ間との接続の方が、ヤマハとNEC、富士通、シスコのマルチ接続の方法が採れるかと思います。
例 Packetix-VPN、SoftEther-VPN
ご質問の件 「yamaha 同士でも標準の DPD を利用した方がいいように思いましたが、なぜこうなってるのでしょうか。」
ですが、恐らく当初はヤマハのみの対応を想定しており、ドラフト仕様にて機能実装後に、規格として認められたのがDPD方式だったからでしょうね。
8. Posted by s-tech 2023年01月19日 21:24
ちなみに、当方のIKEV2-IPSECでは、IPV4グローバルIP、IPV6-DDNSどちらのパターンも、
IKEV2-IPSECの接続は出来ておりますが、一部、どうしてもIKEV2のリアル監視の部分にて、ヤマハとNECの
IPSECのIKE、SAの交換がうまくいかなくなるケースがあり、IKEV1との違いにて、通信状況の甲状腺を独自に維持する
機能を網羅したため、突然回線が切れたり、パケットロスが起きると、SAが消去されないまま接続状態になる現象が、特定の環境にて出ており、IKEV1とIKEV2の混在にしたケースも御座います。
IKEV2-IPSECの接続は出来ておりますが、一部、どうしてもIKEV2のリアル監視の部分にて、ヤマハとNECの
IPSECのIKE、SAの交換がうまくいかなくなるケースがあり、IKEV1との違いにて、通信状況の甲状腺を独自に維持する
機能を網羅したため、突然回線が切れたり、パケットロスが起きると、SAが消去されないまま接続状態になる現象が、特定の環境にて出ており、IKEV1とIKEV2の混在にしたケースも御座います。