NGN VPN(IPoE)のフラグメントについて調べてみた
2017年08月29日 火曜日
CONTENTS
経緯
ある日のこと、NGN VPNをご提供してるお客様からあるご質問が届く。
“NGNを使ったVPN環境の場合、クライアント間の通信はどれくらいまでフラグメントせずに通るの？”
・・・・・言われてみればよくわからない。
エンジニアとしてそれくらい知っておけよという声は無視して、ドキュメントを確認しつつ、実際に環境を構築して検証してみることにした。
ちなみに、NGNってなんだろうって人は、とりあえず「網内折り返しだから速いんだよ」というフレーズを覚えておくとある程度までの人には、出来る人っぽくみえます。
検証環境構成図
早速、検証環境を以下の内容で構築してみた。
※ご自身で検証環境を構築する際にはフレッツ・v6オプションの契約をお忘れなく。
| 項目 | 自宅 | 会社 |
|---|---|---|
| 回線 | NTT西日本 フレッツ・光ネクスト マンション・スーパーハイスピードタイプ隼 | NTT西日本 フレッツ・光ネクスト ファミリー ハイスピードタイプ |
| interface | MTU Size：1600byte(LAN0,LAN1) | |
| L2TPv3 | L2TPv3 over IP(プロトコル番号：115)
Cookie：4byte |
|
| IPsec | Tunnel Mode：Transport
ESP Encription：ESP-AES-128/192/256/ ESP Integrity：ESP-SHA-HMAC AH Integrity：none |
|
検証方法
まずは、NGNの資料をネットからゲットして、MTU Sizeを確認だ！
えーと、なになに。
IP通信網におけるIPv6(IPoE)通信のMTUの値は1500byte です。
IP通信網がMTUの値を超えるパケットを受信した場合、IP通信網はパケットを破棄します。
<参考文献>
東日本電信電話株式会社 『IP通信網サービスのインタフェース 第三分冊（第35版）』、20頁(https://flets.com/pdf/ip-int-flets-3.pdf)
なるほど、1500byteか。よし、お客様へお伝えして終了だ！
mission complete!
・・・って記事を投稿しようもんなら、叩かれること必至なので、当初の予定どおりエンジニアっぽく、きちんと検証してみる。
①検証用PC01(192.168.0.1)⇔検証用PC02(192.168.0.2)の間でpingを巧みに駆使し、icmp Payload sizeを変えながら撃ちまくる。
②検証用PC02でWireSharkを起動しておき、vpn-mtu02のLAN1インターフェースをキャプチャし、通信状況をウォッチ。
※うんうん、完璧な検証じゃないか。
VPNなし(暗号化なし)※ルータ間
まずは暗号化なしの状態で、ルータ間での疎通可能なMTU Sizeをチェックしてみる。
えーと、MTU Size1500byteってことはルータからはicmp Payload size1452byte(1518-18-40-8)でping撃ったらいいのか。
| Ethernet Header | IPv6 Header | ICMP Header | ICMP Payload | FCS |
| 14 | 40 | 8 | 1452 | 4 |
| 1518byte-18byte=MTU Size 1500 | ||||
うむ、想定通りMTU Size 1500byteはちゃんと疎通できるな。
よし、次はMTU Size 1501byteで実験(icmp Payload size 1453byte)
おお、通らない！資料通りじゃないか！(そりゃそうだ
NGNでは、MTU Size 1500byteまで疎通が確認できたよ。
NGNでは、MTU Size 1501byteからはパケットが破棄されるよ。
L2TPv3(L2TP over IP)
さて、NGNでのMTU Sizeの上限が1500byteであることは、資料やルータ間でのpingによる検証からわかったので、NGN VPNを利用する時にはMTU Size1500byteでNGNにデータを送出するようにルータ側で設定するとして、実際にクライアント送出するパケットで、フラグメントしないで送れるMTU Sizeの上限はどれくらいなんだろうか。
まずはL2TPv3単体でVPNを構築した場合を検証してみよう。
と、言ってはみたものの、L2TPv3におけるデータ通信のパケット構造がわからない。
まずはWireSharkを使い構造解析をしてみるために、検証用PC01から検証用PC02へのpingをキャプチャしてみる。
EtherヘッダとIPヘッダはOKとして、L2TPv3ヘッダを確認してみる。
最初の4byte(※赤枠)がSession IDで、次の4byte(※青枠)がCookieなのかな？
実際にvpn-mtu01上でShow status l2tpを入力し確認してみる。
Remote Session ID：49057に、Remote Cookie：418990172か。
Remote Session IDはキャプチャしたパケットの内容と一致してるとして、Remote Cookieはいったい・・・。
キャプチャしたパケットの値を16進数から10進数に変換したらどうだろう。
18f9485c(16進数)⇒418990172(10進数)
一致した！
というわけで、L2TPv3 Headerは8byteと・・・。
ん？キャプチャしたパケットに不思議な表記があるぞ。
なぜCisco HDLCが・・・。
取り合えず、L2TPv3 Headerの次に来る内容を調べてみよう。
ふむふむ、宛先MACアドレス、送信元MACアドレスと続くのか。
てことは、34：95：db：0a：F6：18が宛先MACアドレスの値ならヘッダに異常はないとみていいわけだな。
早速、宛先である検証用PC02のMACアドレスをチェック！
お！一致した。
なぜCisco HDLCの表記があったかは、一旦置いといて、ここまででわかった情報をもとに、クライアントから、フラグメントしないで送出できるMTU Sizeの上限を考えてみよう。
| Ethernet Header | IPv6 Header | L2TP Session Header | Remote Cookie | Original Data Payload | FCS |
|---|---|---|---|---|---|
| 14 | 40 | 4 | 4 | 1452 | 4 |
| 1518byte-18byte=MTU Size 1500byte | |||||
えーと、L2TPv3のパケット構造はこんな感じかな。
続けてOriginal Data Payloadの中身もチェック。
| Original Data Payload(detail) | |||
|---|---|---|---|
| Ethernet Header | IPv4 Header | ICMP Header | ICMP Payload |
| 14 | 20 | 8 | 1410 |
| 1452byte-14byte=MTU Size 1438byte | |||
こんな感じかな。
てなわけで、実際にicmp Payload size1410byteでpingを撃って確認してみよう。
pingによる疎通はOK。
NGNに送出しているMTU Sizeはどうだろう。
お、MTU Size 1500byte(1518btyte-18byte=1500)になってる。
※画像では、Length 1514と表記されていますが、WireSharkではFCS抜きの値が表示されるため、Lengthにプラス4byteして計算しています。
念のためicmp Payload size1411byteでもpingを撃ってみよう。
うん、通らない。
L2TPv3のみの環境では、MTU Size 1438byteまではフラグメントせずに疎通が確認できたよ。
L2TPv3+IPsec
最後にL2TPv3+IPsecでの確認してみる。
またまたWireSharkを使って今度はIPsecのパケットをキャプチャして解析してみるよ。
あれ？・・・肝心な部分が暗号化されてて見えない(そりゃそうだ
調べてみるとWireSharkはIPsecの復号化もできるらしい。
プロトコル設定画面からESPの復号化に必要な情報としては、以下の情報が必要みたい。
Protocol
Src IP
Dest IP
SPI
Encryption
Encryption Key
Authentication
Authentication Key
復号に必要な情報がわかったところで、早速ルータから情報取得してみよう。
うん、この情報(図の赤枠)があれば、復号できそうだ。
WireSharkに情報を入力して・・・と。
こんな感じかな。
さてさて、再度キャプチャしてみますか。
おおお！復号化の情報を入力したSAのパケットが見えるようになってる！
それでは、あらためてクライアントから、フラグメントしないで送出できるMTU Sizeの上限を考えてみよう。
| Ethernet Header | Original IPv6 Header | SPI(ESP Header) | Sequence(ESP Header) | ESP-AES(IV) | L2TPv3 Header + Original Data Payload | ESP Pad(ESP-AES) | Pad length(ESP Trailer) | Next Header(ESP Trailer) | ESP-SHA-HMAC ICV (ESP Trailer) | FCS |
|---|---|---|---|---|---|---|---|---|---|---|
| 14 | 40 | 4 | 4 | 16 | 1422 | 0 | 1 | 1 | 12 | 4 |
| 1518byte-18byte=MTU Size 1500byte | ||||||||||
えーと、IPsecのパケット構造はこんな感じかな。
続けてL2TPv3とOriginal Data Payloadの中身もチェック。
| L2TPv3 Header | Original Data Payload(detail) | ||||
|---|---|---|---|---|---|
| Remote Session ID | Remote Cookie | Ethernet Header | IPv4 Header | ICMP Header | ICMP Payload |
| 4 | 4 | 14 | 20 | 8 | 1372 |
| 1422byte-8byte-14byte=MTU Size 1400byte | |||||
こんな感じかな。
てなわけで、実際にicmp Payload size1372byteでpingを撃って確認してみよう。
pingによる疎通はOK。
NGNに送出しているMTU Sizeはどうだろう。
お、MTU Size 1500byte(1518btyte-18byte=1500)になってる。
※画像では、Length1514と表記されていますが、WireSharkではFCS抜きの値が表示されるため、Lengthにプラス4byteして計算しています。
念のためicmp Payload size 1373byteでもpingを撃ってみよう。
うん、通らない。
L2TPv3+IPsecの環境では、MTU Size 1400byteまではフラグメントせずに疎通が確認できたよ。
まとめ
- NGN(IPv6 IPoE)では、MTU Size 1500byteまで疎通が確認できたよ。
- NGN(IPv6 IPoE)では、MTU Size 1501byteからはパケットが破棄されるよ。
- L2TPv3のみの環境では、クライアントから送出されるMTU Size 1438byteまでのパケットはフラグメントせずに疎通が確認できたよ。
- L2TPv3+IPsecの環境では、クライアントから送出されるMTU Size 1400byteまでのパケットはフラグメントせずに疎通が確認できたよ。
以上
・・・・・・・・・・・・・・あ、自己紹介忘れていた。
IIJ 沖縄営業所でエンジニアをしている「やすゆき」です。
記事の執筆は初なので、見辛い部分もあったかと思いますが、
この記事を最後まで読んでいただいた画面の前のあなたに感謝！
