2021年8月19日 / 最終更新日時 : 2022年8月1日 takai AWS

AWS拠点間VPNルーター移設ではまったお話

とらくらのインフラエンジニア、takaiです。
今回、AWSの拠点間VPNを収容しているルーターの移設でトラブルが発生したため、経緯を整理したいと思います。

ネットワーク構成

前提となるネットワーク構成は下記の通り。

移設前

・回線はFlet’s光を使用(拠点は関東)
・RTX1210

LAN1：各端末を配置
LAN2：回線を収容(PPPoE)
LAN3：RTX1200のLAN2を接続

・RTX1200

LAN1：各端末を配置
LAN2：RTX1210のLAN3に接続(NAT)
LAN3：未使用

・IPv6はルーティングせず、IPv4のみを使用
・RTX1200にてAWSの拠点間VPNを構成

移設後

・回線はNuro Biz(アクセスス タンダード)を使用(拠点は関西)

・RTX1200

LAN1：各端末を配置
LAN2：回線を収容
LAN3：別セグメントを収容

・IPv6はルーティングせず、IPv4のみを使用
・RTX1200にてAWSの拠点間VPNを構成

移設時想定作業

移設に際して、想定した作業は下記の通り

RTX1200の設定変更

①LAN2のIP設定、Default Route、DNSなどをNuro Biz用に修正

AWSの設定変更

②接続元のIPが変更となるため、[カスタマーゲートウェイ]の新規作成
③[サイト間のVPN接続]で[カスタマーゲートウェイ]紐づけ設定の変更
④旧[カスタマーゲートウェイ]の削除

移設作業

RTX1200で①の作業は問題なく終了し、配下端末からのインターネット接続についても無事に行えました。

引き続きAWSにて②以降の作業を実施、②③の作業完了後、RTX1200を再起動。

RTX1200ではAWS接続用VPNのtunnel 2本共にUP状態なのですがAWS側で見ると２本ともステータスが「ダウン」となっており通信ができません。

AWS側ではステータスは「ダウン」ですが、詳細では「IPSEC IS UP」となっており、VPNトンネルは張れているが、bgpによるルーティング情報も取得できておらず、通信が通らない状態でした。

 

Nuro biz回線を使用したAWSでの[サイト間のVPN接続]の情報はインターネット検索をしても情報が少なく、[カスタマーゲートウェイ]を再度作成し直したり、RTX1200の設定値を変更したりしても状況は改善しませんでした。

最後に、[サイト間のVPN接続]の定義自体を作成し直し、RTX1200へ新しいVPN情報を適用したところ、AWS側でもステータスが「アップ」になり、BGPによる経路情報も受け取れて無事にインスタンスと通信が行えるようになりました。

これで対応終了となったのですが、翌日念のため状況を確認したところ、VPN接続が2セッション共に切れており、再接続していませんでした。
当然BGPの経路情報もVPNが切れているので降ってきていません。

時間的には作業完了後、それほど時間を空けないタイミングで切断していたようです。

通常ではキープアライブの設定があるため、VPNだけが切断することはあまりない事と、万が一切断されても自動で再接続するはずなのに切断されたままとなっていますので何かがおかしいという事だけわかります。

障害切り分け

まず、RTX1200にてAWS向けVPN Tunnel IF 2本のSA削除を行いましたが再接続しませんでした。
次にRTX1200を再起動したのですがこちらも再接続しませんでした。
大抵はこれで復旧or仮復旧するのですが今回は復旧しません。

RTX1200のSYSLOGを確認してみるとSAの鍵交換のタイミングでVPN　TunnelがDownしてそのまま切れているようです。

再度、[サイト間のVPN接続]の定義を作成し直し、RTX1200へ新しいVPN情報を適用したところ、VPNがアップとなり通信できるようになりましたが、また時間が経つとVPNが切断されて再接続せず、RTX1200でSAの削除や再起動を行っても再接続できなくなりました。

従って再現性はあるようです。

AWS側のログ確認はできないので、RTX1200のログから原因を推測することになるのですが、明確な障害と思しきエラーが出力されていない事から、MTU/MSSの設定を疑うことになりました。

RTX1200で設定しているMTU/MSSの設定値が接続回線の仕様上の設定値よりも大きい場合、パケットのフラグメントが発生し、速度低下やVPN切断などの不具合が発生することがあります。

現状のRTX1200のMTU設定は初期値のままなので、下記メーカーサイトに記載の値(RTXシリーズの初期値)となります。

9.1.4 インタフェースの MTU の設定 (yamaha.co.jp)

念のため、Nuro biz 回線を収容しているLAN2のMTUを調べます。
RTXのLAN IFの初期値は1500となっていますが、回線収容の場合はこの値よりも小さくなる場合がほとんどです。

例えば、NTTのFlat’ｓ光の場合、V6Plus接続では1460バイト、PPPoE接続の場合1454バイトとなります。

Nuro光(家庭向け)の場合は1500バイトのようです。

MTUとMSSの値は使用する回線環境(通信経路によっても値が変わります)によって異なるため、実測するのが一番確実です。

MTUを調べる場合はpingコマンドにオプション指定をして使用します。

Windowsの場合は下記記載となり、例では指定したIPアドレスに対して、1回だけ(-n 1)、フラグメントを禁止(-f)して、1252バイトのパケット(-l 1252)を送る、という意味になります。

ping -f -l 1252 -n 1 IPアドレス

まず最初に通常通りオプションをつけずにPingを行い、問題なく返答があることを確認します。

その上で、(-l)で指定する値を調整し、Ping応答がある最大値を探します。

下記の場合、指定したサイズ(1350バイト)が大きすぎるためPingに失敗しています

C:\Users\Administrator>ping -f -l 1350 -n 1 xxx.xxx.xxx.xxx

xxx.xxx.xxx.xxx に ping を送信しています 1350 バイトのデータ:
パケットの断片化が必要ですが、DF が設定されています。

xxx.xxx.xxx.xxx の ping 統計:
パケット数: 送信 = 1、受信 = 0、損失 = 1 (100% の損失)、

指定するサイズを1250バイトに変更したところ、Pingが通りました

C:\Users\Administrator>ping -f -l 1250 -n 1 xxx.xxx.xxx.xxx

xxx.xxx.xxx.xxx に ping を送信しています 1250 バイトのデータ:
xxx.xxx.xxx.xxx からの応答: バイト数 =1250 時間 =15ms TTL=127

xxx.xxx.xxx.xxx の ping 統計:
パケット数: 送信 = 1、受信 = 1、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 15ms、最大 = 15ms、平均 = 15ms

この場合、フラグメントされずに通信できるパケットのサイズは1250～1350バイトの間という事になりますので、1250バイトから10バイトずつ値を上げていきます。

すると、1260バイトで再びPingが通らなくなりましたので、1250～1260バイトの間で同様に調べます。

C:\Users\Administrator>ping -f -l 1260 -n 1 xxx.xxx.xxx.xxx

xxx.xxx.xxx.xxx に ping を送信しています 1260 バイトのデータ:
パケットの断片化が必要ですが、DF が設定されています。

xxx.xxx.xxx.xxx の ping 統計:
パケット数: 送信 = 1、受信 = 0、損失 = 1 (100% の損失)、

そうすると1252バイトの時にPingが通り、1253バイトではPingが通らないことがわかりました。

C:\Users\Administrator>ping -f -l 1252 -n 1 xxx.xxx.xxx.xxx

xxx.xxx.xxx.xxx に ping を送信しています 1252 バイトのデータ:
xxx.xxx.xxx.xxx からの応答: バイト数 =1252 時間 =15ms TTL=127

xxx.xxx.xxx.xxx の ping 統計:
パケット数: 送信 = 1、受信 = 1、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 15ms、最大 = 15ms、平均 = 15ms

C:\Users\Administrator>ping -f -l 1253 -n 1 xxx.xxx.xxx.xxx

xxx.xxx.xxx.xxx に ping を送信しています 1253 バイトのデータ:
パケットの断片化が必要ですが、DF が設定されています。

xxx.xxx.xxx.xxx の ping 統計:
パケット数: 送信 = 1、受信 = 0、損失 = 1 (100% の損失)、

この結果から、MTUサイズは1252バイトですね、とはなりません。。

Pingパケットを送信する場合、1252バイトにIPヘッダとICMPヘッダが付加されているため、このヘッダ分のサイズを加算する必要があります。
IPヘッダが40バイト、ICMPヘッダが8バイトなので、MTUサイズは1300バイトとなります。

MSSについては、MTUサイズからIPヘッダとTCPヘッダのサイズを引いたものになります。
IPヘッダが20バイト、TCPヘッダが20バイトの計40バイトを引いて1260バイトとなります。

という事で、MTUが1300バイト、MSSが1260バイトとわかります。
基本的にMTUとMSSの設定値の関係は MTU > MSS となります。

今回はNuro bizのデフォルトゲートウェイに対して上記方法でPingを打ってみたところ、LAN2に設定すべきMTUサイズは1480バイト、MSSは1440バイトという事がわかりましたので、この値をRTX1200に設定して問題なく通信が行えることを確認します。

ip lan2 mtu 1480
ip lan2 tcp mss limit 1440

そのうえで、VPNに設定するMTU,MSSを調べます。
VPNやV6Plus、PPPoEでで使用するTunnelやppで指定するMTU、MSSの値は先に調べたLAN2のMTU/MSS値よりも小さくなります。

VPN等の両値の例として下記NECのサイトにある「Q.1-8」に記載があります。

IPsec/IKE : FAQ : UNIVERGE IXシリーズ | NEC

トラブル時のAWSと接続するVPN Tunnel に設定するMTU値はAWSからダウンロードしたYamaha RTX用サンプル設定ファイル記載の下記の値となっています。(2021/08/16現在)

ip tunnel tcp mss limit 1379

この時点で、Tunnelに設定されているMSSの設定値がRTXのTunnel if のMTU初期値(1280バイト)よりも大きいことがわかります。

AWSとのVPNが接続された状態でEC2内のインスタンスに対してPingを行い、LAN2で調べた時と同じようにMTU/MSS値を調査します。

MSSがAWSが指定している1379バイトで問題ないかを確認する為にはTunnelのMTUを1419以上に設定してからVPN接続したうえで、Pingコマンドで確認する必要がありますが、今回はRTXのTunnel ifのMTU初期値である1280バイトでフラグメントが発生しないことを確認できたので、初期値のままとして明示的に下記設定を入れました。

ip tunnel mtu 1280
ip tunnel tcp mss limit 1240

障害復旧

本記事執筆時点で設定投入後、半日以上が経過していますが切断は起きておらず、インスタンスに対しての通信も問題ない為、もうしばらく様子を見る必要はありますが、事象は無事収束したものと思われます。

RTXの場合、MSSの設定に関してはAutoの設定が可能ですので、MTUのみ明示的に設定を行い、MSSについてはAutoの設定でも問題ないかもしれません。

ip tunnel tcp mss limit auto

あとがき

今回、ルーターの移設という事で、[カスタマーゲートウェイ]に定義している接続元のIPアドレスが変わるだけの認識でおり、[サイト間のVPN接続]の定義に紐づけている[カスタマーゲートウェイ]の情報だけを差し替えれば問題なくVPNが張れると思っていましたが、使用回線業者が変わったことで、結果的には回線のMTU/MSSの設定値も見直す必要がありました。

MSSについてはAWSから取得できる設定ファイルの値を鵜吞みにせず、各オンプレミス側の環境要件に照らし合わせて適時修正する必要があります。

原因の特定を困難にした一因として、VPN切断後の再接続が行えない事象が発生しましたが、RTX1200側でのMSS設定値がRTXのTunnel IF の MTU初期値より大きかった事で、パケットのフラグメントが発生してしまい、VPNトンネルを維持する為に必要なSA等の情報が破壊された事でAWS側の[サイト間のVPN接続]での処理で不整合を起こし、いわゆるTunnel崩壊が発生し、AWS側で以後の再接続要求を処理できなくなってしまったものと推測されます。

両拠点ともオンプレミスの場合は双方のルーターのログを確認することで原因の調査や特定がもう少しスムーズにいく事が多いのですが、今回は接続先がクラウド環境であったため、AWS側のログが確認できず、少し時間を要してしまいました。

最短でAWSを習得したい方におすすめ！
オンラインスクール「とらくら」

当ブログを運営しているオンラインスクール「とらくら」では、AWSを扱うために必要不可欠な主要サービスの知識を、理論学習だけでなく、環境構築をハンズオン形式で実践できるカリキュラムを行なっております。

随時、個別の無料説明会を開催しており、講座内容や料金、本講座を受講するメリット・デメリットについてはもちろん、業界に精通しているからこそできるエンジニアのキャリアプランや業界の情勢などを、ざっくばらんにお話します。

些細なことでも、お気軽にご相談ください。







インフラ構築コース、受講生募集中！AWS WordPress環境構築コース、受講生募集中！






投稿者プロフィール
takai



takai

＜インフラエンジニア＞

■ 家電量販店での商品販売や配送、設置、テクニカル対応等の経験と知識を活用し、Windows環境を主としてオンプレミスの端末、サーバー、ネットワーク構築・運用経験豊富なエンジニア。

■ 広く浅くDIY、電子工作、車、カメラ、動画撮影など多岐色々なことに興味を持ち、自宅に簡易な検証環境を構築して日々コンピュータと戯れている逸般人






関連記事
    

  1. [EC2]WindowsServer2022をAMIからリストアしてみた
    2. 

  2. クラウドサービスの雄AWSとは
    3. 

  3. ワンストップで完結！楽々サーバ構築
    4. 




		
		

	


		
AWS
前の記事
Amazon EC2 の課金で注意すべきポイント
2021年8月18日

		
AWS
次の記事
AMIからインスタンスを作成する際の注意点
2021年8月19日

		

				
			


	
	
	
	
	
		


		
			
ブログカテゴリー
AWS、インフラ
ブログタグ
AWS、VPN
メンバーカテゴリー
takai

		

	
	
			
		

	
		
		
		
			

		
コメントを残す 
メールアドレスが公開されることはありません。 * が付いている欄は必須項目です